 Thank you, Rebel Voice. But welcome to Images on the Web of Past, Present, and Future with Adam Silverstein if you'll take it away. Awesome. Thank you so much. Thanks for having me. Thanks everyone for coming. I see people from all over, so that's kind of cool. And yeah, thanks for inviting me to come do this talk. This is actually the first part of this talk is going to be a redo of my talk at Workamp US this year, which is I'm just going to be digging into image formats on the web. And then that was a 15 minute lightning talk and I spoke really fast the whole time to try to squeeze it into 10 minutes or 15 minutes. And so I'm going to do it a little slower this time and hopefully you'll have questions for me. You know, please pop those in the chat or unmute or whatever. And then I also have some sort of extended stuff at the end about sort of more about how WordPress handles images that you upload and how your browser handles them and also kind of why we might want to care about images. So with that, I'm going to dig in. This is me, a developer relations engineer at Google. So I worked closely with Chrome DevRel, the content ecosystem we call it or the web you might call it. And just trying to work with developers, make developers live easier, educate people about the tools that Google provides like Chrome DevTools, Lighthouse, those kinds of things and feedback from the development community, especially the WordPress community back to those teams building those tools. And for the last kind of, I'm also closely involved in WordPress core and in the last year I've been super focused on images and performance in WordPress core. And this talk kind of comes out of that. So I'm going to talk about images on the web just in general. And then if we get to it, I'll talk about how WordPress and browsers handle images more particularly. And like I said, why it matters. So in terms of images on the web, they kind of have two groups. There's the legacy image formats I like to call them that we're all familiar with like GIF and JPEG and PNG. And then there's these modern image formats that are kind of coming down the line or are with us now that are offered these kind of new features. And we're going to get into why those are exciting and what they might mean for your website or for your web tools. So the legacy formats and by the way, all the images in this slide deck were created by Imogen, which is one of Google's internal text to image tools. Everyone's pretty excited about all these tools right now. But I, you know, just typed in prompts that somehow were funny to me and related to images like and performance like this dinosaur riding a tricycle. The GIF format's been around for 35 years, maybe almost 36 now, which is pretty amazing. Before we had GIF, we had ASCII art. I think that was like, you know, you still have that actually, like if you boot up a Linux machine, you'll probably see a tuxedo wearing penguin that's made of ASCII art. But GIF was 35 years ago, we had GIF and it's supported everywhere. You can use it in almost any place. You can use an image and it has animation, which was pretty exciting when it came out. It has transparency so you can put images over a background, which was also again kind of exciting for images. It had compression and lossless compression, meaning, you know, when you decompress an image, you got exactly what you started with. But it had a limited palette. It still has a limited palette, 256 colors. We tried to dither our images to make them better. Overall, that's kind of a limitation, I'd say, of GIF. And there were some issues with the compression. It's not really great at compression. And also there were licensing issues with GIF when it came out. A couple of large corporations held copyrights on the compression algorithm and that made the free software movement hesitant to rely on these formats, this format. And it actually like resulted in PNG coming along later. Also, people are uncertain how to pronounce it. Is it GIF? Is it GIF to this day? People are still debating this hotly. I'm sure everyone here has their own opinion about it. I'm going with GIF for the purposes of this talk. And also animation, like, is animated GIF really a good idea? Is that something you should have in an image format? Probably not. One of the really bad things about images with animation is that the compression happens frame by frame. So it tends to be very poor compared to a movie format where the compression is the differences between each frame. So if you convert a GIF into a movie and put it on your web page instead, you'll get like 10 times, 20 times the compression level. And since all browsers support movies, I really don't think animation belongs in image formats anymore. But at the time it was pretty exciting. Then along came JPEG 30 years ago. Also supported everywhere. Anywhere you can use an image, you can use a JPEG. It had lossy compression. This is a pretty big deal. Lossy compression, we take it for granted now, but when it came about, it was a very exciting feature. And part of that is the variable level of compression, right? So you can choose to compress an image a little bit and get a very high quality image, or you can go all the way down to a very huge amount of compression and get a low quality result. So that variability meant that you could actually sort of choose the appropriate compression for where that image was going to be used. And that was kind of a new thing that JPEG introduced. And the compression was great. The lossy compression can be up to 10 times versus the original image. So you can really get really nice quality images and load them without a lot of resources. It also had full accurate color. So 24 bit color with color profiles embedded in the image, which was amazing. Not perfect, but still amazing. It has progressive decoding. So that's where JPEGs can do that thing where they kind of start out blurry and then the details load in. So that's a great experience for users over a slower internet connection. They can get the sense of the image coming in well before the full image is loaded. But some downside, it's 30 years old. The compression is not really that great. The modern formats, as we'll see, do a much, much better job at compressing images. And there's also really no progressive decoding in WordPress, unfortunately. So when you upload your images to WordPress, when we create the sub sizes that you serve up on the front end, that we serve up on the front end, those are not progressively decoded images because of the kind of underlying server architecture of how WordPress runs. Generally speaking, this is sort of a generalization. You might be able to work around this, but we don't really get to take advantage of that in WordPress. Next comes SVG. And feel free to ask me any questions here if I'm just going to go through these, but feel free to interrupt me. This is interactive if you want it to be. There's the pig driving the car. The SVG format is 21 years old, so it's been around a while. It's very widely supported. You can use it almost everywhere and images supported. Images scale to any resolution. This is probably the signature feature of SVG. It's built of shapes and curves and lines and angles. So it scales to any resolution. It's not made up of pixels. They get blurry. That's a really huge thing for things like logos. It's very efficient. So it's super small file sizes for things that it's appropriate for illustrations. You can style it with CSS. So you can do super cool things with that SVG that you really can't do with any other image format like apply color overlays or just all kinds of really neat CSS tricks applied to images. It's scriptable and interactive. So SVGs can actually have JavaScript running inside them, which makes them sort of an interactive image format, which is different than any other image format. But that's actually not a great thing. It turns out because it's a security concern because SVGs can contain scripts. It becomes dangerous to allow people to upload to their website. And for that reason WordPress to this day, WordPress support does not support SVG natively. So you can get a plugin and get SVG support, but you will not be able to do it by default. And the reason for that is the ticket that's been open for like a decade to add support has been objected to for security concerns. It's really only suitable for certain images. So again, not for photographs, really for illustrations. You can posterize photographs and do some neat things like that. In general, it's only appropriate for certain types of images. All right, then along comes PNG, 15 years old. So still quite old, been around for quite a while, really works almost anywhere you can use an image. It's really a successor to the GIF format without the licensing issues. So it really, that was the aim of it when it was created, was to replace GIF and sort of supplant it without the licensing issues that existed at the time. It has full and accurate color unlike GIF, so not limited in color palette and also has color profiles. It also introduced alpha channel transparency, which is a big deal for things like product images. So alpha channel transparency is a layer essentially in your image that defines how transparent each pixel is. And that enables you to make images that have very smooth background, smooth edges as they overlay a background. So PNGs are actually way better than GIF for doing any kind of transparency because of this alpha transparency feature. But they didn't support animation. You could say that's a pro actually, but I'll list it as a con here because it was a feature that GIF supported. There are PNGs that support that now, but just in general as a format, it didn't support it. And it only supported lossless compression. So no lossy compression like JPEG, which means that again, the compression really wasn't that great. So I want to take a brief detour before we talk about the modern image formats and talk a little bit about image quality and how to think about image quality because when you get into the modern image formats, this is very much something you have to consider because part of their goal is to do better compression with lost impression. And when you talk about better compression, the more you compress something, the lower the quality. So you have to talk about what is the quality at a given level of compression. You can't talk about quality without talking about compression level. They're sort of two sides of the same conversation. So how do you think about image quality? What does an image look like? If we take these two images and I put them up on your screen, can people tell me which one is the better quality image? And I think no matter how much time I give you, you will not be able to figure it out. It's kind of a trick question. The one on the left is high quality, 90. And the one on the right on my screen anyway is quality 40. So 70% smaller. But you really can't tell the difference unless you zoom in. And certainly not when you're watching a live video stream where there's a ton of compression being added to the video. There's no way that you can tell the difference between these two images. And even if I zoom in on the original compressed images, I can only tell the difference when I look at very fine details, like the little tiny flower details in the middle. So the point here is the context matters. Where you're viewing the image can determine what quality you really want an image to be. If it's going to be displayed very small, like a thumbnail, the quality doesn't need to be very high. But if it's a product image, it's going to be high resolution that people are going to be really looking at the details, then you probably want a much higher quality image. So how do you test that quality? There's algorithms like SSIM, right, that compare quality. Someone said the left one looks more vibrant. Yeah, it's not just about the structure. It's also about the color, like how are the colors represented? And there's all kinds of these algorithmic tests that you can do that will help you kind of compare, like how similar is this image to the original image? Okay, now at this compression level, how similar is it to the original image? And you can run those algorithms against different compression levels and different image formats and try to understand how the quality compares. Where that falls short is that algorithms tend to have a predictable bias. So a structural similarity test might be biased against something like JPEG that produces blocky artifacting versus a format like WebP that tends to produce a maybe more blurry image, but less blocky-ness. So the problem with these algorithms is they tend to be biased in a certain way that's predictable and the actual compression algorithms tend to be written to kind of meet those tests, so to speak. And there's another way to test, which is basically human-based tests. You sit people down in front of a computer and you have two versions of an image and you ask them to compare it to the original. Is this one different than the original? Does it look worse? Does it look as good? And you repeat that test over and over with different types of images, different compression levels. And you do the same, you get the same kind of result that you get from an algorithmic test. You get a plot of different qualities over different compression levels. And it's the same type of test. And there's even algorithms that are designed to sort of try to mimic how humans perceive images. None of these are perfect. You really have to do a variety of tests to come up with meaningful results. But what you get is you get a bunch of data points that you plot out on a graph. And they compare the quality of an image on a scale from here to zero to one, for example, with the file size here given as bits per pixel. But what you can understand from this is that at a given file size, let's say 0.5, maybe that's half the original size, a JPEG will produce this quality and a WebP will produce this quality. That's how you read a graph like this. So where you can go from a quality level and determine the file size. And so what you see in a graph like this is that in general, over a wide variety of compression levels and data points, these have all been sort of averaged out here, WebP performs better. It has a higher quality for a smaller file size until you get to higher quality levels. And then JPEG actually maybe performs slightly better or they're equal. And we have the, I'm sorry, we have a question in the chat. Awesome. Is the compression in the spatial domain only or also color or luminance? Yeah, so it's all, I think it's all of the above and I don't have like detailed technical knowledge about how the compression works internally, but I do know that like with the testing, some of that testing is specifically around colors and certain color channels. And so I know that compression formats, they compress color differently than they compress detail information. And so what you look at when you try to say if something is a good quality can be determined by that, right? By what test you're using essentially. I probably didn't really answer the question but hopefully that is, that's my best attempt to say, yes, it includes both. Yeah. Oh, sorry. Go ahead. Oh, no, I had a follow up. Weston says thank you. Thank you for the question. Based off of the graph you're showing with what P and JPEG and talking about the algorithms to test the quality. We do have a few questions from folks about like, how do I, you know, determine the best image quality? And I'm just wondering, is it realistic for someone, you know, project manager at a digital agency to like ask for these kinds of tests to be run in order to select the best image quality? Or is there just a basic one that people would just, should just. Yeah, no. And there isn't like the short answer is there isn't a best quality, right? It depends on the image. So even with something like this here where it shows, like on this chart, it shows that WebP consistently outperforms JPEG. That doesn't mean there's not going to be an outlier where you might create a JPEG that's actually smaller than a WebP of the same size. And that's because the compression algorithms work differently and they tend to do better with certain types of images than others. So there, it isn't, there isn't going to be either a compression quality level. It's always perfect. Or a particular image format that's always perfect. But you can say something like WebP on average will be smaller than JPEG at the same quality, at the same quality level. So you, you get an advantage if you want to keep your quality consistent of smaller file sizes, meaning, you know, faster load times. But it's always a tradeoff. You know, you have to understand that it's a tradeoff. And I think, you know, in terms of the quality that you use, that depends again on the context where, you know, if it's something like thumbnails, the quality maybe could be lower if it's a product page, or if it's a large image where you're really trying to highlight the quality of something, then you need to use a higher quality. And of course WordPress doesn't, by default, let you control these things at a fine-grained level. This chart here is really more for people who are deciding which format we should use in WordPress, or maybe, you know, which format you should use by default. Not something you would look at like for each individual image, because it's more of like an average of a whole set of images. Thank you. Hopefully that helped. Okay, so let's move on. Unless other people have questions, I will move on. Cool. I'm going to go into the modern formats. So WebP is the one that I was just comparing before. It's 12 years old. So it's actually been around quite a while, almost as long as the last ones we looked at, PNG. And it's very widely supported. Pretty much works everywhere. Works in all the browsers. It works on pretty much any WordPress site out there, because almost all hosts support it, not every single one, but by and large, it's going to be supported on your WordPress site. It offers lossless and lossy compression. So this is actually a big deal. I'm going to get to why it is. But unlike all the formats that came before, if you wanted to choose between lossy and lossless, that meant choosing between formats. Should I use PNG or JPEG? But now one format can actually do both lossless and lossy compression. And it also has the animation that GIF had, and it has the alpha transparency support that PNG introduced. So pretty much what you could see here, other than the vector support of SPG, is that WebP kind of aims to have all of the features that the previous image formats had before it. And where this gets really exciting is when you think about something like a product image with a transparent background, where previously you really are only choice to do a really high quality product image with a transparent background would be PNG, which is a great format, but it only offers lossless compression. So you're only going to get maybe 15% compression over the original image. When you switch that to WebP and use a lossy compression, still with the alpha transparency, you get like 85% better compression. So it's a huge improvement or maybe 70% but it's a huge improvement. And so the combination of all these previous features into one format is actually a real boost for what we can do with images on the Web. It also has the full and accurate color like JPEGs do as well. So it's got color profiles and high bit color. And it's also got fast decoding. This will, this will clear why this is important as I get to the next two formats. So basically as your web browser decodes the compressed WebP, it's just as fast as JPEGs. It is a little slower on the encoding side. So this is when you upload an image to WordPress and it creates all the sub sizes. This takes a little bit longer with WebP than it does with JPEGs because it's a little more computationally intensive. There's also are still some support gaps. So particularly after you, if you were to download a WebP image from someone's website who was using the WebP format and then try to use that image, the WebP image in certain contexts, it may not work. A good example of this, last I checked is GitHub issues. If you try to upload a WebP image on a GitHub issue, they reject that image format. They don't support it. They could at any time start supporting it, but they haven't. And so this is always something we're going to suffer from with a newer format like WebP. It just hasn't been around as long. Another example would be like maybe paint, the paint application on Microsoft Windows. If you're still using that, maybe it hasn't been updated to support WebP. So there's always going to be places where you can't use WebP as well as JPEG. And that is kind of a shortcoming that will never really fully be able to overcome. But in terms of using it on your website, it really is compatible with almost everyone. And it's got some great advantages. Next format up is ABIF. Very young, less than three years or maybe about three years old now. It's well supported. So Safari, Apple announced support for Safari. So Edge is the only outstanding browser that doesn't support it directly. It has both the lossless and the lossy compression, the animation and the alpha transparency, the full and the accurate color, and it has very high compression. So even better than WebP does, something like 50% improvement over the lossy compression of JPEG. Unfortunately, it does have some shortcomings that maybe will be addressed in the future. But it is slow and expensive at encoding and decoding images as compared to JPEG or WebP. So your images are much slower to compress when you upload them. And even the decoding part is more expensive. And this can really play out, especially on low-powered devices. So if you think about... Oh, someone put a comment in there. Ah, interesting. And they said, I'm reading a comment from the chat that says that they downloaded a WebP image and tried to open it. Photoshop, it opened as a camera raw file. So Photoshop succeeded in opening it. Annie, I guess, is your name? And yes, it did. Well, that's good. So maybe it doesn't support it directly fully yet. But I know that support is growing. AVF also only recently gained Photoshop support. This is kind of a challenge with modern images is how are you using them? If it's just for your website, then all you need is the browser support. But if you're using them outside of the browser, then you have to consider the whole ecosystem of all the tools that we use to process images or to use images. So another big gap with AVF support or a problem is server support. So with WordPress, when you upload an image, the recompression of that image happens on the server using PHP. And right now you need PHP 8.1 to support for AVF. So unless you're on some special host that has AVF support or using like an image CDN, you need to be on the very latest version or close to the latest version of PHP to get AVF. And then kind of the newest kid on the block is JPEG XL. It is less than a year old or maybe a year old now. It has everything that these last formats have had, the lossless and lossy, the animation and alpha support, the full and accurate color, everything in decoding unlike AVF. So it's actually efficient like WebP and very high compression like AVF. So it kind of combines those two things. It has this amazing feature, which is that it can losslessly re-encode JPEG. So if you have a JPEG image that's compressed, you can recompress it using this new JPEG XL, get the better compression level without losing any information, which is not a normal thing. Normally when you recompress compressed images, it kind of increases the, it loses information in that process, I guess. And it has another amazing feature, which is this advanced saliency-based progressive decoding. So this is just to describe it in a very rough way is, just the way that JPEG images can decompress progressively. So you get that sort of blurry image at first and then the details come in as the data is loaded. With JPEG XL, you can do that, but you can tell, you can define in the image with a layer where you want that new detail to emerge first, where the data should be used. So for example, you can have an image where there's some people in the middle and the focus of their faces comes into first, the detail of their mind in the background. So it's a really cool progressive loading technique that JPEG XL has. So in terms of disadvantages, it's not supported anywhere. So you can't use it in any modern browser. It is available behind a flag in some browsers, but not really available to most users. And it's also not supported on servers. No PHP version supports it. So even though it's this amazing format and you can test it out and they have encoders and decoders for it, you can't actually use it in a browser. So it's not something that we can really use on the web today. The people who are developing JPEG XL very much want to make it a format for the web, but it's a little bit of a catch-22 where the tooling hasn't caught up. Some of the advantages, there's sort of a little bit of a kind of, I don't know, competition, I would say, between the JPEG XL and AVIF format creators where they're trying to outdo each other in terms of how much compression they can achieve and what features they have. The real advantage that AVIF has right now is the adoption, the fact that it actually works in modern browsers. So JPEG XL is an exciting format, but not really one that we can actually use today. So that brings me to, yeah. Sorry, I had a question. Yeah, perfect time for questions. Yay. Excellent. Excellent. And anyone else, please feel free to unmute or ask a question in the chat. I had like a kind of foundational question, I guess. Yeah. Who are all of these image formats open source? Like who's making these? They are, I think, largely developed in the open. I do think that like Google has owned the WebP format in the sense of it is an open source project, but it's been largely led by Google. And I think AVIF is the same way. I think AVIF is also closely related to a video format that I'm not going to get the right, someone put it in the chat. So it's closely related to some other format that's a video format. AVI, I think, is the format. In terms of how it does compression, the JPEG has like a consortium that runs the JPEG project. There's actually a bunch of different JPEG formats other than this one and the one that we're all familiar with. Like there's one called JPEG 2000, but JPEG XL is very much the one that they've been trying to get adopted for browsers. So I think they are generally open source, but they're also like big companies behind them. Got it. Thank you. Yeah. And this next section that I have is about like how WordPress handles images. So this is a good place to kind of stop and take any questions that people have about the image formats themselves. So unmute or put them... Oh yeah, AV1 is the closely related format. Thank you for putting that in the chat destiny. I'm going to sip on my coffee while you all think of questions or I'll just keep talking. Okay. Oh yeah, AGI. I think it's AGIF the format. Okay. So there's a few questions I'll go through in order. And then if you have more of them in there, I guess, Laura, is that a question you have to format and resize before starting a site or are you just making, maybe that's just a comment. That's one is from Weston. If you have a big image, what are the options to reduce the file size? Okay. So I mean, big image, I think you mean uncompressed. I guess like when we take pictures with our camera, like our phones, a lot of them are just these giant megapixel, 16 megapixel images. You can definitely resize those in a tool to get down to a reasonable size before uploading them. After you upload them, WordPress is going to recompress them. It's going to take whatever size you upload. Let's say it's 5,000 pixels wide. And it's going to create multiple sub sizes, which I'm going to talk about in this next section if I get to it. So the biggest thing there is to choose a good compression level. And I'm sure there's plugins that let you fine tune this as well for each specific size. So you might look at something like that. But in general, the WordPress default level of 82 is a pretty good choice for images that still look good, but are pretty well compressed. So I think accepting the default is fine if you're using WordPress. If you want to get better compression out of WordPress itself, I would recommend considering the WebP format. And there's probably simple plugins that will let you just output WebP by default. That's a core capability currently. And most servers support that. The other option would be to use an image CDN. That is a great choice, especially if your host has one that they provide. There's free ones out there. I think if you have a site that's important to your business, then it's probably worth paying for one. And in terms of the other thing you can do, if you really want to get fun, have fun with an image size, is use a tool like Squoosh.app, which is a web based. I'm going to get the address here in my other window. I think it's just Squoosh.app. Yeah. It's a web based, I'll put it in the chat image compression pool. And it kind of gives you a before after, and you can try different image formats and different compression levels. And even within different compression formats like JPEG, there's actually different compression algorithms that are available. I didn't touch on that, but a lot of people talk about MozJPEG as an improvement over default JPEG. And that's true. You can use that to create your images. One thing to be aware of though is that WordPress is a very high-quality image. So if you want to create a highly optimized image for, say the top of a hero image for a particular page, what you want to do is use a tool like Squoosh to get it to just the right size and the right quality level. And then you want to upload and use the full sized image that you've uploaded, which will be the original image, which is normally not what you want to do. Normally you want to use those compressed images that WordPress creates, because those will be at the various sizes. So if you're optimizing an image and like spending a lot of time making that compression level and image format choice, then it's probably something you want to handle more manually. I'm going to go back to the question. So there's a lot of stuff in the chat to catch up on. But once someone asked about the HEIF format, I just want to say that's a super interesting use case because it's the format that iPhones now use by default. And Apple actually hides this a lot from end users. Basically they make it very easy to use these formats, even if you're using a tool that doesn't support them. Like if you drag and drop a HEIF into a web upload in Safari, I'm pretty sure it automatically converts it into a JPEG behind the scenes for you. And similarly, if you try to open it on desktop and Mac and a tool that doesn't support it, it automatically will convert it for you. So it does hide that. And obviously Apple gives you the ability to switch that to JPEG. But this is a real challenge. Like there's no way in a browser, for example, to tell the browser that when you right click to download something that you wanted in a different format, like save as JPEG would be a killer browser feature for solving this problem. Although it has its own issues. OK, missed SVG and PNG slides. Can we see those two again? I'll just very quickly go back there and leave those open for a minute. And you can ask questions if you have specifically about these. So there's the SVG one. I'll just leave that open. Is there one image format you can suggest that to use, support it on every device and browser? That would be WebP. I would say WebP has supported it everywhere. The only exception, so that would be certain email newsletters. Like if you're emailing to, you know, you have Windows Outlook clients. Or if you know you have really old Safari users, then you might not be able to use WebP. But other than that, I would recommend WebP as sort of the default output format. WebP has a filter, like a one line filter that will change its default output format. So it's very easy to do. And there's plugins that do that as well. Is the general rule of thumb a photo on a site shouldn't be more than 100K? I know people would love me to give a cut-off. I don't think there is a cut-off really. I think it depends on your users. This is one thing when we're trying to measure performance, it's important not just to look at how fast the site loads for you, but how fast it loads for your users. The way you do this is you get real user metrics or ROM data. There's a couple of different ways you can collect that. One is with JavaScript on your site. Another, if your site is big enough, is to use public data sets like the crux or HTTP archive data set. But really, you can't answer that question as a rule of thumb. I mean, I'd love to give you a number. It used to be 50K, I remember. Probably 100K is reasonable. But if you're a photographer and your images are super high quality, then no, they should be much larger than that. And if you exist in a market where people have low-powered devices and limited bandwidth, then they should absolutely be much smaller than that. So it really varies. There isn't an answer. There isn't one answer. Cool. Some people answered and explained what I said, CDN, content delivery network. Image CDNs are a really cool way to serve images. In part, oh, I'm going to go to the next slide, too, because someone asked about the PNV1. What an image CDN does, and like if you install Jetpack, for example, and use their Photon image integration, that's an image CDN. And what that does is it will take the original image that you've uploaded to WordPress, and it will serve it up to users in whatever the best format their browser supports is. If their browser supports Avif, they'll get an Avif version. If their browser supports WebD, they'll get a WebD version. And often image CDNs will also resize the image so that it's exactly the right size for how you've served it on your Web page. WordPress tries to do that. So when you upload, we create multiple sizes, but we don't create every possible size. And if you are editing your site and you drag the image and make it a little smaller, you might get into a situation where the size that you've specified is different than the available sizes. So we do our best guess. With an image CDN, it can actually just sort of resize things on the fly. So that's the real big advantage, the ability to dynamically serve the right format and the right size. So I'm going to jump back into, unless people have questions, I have like 20 more minutes. So I'm going to jump back into slides. Is that good, Destiny? Should I do that? Yes, I think that sounds great. Okay. And feel free to unmute if you all have questions. I think I answered everything in the chat, but I easily could have missed something because it was a lot. It's hard to read things while you're talking. You got everything, don't worry. Okay, cool. So just want to briefly talk about WordPress and images. So we're all familiar with the media library. Probably if you've uploaded images to WordPress, you spend at least a little bit of time in this nice grid view that we have in the media library. I want to give a shout out to the list view, which a lot of people are not aware of. You get to that by clicking this little list view icon here in the upper left. And there's actually a bunch of features that are available in list view that are not available in the grid view. So check it out. You can also upload images directly in the editor now. So this is the experience where an image is in the process of being uploaded. It's slightly different than uploading in the media library, even though they wind up in the media library as well. When you upload images to WordPress, the original file is stored on the server. It is always, the original file that you upload is always stored indefinitely on the WordPress server unless you do some special thing to delete it. That's kind of part of our core philosophy of like, it's your data, the user's data. We don't, we don't touch it. So everything we do at this point is creating other copies of your image. And the really great thing about that is that, like if you uploaded all your images years ago, before we add AVIF as a format, that doesn't matter. You can still regenerate your images using a plugin like regenerate images and you will get whatever new format you have set up on your WordPress site because it will, we always have that original image. We can always regenerate the, the sub sizes that are specified. So PHP is the, is the, you know, the kind of tool, the programming language that the web server is running on, that the web server is providing that WordPress is running on. And it uses two underlying libraries, GD or lib GD and imagic, like image magic, but scrunch together imagic to create all the various sizes. So you're familiar with large, medium thumbnail. There's also medium large. There's also a couple of HDPI or high definition images that would create if you upload a large enough image. If you upload an image over a certain dimension, which is by default something like 2048 by 2048, those are considered extra large images. And we resize that into a scaled version. Again, we always keep the original, but we make a scaled version that's just at that largest size that we think is a reasonable size to serve on the web. And then of course plugins or themes can add their own custom sizes. So, you know, in, in some cases you might have half a dozen or a dozen different images being generated when you upload one image for WordPress. So other than when you insert from URL, every time you upload an image, you're going to get this process of creating the sub sizes. Right now that process is, I would say, semi asynchronous. It happens on the server in the background, but as an end user you have to sit there and wait for it to complete. So either in Gutenberg in the block editor or in the media library, if you navigate away, that breaks the upload. So we, that's something we really need to fix in core is to make that process continue in the background, even as the, if the user agent leaves the page. But we also handle some other things which are kind of cool that you might not be aware of, including image rotation. So if you take a photo with your phone and it's rotated into a, you know, horizontal or vertical aspect, that rotation is actually recorded as part of the image made of data. And WordPress handles that when you upload and properly re-rotates the image, no matter what the rotation is to begin with. And like I mentioned before, WordPress can automatically generate images in a different format like WebP with a simple filter that we have in place. There's no UI for that, but again, just to plug in, we'll enable that for you. A couple other things just to shout out to the editor we have built in to WordPress where you can rotate images. That's also available. The cropping is available right inside Gutenberg. And you can also rotate and flip images in the media library. WordPress handles high definition images by default. So when you upload large enough images, we'll generate those HDPI versions. So if you're using like a retina screen on a Mac, this is the most common use case, you get these very high resolution images, which is really cool. Something else I learned while working on images in the last year is that the Web also supports HDR or high dynamic range images. And the AVIF format currently supports that. So you can actually load a photographer's website that's linked from this core ticket and see these amazing images. I had fun dragging them from my desktop, from my MacBook to my monitor, and you can just see the difference between a high color screen and a normal screen. It's stunning, actually. Really only applies probably to photographers who are doing HDR photography, but still a really cool thing to know about that's out there and currently supported on the Web. Just to say that in terms of performance and optimization, loading images is a complex part of a very complex process that browsers go through when they load pages, including loading all the, you know, scripts and CSS and the header. And how big your images is, how large that image file is, only has a small part to play in the overall experience of end users on your site. So while optimizing images is a valuable thing to do, it's not the end all to solving all of your problems. And even though images frequently come up in reviews of website performance, like if you run a lighthouse test on your website, you'll frequently have the largest image marked as a problem. That's true and making that image smaller will help, but there's often a lot of other things that go into why that image is slow that aren't just about the size of the image. They're about how the page is structured and what other things the browser has to do before it gets to loading the image. So just to wrap up with this section on why this matters, why smaller images do matter, you're building a website, you're coming up with an image to put at the top of your page. You wanted to look as good as possible at the same time you don't really want to make the experience bad for your users. And overall WordPress has a problem with this. This is a problem we know that WordPress has. When we look at WordPress sites on the Core Web Vitals technology report, we see that of the Core Web Vital metrics, the LCP is the largest contentful paint is the one that WordPress suffers most on. And I'm going to briefly describe what this is, but just to say that only 35% of WordPress sites in the wild do well with this metric. And what this metric is, is part of what we call the pillars of user experience on the web. So there's three main components. There's like, is the webpage loading? Is it interactive? Does it respond to user interactivity? And is it visually stable? Are things popping around or is it stable for end users? And we measure these through these three Core Web Vital metrics, largest contentful paint, first input delay and cumulative layout shift. And these are metrics that Google developed, the Chrome developed to try to provide a way to gauge user experience in a measurable way. And they're not set in stone, they're actually changing. So there's a new metric that's been introduced this year called interaction to next paint. But just to focus right now on the largest contentful paint metric, that's the one that WordPress currently really has a tough time with. And so what this is, is basically what it sounds like. It's when does the largest element on a page complete painting. So this is a little different than how we used to think about performance with like, when is the first byte delivered or when is the page completely loaded? This is to say, when is the largest thing on the page completely loaded? That's sort of when the user feels like the page is completely loaded. There may still be some other things that are loading, but that big image is loaded. So that's sort of what we're trying to measure here as a good experience. It's usually a large image, but it sometimes could be a large block of text. But in the case of a large image, this is where optimizing the image can actually make a big difference. Another thing to think about with images, and this is not just the one that's at the top of the page, but all the images on your page is that they cost users to download these images. We're used to having unlimited bandwidth and not paying for our Wi-Fi beyond for our usage, but that's not the case in a lot of the world. So depending on where your users are, it might cost them like per megabyte to download your images. So there's an actual cost. And even if users aren't paying directly for this with their dollars, there is like an energy and environmental cost to storing and transmitting all of this data. So there is an actual cost to larger than needed imagery. And then just to kind of wrap up like where I see this going in the future. Oh, any thoughts? There's some questions. I'm going to answer a question. Any thoughts on WP changing these default sizes? They've been around for 15 years. Changing things in WordPress is very hard. Changing anything in WordPress. We did add one new default size in something like WordPress 4.7. That's the medium, large size. And that experience was painful. We broke image uploading for a certain percentage of WordPress sites. I don't know what that percentage was. It might have been 2% or 5%, but it was still millions and millions of sites that suddenly couldn't upload images just because we introduced one new size in core. What we discovered from that is that our upload process was extremely fragile. And since then, we improved it somewhat. Now it's more resilient. So we actually retry if the processing fails and we'll retry up to several times to get that process to complete. So it's a little more robust, but not as robust as what I was talking about before, which would be fully asynchronous image compression happening in the background without the user agent needing to be present. In terms of changing the defaults, those are actually user editable fields. So the defaults are there when you set up your WordPress, but they're not stored. They're actually stored as database entries. So the users can change them, at least for those default sizes. I guess the only thing that would prompt us to change them would be some really strong reason we needed a certain size. The reason we added the medium, large size was there was a gap. We sort of had this gap between the medium size and the large size when we were building out source sets and we realized we're sort of missing one sort of fundamental size that's very commonly used on the web. So the only argument for adding a new size would be, okay, we need, we really want HTTP high definition thumbnails or some use case that, and for it to be in core, it needs to be beneficial to 80% of our users as kind of a philosophy. So it has to be something that, and of course you can do this now with a plugin. It's not like you can't do it. It's just like, is it a default thing? I guess is the question. Question, could you explain GD library and Imagic again? What happens when you upload a footer to the media library? Yep. So PHP itself currently bundles the GD lib library as part of PHP, but previous to version, I think 8.0, those were separate things. So if you are a web host and you're building your server, you're setting up your server, you're either using a pre-built kind of bundle that has your PHP in your Apache, or you're actually literally like compiling the software. And when you're doing that compilation, you can bring in libraries that add support into the web server. And one of those libraries would be the image library. So this are, like I said, GD is now bundled with PHP by default, but previously you had to choose sort of which one you wanted to use and GD and Imagic were the two main ones. So WordPress supports those by default. And what that means is that if your web server has Imagic available, we'll use Imagic. It's considered, I guess, the more robust. It's the default if it's available in WordPress. And then if not, it will use GD. GD is always available. Now, which version of GD do you have? That depends on which version has been bundled or built into PHP at the time that it was built. And so if your host is using a pre-built package, like a Ubuntu release, for example, it will depend on the version of that release that they're using. So it will depend on your host. And there's different versions of GD. There's different versions of Imagic. So it's not just like which one are you using, but also which version. And that can affect compression, for example, things like what we have improved over time. I hope I answered that question. When you upload them to the media library, WordPress creates multiple subsizes for you. So you upload your original WordPress creates four, five, six, seven, 10, however many subsizes. Those are all stored alongside your original image. And when you look at the source code of your website on the website and you look, you'll see that we serve up what's called a source set. So instead of just one URL for your image, you'll see all the URLs referenced that have been created. And what they're designed to do is load depending on break points, depending on the width of the screen. So smaller screens, like a mobile phone, we'll get a different image size serve for them than a larger screen. And in a responsive theme, you know, it might be several different break points where different sized images would be served. And then similarly with a high definition screen, if you're on a Mac with a high definition screen, you'll get served a higher definition image, like twice the resolution that you otherwise would be. Okay, I'm going to answer another question. Oh, I think the core WordPress performance team works to find these kinds of improvements. Absolutely, thanks for that link. I am on that team and we've been actively working on trying to land WebP as a core feature. We did land it as a core feature in terms of WebP being available in 5.8. But in 6.1, we sort of failed to make it the default. And I'm hoping that at some point in the future we can change that and make it the default. But if you can install the performance lab plugin, which is available in the repository and developed by the performance team, and that has all the kind of features that we built out for image, including some really cool ones, like an experimental feature called fetch priority, which allows us to kind of tell the browser that the particular image is the most important image, like what we think is the LCP image and prioritize its loading. I had a slide that I skipped over before about how browsers prioritize loading. And it's a very, very complex process. And so part of what we're trying to look at on the performance team is how can we hint or signal to the browser, hey, this is the image that you should prioritize. Martha had a question. I compressed my images in Photoshop, then I uploaded them to Media Library. Are they getting compressed again? So the answer is yes, they are. And which image size you use can determine whether your original upload is being used. So this is what I was talking before about the full-sized image. So when you upload an image and insert it into Gutenberg into the block editor, you can choose which size to use, like full, medium, large. The full-size is referring to the original image that you uploaded as long as it's not larger than the scaled cutoff, which is 20 something, 2048, and can be changed by plugins. So what I would recommend to verify that, Martha, is to upload your image, select in Gutenberg, like the full-size image, say publish the post, and then go look at the post, look at the source code, look at the image, make sure it's the same image. Like it should have the same file name, exactly the same file name. If it has a dash and a number by it, then it's one of the compressed images that Wordpress creates. Because when we create those subsizes, the names are changed. So it's the original name, plus a dash, plus the dimensions, the width and height of the image is added. So you can very quickly tell just by looking at the source code or looking at the image if you download it, whether it's your original upload or one of the recompressed images. But yes, the answer would be we do recompress it regardless to create smaller sizes. So if you upload a large image and then say you place it on your homepage in a thumbnail layout or on an archive view where the thumbnail version is used, then it's gonna use that smaller version and that's what you want. You don't wanna serve up that huge image, generally speaking, in that list view. Pixel width of a hero image might take the full width of the browser screen. I think that's a question for your designer because it sort of depends on what you're trying to achieve. I love images that are full width and fill my homepage. That's not the best for performance. If your goal is to get maximized performance, obviously the bigger your image, the slower it's gonna load. So there's a trade-off. It's a value decision that you have to make. A large image can be super impactful to people when they first visit your website. If you're a visually oriented company, you're a landscaping company and you wanna show a beautiful landscaping photograph. You want that to be a large image. So I don't have any answer for you unfortunately, but I think it just depends on the situation and it's a trade-off. What you choose is a trade-off. And I guess the best way is to do some research, to test things out, try a large image, see how your users respond to that, try a smaller image, see how they respond to that. You can even do A, B testing if you get really fancy, but you can even just do some sort of informal testing where you try one thing, give it a chance, see how it performs, ask your users if you have an opportunity, try something else. I don't think there's one answer that is right for everyone or every situation. Cool. And I've managed to use up a whole hour of time. That's amazing. All I was gonna say in this last section, and I guess I'll just say goodbye, is just use an image CDN. That's really your best bet for now. And in the future, there's some things that are coming down the pike that could be really exciting where, you know, we do more image processing in the browser as opposed to on the server. Just like we're moving to editor being fully JavaScript, like we could do a lot of our image library stuff and WordPress in the browser. And then that would leapfrog some of the limitations that we have on the server. That's it. I'll leave this slide up as my final. Thank you, Adam. That was super, super insightful. I learned a lot. I hope folks also got a lot out of this. I'm sure they did. I'm going to stop recording. And.