 So today's topic is about user experience, web performance, and search, and also potential future initiatives in Drupal. So for a long time, I'm sure you've attended different sessions at DrupalCon talking about web performance. You've probably worked on areas of performance yourself. And many of these conversations have been focused on the back end. So we're going to be talking about front end performance in particular here and giving you some concrete steps and also some ideas that you can explore. So let's kick this off with some basic introduction. So I'm Tim Lennon, my username on Drupal.org in GitHub and elsewhere is Hestanet. I'm the CTO at the Drupal Association. So I lead the engineering team that helps the community build Drupal by providing all of the tools on Drupal.org that let us collaborate together. So I'm thrilled to be here with Ben and I will let Ben introduce himself. Thank you, Tim. I'm Ben Morse. I'm a developer advocate at Google. My job is to help the web be faster and more beautiful and to make it easier for developers to make great sites for everybody in the world. So it's wonderful to get involved with the Drupal community. I've made Drupal sites before and it's pretty exciting to get to meet you all today. Awesome. So I also want to give a shout out and a thanks to some faces that some of you may recognize from our Drupal community. So these three folks, Wim, Fabian and Neils are all experts in Drupal performance initiatives and Ben and I have been collaborating with them a little bit about some of the content we're talking about today, about possible performance considerations for the web in general and for Drupal specifically. So just want to give them their thanks and their kudos for contributing to the discussion that we're going to have today and for all that they've done for performance in Drupal in the past. With that, let's talk a little bit about why performance matters. So let me hand it to Ben to talk about the sort of general use case and then I'll talk a little bit about Drupal and Drupal's history as well. Thanks a lot Tim and yeah thanks also for the folks who've been working with us that Tim just mentioned. You've had a great time just like brainstorming ideas and dreaming up ways to make performance easier by default for everybody who uses Drupal, which is of course a powerful idea because Drupal is a very popular CMS as you know because you use it. So okay onto performance over here, you can go the next slide over there. Thank you very much. You want people who use your site to have a wonderful experience and forgive me this is review in some ways but it's a good intro to performance and why it actually matters. You want to go to your site and of course it should be beautiful, easy to find information, relevant information, well designed, it should feel good to use and part of that is being fast. So if a site is slow, people tend to like it less. If it's fast, it just feels better. It's like if you're looking at something on your phone, if you're looking at messages or loading up an app or whatever, TikTok or a game or something, you figure it's going to appear almost immediately. The web is the same way. People don't say oh it's the website, I can wait five seconds for this to appear or 10 seconds for this to appear or sometimes 15 seconds for this to appear, they just get irritated. If you can go back to the previous slide, you're giving away my next moment. Okay, now you know the next part is going to surprise you. So if you're making a website for people that only have 4G connections and are on the latest super nice iPhone or Samsung, Galaxy 20, whatever it's called, that's great that a lot of people out there don't have these things. I think the vast majority of phones that are sold in the world these days are much lower powered than those phones. And if you use a phone like that, they tend to, for example, have a processor that runs five or 10 times slower than on those super nice phones, in part because they're slower processors, in part because they're throttled so they don't get too hot and the phone doesn't melt in your hand, which is a bad user experience, by the way. So phones out there are mostly slower and lower powered. And, you know, I live in New Jersey near New York when I used to commute to a job back in the olden days. I used to commute on a train and I had a 40-minute ride during which I shared my Wi-Fi with a thousand other train passengers and it was horrendous. So I knew that some sites just were not going to load at all or load very slowly. Maybe I was trying to buy a plane ticket or pay a credit card or even work if my job, Lord forbid, and it would be sometimes impossible to do these things. You knew that certain sites were going to load great. Certain sites weren't. You also know if you're a programmer as you are, if you're a developer as you are, that usually the reasons these sites load slowly are not good reasons. It's not because they're loading crucial code that must be there or loading images that are as small as possible. They're often loading things that aren't really being useful at all. It's a frustrating experience. So to build everybody in the world at all times, it's important to have your site be fast for those reasons. And, in fact, a lot of folks don't have 4G access. A lot of folks in the world end up with 3G connections. And next slide, please. The last app that I saw, surprise, saw the average web page took 12 seconds to load on 3G. 12 seconds is a long time. You may be looking at your phone for those 12 seconds and decide, you know what? This is not going to work. I'm going to go to something else. I'm going to go play Among Us. Something else is going to happen. But it's actually worse than that because, in fact, a lot of people in the world don't have 3G connections. Next slide, please. The last app that I saw showed that 40% of mobile connections in the world are actually 2G connections. And I know this feels because I used to travel, sometimes we used to travel places because there were planes you'd go on and go places back in the old days also. And I had T-Mobile, which is a fine carrier. But T-Mobile, in their kindness, would give me a free international data, but 2G only. So most sites didn't load, period, or load it on Google Web Lite in lighter versions, and it wasn't good. So next slide, please. Make your site faster. It's important. Look at this guy over here. He's looking at your site loading on his phone. It's not loading. He's taken to smoking and drinking to alleviate the pain of the experience. So to make this man's life longer, you should make your site faster. That isn't a reason. I don't know what it is. So beyond this kind of silly beginning over here, there are actually a lot of studies out there. There's data you've probably seen before. Next slide, please. Some studies you might not have seen that are more recent. I think these are from a couple of years ago now. They're pretty recent. So one study was that a two-second delay in content appearing raises the satisfaction and lower people's intent to return to the site. Another study, they took buttons and made them slower and slower to make users angry. And it turns out that they changed the speed of response from 70 milliseconds to 100 milliseconds. People noticed that. Like the site's less, when it got as far as 150 milliseconds, then people rated the quality of the buttons significantly lower. So they just thought these buttons are no good. They're not working. Usually you press the button on an elevator. It lights up immediately. If you press the button on a phone or a computer screen or tablet, nothing happens for a while. You think, is this thing broken? This computer is no good. Also, another study showed that mobile users tend to lose their attention after four to eight seconds. So after a couple of seconds of sites loading, they'll go do something else. Next slide, please. Of course, you're thinking about not that, but you're thinking about money, probably. Like, well, who cares about the users? How about my profits of my business? Next slide, please. Well, a lot of studies also have shown, of course, that of sites that people like more, they spend more time on and spend money on or convert on more. For example, a recent study showed that mobile sites that loaded in less than or equal to two seconds had a 15% higher conversion rate. So that's pretty significant. By making your site load quicker, you're going to have people convert more. That's a lot of studies have shown this. You can't always guarantee it, but in some cases, I've seen conversion rates actually double. So you can get a lot from these. Next slide, please. Also last year, eBay worked on speed around the company and tried to improve their front-end performance, and they found that for every 100 milliseconds improvement in search page loading time, there was a 0.5% increase in the add to cart count. 0.5%, not huge, but imagine if it was a full second of loading time, if you get a 5% increase, but even a 0.5% is significant. Again, some cases makes no difference if your site is just like not fun to use anyway. Some cases I've seen people say metrics actually double or triple. Things got much faster. They adopted AMP or PWA, for example. So it can make a big difference. So for all these reasons, try performance today. And now back to Tim to discuss the historical things about web performance. Yeah. So thank you, Ben. It's really interesting that when we often conceive of improving conversion rates on whatever kind of site we have, we tend to think about the funnel design and our calls to action and the visual user experience and user journey without realizing the benefits we're leaving on the table just from pure performance optimization or without realizing that we can do these things together. So I think it would be a really good opportunity to both please your developers by saying, hey, let's fix some technical debt, let's improve performance, and at the same time, let's improve our conversion rate for our business users. But yeah, I want to talk a little bit about history of web performance, where we've come from, where we're going, and why we're framing today's discussion the way that we are. So as early as 2007, Steve Sauders observed, at least 80% of the time that it takes to download and view a website is controlled by the front-end structure. It's not necessarily the actual sort of server latency, the CPU usage and memory, even necessarily kind of like the HTTP request management. A lot of it is about the actual arrival of the web page and then being rendered out in the browser, the CSS, JavaScript, all those other components coming together. Now if you don't remember or recognize this name, Steve Sauders was probably the first web performance expert out there, worked at Google, at Yahoo, I think currently works at Fastly CDN. So there's a source in the bottom if you want to read more about this sort of general history of web performance and these observations. And it's interesting that going back now 13 years, it was clear to experts like Steve that front-end performance was perhaps even the bigger factor than back-end performance. And yet we have found ourselves primarily focused on back-end performance. If you manage a Drupal engineering team or you're a Drupal developer or a DevOps person who supports Drupal, you are probably familiar with this book. High Performance Drupal is sort of the book. It's the Bible when it comes to performance in Drupal. And the addition is getting a little old at this point, but it still has a lot of really valuable things. So in 2013, Jeff Narayan and Nathaniel literally wrote this book with all of the details about Drupal performance. And what's super interesting is even back in 2013, if you look at the table of contents, a huge portion of this was focused on front-end performance about HTTP request limits, image management, minification, CDNs, all sorts of things. Things that we're going to continue to talk about today. Because in my experience and probably in the experience of many of you out there, we skipped this chapter in many ways. We were like, gosh, it's so much easier for me to look at my NGINX configuration at Apache, at my varnish caching layers and things like this. And not so much worry about things on the front-end that maybe I have less control over or that are so influenced by my end-users, who are the ones uploading images and things like that, that we haven't focused and felt like we had the control where we needed to. So why the heck focus on front-end performance now? Well, partly because it's neglected and partly for some reasons that Ben is going to talk about in terms of what he and the team at Google have measured about what's on the web. Which I guess I will now do. So web performance, the basics. Yeah, like Tim was saying, but sometimes it's something to look at back-end performance and it matters a lot. Of course, server time, time to first byte, these things are all important. But for a lot of people on the web, a lot of sites, the thing you can do to make your site faster is often really simple. Often you can do it in an hour and often makes a big difference. So usually is that low-hanging fruit. And we'll discuss that actually with Drupal.org in about a minute. But first, go to the next slide, please, over here. I mean, you can do a lot of elaborate things also as a programmer with front-end performance. You can look at these traces over here. I do things like make sure that your JavaScript tasks are all shorter than 16 milliseconds. So you have a chance to have the browser paint frames every 60, 60 times a second for a smooth animation. You can do a lot of things like that, code splitting, bundle reduction, service workers for caching. But the basics are still basic and still matter the most on the web. Next slide, please. I actually looked at this last night. You got the next slide for me there, Tim. Oh, there we are. Yes, there it is. There it is. Thank you very much. This is from the web, Almanac, which is created by Rick Biskomi and some other folks like that. If you press a button there again, you'll see these wonderful purple bars or I guess rectangles flew out there. Notice that 25% of sites on the web on mobile and desktop load up more than 3,000 kilobytes of data. And the top 10%, or rather the worst 10%, the heaviest 10% load more than 6,000 kilobytes. And that top 10% heaviest 10% load on mobile almost 5 megabytes of images on desktop, more than 5 megabytes of images. So there's a lot of lying fruit out there. I mean, very few sites in images that are that big and that numerous. And notice that a megabyte of JavaScript is also pretty common out there. It's usually for most sites that are just content sites or mildly interactive sites far too much JavaScript. Next slide, please. Simple thing to do really is just you want to really load stuff that's visible above the fold as fast as possible. I can't say it more simply than that. Above the fold, meaning here's your device. This is like a phone. My hand is now a phone. Now it's a computer monitor. Now it's a phone. So the stuff over here is considered to be above the fold. The stuff that you have to scroll down to see, we're going to load that soon too, but it's not as important because you see these things first. When the user sees stuff over here appear quickly, they feel like the site is live and it's there. Then things that are down there below can load whenever they load. It's not as big a deal. So to make that happen, there are two important things to do. You want to avoid loading other stuff before that. You're loading lots of JavaScript that doesn't really matter for the stuff people have to appear. It's better to load that later as long as things are interactive, not too slowly. If there are videos or components or chat widgets or images that are below the fold, it's better to load those things later because as they load, they'll concurrently slow down things and loading above the fold. Now if you hit a button there, you see a little phrase drop in there. And of course, to load those things with as few requests and as few bytes as possible. Less requests means less network latency, especially on mobile devices. And less bytes means, of course, things are faster. As I can mention, also less bytes means it's better for the environment. You're storing less things in the servers. You're sending less things around the world using less energy and actually using less of a carbon footprint. Next slide, please. So when I say stuff, what kind of stuff do I mean? I mean things like images. We just saw that images are actually still the biggest thing byte-for-byte on the web. We mean things like JavaScript, less code. That matters in a couple of different ways. One is to simply bytes over the wire, which makes things load more slowly. And also the time required to actually parse JavaScript can be pretty significant. And then, of course, CSS, which usually has less bytes than images or JavaScript, I hope. But CSS also often render blocking. On the CSS loads first, before images or visible things, until loads, nothing else can be displayed. So it can be pretty significant, especially if the network requests for CSS is delayed for some reason. And then, of course, fonts, videos, other kinds of things that also can matter as well. But usually it's images and JavaScript and CSS. And I want to show you an actual demo over here. We're going to do some live stuff. So I'm going to share my screen. So we'll do a little bit of a swap brew here. So I'm going to stop sharing. So Ben can bring up a little bit of a demo. As we call it in the biz, the old swap brew. Yes, indeed. And as Ben is getting started, I'd also love it if you would think about image and JavaScript and CSS usage on some of your own sites. If some of what we're saying is beginning to raise some of those questions, again, as a reminder, feel free to drop into that Q&A and begin asking those questions. And we'll be happy to get them as we get towards the end here. All right. Go ahead, Ben. Thanks for that, Tim. And if you have observations of your own about how to make things better, please add those things in there as well, because you've worked on this stuff before probably too. So Tim told me I could use Drupal.org as a test site over here. I usually use Google sites because I don't want to pick on anybody else. But Google does notice a lot of Drupal sites. There are some but not very many. So Drupal.org, we'll look at that for a minute and just see, okay, if you're going to use Chrome DevTools, for example, to analyze this for performance problems, what would you find? So what I do with the site is I load it up over here, Drupal.org, for example, I go into DevTools. I will do a couple of things here. One is I will actually throttle the speed to a fast 3G connection, simulate how it would look on a mobile device. I might be able to do this. If I tried this before, actually, I couldn't get into the site on my mobile simulator in DevTools, but we'll try it and see what happens. If it fails, we're turned to the desktop mode. So I have to throttle it. Sometimes I will want to go and capture a filmstrip as we go over here, which, oh, no, I can't find the filmstrip. Filter. Why have I lost the filmstrip? There it is. Okay, capture screenshots over here. Then I will just go ahead and delete the DOM so we can start over and see what loads up, when it loads, and when things appear on the screen. It's not complicated. When you things appear in front of us there, it's good. When things aren't appearing, it's not good. Of course, interactivity also matters, but really appearing matters. So as we load the page over here, so now it's loading up some stuff. You see various things happening down there, and now it's not too bad. We've seen worse. So that was about five seconds before anything appeared at all. And then somewhere around in our filmstrip, six, seven, yeah, about six seconds over here, we saw the actual video thumbnail appearing. So what made that actually slower? Let's go ahead and look at what that was. On the right here is the waterfall. This shows all the things that were loaded and when they loaded. At the top over here, HTML for the site, that's good. And then a lot of CSS files loaded, they were all very small. Normally it's good to concatenate those things into one CSS file, but in this case, we're using HTTP2, which means it can load a lot of requests concurrently. That's totally fine to do that. There's a lot of requests for SVGs, other kinds of things we're not really going to see for a little while. That's not ideal. SVGs, lots of different icons are being loaded up. And then, interestingly enough, we have these bigger images over here that are loading up. So this is a 238K image of Boston City Hall. It's a nice city hall there. It looks like 16 seconds to load that in the waterfall. It took a little while to load. The weird thing about this is, well, before I say that, down over here, also a nice soccer image, which is 400K. A Pinterest image is 413K. A bunch of images. So where are those images on the site? Let's look at the site over here. They're not over here. I don't see Boston City Hall yet. They aren't over here. There's a nice picture there. Wasn't that one? Where are these images? Where are these images? Where are these images? Where are these images? Where are... It's a long way to go. Here we go. Ah, the city of Boston. There it is. So this is a very, very small image. That's 300K plus. I'm just guessing if I look at this image, that we'll see that it's actually loaded in a bigger version. There's the link. Is there actually an image in the link? And the div. Look at all these classes here and things. Here it is. Here's the image. It looks like actually it is, in fact, shown at about a third, actually one ninth, one third, both mentioned. So about a ninth to size, it actually it is stored in. So this image is a lot smaller. It will load a lot faster. It can be about 20K, probably an image to size for mobile. Notice also the image here is just the same image for any device. There's no responsive image here. So if it was, of course, a desktop machine, you want to have a bigger image, but it isn't bigger. It's the same image for everything. So actually, those images in this image slideshow down here load before things up here load. Because this here is actually a YouTube video. And YouTube has a lot of JavaScript, unfortunately. It's actually not the best thing to put up top because it'll be slow to load no matter what you do. It's YouTube. Of course, it's possible that your user will have gone to a video recently and it'll be cached in their device, in which case, it isn't that slow after all. But it's better to show a thumbnail over here of the video. And then as the video actually loads, then to, you know, pop that up when it shows up. So back over here, these images should be loaded later. And actually, we now have this new feature in Drupal, which leaves those images automatically, which will be a huge help for us over here. It's not implemented over here. There's no easy loading happening here. But now in Drupal, you can do that, which is kind of neat. That's all thanks to recent work that happened in Drupal. So going down over here, you see some more things. I'll go over all this stuff. I'm looking for the first JavaScript to appear. We can then just filter to find that over here. This is the first JavaScript. This baby over here is 282k. That's pretty big for a script. So what does it do? Let's look at it. We can find out thanks to the magic of our DevTools. There's some comments in there. If this is minified, Philly, you wouldn't see any comments, but I guess it's not too bad because most of this is minified. So looking down to some stuff over here and then look at this. Notice all these things here that are, would appear to be base 64 encoded images. And there's a lot of these base 64 encoded images. I'm not sure what file this is, but it exists almost entirely of all these base 64 encoded images. So all this code is loading before our visible content. Anyway, it goes for a little while. And I think a lot of that might be, give us our fancy lava lamp effect on the behind door. Oh, the lava lamp. That's what it is. Yeah. See, modules and CMSs are wonderful, but then you might actually have a lot of code that you've not sure what it is, why it's there anymore. So there's that. And then finally, YouTube's video loads over here. Sorry, I clicked on that. Look how big YouTube JavaScript is. It's quite large, unfortunately. And loading that very late would be a good idea in general. So you want to load first up like the SVGs for these things, which is good. You're going to load the Drupal logo and name as soon as possible. Have this button be active and usable as soon as possible. And the thumbnail for this and then go from there. So performance is hard. Like my personal site is full performance problems, too, because I can just ignore them. I don't know they actually exist. But as we said before, it does actually matter. And in this case, you can see some really low hanging fruit. You can compress those images in the image slider right there. And maybe take the JavaScript that loads up the lava lamp thing and do that later or make that smaller. And right there, it's quicker. Real quick, I'm going to look at someone else's site because I saw something over here. Another Drupal site I looked at recently. Now it's appearing in our 3G connection, still showing up. Is this the one or is it a different one? Let's sort by size over here. It's not the one. This has a lot of requests. But I was looking at one other one recently. This is a nice site over here. It looks pretty. A little slow to load on our 3G connection. Again, a fast 3G connection. An image there is pretty slow to appear, unfortunately. And that is because it is rather big. 650K over here on mobile. The desktop version actually is 1.5 megabytes. So no image would be that big over on a website unless you're trying to sell people, I don't know, architecture with a beautiful or diamonds with a beautiful very, very detailed kind of jewel shown or something. It's just too big. You can make this probably 200K, 100K. It would look just as good. So there's my live demo. I'm going to stop sharing my screen now. Awesome. Look at the site, see what it's like, and find things. It's not hard to do. Awesome. So I do see some questions trickling in. We'll answer some of these at the end. Again, you can certainly use the Q and A feature as well so that it's not lost in the chat back scroll. So that gives an awesome example and one that I think I'll probably review with my own engineering team for Drupal.org itself about how we can use these tools to identify the most low-hanging fruit for these improvements. Things like these images should be relatively easy. Even if we don't find it as easy to implement the load order, perhaps, we can certainly still make some of those things smaller, use better image formats and things like that. But Ben, you're also going to talk about some stats that represent these kinds of things that we're talking about in maybe a more easily measurable way. Let's go into Coreb Vitals for a bit and then I know you're going to talk about some more Drupal-specific things, which is really, really great. So yeah, some stats, some Coreb Vitals things. So Coreb Vitals is Google's attempt to make all this a little easier to measure. If you go to the next slide over here, you can look at this beautiful picture of people. So there's a lot of metrics people use for performance. There are speed index. There's time to first buy. There's a lot of different things people talk about. And it's kind of an alphabet soup of things. So folks at Google, the W3C Performance Working Group and other places discuss this for a couple of years and found some metrics that they like that can measure performance pretty well. Now these metrics will change every year. They're going to keep on updating these things as more is discovered about the web as the web evolves. But for now, there's three metrics that are pretty good ways to measure not just your performance, but also just user experience of your site. You go to the next slide over here. The goal of these on the next slide is to measure three things. One, loading. Most of you have been discussing loading so far. Like, is the site actually appearing? Is anything on the screen? Is anything happening at all? But number two also, interactivity. Once the site actually appears on the screen, does it do anything? You press a button, does it respond? Let me try to scroll. Can you scroll? Or is a browser being blocked by something else from scrolling? Because remember that JavaScript is single threaded. So actually, your JavaScript can kind of block the browser from doing things. You actually, as a developer, can block the browser. And finally, visual stability. Some sites, you load them up and things appear on the screen and there they are. They're easy to read. Other sites you load up or site, especially a recipe site for some reason these days, and you see suddenly an image pops in and things shift around. Then you're reading some more about your ingredients and then suddenly a video pops in and things shift around. You want to kind of ignore that video, look at the text again or look at whatever you want to look at the image. And then maybe worse yet, maybe a video ad pops in. Things shift around again. And the shifting can occur sometimes three, four, five times during a page load. It's quite distracting. And Google's goal is to discourage this as well as discourage slow loading. Next slide, please. So these three metrics measure those three things. For loading, largest contentful paint, for interactivity, first input delay, for visual stability, cumulative layout shift. And you can look at all the decisions behind these things, how they were came up with, and how these goals are come up with all on web.dev. I'll show some links in a minute. But for now, they found that it was good to have LCP, largest contentful paint happen in two and a half seconds or less. Pour is four seconds or more. First input delay, 100 milliseconds or less is quite doable and considered good. And cumulative layout shift is a score, which I'll discuss in a minute. Next slide, please, over there. Oh, yes. And also, sorry, you want to have this happen for 75% of page loads on your site. Some can be slower, some can be faster, but this is a pretty good goal to reach. So these come from things called a Chrome user experience report. These metrics aren't actually from you trying things out in your browser or Google or someone else measuring things on their own servers. Chrome has anonymized data from Chrome users that is available, if anybody to use, to query using BigQuery. And these metrics drive from this actual real world data that isn't just guessing as we used to do using web page test about how it might actually be. This actually is people in the actual world. How fast does your site load on their actual devices they're using? How slow is interactivity? It's kind of neat that we can do this now. Next slide, please. Here are the three ingredients, ingredients of our web vitals here in order. First of all, largest contentful paint. It's simply how long does it take for the largest thing above the fold to appear? That could be an image, a hero image often. It could be a block of text. It could be anything. It's nice because it's pretty easy to describe this thing. It isn't like speed index, which is also as nice, but requires a calculus to actually define and things about how fast various elements appear. It's simply how fast this biggest thing show up. For more on this, look at web.dev slash lcp. It's discussed in more detail that I can discuss here. Next we have first input delay. It's simply the time between stuff appearing on the screen and becoming interactive. So actually more specifically, the first time a user presses a button or tries interaction and the browser actually responds to that. So they try to scroll your content. They actually press a button like the menu button or some sort of navigation button. How long is it delayed before this actually happens? 100 milliseconds or less is considered good. As you saw before, people like a button that's faster than that. If you're slower than that, people will begin to notice that it feels slow and begin to think this feels kind of broken in some way. Finally, cumulative layout shift is a little harder to describe, but it's a way of measuring the sum of all the layout shifts that occur during the page load and the page's lifespan. This is calculated by taking individual layout shifts, which are measured by how much of the screen shifts and how far it goes, taking those two things, multiplying them together, and then summing those things up. That gives you a score and .1 or lower is good, .25 or higher seems to be not so good. So they did a study, looked at these metrics over here. Next slide, please. And they found that when a site meets these specials, users are 24% less likely to abandon page loads, so they actually make a pretty big difference. 24% less likely to abandon is a pretty big difference, so they're good goals to shoot for. So the next question would be, well, how do Drupal sites do on this? I looked at one of our dashboards here internally at Drupal sites. And next slide. And it wasn't much worse than the rest of the web. It wasn't great. It wasn't bad. It was found that on desktop, 35% of sites passed on mobile, 22% basically passed. The difference is typical because mobile tends to have slower connections than desktop. Notice each individual metric is not so bad. For simple delay on desktop, 99% that the standout, that's really pretty good. But taking these things together, the actual scores for sites passing all these things is kind of low. However, I can say that there's going to be a report coming out about all the CMSs out there and the top five CMSs by web popularity, which are WordPress, let's say Drupal, Jumla, Wix, and Squarespace, I think. Drupal was among the best ones. I have a note on this somewhere over here, but not in this slide. Actually, I think it was Drupal was the best in largest contentful paint and the best in cumulative layout shaft of all five. Drupal is doing pretty well already. This room for improvement, but Drupal's people have worked on this stuff already in Drupal I think more than other CMSs and that really shows. Let's go to the next slide. How do you measure all of these things? Google is a very big place and known for people saying different things at the same time. In this case, people have gotten back together and have these core vitals in at least six different places you can measure them in. Two of these places you can't measure first and but delay because it requires having actual live users out there, but you can get total blocking time, which is pretty similar. It's kind of a good stand-in for first input delay. Next slide, please. Let's look at these six tools here. Number one, the popular PageSpeed Insights. People use this a lot because it looks at your site quickly and tests out your site on Google servers. It used to be stored actually in someone's apartment. Now they're actually more formally stored in a nicer place. It uses Lighthouse's API now also, so these things are more consistent. It tries these things out on real live machines and gets a score of 0 to 100. The score I think is over discussed and can be a little bit distracting, so I haven't put it in the screenshot at all. But right below the score are some useful things and now it gives you your scores on these free core vitals plus also a first contentful paint as a bonus. Then it gives you here lab data, which is basically data from running this on servers that Google owns and also field data, which is actually from the Chrome user experience report. So you get data from Google trying these things right now and then also from real-world users. You can see that various things here could be better. You go to the next slide, you'll see it gives you more specific advice on things to actually do. If we could actually expand these little arrows here under the accordions, we'd see specific things that could be done, specific JavaScript files that may be large and could be reduced, things that were blocking, images that were too large, all those kinds of things. So all this actionable advice is here in PageSpeed Insights. Next, we have the Chrome user experience report itself. You can use this yourself. You set up a Google Cloud account because all the data is on a Google Cloud and you can use BigQuery to query this and look at data for CMSs, data for your site, your competitor sites, whatever else you want. It's quite useful. If you go to bit.ly slash crux hyphen tool, you get more information on how to do this. You go to the next slide, you'll see that I in a couple of minutes here made this little dashboard showing how Google.com fared. This was pretty easy to make. Notice it did pretty well. There's still room for improvement. And making this dashboard is pretty easy too. Go link there on your screen, d.co slash Chrome UX dash and make your own dashboard. Next, we have Google search console. If you use this, if you're curious about Google search and how you stand on Google search, search console is a good way to see how you're faring and search. And it also now gives you the same metrics, core of vitals. You can see all your URLs right there and how many pass which metrics. It's kind of nice because it does this for you all the time, automatically in the background. Sorry. Speaking of search ban, these core vitals are becoming part of the search ranking algorithm as of next year. Is that correct? Yes, that's also true. So we announced in May that they'd be using a thing called page experience as a ranking factor in search. Currently, speed is a ranking factor. They're going to replace that with something called page experience, which mixes core vitals plus basic things like is your site secure, HTTPS, things like that. Is it mobile friendly? Do you have things that block your screen when you pop interstitials that block people from using it, using it? All those things. So they announced this back in May that they'd be soon making this change. We just announced last week, actually, that the change is going to happen next May, giving people a lot of time because people are working from home. Things are very strange these days and unstable. But starting in next May is going to be a ranking factor. So improving these things will make your ranking a little better. Thanks for bringing that up. I had forgotten to mention that completely. We actually cut the slide. So I totally forgot about it. It's actually pretty important to realize that it will matter in Google Search. Number four, Chrome DevTools. A nice tool to do this with. We showed this before. You can find all kinds of fascinating things here in Chrome DevTools. Edge also has the same DevTools these days. Firefox has its own set of tools. So to Safari, use your favorite browser. Look at your site. Look for large things and see what can be gotten rid of. Number five, in Chrome, back to Chrome DevTools again, Lighthouse now has a home in Chrome DevTools. You look at Lighthouse tab over here and you can run this report. Thank you for showing that there. It is the same report used by PageSpeed Insights, which uses now Lighthouse's API. It doesn't have that kind of real-world user data. It's data measured on your machine right now. You can be testing out your site, trying to improve things or Lighthouse on it and you can find things you might have missed. You can also, next slide, please, use Lighthouse in different kinds of ways. It can be used in the command line and you can also use it, for example, if a thing was integration. After a commit happens, run Lighthouse and see if there's any regressions have occurred. This is kind of nice because sometimes people will just load large images on your site or someone else will just add some big tracker or something and no one notices it. In this case, you'll actually notice it, see what happened, find the person and make fun of them. Also, Lighthouse has Lighthouse stack packs, which are specific recommendations it can give for specific frameworks or CMSs. This is one here for Drupal, the community contributed, where if you have advice for a Drupal site, it will detect that and give you suggestions for modules or other things to improve Drupal site specifically. Finally, my last tool over here, number six, there's a web vitals Chrome extension. You can add this to Chrome and it will measure these metrics right there on your site. You can also, next slide, please, use this GitHub library over here and use the same code from the extension in your own project. So, this here has all the code you need in JavaScript to measure these three core vitals. You go to the next slide, you can see an example of how it would be used. You simply would import what you want to use from the web vitals and then you could just go ahead and use get CLS, get FID, get LCP and output the results or use it however you want to. You could be reporting things back from the field, whatever you want. That's my core vitals bit for today. Thanks very much, Ben. So, that covers a lot of like, how do you actually objectively measure these kind of front-end performance metrics and user experience metrics that we've been talking about as being so important and going through a variety of these different tools that you can use yourself to analyze your own sites and, as Ben said, to apply them to competitor sites and things like that. The next thing we want to do is talk about concrete improvements that you can make today. So, Ben is going to talk about some general cases and I'll add in some Drupal specific cases as we go that affect each of these different areas that we've talked about. So, hopefully, this will give you some things that you can take away and use and implement on your own sites or, if you're a contributor to Drupal, they might give you some ideas about some improvements we can make in Drupal Core. We'll talk about a few things along that front as well. So, hand it back to Ben just to kick us off. Thanks. I'm very excited about trying to make changes to Drupal Core that will make things faster by default when already has happened and there's so much potential and excitement about this. It's kind of fun just to be able to watch this happen. So, for now, things that cause poor largest contentful paint, of course, are big resources. View, yeah, there we go. It's nice purple boxes are going to appear there. Of course, things that are large resources will load slowly. So, you want to avoid that. Images, JavaScript, CSS, whatever. So, of course, making things smaller is good. Having less things is good. And then, if you have to load a lot of JavaScript and CSS, try to avoid loading that in the head. Try to defer things. Try to load them even as late as you can after even the load event, for example. You won't get really crazy about it because all those things can slow down the load. Some of these things in particular, if you use a decoupled Drupal site where Drupal is acting primarily as your backend and you're using a major JavaScript framework as your front end, a lot of these JavaScript optimizations in particular may become especially important. Definitely something to watch out for. For images in particular, making them smaller, of course, is the key. And this is not complex to explain. Images are simple. Choose smaller sizes for things or compress the images. You can use modules like Image Optimize. A tool that I love is called Squoosh.app, where you can go ahead and load up an image and then try compressing it more and more. And you can see the difference between the original image and the compressed image and compare and get it so that it's smaller, but it still looks basically the same. I can offer compressed images by a factor of 4 and 5, in this case, down to like 20K, 30K. Very powerful tool. Use the power of WebAssembly to do these code acts and things right there on your browser. Also, using responsive images, of course, helps. You can have smaller images for smaller devices. The responsive image module is a great name. Seems very appropriate. And does this with you and for you. And lazy loading. Try modules like lazy load and blazy. And, of course, now Drupal supports the attribute that ImageTag now has to do lazy loading right there in your browser. Yeah, absolutely. So I'll talk about a couple specific things here in Drupal. So one of the major innovations in the Drupal 8 cycle that, of course, is in 8 and beyond through Drupal 9 is that we use image styles in Drupal. So I would bet that a lot of the Drupal sites that are in the scores well column of our Drupal evaluation earlier are probably sites that are on these later versions of Drupal in 8 and beyond and that have properly implemented image styles, right? So using your image styles properly lets you take any of your image fields, set a scale and crop factor for those images, and just helps ensure that your user workflow is not going to accidentally result in someone uploading a 2.5 megabyte hero image for upcoming blog or something like that, right? So definitely define your image styles for the image fields across your top content types as best you can. And there will be some places where maybe that's not as easy to do. Sometimes you have a content type or an image field that's a little bit fuzzy around the edges and so you wind up leaving some unconstrained styles. So we'll talk about that too. We talked about optimizing on upload or before upload. This is that scoosh.app tool that Ben was talking about before. So just to give a little bit of an example, the image we're looking at is one of their sample images. The base image is a 1.6 megabyte image and you can see some comparisons of different alternative formats and quality settings. You notice that on the left-hand side of this example screen is using the AVIF format, so that 1.6 megabyte image becomes 90 kilobytes. It's 94 percent smaller. You can also see it in a traditional JPEG format, which is 88 percent smaller. So format choice, WebP is of course another great choice. And checking your scaling factor in things is awesome as well. Finally, lazy load. So as Ben mentioned, and something we want to celebrate, we'll talk about it slightly further in the presentation. In Drupal 9.1, we've managed to commit lazy load by default for images added, whether it's with the WYSIWYG, image API, all of those things. They have the default lazy loading HTML attribute. So that's going to be there for you if you're upgraded through Drupal 9.1 and beyond upon release in December. But if you happen to still be on Drupal 7 or if you're on older versions of 8, if that upgrade is going to be a while away, definitely take a look at some of the lazy load options in Qtrip. So there's lazy load, there's blazy, there's a few. They give you a variety of additional choices you can enable for certain kinds of tags. Again, you can set settings on a per-field basis in your Drupal content types. So it's definitely worth the investment to try and stop that image render blocking kind of thing that happens with these very large images and get things all set up and use responsive images as well. So that's probably the number one impact area and one of the easiest to implement. So Ben, let's talk about JS and CSS. You have JavaScript and CSS. It really is the same idea as images, honestly. You want to have less of these things and make them smaller. Techniques involved, of course, are different than images, but compressing it is still a thing. And minification should always be done. All those wonderful comments in the code and copyright notices and 20 character property names can all be shortened. Also important when using the CMS to make sure that your modules don't really apply their JavaScript and CSS every page on your site, this page is where they're used. I've seen lots of pages out there on the web, WordPress sites where they're like a very large, like, recapture JavaScript on every page on the site, or e-commerce things everywhere when they don't need to be everywhere. So loading them later also was good. Async and defer helped to a certain extent. I did see when I looked at the Drupal site there, although things were often loaded with defer, browsers didn't defer that much anyway. So it doesn't always help that much. Browsers will defer to a certain extent, but loading things really last requires JavaScript to be adding scripts to the DOM specifically. Yeah. So there's lots good here. And of course, depending on what modules you're using, you may not have the greatest control about how the module maintainer implemented their JavaScript. However, I do know that we do have a lot of performance-minded developers in our community. So when you look around a little bit and our first evaluating modules, that might be one of the criteria that you're looking for is how they're handling any JavaScript that they might be using. So there's some things that you can do in Drupal as well, of course, that are already there. Drupal core already has aggregation built in. So there's an aggregation function that you can just flip on for CSS and JavaScript. There should hopefully be no reason that you need to turn that off. So I would go and check and make sure that you've got that going. In almost all cases, it shouldn't cause any trouble with what you're doing and should just make things faster. There's also some advanced options in the contrib space. So the advanced ag project has a variety of more sophisticated aggregation tools that make things even faster. You can see on this project page, there's actually a chart that we'll look at again slightly later that talks about the difference between no aggregation, core's aggregation function, and then the aggregation that you can get using this module. And this is available in seven and eight, compatible in eight and nine, and it has multiple different layers of aggregation tools. So some of them, you can kind of pick and choose what's going to work best for your particular use case. It does, in my experience, we use this on Drupal.org. It does take a little bit more testing to just make sure that you haven't accidentally munged some of your JS together in a bad way or something like that. But it's generally a really good tool that can make a big difference as well and relatively easy to get started with. So, Ben, what about interaction delay? For any kind of long solid bug by these things very briefly, the first input delay, yeah, it's basically long tasks in JavaScript, things that take a long time to execute in general, and things that are just executing and making things slower. So for these things, you can look at Chrome DevTools, for example, at that performance panel, and you can actually see there, I haven't shown you this, you can see JavaScript executing and then things take longer than, you know, 50 milliseconds, 100 milliseconds, split those things up, or wonder if they're actually important to have there at all and make them slower. Again, the browser is single threaded for each tab, so your JavaScript can block the browser from doing anything or from responding to other user events with other event handlers. The next page over here, cumulative layout shifts, they're usually are caused by injecting content dynamically, like on the fly, or by things that have no dimensions attached. So if the browser doesn't know how big things are, it can't reserve space for the thing, and it will have to make the layout shift around as things load, which also, of course, slows things down as I had so recalculated and painting has been done all over again. You go to the next slide over here. Oh, sorry, go ahead. Oh, no, please continue. And of course, web fonts also, fonts are loading and things going to display until the fonts actually are loaded, that could be slow too. So back in the olden days, the best practice was to specify width and height for everything, because then the browser knew the size of everything, it could leave space for it as it loaded, and that was all great. Then responsive design became a thing. And now we often just say, well, fit it in the container, and then we're all done. And the browser says, I don't know how big this is going to be. So it can't leave space for it. And it's just guessing. Best thing to do now is specify the aspect ratio. And that way, once the browser actually knows the width or the height, it can get the other one, and it can leave enough space for your image. And that makes content layout shifts better. Or you can use things like AMP. Part of the way that AMP is built is that it makes you leave space for everything in advance. If you're using a valid AMP, you're required to specify height and width for everything. So AMP has very little cumulative layout shift, because for every object, even if it's like a component or a video, space is preserved for it, and things load in, and it pop into their spaces, and it has a nice kind of smooth loading experience. Now AMP support in Drupal is okay. There's a module for it, but it hasn't worked on, I think, that much for a little while. WordPress has seen most of the work because people have just figured WordPress is this big CMS. It should have a good AMP support. So the AMP module there, I guess the AMP plugin there they're called, has worked on for a while to look kinds of complicated things. It does tree shakings, makes CSS smaller, has massive support. There's actually a project here as part of this WordPress and AMP plugin to make it so that the guts of this can be used in any CMS to take the parts of the WordPress specific, like the tree shaker, for example, and to make those usable by any PHP CMS. If you're curious about this work or helping out with the work, check out this GitHub issue. This work is ongoing right now. Awesome. So I'm going to talk about some Drupal-specific optimizations you can do around this that are really helpful. So we are low on time. We're going to go ahead and run long so that we can answer some questions as well and get through all of our content. Hopefully you can stick around with us if you do have questions. And hopefully we don't run too, too long. But I'll dive right in here. So one that I wanted to throw in, we briefly touched on early in this conversation some of the HTTP header stuff. And I wanted to mention a certain open source project founder named Dries, who you might have heard of. He did this little CMS called Drupal. He has one other little open source project that he did much more recently, which is an HTTP headers analyzer. And so this is just another tool that you can use. It will take anything. This is like an example from CNN.com that will go from your origin through to the browser, look at header controls, provide explanations of issues that might exist in your HTTP header sort of situation. So that's something that you might try out just on that side of the optimization path. I'd also like to talk about dynamic page cache and big pipe. We've had a little bit of conversation about this going on in the chat window that I want to add to a little bit. So in Drupal 8, it was a big initiative to create this dynamic page cache system and to create the big pipe rendering method. What it roughly boils down to is there is an auto place-holding system, which can relate very closely to this conversation about content layout shift. Effectively, using cache contacts or cache tags within the way that Drupal's rendering works, we can identify elements of a page to cache separately from the whole page based on what they are, and we can auto place-holder those elements as part of sort of a lazy loading sort of style. Now, depending on how it's done and how your content is built, if your auto place-holders are getting defined with the proper dimensions, it can prevent content layout shift. If they're not being defined with proper dimensions, it can cause content layout shift, but it's something to look at how you're using and certainly definitely a really powerful performance tool that's been built in since Drupal 8. So something to look at. There's more documentation, of course, in the Drupal Core documentation about Drupal.org. You can also customize this yourself. So those same cache contexts that are used for auto place-holding and things like that, you can use for, say, some kind of view that you've written for data visualization or some custom-level sort of application layer based on your own content types or your own integrations, that maybe the core auto place-holding and dynamic page cache doesn't know how to handle, but you can apply some new rules too. So it's something to look at because I'm sure if anyone's added sort of a beyond the normal use case layer, you'll definitely want to look at what else you can do with cache contexts to continue taking advantage of that page cache and place-holding functionality in Drupal Core. You'll also, of course, I won't say much about this. You'll want to look at your CDN implementation, especially if you don't have one at all. And when it comes to looking at CDNs, I would suggest looking at ones with varnish configuration built into them or other kinds of edge logic that you can use, whether you're doing something like image optimization at the edge or other kinds of clever things that you can do. So you can do that with like Google Cloud CDN. You have the possibility of varnish configuration modules. There's a varnish configuration built into Fastly, into Section IO, into a number of other providers. So it's just something to check out so that you can implement some edge logic, which can also be a clever way to manage some of these issues. So now I'd like to talk about being more performed by default in Drupal, some initiatives, or at least some things that we could throw out to think about for the future of Drupal, whether it's in Core or areas of Contrib or even just changes in configuration of what we're already doing in Core. And these are just some ideas that go along with other performance initiatives that have been proposed by people in the community and perhaps some ideas that you have. But I hope we can talk about them at upcoming events like Drupal Kanyarup and other places. So when it comes to optimizing images, what are some things that we could do around that for the future of Drupal? Well, one of them we've already done. We've talked about this earlier in the presentation and we've been celebrating it since it happened. We managed to get lazy loading of all image by default committed to Drupal 9.1 for release in December. It's really exciting. It's going to make sites faster for everyone. And it was a great collaboration, I think, between Ben, myself, other people in Drupal, other people at Google, to say, well, how could we find one of these low-hanging fruit items and just make it easier, right? Even better than having an easy step-by-step guide to performance improvements is having them just done for you once you get to that version. So we're looking for wins like that. Another thing. I think this is pretty key. I mean, if you're an advanced Drupal developer, you'll know about these things. You'll know which modules to incorporate and which ways to tweak your own JavaScript to make these things happen yourself. But changing it for all users of Drupal is so powerful. And we have some ideas beyond this, but also we'll make it so everyone by default will get these things just by using Drupal. Yeah, exactly. And I think it'll not only does it improve Drupal's reputation in the market, it's a win for the notion of the open web, right? If we want actual open source-based, you know, public square web pages to compete with the kind of walled garden ecosystems of your sort of Facebook marketplace pages and other kinds of things, right? They need to share the level of quality of user experience when it comes to interactive design, fast loading, fast interaction. So things like this would be great. So this has also been a conversation on going here in the chat about looking at AVIF support. So a quick heads up for people who might not know about it. A consortium of folks came together to kind of define what the AVIF file format would be. Netflix was actually one of the, like, core people in that group because they have all those thumbnails of all those TV shows that we're all watching during the lockdown that they want to try and optimize. So just as a quick comparison, on the left and the right, we see the same image, but on the left it is using JPEG compression. It's almost 14 kilobytes in total and it looks pretty awful. The artifactian compression is terrible. On the right, we have an AVIF example. It looks much, much better. I'm still blowing up probably a little bit bigger than it needs to be, but it's only four kilobytes and the quality is massively improved. Now, AVIF is not totally immediately ready to go. So Ben is starting to work on this. There's an issue in GitHub about AVIF support. Do you want to say a few words about this, Ben? Yeah, we could use your help. I've begun looking at this, but I just started looking at it last week and need some work. But once it's actually that exists in GD, then other PHP-based CMSs can inherit it. So image magic is also used by WordPress, for example, but Joomla, other CMSs that use GD can also inherit this AVIF support. And it is quite a game changer. If you go to Squish.app and try compressing an image with AVIF, it's surprising how good it looks at such a small size. Yeah, it's really very impressive. And this is one of those great opportunities where if we can find some collaborators who want to work in libgb, again, we can make the web better not just for Drupal, but for all of these different CMSs that use it. So another proposal that I'm going to paraphrase really quickly, this comes from Fabian X, Fabian Franz, is handling of above-the-fold elements, and this is or really the handling of the below-the-fold elements. And this is a proposal that really will take some thinking and some more collaboration to understand what kind of direction to go. But the idea is to enable us to define the content that is the truly important above-the-fold content versus defining the below-the-fold content and doing so semantically in a best-case scenario using some new web standard. It's not something Drupal specific, but however we can do that so that not just images and certain script content can be lazy loaded, but that we can have the entire page contents of the render area below-the-fold load in lazily. So there's a few ideas about how to do this. Fabian has a whole sort of proposal worked up. So this is kind of a teaser. It's hopefully something that we can talk about more. But if you're interested in the concept of using sort of a semantic attribute to define below-the-fold content and then kind of a no script, JavaScript load option to lazy load everything, I think there's some cool possibilities here. Again, for Drupal, but also possibly for the web in general, if we could maybe collaborate with others and try and create a standard. Yeah, be a good example for the whole web. You'll see more advanced sites out there that if you scroll down the site and look in DevTools, you'll see not just images, but also JavaScript and CSS loading as things are loaded. So more complex interactive things that are below-the-fold can also load lazily as well. And this proposal can make that happen. It'd be more powerful than even image load, lazy loading or iframes. Exactly. I think it could be really cool. So minification and aggregation and these things. We've talked about this a little bit before. I'll go through pretty quickly. Advanced aggregator has awesome tools. Here's that chart in a larger format to show you the difference between no aggregation, core aggregation, and what the advanced aggregator module can do. It's been a little while before we've, I think, looked at core's aggregation functions and said, gosh, there's some more things that we should move in there. So I think there's an opportunity, particularly for people who are interested in core contribution and also interested in CSS and JavaScript performance, to maybe set up a contribution table at DrupalCon and look at how we could further enhance core's default aggregation functionalities. Can we take learnings from the advanced aggregator contrib module and begin moving some of those things into core? That kind of stuff is always helpful. And those of us who are really familiar with the ecosystem and advanced Drupal developers are like, well, gosh, we can always just get that module and set it up. But part of the idea, as Ben said earlier, is we want to try and be fast by default. We want to have these tools available for everyone, even the newbies to our community and ensure they have a good experience and continue to see Drupal as their best option. So finally, another idea of things that we could work on, and there's multiple ways we could implement this, but is to provide actionable performance insights in the Drupal backends. So one example, and on the left here, this is not literally the StackPack recommendations, but it's the PageSpeed Insight recommendations, is could we take performance recommendations like we looked at with these other measurement tools and actually surface them directly in Drupal status report or some other place? And can we make them very specific? So if we could have a message that says, oh, we've detected a 2.5 megabyte image on your front page, we suggest you install the ImageOpt module or define your image style. If we give them the Drupal specific step to solve problems that we surface, I think we can probably make a significant proportion of the Drupal sites out there faster. So there's some things that we could consider. Again, we could build some of our own recommendation engine ideas in there. We could integrate with the Lighthouse StackPack tools. There's a variety of ways that we could come about this. But I think this is another area where the community could think about not just the technical side of how we implement great performance, but the onboarding side of teaching our end users the best ways to implement these things. Yeah, if they add a module that actually ends up adding 100 kilobytes of JavaScript and they hear about that by seeing it in their dashboard, maybe a lot of different modules instead. Exactly. So last thing I want to say is that for these ideas that we've discussed today and any other ideas, we're certainly going to talk about these sorts of things more at Drupalcon. So Drupalcon Europe is coming up the 8th to 11th of December. It's an all virtual event. So no matter where you are in the world, you can attend. There will be contributions happening throughout the event, contribution tables. So if you're curious about these things, and you maybe want to get involved in this from an initiative point of view, I think that'll be a nice place where people are coming together around this and we can put some ideas together. So we're going to switch to questions. We're significantly over time, but we'll try and take the couple that we have and do the best we can. And I'll see if I can go through the back scroll as well. But the first question here, maybe Ben, you could take this one in our Q&A section. So how does someone use the Drupal StackPack? What do you actually do to install a StackPack and use it with Lighthouse or local Chrome or whatever? The nice thing is, you don't have to install anything. Lighthouse comes with this built-in. So Lighthouse will detect it beside the Drupal site and simply tailor recommendations according to the text strings that are provided in the StackPack. Yeah, so that's it. So that StackPack code, that repository is actually like, it's the community contributed extension to Lighthouse that winds up getting bundled with Lighthouse when people do that. So this is the other thing. I think if the Drupal community comes along and says, oh gosh, there's another recommendation we should add, any of us can contribute that. And then any other Lighthouse user will see those new recommendations if they're merged in. I'm going through the back scroll in the chat really quickly here. I think we may have addressed many of these questions. And again, feel free to use that Q&A button. We talked a little bit. We have plenty of AVEF discussion over here. AVEF certainly is supported only by Chrome and Opera right now, but support will arrive on other browsers. And there are ways you certainly can specify your image and HTML so that you can fall back to other formats if the current format is not supported. So for WebP, the recommendations use picture and provide different formats there in the picture element. AVEF works the same way. Yeah. We have a question from Steve Wickham, which is based on the demo that you gave earlier, is there a way that we can provide folks with a kind of a checklist of things to look at or to look for within their website? Certainly we'll send this recording out to everyone after the fact so that you can review this again. But is there kind of a resource we could provide for like, here's what you should be looking through? That's a great question. I actually spent a while at Google a couple of years ago equipping non-technical people to actually do this kind of analysis. I spent a long time making these spreadsheets full of things to look for and things you could look for. What's available publicly? I actually don't know. There must be a dozen things like this out there on the internet, but I am not sure this actually exists. That's a great question. I can try to find out what's out there and get back to you. Yeah. So as I said, we'll send out the recording to everybody who attended. We'll probably put some follow up content in the Drupal newsletter coming out. So if we do find some of those resources, we'll try and add that in as well. I think given that I'm not seeing more things in the Q&A and struggling a bit to scroll through the rest of the chat, and we're also over time, we'll probably go ahead and wrap here. But what I wanted to do is say a big thank you to all of you out there who joined us today from all over the world and who participated in the chat and shared your own ideas and expertise. Drupal, of course, as an open source project thrives on collaboration. And so we really would love anybody watching this live or in the recording to keep participating, to keep joining us for future conversations, to maybe join an initiative or to reach out to ask how to get involved in the project or to get involved in web performance. I also want to do a big thanks to Ben for joining me here as a co-presenter. Thank you so much for this conversation and for sharing the insights that you have and that Google has developed. And thank you to Google as a whole for supporting the Drupal Association and becoming one of our supporting partners and helping our community thrive. I think that's really great. So with thanks for having me. Yeah, I really appreciate your like becoming, share this with you and I'll discuss performance today. Fantastic. So with that, we are going to wrap things up. Say goodbye for now. But again, we hope to speak to you all again soon and we'll have that recording to you just as soon as we can get it all cleaned up and processed. So thanks everyone. And I hope you have a wonderful rest of your morning, afternoon or evening as the case may be.