 One, two, three. All right. Everybody here OK? Sounds good. All right, thanks, everyone, for coming out of Pact House today to talk about an eye on acceleration, how you can optimize your images to make your Drupal site load faster. So my name is Martin Anderson Klutz. I work at Acquia. I've done some certifications, particularly for Drupal, but for some other things as well. And potentially, most importantly, I go by a man clue on social platforms and also Drupal.org and Drupal Slack. So if you need to get ahold of me, those are all good options. So first question might be, is it important to have a website that loads quickly? Well, whatever success looks like for your website, you're going to get more of it if your website loads quickly. So e-commerce sales, getting people to sign up for your newsletter, filling out a contact form. All of those are things that people are more likely to do if your site loads quickly. And there's lots of data to support that. This graph from this year actually demonstrates that. It's a pretty clear relationship. But we can also see that it's a problem that's been growing over time. So if you look at this Web Almanac chart, it clearly shows that over the last 10 years, websites have been getting bigger and bigger. And by far images are the worst culprit. So I see a lot of tutorials and have heard a lot of presentations on how to make Drupal itself render pages faster. But most likely the biggest issue on your website if you have a performance problem is actually with the images. So today, tried to break it up into sort of these three clear areas around how you can optimize how your site handles images. So number one, being to defer the image load. Second, to size your images. And third, to optimize the images. So being able to defer an image basically just means don't load it until it's actually within the viewport that the user can actually see. So we know that users most often don't actually scroll all the way down for most of the pages that they're on. So don't load all the images if they're never gonna see them. And from an optimization standpoint, you'll never do better than not loading an image. So the good news is that lazy loading, which is really the more common name for this, Drupal actually does out of the box for you. Since about 9.2, it by default implements a property that initially just Chrome, but now other browsers as well, will use to automatically lazy load the images. Now if you want to have more control over it or to be able to use it for other things like video players, which is highly recommended, then you can use contrib modules like blazy. There are others, but that's the one I've used the most. And I'll point out something here. There's a convention that you're gonna see through the presentation and I will make these slides available. So here blazy is a link to the actual contrib module page. It's in green because it's Drupal 10 ready and it's bolded because it's stable. So you'll see a bunch of other modules that are linked to and you'll know just by looking at that, whether they're D10 ready or stable. So the next major area is around the sizing of your images. So there's no point in serving pixels to users, forcing them to download those pixels if they're never gonna see them. So the example that we can see on screen is around a cropping. So let's say that your site was only showing that area that's in the square. So if you do that cropping via CSS and force the user to download all those pixels around it, they're probably only seeing less than half of the pixels you're forcing to download. So within this sizing, there's actually three secondary concepts that we're gonna cover. So remember one, cropping, which we've just seen, also shrinking the images and then using responsive images as well. So for cropping them, we've already kind of covered what the concept is. So I'll jump right into the contrib modules that you can use. Crop API gives your editors some manual control. So if you don't use that, it's always gonna be kind of around the center. Crop API allows your editors to sort of designate where the image should be cropped. So you can use focal point where they can set one point within the image. And then regardless of how that's gonna be sized, it'll always be around that focal point. Whereas image widget crop gives sort of manual control for each image style. So which is the right answer is gonna depend on your editors and how much manually control they want. I find focal point is usually enough, but that's a conversation I have with your editors. So sizing is really around making sure that you're actually serving the images at the size that they need to be. So no point shoving down a 800 pixel wide image if it's gonna be displayed at 200 pixels wide on within your layout. So usually in Drupal, you can do that just with image styles. So again, nice that that's built in a core. There's a link there for the user got on Drupal.org. Basically you just wanna set up image styles for every proportion and size, how the images are gonna be used within your website, but also keep in mind they're retina devices. So initially it was Apple devices, but now there's lots of others. Sometimes we'll do sort of like pixel dabbling or even on mobile devices, it can be like a three or a four X. So it can be complicated. You don't necessarily, you wanna have those available, but you don't necessarily wanna send like, again with our example of a 200 pixel wide image, you don't necessarily wanna send something that's 400 pixels wide to devices that aren't retina devices, which is why it's nice to have responsive images also built into core. They can be a little complicated to set up. So I've got links here to two different tutorials because there are really sort of two different methods that are supported by core. One is called image source set. So it's basically providing, you basically tell, you provide markup that tells the browser what proportion of the sort of overall viewport it needs to size those images to and then you provide a bunch of different image sizes. And then the browser itself will figure out which image that it needs to grab and then download only that one. So in some ways that's easier to set up, but using the picture element actually gives you more options. So you can do things like what's called art direction. So you could say have the same image as a square on mobile device, but let's say very wide on desktop. So you can have some of those different controls that you can embed. Also with a picture element, it's easier to have sort of fallback image formats. And we'll talk about that a little bit later on. Now, if you are new to these, there is a contrib module called easy responsive images that is meant to sort of provide a lot of this capability out of the box. I haven't personally used a lot, so I can't vote for it, but we can see by our convention that it is both D10 ready and stable. So it does have that. All right, so last major section that we're gonna talk about is really optimizing. So making the images themselves as efficient as possible. And within that, we're gonna talk about using the right format as well as doing some processing to sort of strip out any unnecessary data. So the first image that we're gonna talk about is WebP. So WebP is sort of a more modern format. It's what Google calls a next gen format in its light house scores. It does support both continuous tone and line art. So if you're not familiar with that, those sort of basketballs on the right will help you to understand continuous tone is kind of like, more like what we think of as like a photograph, whereas line art could be things like logos or charts. WebP also supports animations and it can also, or it has support in core, but doesn't provide a fallback if you're using the core WebP format. So that is the reason why you might want to use a contrived module to use WebP in your site. So there are two modules. There's WebP and image API Optimize WebP. Unfortunately, neither of those are stable or have Drupal 10 support yet. This is actually how I first encountered WebP. So downloading images from the internet and then realizing that I couldn't put them into like Google Slides or they wouldn't open up in certain applications. It's kind of a side effect you should be aware of. So WebP, actually, I'll just go back for a sec. If you see top right is pretty widely supported in terms of browsers, but for desktop applications, definitely less so. So that may be a plus. It may not be something to be aware of. An emerging format is AVIF. So this is sort of the static image equivalent of the sort of growing in popularity movie format called AV1. The sort of press around it is that it's supposed to give smaller images than WebP. I've seen some indication that that may be more true for sort of photograph. Yeah, continuous tone images as opposed to line art. So as with a lot of things that I say, really test them out on your own site with your own images and see what works best. AVIF supports sort of like 10-bit images and a few other things, animations as well. Because it is a newer format, it has less browser support. So you can see the difference between 96% and 71% is pretty massive. If you do wanna use it, there are some module choices. So there's the AVIF module, which is really meant for your response of images, so like page header kind of an idea. There's a companion module called AVIF lib that basically adds a local library to do the conversion for you. And then you've got some that work with the image API optimized module. So image API optimized AVIF currently is dev only but does have Drupal 10 support. It's actually maintained by Sasha Eganberger, who is the maintainer of GIN. So that seems like a safe bet. Image API optimized AVIF and WebP beyond being a mouthful. It's kind of cool because it generates both AVIF and WebP plus a legacy fallback. So it kind of covers the full gamut there. So the next thing we're gonna talk about is SVG images, which is really based around vector markup. So the idea being that you're really defining outlines and then potentially giving them things like stroke and fill as opposed to sort of pixel by pixel representation. Because of that, it works well for things like, you know, again, charts, logos, a lot of those kinds of things. Internally, it's actually XML based and so there are solutions that will actually give you the option of either linking to that as a separate file or even injecting that inline as part of the actual page markup. Unless it's a really complex logo or whatever it is that you're trying to represent, oftentimes an SVG will be a small fraction of a PNG so it's a very efficient format. But the caveat is that unless you're starting out with vector artwork, it can be really time consuming to do the conversion. So if you're not familiar with what vector art is, talk to your friend and designer. But usually it's like an illustrator file, some PDFs will be vector, some APS files, you know, that kind of an idea. Now there are three good options in terms of getting your Drupal site to work with SVG. All of them have stable releases and two of them are D10 ready. So that on top of the fact that, you know, 99.97 browser support is pretty ubiquitous so definitely if you have a lot of these kinds of images then SVG support is highly recommended. So to optimize the images really to make the files themselves as efficient as possible, the main thing you're gonna rely on is this Image Optimize API. And it's gonna rely on other modules to actually do the work. So, and it depends on what source you wanna use. So Image Optimize Local Libraries is going to use sort of different libraries to actually sort of perform the optimization. There's a nice comparison blog here and I'll just quickly click over there so you can see they've done some nice work in terms of analyzing a variety of these different binaries and then actually comparing the results. So the interesting thing here is that PNGQuant provides dramatically higher rates of, you know, processing savings but it does that by using a lossy compression. So whether or not that's acceptable to your individual site is again something you're gonna wanna test. These other two, these other two rely on third-party services. So re-smush it to something most sites can use for free. I think there's sort of like a usage threshold beyond which you have to pay for it. Kraken I think is only paid and does a little bit more. To me the big drawback of the third-party services is that your editors will probably see a noticeable lag between when they hit save and between when like the header actually starts to display which with enough training maybe is fine but something to be aware of. So we've got this sort of primary framework of those three key concepts and then our secondary concepts here and I thought it would be useful to sort of quickly show an example of what the optimized markup could look like. So if we can see here, so in this case we're using two different breakpoints and then we've got, we're serving off up both WebP images and then a JPEG as a fallback. Again, Drupal with a little bit of setup is doing all the hard work of generating out these five different image variations and so that's good news for anyone who's a Drupal site owner. With a little bit of setup you can get it to do all of this work for you so that a variety of different devices are getting the most appropriate sized image. A couple of other options I thought I'd mentioned. So if you're using a web host that uses Apache as the web server, you can use the HE access file to set longer cache lifetimes. So Google in particular will recommend that as one of its recommendations for things like Lighthouse. You can also set SVG files, even your fonts to be compressed in there. Best practice, many people say is to use image magic instead of GD because it's not using your PHP memory. So that can lead to faster processing, better distributed load for things like memory, but again, test it and see what works best for your site. And speaking of testing, here's some tools I like to use. Webpagetest.org is probably my main go-to, but I also use page feed insights because particularly if you're concerned about performance for SEO reasons, you definitely wanna hear from Google what they think in terms of your site speed. Lighthouse for local development obviously is gonna give you something roughly equivalent, but personally I like to hear from Google using their infrastructure, what it thinks of the page speed. The other thing I'll mention about testing is definitely test before you make any changes, so you have a good baseline and then as you make each test, do testings to validate that it's actually improving things and that it's roughly equivalent to sort of the level of impact that you were expecting. GTMectrix is one that I haven't personally used a lot, but has been mentioned to me as another good option and Expert Page Speed, I haven't used a lot. It's a newer one that I've heard of, but the interesting thing about it is that it will actually do a crawl of your site so you can get sort of a broader sense as opposed to sort of like cherry picking individual pages, excuse me to test. Now if money is no object, obviously there are other ways to leverage other organizations to sort of do a lot of this heavy lifting for you, so if you can use a paid CDN like Cloudflare or Akamai, they have services available that will sort of automatically optimize your images for you. OptiPick is another third-party service and there is also a Drupal module specifically for using that and then a newer one that I've heard of is this TwikPix, which has actually a number of different ways that you can use it to optimize your images. It'll actually do some cool stuff around sort of like AI to sort of automatically figure out the focal point for an image, but right now it has no sort of like formal path for Drupal integration, so you'd kinda have to roll that on your own. I've got some extra resources here, so some of these are blogs that I wrote specifically around individual parts of this whole idea of optimizing your images. There's also a link to the page weight article from Web Almanac, so we saw those charts at the beginning, a couple of articles about AVIF and how that compares to WebP and then if you are interested in sort of going down the rabbit hole about SVG and all the cool things you can do with it, there's a good article there from Smashing Mag as well. Please do join us for the contribution opportunities through the week. Drupal definitely relies on folks like yourselves contributing to make everything better and also please fill out the survey using the mobile app and also as a reminder, there's a conference survey as well as the individual session surveys. So with that, I will open it up and also reiterate you can reach me at Mancloo and I will be posting these slides via Twitter later in the week. Any questions? Don't see, oh, there we go. What was the first part? CLS problems? Oh, cumulative layout shift is probably what that means. Yeah. So yeah, definitely you wanna have sort of those width and height properties on your image to help with that. But the other thing to keep in mind is that you don't, there's probably no value in using the lazy loading for images that are like at the top of the viewport and that's really like because it's cumulative layout shift, things at the top are gonna give you more CLS than lazy loading things further down. So usually things like a hero image, I'm not gonna lazy load because it's gonna load right away anyway. So yeah. Because you don't have like a decent width or height on your image. So you're not able to put width and height on your image? No, but when I wanna scroll like for example to a contact book at the bottom of a page and then you have like several images lazy loading and you don't have a width or height specified exactly. Then they just like assume the width is the same as the height and then my scroll trigger is wrong at the end of the page. Then I get further down to where my anchor is exactly. So that's kind of the problem that we had and we had to solve it by writing a helper function in Drupal to manually calculate the width and height and set it on the image. So I was wondering if there's an easier solution to that. Because it doesn't. If there's some way to leverage, I don't know exactly how you're embedding those images. Obviously, if you can keep track of those as they go into the CMS, that feels like it would be easier but it sounds like there's probably some other factors that play in your specific case. So, sorry. It's gonna happen. Hi, we had an issue in our project with lazy loading because it depends on Java scripts, loading scripts and other scripts were loading before and were differing the lazy loading script. And the issues were that the image is visible by the user while loading really slowly because of that. What's your opinion on that? So the nice thing about the lazy loading that's performed by core is that it actually uses that property on an image tag as opposed to a JavaScript. So potentially if you could rely on that as opposed to having to use something that's more script based, it sounds like that might help. Any other questions? Right here in front. Do you have any experience with the HEIC format? The- HEIC. From Apple. High efficiency image format, I had to Google it. I don't personally have any experience with that. To my knowledge, it's not really like a web format. Yeah. That's why I ask for- Yeah. I feel like it's probably one of those things that if anything you're wanting to convert from HEIC into like a WebP or ABIF, something else, so it's something you would wanna see. I have to imagine there's probably some at least patch or something like that that you could get for like image magic or something like that or like a preview build that you could try out that would do that conversion. But if it doesn't exist already, it has to be coming because lots of people wanna- It's quite new, so yeah. What's up? Sorry, I can't see your mouth move, so I can hear. Yeah, so I'm sure it's something that's on its way, but yeah, there could be a technology gap there. Yeah, sure. Thanks. The questions, anything in the app? All right. Well, if there are no other questions, by all means again, feel free to reach out if you think of a question later in the week. And thanks everyone for joining us. Can I ask a question? Oh, yeah. I have one question I was thinking of. So in your sample code, you had quite a lot of markup. I can imagine for large images, that's going to, you're still gonna have a benefit, but you're still gonna be pushing quite a lot of markup, and for small images, is there a danger that your markup is more than you're saving on the images? And I wonder if you looked at solutions like where the website is querying what the browser can accept, and only sending the markup for images that you know will be acceptable. I mean, I feel like it's, in a lot of cases, it's really, you have to follow what works best for your individual site. So I mean, if you're talking about tiny images, then it probably doesn't make sense to make those responsive. But I feel like for most images, like you're probably talking about less than one K of markup, like even what we saw. So to say, are you saving more than one K to serve like a four times written image versus a one K, you're probably saving more than one K. So if not, clearly, you don't need a responsive image anyway, so. Thank you.