Day: October 19, 2022

[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, the state of images in WordPress.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea featured on the show. Head over to WPTavern.com forward slash contact forward slash jukebox and use the contact form there.

So on the podcast today, we have Adam Silverstein. Adam is a WordPress core comitter, where he works to fix bugs and improve modern web capabilities. As a developer relations engineer in the content ecosystem team at Google, he works to invigorate the open web by empowering and educating developers.

At the recent WordCamp US he gave a presentation entitled images on the web, past, present and future. In it, he outlined his thoughts on where the web is going in terms of support for different image formats.

Alongside text images are the bedrock of webpages. We browse the internet and expect pages to have images of all forms. Photos, illustrations, charts and images to convey additional meaning to the text.

But how do the images actually get on the page? WordPress makes handling images pretty easy, and Adam explains what happens when you upload an image to the media library and then display it on a page or post in a browser.

We discussed the fact that different image sizes are created automatically by WordPress, which can be used in a variety of contexts across your website. You’ve likely heard of many of them. But perhaps you have not thought about which image format belongs where.

As with code, the technology behind images does not stand still. New image formats are being created all the time, and are being supported at differing rates by the major browser vendors.

In the past, we typically used JPEG. GIF or PNG files to display images on our websites, but there’s good reason to think about adopting other defaults in the near future. We discussed some of these new formats, such as WebP, AVIF and JPEG XL, and find out how they are speeding up website loading times because of their smaller file sizes.

We also get into how you can optimize your images and how plugins and SaaS solutions can reduce the size of your files before or after you upload them to your WordPress install.

Adam has some good advice about a topic which is becoming increasingly important, page load time. And if you’ve never given the serious thought, this is a great podcast episode for you.

Typically when we record the podcast, there’s not a lot of background noise. But that’s not always the case. Over the coming weeks, I’ll be bringing you recordings from a recent trip to WordCamp US 2022, and you might notice that the recordings have a little echo or other strange audio artifacts. Whilst the podcasts are more than listenable, I hope that you understand that the vagaries of the real world were at play.

If you’re interested in finding out more, you can find all the links in the show notes by heading over to WPTavern.com forward slash podcast. Where you’ll find all of the other episodes as well.

And so without further delay, I bring you Adam Silverstein.

I am joined on the podcast today by Adam Silverstein. Did I get that right?

[00:04:38] Adam Silverstein: You did. That’s the way I like to pronounce it.

[00:04:40] Nathan Wrigley: Yeah. Perfect. Adam is here because he did a presentation at Word Camp US this year. What was the presentation about Adam?

[00:04:46] Adam Silverstein: It was images on the web, past, present, and future. So kind of like a history of images and also what’s coming in the future for modern image formats.

[00:04:54] Nathan Wrigley: Okay. We’ll delve into that in a moment, but before we do, would you just give us the two minute potted history of Adam. How it is that you’ve come to speak at a WordCamp.

[00:05:02] Adam Silverstein: Sure. Yeah. I mean, I used to build sites in, uh, Dreamweaver. Then I discovered WordPress as a way to let my clients be able to edit their content. Then one day I decided I should contribute back to WordPress. I became super involved in Core and help rewrite revisions for 3.6. Eventually, I became a core comitter. And, worked at agency, 10up, for quite a while, and then eventually wound up on the CMS team at Google. Working on the web platform, trying to make the web platform better. And I still work on WordPress quite a bit in that role.

[00:05:30] Nathan Wrigley: Google seemed to be doing a lot more with WordPress.

[00:05:33] Adam Silverstein: Absolutely. Since about 2017 when they started showing up at every WordCamp. And also they have that first party plugin Site Kit, which is their own plugin that’s very well supported that connects your WordPress site to Google Services.

[00:05:45] Nathan Wrigley: Yeah, we spoke to Felix a few episodes ago. So, if you’re into Site Kit and things like that, you can search for the Felix Arntz episode. But we’re here to talk about images today. And I’m going to lead off with something which is going to make me sound incredibly ignorant, and apologize for that.

And that is simply this. When I visit a webpage or I’m building a website, images basically just magically appear. They’re on my computer. I see that there’s an image, there’s a file name and a file format, JPEG and so on and so forth. But I honestly have no idea how the browser makes the image appear. I don’t know what the mystery voodoo that’s going on in the background to turn a piece of code, I’m guessing, into something visible on the screen. So ridiculous as it may sound. How do we even get images on the web? How does it work?

[00:06:31] Adam Silverstein: Yeah, so it’s not a stupid question because it’s it’s incredibly complex, actually how browsers deal with images. But at a very basic level, typically there’s a lot of ways images actually appear on webpages, because it could be in your css or you could load it dynamically with JavaScript.

But in a normal HTML context, you have an image tag, and that image tag has a url. When the browser first gets your HTML page, it goes through a parsing phase where it tries to decipher what all the elements that I’m gonna need to construct this visual page. What CSS do I need, what images do I need?

So it goes through the HTML and each time it encounters an image. It makes another request back to your web server, that’s running WordPress. And then that image is brought back to the browser. Now that’s a binary format, that image. So the browser also has to have a capability of decoding that image. That’s where support for different image formats come in, and all the browsers support all the formats that we’re used to.

But then there’s these more modern formats that maybe aren’t supported. That’s kind of the simple version of it, is the browser finds the reference that you have on your HTML. Goes out and retrieves it, just like it does any asset, and then it decompresses it and puts it on your display.

[00:07:37] Nathan Wrigley: If I was to look at the binary code, which made up the image. Which I presume is possible? Is it just a combination of letters, numbers, and characters?

[00:07:46] Adam Silverstein: I mean, it’s binary encoding, so I don’t, I don’t actually know what, it’s eight bit probably, or 16 bit encoding. But you’ll have, typically at the first bites of an image will be like a header block. That defines what the image is, the meta information about the image. And then you’ll have the actual data of the image. And that’s in chunks. And it depends on how, what image compression format you’re using.

But typically images are compressed. So you have some information about that compression in the header, and then you have the chunks that make up the file. But it wouldn’t be something, if you looked at it, it wouldn’t make any sense to a human.

[00:08:17] Nathan Wrigley: Right.

[00:08:18] Adam Silverstein: It would just be like binary data, just a bunch of numbers.

[00:08:20] Nathan Wrigley: It kind of reminds me a little bit of TCPIP packets, you know, it’s surrounded with metadata to give, well, in this case it would be the, the OS stack. But, to give the browser information about what’s coming down the pipe in the next moment.

[00:08:32] Adam Silverstein: Right.

[00:08:33] Nathan Wrigley: So how big it is, what the dimensions are, and so on and so forth. And then each little bit will render I guess a pixel or something like that.

[00:08:40] Adam Silverstein: Exactly. You could think of it that way. But you know, in a lot of these compression engines, it’s actually like an eight by eight block, and then there’s more detail. It’s very complicated really.

And even the thing about, like, I very much simplified the how the webpage is loaded because the browser has to decide which resources to load first and which to prioritize. And also just think about an image tag. Image tags now typically have a source set attribute, which indicates which size image we want, depending on the break point that we’re in.

So the browser has to figure out that information as well. It’s quite complex and people have written whole articles on it. So if you’re interested in it, there’s, like in my talk, I’ve got like a links document and there’s some links that I’ve put out to like how browsers work. It is very interesting to understand and I think it, like, can help inform, just the more you understand that, the more you understand why trying to optimize performance is so complex.

[00:09:32] Nathan Wrigley: It really does amaze me, and these days, images on the connection at least that I have in my home, seem to load more or less instantaneously, but I remember going back in the day when it was dial up, this laborious line by line creation of the image. You could watch the image load and it would just sort of generate going down. Do you remember seeing all of that?

[00:09:51] Adam Silverstein: You could see it loading.

[00:09:52] Nathan Wrigley: You could actually see the image loading.

[00:09:53] Adam Silverstein: And you could simulate that, you know, in Chrome using the throttling, in Chrome dev. But the other thing to remember is that, we’re a little privileged here. We have very high speed connections. We have high powered devices, but if you look at the world as a whole, that’s really not the case. There’s still a lot of people in the world who are using low powered, they’re using a phone, it’s not like a smartphone, like an iPhone. It’s a very low powered device. So even just the decoding of the images can be expensive.

And then the bandwidth thing,. Some people, a lot of places in the world, people are paying for bandwidth. So the more bandwidth you use. So they may have images turned off or they may be in a low data mode. A lot of phones support a low data mode where they’ll try to reduce the amount of data that they’re using.

Yeah, it’s interesting. One of the things we introduced recently into Word Press Core is native lazy loading of images. So this is something we used to do in JavaScript, but now is built into browsers. And what it does is it prevents the images that are off your view port from loading until you start scrolling down. Before you reach them, when you start scrolling, as you get closer to the where they’re gonna appear, then it will load those images. So, of course this is great for saving resource because when your page loads, if it’s a long page with many images, you don’t have to load all those images unless and until the user starts scrolling down the page.

And this sounds great, and especially at, in a high speed connection environment, it works great. But someone gave the feedback during the process of introducing this, that they work on a low bandwidth connection. And what they like to do is start loading the page and then they switch to another tab and they wait till everything loads and then they come back and they read all their content. But with lazy loading, it doesn’t work very well because suddenly they scroll a little bit and now they have to wait for another image to load.

[00:11:26] Nathan Wrigley: I’m imagining that typical user is not browsing the web in that way. But that is an interesting.

[00:11:31] Adam Silverstein: Isn’t it?

[00:11:31] Nathan Wrigley: Is an interesting case.

[00:11:32] Adam Silverstein: What it just brings up is that you really have to think about your users. When you’re trying to optimize your site, it’s not just optimizing for yourself, it’s optimizing for your users. And that’s why having real user metrics is so valuable. Collecting actual field data about how people are experiencing your website, as opposed to doing lab tests like we are running lighthouse or page speed insights to try to figure out like, oh, how’s my site performing? That gives you one metric, but that doesn’t tell you how people actually in the wild experience your website. If most people have low bandwidth connections, that’s gonna be really different than what you might get from a local test.

[00:12:03] Nathan Wrigley: Let’s just pivot a little bit and talk about the different types of images there are. I would imagine almost everybody is familiar with the regular, the usual suspects, shall we say.

[00:12:12] Adam Silverstein: Sure.

[00:12:12] Nathan Wrigley: You know, the JPEGs and the PNGs, and don’t even know if that’s how you pronounce it. Some people I’ve heard say, ping. But I always say PNG and I say GIF.

[00:12:20] Adam Silverstein: Yes, and I say GIF.

[00:12:21] Nathan Wrigley: Okay, yeah, but there’s all of these. There’s more, which we’ll get onto later. But presumably there’s dozens more that are not typically used on the web. Why have these formats evolved over time? Why don’t we just have one?

[00:12:33] Adam Silverstein: Right, that’s a great question, I mean, uh, the GIF format came out 35 years ago, and it pretty much did everything we needed to do, right? It could display images, it had animation, it had transparency. Wow, like images on the web. That was actually a big deal at the time. But there were some limitations. It only had 256 colors. So if you wanted to make a photograph, you had to dither the colors and it only had lossless compression, which is not really that efficient. You know, you maybe get 10 or 15%.

And it also had copyright issues. The LZW compression algorithm that was in GIF, there were copyright holders. Big corporations and the free software movement didn’t feel that they could trust this format. That’s part of why PNG came about 15 years ago, was as a response to the limitations of the compression algorithm, the copyrights. Of course PNG also added alpha transparency, which is an improved version of transparency because you can define opacity on a per pixel basis, and this lets you create an image with a transparent background that’s got like smooth edges. Like GIF images with transparent have those like blocky edges. But with a PNG, you can create a gradual fading to opacity.

And that was a big improvement. So it actually added a really useful feature. It’s great for product images, PNGs. Of course, JPEG introduced lossy compression, which let you just tune your compression to whatever level you wanted. You could get 10 times smaller images that still look good, which was really important at that time. But you could also fine tune that if you were a photographer and you wanted higher quality, you could choose that higher quality setting. That was really unique. GIF didn’t have that, right.

And SVG of course is the fourth kind of major one that we use on the web. And that’s just like very different. It’s for illustrations. It’s vector based instead of raster.

[00:14:10] Nathan Wrigley: It’s a file format isn’t it?

[00:14:12] Adam Silverstein: It is, it’s actually XML, think.

[00:14:13] Nathan Wrigley: Yeah.

[00:14:14] Adam Silverstein: Unfortunately it also includes scripting, which means that we don’t support it in core because of the security concerns. But it’s also very specific to like illustration type formats. That’s where it really shines. It has some big advantages. It can be styled with css. You can’t do that with other image formats. What I’m trying to get at is that each format introduced new capabilities that were important at the time.

We started to talk about modern image formats, which I include WebP in, even though it’s 12 years old at this point. What’s really cool about WebP is, it kind of combines all the features that came before. So it has the alpha transparency of PNG, but it also has the lossy compression of JPEG.

So suddenly you can take a transparent PNG and you get 80% improved compression, by making it into a transparent WebP. You still get all the features you need, the alpha transparency, but the compression is lossy now, which is impossible for we didn’t have a format that had both lossy and alpha transparency.

WebP kind of is like, essentially trying to be all the things you need. Like if we had started with WebP, we probably wouldn’t have ever needed another format, because it supports animation, it supports lossy and lossless compression, it supports alpha transparency. It also has better compression than JPEG, like 30% better on average for the same quality. So it’s a big improvement.

Then there’s a couple other formats that are upcoming, I would say. AVIF is probably the next one. It was just, support was just announced in Safari for AVIF. So Edge is the only remaining browser, major browser, that doesn’t support it. And the big promise of AVIF really over WebP is not on features, it’s just the compression that it achieves. And it’s able to achieve a 50% improvement over JPEG. So it’s very promising.

And then the one other one that’s, that’s kind of coming up that’s even newer is called JPEG XL. And this is from the same group that made JPEG and it’s just like a way, way better compression, like AVIF, but it has more affinity to JPEG so it works better with existing JPEGs. Like, it can losslessly recode existing JPEGs. The problem with JPEG XL, at least right now, is that it’s so new that it’s not really supported anywhere.

So there’s a couple things that have happened. There’s been a lot of advances in compression over the years. A lot of them actually related to video, because we’ve, we started streaming video on the web and a lot of investment went into making those compressions better. And then those, like the AVI video format is the basis, the same compression, forms the basis of AVIF, hence the naming similarity.

I’m not sure about the WebP, the history of, of like where that compression algorithm came from, but the, the goal was to create something that was better than JPEG. Higher quality at the same size, or smaller size at the same quality. You can think of it in, in either way.

[00:16:48] Nathan Wrigley: Yeah. I remember back in the day, I hate to age myself in this way, but I remember Internet Explorer six, and the enormous fun that we had with trying to get transparency and the sort of kludges that you had to.

[00:17:00] Adam Silverstein: To get it wo work?

[00:17:03] Nathan Wrigley: Yeah, a little JavaScript snippet so that you could get transparency and so on. And so that tells me that, at certain points in. history, certain image formats have not been available in browsers. Broadly speaking, there’s probably three or four browsers that the majority of people on Earth are using these days. We know what they’re called. But do they support all of these? Really, the reason I’m asking this question is, let’s say I’ve got a website and I’ve got 10,000 images on website.

And I, I now have learned that there’s a potentially 30% benefit in getting them rendered as, let’s say, WebP or, or any of the other ones that you mentioned.

[00:17:37] Adam Silverstein: Yeah.

[00:17:37] Nathan Wrigley: Would you say it’s worthwhile doing that work and re rendering them as, let’s say, WebP or something like that? Or should I just carry on and do the new formats for the new images? Or like I said, go back and redo them all?

[00:17:50] Adam Silverstein: Yeah, I mean, it probably depends on how much actual traffic you get on those older posts. I think a lot of people have older posts on their site that get very little traffic, and then I would say it’s probably not worth updating it. With the filter that we have in place in core to control the output, you can use regenerate images and regenerate all your old images.

And get that WebP benefit, like switch from JPEG to WebP for your old files. There are some caveats there. You need to make sure that the images have been inserted from the editor so that they’re actually replaced in the HTML. Because if you’re changing all your image file names, you don’t want to have broken images in your old posts.

So WordPress does do that on the fly, where we, if you insert an image from the editor, then it has like a WP image class name. So we can identify the source image and then we go and we, we build that source set into the HTML by looking at the metadata about the image. So when you do that regenerate images, it updates the metadata and therefore you’ll get the new images even in your old posts.

But that’s not guaranteed. If you have really old posts or they don’t have that WP class, and then for some reason, because you maybe built it with a page builder tool, for example, that doesn’t include those, there are scenarios where that could break your images. And all the regenerate images plugins have options around this.

Like um, WPCLI, you know, you can have it not delete the old images. So if you have URLs that are still out there referring to the old images, that’ll work. Or another example is you might have a third party site that has embedded your image. If you’re okay with that and you don’t want to break that, then you want to avoid changing your file name.

[00:19:13] Nathan Wrigley: Yeah.

[00:19:13] Adam Silverstein: So it depends a lot on your use case.

[00:19:15] Nathan Wrigley: Yeah. Caveat emptor really. Just give it a bit of thought. In terms of the browsers. What is the support like for, well obviously we know that the usual suspects that we mentioned at the beginning. The age old ones, GIFs and PNGs and JPEGs, that’s fine?

[00:19:29] Adam Silverstein: Yes.

[00:19:29] Nathan Wrigley: What about the other ones? What about the WebPs and the AVIFs and.

[00:19:33] Adam Silverstein: Yeah. So the great place to check is the, can I use website, right? They’ve got all the details but, right now WebP is supported in all the browsers, very widely supported. The only exception is older versions of Safari, and Safari support actually depends on the underlying operating system.

So this means that users have to upgrade to, I think it’s two versions ago of MacOS. So there is a small percentage of users out there that have this older Safari version that won’t load WebPs correctly. It’s actually very difficult to tell how many because there’s a bug, in like one of the subsequent versions of Safari where the user agent string misreported the OS version.

So between a couple versions of Safari and iOS or MacOS, you actually can’t tell the difference from logs. And so we don’t have good data about that in the wild, but from the data that we have, we think it’s between 1 and 2% of browser users in the world that don’t support WebP currently.

[00:20:22] Nathan Wrigley: Dare I ask, was there any politics in Safari not.

[00:20:26] Adam Silverstein: Supporting it? I don’t think so. I mean, people say, oh, it’s a, it’s a Google format. Like it’s an open source format that Google developed. But it is widely supported across a huge number of applications. There’s a lot of criticism of Safari for under investing in web capabilities.

I don’t know if this really falls into that. I do think that Apple as a company has a vested interest in keeping their app ecosystem more powerful than the web ecosystem. So I think there’s sort of some natural tension there, but I probably wouldn’t blame the Safari team. My expectation is the Safari team is all on board on making the web better.

But it’s a big corporation and there’s different interests. So there could be some political part to it, but I, not that I’m aware of. Safari, just to continue like the AVIF is sort of the next one. And Safari did just recently announce AVIF support. I think they’re just slower to adopt some things than other browsers.

[00:21:15] Nathan Wrigley: I guess if I’m using WordPress and images are a key component. I do want to be really mindful that, that number, the percentage. So you think at the moment WebP is about 98% of.

[00:21:26] Adam Silverstein: 98 to 99.

[00:21:27] Nathan Wrigley: So, at some point the Rubicon got crossed and you can say to. yourself, that’s fine. The percentage is easily high enough. I can confidently use WebP.

[00:21:35] Adam Silverstein: Yes.

[00:21:36] Nathan Wrigley: How about the other formats? Also just staying on the WebP, let’s do that bit. first. Would you recommend people to shift over to WebP henceforth?

[00:21:44] Adam Silverstein: Yes.

[00:21:44] Nathan Wrigley: Or is there, is there a good reason to stay with the older formats?

[00:21:47] Adam Silverstein: The only reason I would say not use WebP would be is if you knew most of your users were all on older Safari versions. Or you sent newsletters out to Windows users using Outlook, which is one other use case. We know that doesn’t support WebP. But this is like old versions of Outlook running on Windows. Not modern outlook.

[00:22:03] Nathan Wrigley: I guess at some point you just have to take the plunge and say there’s enough.

[00:22:07] Adam Silverstein: Yeah, Well, and we do have a support shim for Safari. So in the browser, if the page is loading WebPs, we add this little bit of JavaScript, it’s a tiny little bit that does feature detection. So it can actually detect whether the browser supports WebP. And at that point, if it doesn’t support WebP, we can actually swap the images and use the JPEGs that we do have available, We use like the next largest size that’s available. And with the current implementation, that would be either your original image or like the one of the H, high definition images that WordPress automatically creates.

So there will be, like, the primary sizes would be WebP, but there would be still be some available sizes in JPEG. If nothing else, the original image. So that means that your Safari users will still see images, they’ll just get a slower experience. So 1% of users will get a degraded experience. 99% users will get an improved experience, and then it’s up to you to decide whether it’s worth it. But at least those Safari users won’t be totally left out in the dark. They’ll still be able to see your images.

[00:23:02] Nathan Wrigley: It’s really curious. For some reason I have this atrophy and I’ve known that WebP was at about 98. And I put several images online each and every week, maybe a, a dozen or so. And for some reason I always export them as a JPEG. I haven’t managed in my own mind to say, this is now the moment. I think you’ve convinced me. I think.

[00:23:20] Adam Silverstein: Yeah. But I mean, in my opinion, like that really shouldn’t be up to users to understand that or figure that out. I mean, if you’re very technical, if you’re a photographer, maybe. But for the average WordPress user, they don’t know what image format they’re using. So this is why, it should be like a core capability where it just happens for users.

[00:23:37] Nathan Wrigley: Yeah. Okay, so WebP, that’s great. But you, you mentioned a couple of others. There was JPEG, I wanted to say JPEG 2. What was it, JPEG?

[00:23:46] Adam Silverstein: XL.

[00:23:47] Nathan Wrigley: JPEG XL.

[00:23:50] Adam Silverstein: And there’s a bunch of JPEGs actually. There was one called JPEG 2000 that you might remember that was pushed by the JPEG foundation, or organization, for a while, and that was never adopted. But yeah, let’s talk about those.

[00:23:56] Nathan Wrigley: So they, they’re presumably growing in use? Are they safe to use at the moment? Would you recommend, for example, my website using those image formats? Or Should I wait a little bit longer?

[00:24:07] Adam Silverstein: Probably wait a little bit longer, yeah. Safari doesn’t support it yet. They’ve announced support, it’s coming out and whenever the next Mac OS comes out, I think it’s like this week or something. Or it’s soon. It’s very soon. But that means that they’re just starting support so you probably want to wait till a significant number of users are actually on that version.

[00:24:23] Nathan Wrigley: Yeah.

[00:24:23] Adam Silverstein: Which in the Apple ecosystem actually happens pretty quickly. People generally, you know, there’s a very large percentage of users who will go to the next OS version very quickly. It doesn’t cost anything. And it’s like they’ve proven that it’s safe. Um, they have a pretty good uptick rate. So yeah, I mean, the only way, if you really wanted to take advantage of AVIF, we have a couple options. One is using an image CDN. So the advantage of an image CDN is that, it can actually negotiate the format.

So when browsers make a request for an image, they actually can indicate in their header, in their request headers, which formats they’re capable of decoding. And that means that the image CDN can be like, oh, you, you take AVIF? I’ll give you AVIF. That’s the best one that we have. But if it doesn’t support AVIF, okay, how about WebP? You support that? Okay. No, you don’t support any of those? We’ll give you the JPEG version. The CDN can use this capability negotiation at header time, to deliver the best image. And also they can resize the image to exactly meet the size specifications of your HTML, which WordPress doesn’t do.

WordPress generates several sizes, and then we pick the best size that’s the closest to the one that you’ve put on your page. And also we can’t do the header negotiation because we don’t handle the image requests. Those are handled by Apache or whatever web server you’re running Nginx, you know. You have a web server running, it actually handles the image request directly. WordPress has no involvement in that whatsoever. And there are plugins that do this, the only way that you can interact with that is, is using like htaccess. There are some ways to do it, but there generally outside of cores scope.

[00:25:52] Nathan Wrigley: Typically, would this CDN be the kind of thing that you would negotiate with your hosting provider?

[00:25:56] Adam Silverstein: Some hosting providers provide it. There’s of course all kinds of third party CDNs. Jetpack provides an image CDN as one example. Some of them are free, some of them are paid. I think every major CDN has a WordPress plugin that will directly integrate. So you don’t really have to do much to set it up, maybe put your login or your key in or something. So I would say like, if you can hook up with an image CDN, then you’re sort of automatically able to take advantage of the latest versions of images.

[00:26:19] Nathan Wrigley: Yeah that sounds like the way to do it, if you can stretch to that. That sounds like the best way because you can just forget about it. Everything will be taken care of.

[00:26:26] Adam Silverstein: Exactly. If you have a reason that you can’t do it or there’s a cost associated with it. Your best bet is probably to stick with WebP for now.

[00:26:31] Nathan Wrigley: Right.

[00:26:32] Adam Silverstein: Because that is so widely supported.

[00:26:33] Nathan Wrigley: On that point, are there particular types of images that you would recommend given a certain scenario? So, for example, let’s say I’m taking wildlife photography. Fairly specific example, but there’s an awful lot on the image. There’s dark areas, light areas. Lots of color. Let’s say for example, I’m creating some graphic design and it’s fairly plain, it’s text based. There’s not a lot going on in there. Is there a preferred way in, at least in your mind, or is it always WebP?

[00:26:58] Adam Silverstein: I mean, there are definitely cases where WebP like really performs better, and there’s cases where JPEG performs almost as well as WebP I guess. And even there are images where the WebP will be slightly larger than the JPEG, in certain cases to get the same quality. You know, I would say certainly if you’re doing illustration, something that’s like a line art, then if it could be an SVG, that’s probably gonna be your most efficient format.

But other than that, I think probably WebP is gonna win out on average, right? So you can look at specific images and find that maybe one would be better as JPEG, one would be better as WebP. But in general, if you take all your image is an aggregate, you’re gonna be way better off going with WebP.

I think the exception to that would be like, is if you are a photographer and what you’re showing on your website is your photography, and you want it to be like the absolute highest quality. You maybe already have changed the default quality that WordPress uses, and maybe you just want to stick with JPEG so that you know that you’re getting exactly what you’re used to. There is a visual difference between JPEG and WebP and, you know, there’s all these tools that, that they use.

I talk about it a little bit in my talk about, how do you measure quality? It’s a very subjective thing actually. There’s algorithms, so when I’m talking about how do you measure quality, So let’s say you take an image and you compress it with a JPEG and then you’re comparing it to something you’ve compressed with WebP and you say, oh, the WebP is smaller. That’s great. But it’s not that great if also the quality is lower, right? If the quality is the same and the file smaller, you win. But if the file smaller and the quality is degraded, then is that really something you want? So that you have to look at both quality and file size as two parts of the same discussion.

So it’s very interesting how we think about quality. I think, I have a slide in my talk where I have two images and there are very different compression qualities, but you actually can’t tell the difference on the screen because it’s blurry and you’re looking at a screen from 30 feet away. And the point is that it matters, the context where you’re gonna be viewing that matters. If it’s a little thumbnail, you’re not going to really matter if it’s like some pixels that are off. But if you’re looking at like that big gorgeous wildlife photography and you’re a photographer, you want the best possible quality.

[00:28:57] Nathan Wrigley: I guess it’s a case by case basis, isn’t It?

[00:29:00] Adam Silverstein: It is.

[00:29:02] Nathan Wrigley:Just suddenly occurred to me that we didn’t talk about how WordPress deals with images. We have the media library. I would imagine that’s how most people interact with their images on WordPress. You go into the media library and you upload things, drag them in and what have you. But there’s all sorts of wizardry going on right at that moment where you pull the image in for the first time. And, potentially people listening to this, they won’t know about that. So.

[00:29:20] Adam Silverstein: Sure.

[00:29:21] Nathan Wrigley: Are you able to run through that quickly?

[00:29:22] Adam Silverstein: Sure, so when you upload your image to WordPress. You’re uploading your original image, and then WordPress is gonna create a series of subsidized images. By default it has I think four, it’s actually six sizes built in. Four that you can see in the settings, or three that you can see in the settings screens. Thumbnail, medium and large. There’s also a medium large size that we added. And then there’s also two HDMI, high definition screen sizes, that are like even larger than the large size.

So when you upload your image, WordPress will go through this kind of crunching phase where it generates all of these subsidized images, and then those can be used later on the front end, depending on your context. So if it’s a thumbnail image, it’s gonna use that really small image. If it’s a larger image, it’ll use the larger one.

So we sort of pre-create these images when you upload. That process uses, uh, one of two libraries on the backend that tie into your web server. One’s called LibGD, which is now built into php. And the other one’s called ImageMagick, or people call it Image Magic. That’s like the GUI for it. And both of those libraries are available in WordPress.

We have built in image handling classes for them. I will say you can also extend the image library to add your own image handling class, but I’m not aware of specific implementations. But those are sort of the two that we support out of the box. And they’re very popular and common in php. Like I said, GD’s built into php now.

Those libraries may or may not support different formats. So getting back to your question of which format is supported. In order to be able to use AVIF with WordPress, we really need that server support. because if the server can’t read AVIF, if that means when you upload an AVIF file or you upload a JPEG and you’re trying to output AVIF, it can’t do that.

It doesn’t know how to do that. So until we get to PHP 8.1, which supports AVIF, we’re probably not going to be able to support directly AVIF in WordPress. So there’s that server dependency that you have. And also, just to add a little wrinkle to that is that, GD supports WebP or, you know, Imagemagick supports AVIF, but only if it’s built with that. So literally at compile time, someone has to build the web server, right? It’s written in C or whatever assembly, like whatever code it’s written in, and then someone has to compile and they have to decide, am I including the AVIF i library? Am I including the WebP library? And so whether you have support for those depends on your host.

Like what is their hosting stack, what is the distribution that they’re using? It’s a wide variety of things out there. But yeah, that’s the general process. You upload, the images get generated, and then, when you insert the image into your post WordPress will use all of those images. They’ll use it in the source set to build out the responsive design.

[00:31:48] Nathan Wrigley: As with all things WordPress there’s plugins that step in and do additional features. I mean you can code this yourself but you know, you can create other image sizes that WordPress will create on the fly, soon as you, you know, you crunch an image. Yeah, but also there’s this curious third party industry of image s smushing, I want to call it. You know where, when it’s uploaded, and I believe also WordPress itself now has a maximum, you know, if you’ve got a vanilla install of WordPress there’s a, what is it? What’s the.

[00:32:15] Adam Silverstein: It’s It’s like a max threshold size for image uploads.

[00:32:18] Nathan Wrigley: Yeah. That, I suppose is a useful thing to talk about. The idea that, okay, so you’ve got this brand new beautiful camera, which is taking images.

[00:32:27] Adam Silverstein: Sixteen megapixels.

[00:32:27] Nathan Wrigley: Right, and honestly you’ve got a 10 megabyte image but you’re intending to display it as a thumbnail in the corner of your post or something like that.

[00:32:34] Adam Silverstein: Right?

[00:32:35] Nathan Wrigley: The intention, therefore, from these third party plugins and, and what have you, is to take that image and just reduce it. Make it teeny tiny. Why do we do that? What’s the benefit to begin there? You talked about bandwidth and all of that earlier. Is that the only reason that we’re doing, it’s just to save on bandwidth?

[00:32:52] Adam Silverstein: And to speed up the loading of the page.

[00:32:53] Nathan Wrigley: Right.

[00:32:54] Adam Silverstein: So, and just to Expand on that. It’s not really just about the speed of the page, but it’s about the experience of your users visiting your website. If you have slow images that are too large for what you need, then you are giving your users a poor experience. There’s all kinds of studies that show that by improving the loading time and responsiveness of your website, you get better results. So whatever those goals may be, conversions into newsletter subscribers or people who purchase products, or someone who reads more than one article on your website. Those things are all enhanced by having a better user experience. And so if we’re talking about optimizing images, we’re really talking about creating a better user experience.

[00:33:33] Nathan Wrigley: You’re wearing your Google t-shirt today.

[00:33:35] Adam Silverstein: Yeah.

[00:33:35] Nathan Wrigley: So you know you’re doing all all the right things.

[00:33:37] Adam Silverstein: Google google loves open source.

[00:33:39] Nathan Wrigley: You are not on the search team, so maybe this question is not gonna be one that’s right in your wheelhouse, but I’m gonna ask it anyway. SEO and search engine results. I’m presuming there is a benefit because you know, in the last couple of years we’ve all been thinking about Core Web Vitals and that’s been a big push from Google, and everybody’s taken that very seriously.

[00:33:56] Adam Silverstein: Yes.

[00:33:56] Nathan Wrigley: And, you know, is there a benefit to your search position, should you take the time to do images right?

[00:34:04] Adam Silverstein: Yes, and I’ll say that it’s only really a very small benefit. Really what gets you the best position in search results is having the best content. And if I have an article about Bartlett pears growing in San Diego and someone Googles it, and I’m the only article about that on the web, they’re gonna go right to me. No matter how performant my site is. Where performance comes in is as a waiting factor, like many, many other factors as a signal to Google. Just like HTTPS, mobile support. These are all signals that Google has announced.

But, uh, you’re not gonna be like, penalized for poor performance. It’s more that if all other things are equal, this could be a weighting factor that would bump you up, having a better experience for your users. But that really shouldn’t be your motivation. Your motivation should be creating a better experience for your users first, and then secondly better achieving your goals once people reach your site.

So someone described it as a funnel, right? People think of web conversions as a funnel. You start at the top, all the people who see your search results, and then it gets smaller. All the people who click on your search results. And then, all the people who actually do something on your website. And then finally, this tiny, small number of people that convert to being paying customers. And I, and in my hands here just for audio, I’m going from wide to smaller. And where the user experience parts helps, uh, improving user pitch is not up here at the top in getting more search results. It’s here where once users reach your site, then you’re gonna really see that benefit. And so, that’s where you should think about where the benefit comes. It comes from turning those visiting users into actual, whatever your goal is.

[00:35:36] Nathan Wrigley: Okay, I’m gonna go slightly off piste. Google does a fantastic job. I use Google photos, and Google Photos is able to identify the objects in my photos. And so I did wonder if there was a potential Google search. So, for example if I have a website I don’t label, I don’t put any metadata on my images at all. Does Google do any of that? This website is full of trees, and so if I search for a particular tree.

[00:36:05] Adam Silverstein: That’s a really good question. I don’t know the answer. I would say, first of all, please put alt tags on your images. Don’t do that. Because there’s a reason we have alt tags. Actually someone, so it’s the reason, the big reason is of course, accessibility, right. People who are visually impaired can’t see your images. It’s nice if they have a description of what they’re missing.

Someone actually today came by and said, do you think there’s a way we could take image recognition and make it so that non sighted users touch over the image, they get a description of what they’re seeing. So, if you’re a non sight user, I don’t know if you’ve ever seen people, a lot of times they actually use a touchscreen that’s haptic.

[00:36:37] Nathan Wrigley: Yeah.

[00:36:38] Adam Silverstein: So they can move over and they can feel the buttons, right. It’s not just, having the buttons described to them in text, but literally a screen that as you’re moving over elements of the page, it bumps up. So you can actually feel, oh, there’s a button. That’s where the home button is, and then they can tap it, right? So they already have this technology, screens that are like this, and of course visually impair people are, are often used to reading braille, so they’re very sensitive with their fingers.

So imagine something where you have a picture of trees and a person and a visually impaired person could move their hand over and say like, oh, there’s the person and there’s trees back here, and they’re feeling the image. Like that would be amazing. And that would again, require that same visual recognition of images.

[00:37:12] Nathan Wrigley: That is a truly, astonishingly good idea.

[00:37:14] Adam Silverstein: Right, I had never heard that idea.

[00:37:16] Nathan Wrigley: That is just mind blowingly clever. Let’s hope that somebody can build that.

[00:37:21] Adam Silverstein: Yeah. There was another, just one more that someone posted recently to Twitter, you might have seen, but it’s the, it’s like the DALL E tools that are out now with the image generation. So someone has built a WordPress plugin in Gutenberg where you type in, like you’re working on your post and it’s about Bartlett pears in San Diego. So you type in like Bartletts flying across the San Diego Bay, and it generates an image for you of that. You’re there in Gutenberg and you just insert it.

[00:37:45] Nathan Wrigley: The whole AI piece. Rewind the clock just two years, and I thought it was, no, this is going nowhere.

[00:37:51] Adam Silverstein: Right.

[00:37:51] Nathan Wrigley: At no point in the future will you be able to tell a computer to create an image or a piece of art, or replicate, well, almost anything, but especially the things which don’t exist. You know, the triangle dog or whatever it might be.

[00:38:04] Adam Silverstein: Yeah.

[00:38:05] Nathan Wrigley: And, and yet you input it in and just in the space of two years, it’s gone me laughing at it. To me, just being in awe of it.

[00:38:13] Adam Silverstein: It’s amazing.

[00:38:14] Nathan Wrigley: It’s truly amazing.

[00:38:15] Adam Silverstein: Yeah, so I use one of those tools to generate all the images in my slideshow for my presentation yesterday. So I have like hilarious images, like a raccoon surf boarding and a, a goat driving a race car.

[00:38:25] Nathan Wrigley: Yeah.

[00:38:26] Adam Silverstein: Impossible things, but they look, you know, if you look closely, you can see some weird details. They’re very, very accurate.

[00:38:32] Nathan Wrigley: There’s lots of them as well. I believe the one that captured my attention recently, I think it was called Mind Journey or something like. It’s implementation is to create art.

[00:38:43] Adam Silverstein: Right.

[00:38:43] Nathan Wrigley: So you give it the, the thing that you feed it is, I don’t know, I’d like a picture of a sunset that resembles Rembrandt, with a red sky to the left and so on. And it completely does it.

[00:38:54] Adam Silverstein: That’s amazing.

[00:38:54] Nathan Wrigley: Yeah, an absolute miracle. Adam Silverstein, thank you so much for joining me on the podcast today. I really appreciate it.

[00:39:00] Adam Silverstein: It was fun. Thank you.