 Howdy. All right, thanks. All right, so this is a pretty big topic for 10 minutes, but we'll see how much we can cover together. So here's what we're going to talk about. I think when most people think about WordPress and media, they usually think about the media gallery, which looks something like this. So we're going to be talking a little bit more about what happens before your image ends up there. So when it's kind of spinning like this inside Gutenberg and it's uploading, or you drag it into the media modal. And so we're going to be talking about sort of that process that happens in the middle between there. So after you drag an image when you're waiting for it, WordPress uses Plupload to handle that upload. And Plupload handles all that sort of middleware between your browser and the image itself and WordPress. But it doesn't do anything with the image itself. It just serves the full size image directly to WordPress. And then visually, it lands it in the media gallery that we saw earlier. But what's it doing while it's uploading? The main thing that takes the most time are sizes. And what I mean by that are different resizes of the same image. By default, the ones that are created by WordPress are thumbnail, small, medium, medium, large, large, and full. The full one is just the entire image that gets uploaded. And mainly what this means is different sizes in resolution. And so that's mainly for both caching, so that WordPress already has an image of that size to serve. And also so that it can provide your browser with a series of sizes for responsive images with source set so that your browser can pick the image that's most appropriate for the user in that particular instance. Other folks also, so plugins and themes, can add additional sizes to the ones that WordPress generates for art direction or for different resolution reasons. So if you would want an image to be both presented as a logo, but also somewhere else in your site and maybe like an About page, you could use the same initial original image and have it just cropped a little bit differently automatically by WordPress at this time. Underneath, now this is a super light sort of description of the way that this works, so pardon me with that. But there's a function that is called WP Generate Attachment Metadata. And it does a lot of processing of the image. But one of the things that it has is a big, long call inside to a function called multi-resize, which takes the image and then does a big set of resizes just in succession, just in order, all of the sizes, all at once. And this is actually an instance of WP Image Editor if you're interested in a little bit more of the details rather than being a method. But this is basically how that works. How it happens, so WP Image Editor, the actual thing, then calls either a magic or GD by default. And although if you're a developer and you want to provide a different image back end to WordPress to be able to do the sizes a different way, you can totally also do that. So by default, the engine that's used is a magic, which uses image magic if you do a lot of image manipulation. Some folks get asked pretty frequently why this is used as the default in core and why this was chosen. The main reason is that, especially when it was first added, it's kind of the most universally available solution across different hosts that I know of, even still, to be able to manipulate images and do it with detail. GD allows you to do resizes, for instance. It doesn't allow you to go more in depth. So some of the things that we were able to add as a community to WordPress by starting to use a magic. So if your host supports a magic, this is a good thing to check. You can check it with the new site health feature in WordPress. You can go and it'll tell you whether it's supported or not by your host if you want to check later. One of them is color profiles. And I hope this shows up well on the screen. So if you have a custom profile for an image that isn't just sRGB and you upload it, it might look something like this. I think this one was an Adobe RGB image that I uploaded to GD. And GD is unable to save color profiles. So your image might, the resizes, the other sizes might end up looking a little funny. However, if you used a magic with this exact same image, you'd end up with some colors that are a little bit more accurate for the original image. So that's one of the things it can do. We're also able to, in WordPress 4.5, reduce the sizes of image hugely. So the total size of images that your user will download from the sizes that are generated, we're able to go down up to 50%, because with a magic, we're able to be a lot more specific, both on what information stays in the image and also how the compression works. And we're able to do this without changing visually the way that it looks to users at all, which is pretty cool. Another thing that it allows you to do, and magic supports a lot more file types. So one of the things that it can do is handle, now, as of WordPress 4.7, so this is still a little bit ago, this is where the PDF thumbnails come from, so only a magic can handle that. And if you wanted to do other profiles, a lot of servers support a ton of different formats, I mean. A lot of servers support many, many different file formats with a magic, an image magic. And you can write code that will allow you to parse that. You're not blocked from doing so. From doing operations, basic operations on images for any file type that your system supports. So that's a thing that you can do, absolutely. Magic is also a bit kinder on resources, which takes us to the next part of the talk, limitations. So there are some limitations with the way that the system currently works. Maybe you've seen this before. I mean, I hope not all the time, but it's a thing that happens. There's been some work to avoid it. But the biggest problem with the way that images currently get generated is that they are all generated in one HTTP request. And as plugins and themes add more and more sizes, and also as images get larger, this becomes more and more likely to either time out or for your system to further the server that it's on to run out of resources. So if it does time out, right now, your original image will end up in your media library, the one that you uploaded, but none of the sizes will show up. And WordPress won't even know they exist. So that's kind of a problem. When we talk about resources, what I'm mainly talking about is processor time, which is in effect about the amount of time that you're just waiting to, if you want to think about it in memory, one of the things that's a little bit more difficult with GD when it's resizing images as far as resources go is that it requires that the entire image be uncompressed in memory while it's doing all of its operations. And magic does not. So if your host, especially if it's a shared host, supports a magic, then you're a lot more likely to have the request completed if you're using a magic. So that's another cool thing. And of course, as images get larger and larger, now we're seeing phone images be the size of what used to just be professional camera sizes and resolutions. It becomes more and more likely that you might run out of resources. So that's one issue. Another one is that it's not dynamic. So the reason that it's done the way that it is right now is because doing it in a dynamic fashion might take too much time to generate those images for all the users. And so especially with shared hosting, it's you're less likely to be able to have those sizes delivered on time and quickly to users. But it also makes it harder. So if you have just one page that needs a different size, for instance, you don't want to have to generate all those sizes for every single image that you upload. And so it's a little bit harder to get exactly what you want or just an image on demand. So the current state is not really the best state. All of this won't be fixed in WordPress 5.3. But let's talk about a few things that are on the roadmap. So the very first thing, and this is kind of the one I'm most excited about, is save state. So now as the different sizes get generated, so right now we're ready in course, assuming we don't end up the general disclaimer, these are things that I hope will be finished. But you never really know what bugs are going to come up during alpha, beta, and RC. So we'll see. But these are some things I really hope will end up in WordPress. This is one that has already landed in trunk. So it's kind of the most likely. So right now in trunk already, WordPress is able to save as it generates images into meta each of those images. And what that means basically is that each as WordPress is making those sizes, it remembers that it's already done it. Because previously it did not. So we're now able to add a feature to resume or detect that it has failed and then retry and not start from the beginning. Previously the only way for a user to really recover would be just to kind of keep uploading and kind of hoping it's going to work that time, which is really, really, really bad user experience. So I'm excited about this one. The next one is the idea of having sort of a gold master in and full changing what it means. So at the moment, you do basically have a gold master in that your, and what I mean by gold master is a file that is exactly the same as the original image that you uploaded. I think it's important to always have that uploaded on your site so that if in the future you need additional sizes or you're going to do something different with your site, you can, WordPress can create those images from the original source. So really, one example of that is when you're switching themes, the new theme might require different sizes in the original one. So it's really good to have that source that's there. But at the moment, the way that it works, you might have the source image served as just an image on the site if a device is requesting a resolution that is higher than the sizes that WordPress generates. And that's not ideal because your original image probably has some things inside it like thumbnails and data that makes the image large enough that you don't really want that to be served. So the idea is to change that. The next one is to add back. So many years ago, there were details on what HTTP error meant. Now you get no information. The idea is to add that back. There's a cool patch that fixes this from Ramon Finken. And I'm pretty excited about that. I'm hoping that can make it in. Another thing that's being discussed is to maybe add some more sizes. The large that is currently there isn't that large, the default WordPress size. And so often that also results in the full, makes it more likely that the full size is going to be served. So because we want to always serve the smallest image possible to users, this is something that is possible that we couldn't do before because we were worried about adding more sizes and making it more likely to fail for users. But it is now possible because WordPress can remember what it's done, essentially. If you want to see more details or are interested in helping out, which would be super great, you can check out this post from Andrew Oz about some important image tickets on make.wordpress.org slash core. Or also, there is a contributor day tomorrow. Feel free to come chat with me. I would love to help you get connected. And that is it. Does anyone have any questions? I have a question. It doesn't just have to be about images, too, yet. Can I ask you about coffee? That's also true. Can I ask you about coffee? Happy to chat about coffee. Good morning. I may have three questions. The first one. Yes. So by default, WordPress uploads images in multiple formats. So you have to have a similar image. Then WordPress creates, say, three or four sizes, right? Correct. So how do you stop that from happening? That's the first step. Because it's fancy. You just want a single size. And WordPress does multiple sizes. Because we talk about resizing all that. Sometimes your team could do that. Your team could resize. I mean, do it or pack it for you. I don't know. So second question is that. Well, can I answer the first one first? OK, sure. So yes, you can change it. I don't remember the filter name off the top of my head. But there is a filter that you can use in WordPress. And you can change what those sizes are. So absolutely, if what's best for your site is not that, then that's cool. I generally don't recommend that folks that don't have a team working on it do that. Because then that disables the, if you're not using either the sizes from your theme being generated or the default image sizes, then WordPress doesn't have anything to serve except for the original for responsive images. And so you lose all of that bandwidth savings that you would end up with if you disable it entirely and are using another method to have your responsive images needs sort of taken care of. But yes, absolutely, there's a filter. And you can disable it or add sizes or whatever you would like, for sure. So that comes to my second question. So WordPress, in my opinion, they handle images pretty poorly. So especially comes to loading big images and all that. So my question is that, what is your recommended? Like Google is using Wrappee formats and all that, right? So for speed loading and all that. So what's your recommended? I mean, if you just say a site that's hosting multiple images and all that, what is your recommended way of, I mean, what's the, what do you recommend to for speed loading for images in WordPress? I'm not sure I 100% understand the question. WordPress doesn't use WebP because it's not supported very widely across browsers. There has been talk about supporting it in the future and there's a patch that you can look at if you wanna try and use that on your site. Right now, I mean, most of my recommendations for sort of the general user would be, a lot of them are reflected in the way that WordPress handles images, but I'm not, so I'm not sure. What's the best way for, what's the best way to optimize WordPress in WordPress? Any recommendation for speed, for the speed in loading those images and what do you recommend? I guess, so there are various tools that you can use to sort of minify images more. In the general case, I have a hard time recommending any particular thing because I think everyone's site works a little bit differently. WordPress does its best to sort of make those images as small as it can right now. And I think as far as sort of general users go, I would recommend using WordPress the way that it's set up. But if you wanna go further and do more manual optimization of images then I think whatever is best for your site is whatever you recommend. I don't have any specific services. I don't have any specific services that I would recommend. How about CEO for images? I mean, do you recommend anything for CEO for images? For what, I'm sorry? SCO. For, oh. I am not an SCO expert, so I don't think I'm gonna, I don't think I'm qualified to answer that question while I'm sorry. Ask Ivan, okay. So later, look for Ivan, okay. Thank you for your questions, thanks Mike. All the more questions? Just one more, just one more, okay. Last one, okay, last one, last one. I'm sorry guys, I'm gonna give you a last one. Hi Mike. Howdy. So supporting WordPress, one of the challenges that I've always had is identifying unattached images. Yeah. And then kind of going back to the error that you were talking about the very beginning when you upload and you get that time out. So what's the best way to identify what those unattached images are? Because I've always found that the media library calls them to be unreliable. So how would you suggest trying, finding unattached images the right way when you're supporting users just because I've always found it to be very dodgy? Yeah, I don't think that there's a, I'm trying to remember if there's a good user interface option for that. I don't think there is a really good user interface option. I think you could probably do if I were supporting a user and needed to sort of mass fix a problem like that, I might look into making a WPCLI script or just running WPCLI and checking the meta on the images to see what they're attached to maybe. But yeah, I don't think that there's a good sort of end user, as far as I, if I'm remembering correctly, I don't think that there's a good like way to do it visually for users right now. Yeah, I would love to chat with you more about that specifically because there's a lot of conversation around how attachment should work in images and how they should be connected or not connected to posts in the future. So I would love to chat with you more about it. Thank you. Cool, thank you. Thank you. Thanks so much.