 Hello, everyone. We're going to take a few minutes as folks are joining in before we get started today. So as you come on in, feel free to introduce yourself in the chat. Say hello. We'll do a little bit of housekeeping before we get started. We want to encourage everyone to think of questions during this conversation. Put those in the Q&A tab in the toolbar of your zoom and we'll save some time to answer those at the end. We also would love to hear from you sort of where you're from, who you are, what your kind of general interest is in these topics. So please throw that in the chat and feel free to talk to each other. And we'll give it another minute here for more of our attendees. Oh, it says chat is disabled. Let's see. We got to enable that for participants, don't we? Um, do, do, do, do. Just one moment. We'll get that sorted out while we are. There we go. Martin, thank you for mentioning that in the Q&A. I believe the chat feature is now working. Would someone give me a quick check there? Lovely. There we go. Hi, Kelly. Hi, Shirley. Welcome, everyone. I think we're just about ready to get started as more folks trickle in. So I'll repeat one more time. We're going to have a very sort of conversational presentation today. We'll be doing some demos. We'll be talking about a lot of different topics throughout this whole process. We really encourage you to use the Q&A button in your zoom toolbar to ask any questions that you have. Save time at the end to answer those questions. And then also to use the webinar chat to introduce yourselves, explain, you know, why you're here, what's most interesting to you, maybe chat with each other. Certainly encourage you to do that and we'll be dropping in and out of the chat as we go as well. Let's get started. Today's conversation is about Core Web Vitals and improving the end users experience in Drupal. This is a joint presentation between the Drupal Association, Google, and Tag1 Consulting who have partnered together to make improvements to the Drupal platform that improve this experience for end users and hopefully improve the experience of the open web in general. If you've heard of Core Web Vitals before, you might think of them as sort of performance metrics or things like that. But this focus specifically on the end users experience on how these metrics impact the experience of using a site is really crucial to this idea and why we're focusing on that. And we'll talk more about that today as we get into the topic. Our speakers today. I'm thrilled to introduce Andre, who is the strategic partner manager who works in the Chrome team at Google. Adam, who's a developer relations engineer also on the Chrome team at Google, and part of the WordPress community. Myself, I'm Tim Lennon or Hestanette on Drupal.org, the CTO of the Drupal Association, which is the 501c3 nonprofit that supports the Drupal project. Fabian who's the VP of software engineering at Tag1 Consulting. Yannis who's a senior engineer in the multimedia orientation at Tag1 Consulting as well. And together we're going to talk about general ideas around end user experience performance. We're going to talk about prior collaborations and the history of the collaboration of our organizations together as partners and some future ideas. So our topics today will start with the core web vitals themselves, what they are, why they're important, and sort of a practical demo of kind of what they mean how they work. We'll talk about our collaboration, how Tag1 and Google together implemented some meaningful changes in Drupal already and some of those successes that are hopefully already reaping benefits for your own sites. And then we'll talk about upcoming projects and collaboration between the Drupal Association, Tag1, Google, and hopefully other folks. A few of yourselves are interested in partnering and have ideas or have some resources that you'd like to support some of these ideas. We'd certainly love to hear about it and create some opportunities for even more collaboration and involvement. And then finally we'll go into that Q&A portion. Before we hand things off, I'm going to hand things over to Andre, who is going to give us that sort of basic orientation to the core web vitals. Talk about really sort of why they're important, what we're doing here, and then do this little bit of a demo of taking a look at a couple sites and understanding what their meaningful impact really is. So with that, I'm going to stop sharing my screen and let Andre take it away. And thanks for the setup team and thanks for having us here. It's a great pleasure as always being with the Drupal community. It's always exciting and always one of my highlights of the day and it's not a month. So look, many of you, let's quick show of hands in the chat. If you've never heard of core vitals before, just type that you haven't. I should have come up with a clear thing for you to type, like, type no idea. Yeah, if you're not familiar at all with this concept, let us let us know in the chat. I don't think you're second to find out when you have to come alive, which I think in this case is a new journey. Perfect. Well, in that case, we'll take it. We won't make any assumptions. So we'll try to cover all the elements of this, but the concept has been around for a while now. And it has also been part of the discussion within the Drupal community for quite some time as well. So hopefully there'll be a good mix of people here who can actually help each other in the spirit of the community. But in a nutshell, like Tim said, getting user experience right is complex. And understanding what and how to measure it is not always straightforward. So in an effort to make it easier, the Chrome team has introduced a set of metrics that are meant to be comprehensive enough covering several major aspects of the user experience. And reasonably independent of each other, allowing for us to look at what happens to your users on your websites in real time, and then provide that information back to you so you can make decisions about the elements and aspects and the various functionalities of your website. These three aspects that we're looking at are speed of delivery of the most important concept you use. There's something that is called LCP. We'll go over this in a little bit more detail with the tooling. So don't worry about it too much. It's called largest content for print. It basically is how fast the thing that the user came to the website for FPS on the screen. Then something called FID, which is first input delay. This is quite simply how quickly the interactive elements on the website respond to the first interaction. Let's say you see a button, you want to tap on the button, does something happen immediately? Does nothing happen for minutes? That's what we're measuring here. And then something called community layout shift, which again sounds a little bit fancy, but all it means is how stable is the content of a page on the screen? Is it just randomly jumping around? Why would content be jumping around? You might ask yourself. You might be introducing banners to the top of the page once the main content has loaded, and that shifts the entire content down. There might be other reasons. Blocks might be arriving a little bit later in the life cycle of the page and shifting everything to the left and to the right. So what we're trying to measure is by how much? So we don't just say, well, it has shifted, or we can actually say, well, it has shifted by 10%, or by 5%, or by 1%, or by 90%. And so if over the lifetime of a page, which is basically the duration of the visit of a particular visitor, it has shifted tremendously, maybe that's not a great experience. If it hasn't shifted very much, that's much better. So those are the three things that we're looking at, and those are the three metrics that form part of the cover files. But with that, I actually hand over to Fabian to talk a little bit about why we together believe and why TechOne as a development agency believes these metrics are actually important to take a look at. Yeah. So why are those core webbytes so important for developers and users and site owners? The answer is pretty simple. Developers want to make their site owner happy, and site owners want to make their end users happy. And all of those core webbytes in effect are increasing happiness. For example, as Andrew said, if you look at the cumulative layout shift, have you ever been on a website and you want to go to another link and you clicked and then a banner popped up, but you accidentally clicked on the ad? That's kind of like making you unhappy. Or have you ever been on a website and you really want to shop a product, but it just took way too long and you were like, maybe I just get it from that other website, which is just way faster in that. And so these are just two examples for why it is so important in general for the end user, because if an end user is not happy, if performance is not good after core webbytes, then they just go somewhere else. And if you've ever stared at a very blank screen, then you also will have like, well, I'm just leaving. And so end users definitely care about them. And Google cares about end users. That is why Google is penalizing sites that are not having great core webbytes. And that's the other part. So if you want to rank highly in the Google search, it's no longer enough to have like the best keywords, the best linking, etc. It's also important to have very good core webbytes. Because that's something Google is tracking, we can, everyone can see their own core webbytes. So it's well worth an exercise to look at your own core webbytes and to check what's the experience for my end users like. And Andrew will be going in for details here in a short moment. So this is kind of the other part of the equation. Aside user both wants to make their end users happy but also Google so it's higher ranked on the ranking screen. And so for developers core webbytes are important to just know about them, what are they? How can I measure them? How can I improve them? How can I see if I'm doing a good job in core webbytes? And again, if a developer is doing a great job or CMS like Drupal is doing a great job in providing nice core webbytes, then in the end, there will be so much more happy users on the internet, but also the experience will be so much better for everyone that is using the internet. And especially for, and it comes out a little bit later again, to if you have users also from Africa or whatever like that, it's worth to try to compare webbytes not only for the fast users that are purely in the USA, but also from developing countries and in other parts just to have a very inclusive website. I want to kind of break in before we go back to Andrea to give us a sort of specific example of analyzing a couple of sites to just add, you know, one of the reasons it's really valuable to come up with these objective metrics that help measure end user experience is so that you can make this business case about why the user experience and sort of the sort of speed and accessibility and smooth interaction of the site is important, right? It's very easy to have folks suggest, hey, maybe we should have a full site takeover banner to do our promotional campaign. Or maybe we should, you know, maybe we should introduce this, this, this, you know, multi element carousel with these really heavy images or things like that. As a developer, you might have in your own mind this, this, this kind of instinctive notion that no, I don't think that's going to be a good experience, but the core web vitals give you a tool to make that case of why those things are important. And part of it's because expectations of users have changed. People are looking for, right, we experienced the web through a browser, but we also experience it through app ecosystems, and we have this expectation of this instantaneous real time responsiveness that comes from an app world. And if we want the open web to be able to compete on that level, we need to understand the factors and measure the factors that create that kind of experience. So sorry for that interjection, Andre, but I'll let you take it again from here. No, this was perfect. Thanks for jumping in, Tim, and thanks Fabian for setting the contacts. I'll just put it out there, given that Adam and I are here from Google, we're not from the search team. So we don't talk about ranking, because we don't know what's going on there. What I'd like to say is that so so much from my understanding is not so much about penalizing anybody for anything. I think it's more about taking user experience into account and search, Google search has tried that for a long time. And now with Chrome introducing this is a major distinction, maybe for some of you not so clear why we make it, but hopefully I'll explain. Because Chrome and search are independent. And these metrics were introduced by Chrome for the benefit of Chrome's users and web developers. And search kind of went, well, this is like the best thing since sliced bread, because finally we have something that we can measure user experience with, right, and therefore we can use it for our page experience update. And hopefully, at some point, the host will drop a link to the blog post by the search team, explaining what the page experience update is all about. But those things are related, right? The metrics were launched, so we can do a better job of providing great user experiences. And the search team kind of went like, well, this is awesome. And actually, personally, I'm kind of hoping that other search engines and maybe even other platforms that kind of care about users clicking on links and going somewhere also take this into account because it's really easy to use and the data is publicly available, bringing me to my next point. So let's take a look at how do you, how do you find out what the cover battles for your website look like multiple ways we'll show you one, not going to detail a great amount of detail on all the possible tools as too many because we don't have all the time in the world. But let's take a look, take a look at something that's called page speed insights. Can you hear me now, because zoom always does this to me. Yes, we can. I remember to turn my sound back on. There we go. So hopefully I'm sharing what I think I'm sharing. Because I can't even, yes, I know I see which time I'm sharing this. This is perfect. Everything is working as intended. So page speed insights have had many different URLs in the past. It's finally found, I hope it's permanent home. Wonder what the depth website, which is by the way, Google's main source of information for web developers. It makes total sense that this kind of tooling also lives there. Just go to web page speed. Web.dev. There's a field at the top and to your URL. We picked around the one for no particular reason. Let's put it, let's make it a bit of an Easter egg, like a pre Christmas Easter egg. If you, if you can identify the relevance of this website to the Drupal community, say that in the chat. So you put the URL in there, you click analyze. And what you get instantly almost instantaneously is data on your on the cover vitals for this website. And in this particular case, it says past. It might also fail. That's a very binary assessment right away. There is no score here. It's very important. There's no cover is remember this and tell all your friends. There is no such thing as a cover vital score is a lighthouse score. It's a different thing. We might even take a look at it in a second. Cover vitals don't have a score. You either pass them or you fail them. That's it. Right. And then individual ones to also don't have scores individual cover vitals. They have the dimensions like they have their numbers associated with them. This here at the top three, right, hopefully you can see what I'm highlighting. And the three that I've been talking about, there's some additional ones not going to spend any time on those. The reason you get this instantaneously is because they're pulled from a publicly available database. Again, important disclaimer, important information for you to know is that only data from users who've consented into this into the sessions being logged by Chrome gets collected. And only if it reaches the traffic of the site in Chrome, which is a certain threshold can Chrome then confidently say that this can be presented anonymously. One thing is on the one hand that user privacy is really well protected in the sense. On the other hand, it means sites with a bit less traffic might not form part of this database or individual pages because here you see data for URL, right, but also the origin, which is the entire website. You can see that the numbers almost don't change, but you can see them changing slightly. So this is for the URL. And this is for the entire website. Sometimes you might not have data for individual URLs, but you might have it for the whole website. Sometimes you might not have it for the entire website either. So what are we looking at, right, there's some pass rates. The thresholds have been set experimentally, and there's a possibility they haven't changed for the past few years, but there's a possibility they might change if the entirety of the internet improves. So you're looking at seconds for the largest content for paint, and you're looking at milliseconds for the first input delay, and a number between zero and one for the cumulative layout. In fact, it can potentially be larger than one. It is possible for the, like you might surprise you, but it is possible for content to shift so much that it actually shifts by more than the size of the screen. So there's just a ratio between the size of the screen and by how much the content has jumped around, right? So you get that immediately if it's available. If it's not available, you're not going to get it at all, which brings me to a point slightly tangential but important. Get your own data. It is also possible for you to measure COVID vitals using real user monitoring, right? I'm not going to get into detail on that, but it is useful. So then you get into Lighthouse. Then you get into sort of a lab test where Chrome's internal tool Lighthouse, which is also publicly available, including through this interface, starts measuring different things and you can see accessibility as practices and even SEO here, right? So there's lots of stuff mixed in, including performance, right? And so there's a relatively complicated formula on how this number gets calculated. But important to remember, see a perfectly green passing COVID vitals website might be having a red score on performance, and that is in some sense fine, because for this particular website, the audience probably is largely in areas with networks and devices. Where everything works out well for them, right? Lighthouse tests and gets the score based on a very poor network and a very old device, right? So this is by definition like almost, if not the worst case scenario, then close to the worst case scenario for your user, right? So this is what this number indicates. But the calculator is also linked from here, so if you're interested in exactly what is being calculated, you can also take a look. But the main reason I want to jump into this is because of another thing that I also wanted to show you is that here in the recommendations area, you can actually see recommendations, not just so an advice on what to do, like sort of serve images that are appropriately sized, great stuff, but advice that is specific to the platform or the framework that this site is built on so that you can take a little bit more specific action. We don't have this advice for all the frameworks and all the CMSs in the world, partially because this is an open source project and it's entirely community-based, so people who contribute, contribute. And the Drupal information, as we shall see in a second, if I can switch. Did that work? Yes. Perfect. Exactly. So now that we're looking at the Drupal site, and we'll go over some of the detail, some of the recommendations in a second, but you will also see here that you get Drupal specific recommendations. You can find where these come from in the Lighthouse repository on GitHub. There is a thing called StackPacks, and so there's a Drupal StackPack. Feel free to contribute to it. If you have additional advice, if you think you know what you're doing, if you'd like to see more stuff and get involved with the community, provide your contributions. But let's spend, literally, well, not much longer on going through the kind of recommendations that you can see here and the kind of usual suspects that we can see. And the reason we partially decided to use Drupal.org as an example here is because it's still, can correct me guys, it's still in Drupal 7, right? That's right, Andrea. Drupal.org, as some of you who are listening may know, is usually one of the last sites to upgrade to the sort of latest versions of Drupal because of the custom integrations for issue queues for the Git repositories and the projects. So we tend to be sort of the last to leave the legacy systems, and that means that a lot of the recommendations we're seeing here are things that we're going to talk about that have been improved by this collaboration together with Google and Tag1 already in later versions of Drupal. We'll talk about some things that have been committed to Drupal 9 in a moment. But yeah, that makes Drupal.org a really good case study for what's the before state look like and what are some actionable things that you can do if you're in that situation. Exactly. Again, if you feel really passionate about making improvements at Drupal 7 for some reason, you can jump right in and copy over the stuff that was launched in 9 and so on. It's a complicated process, but if you feel committed, you can probably get it done. But the examples here, talking about deferring off-screen images, right, seems to be one of the highest culprits for probably effecting. And if here, in fact, you can see, or it's relevant to the different vitals, if you click LCP, right, you'll actually, no, doesn't seem to be the one affecting that much, I don't know, and the off-screen images, what they are, what are they culpable of. But in any case, they are slowing down the loading of the page. And the recommendation, the generic recommendation for Drupal, and we probably need to take a look at how to update this, is to install a module that can lazy load images. Well, as we were about to tell you today, you don't need to do this anymore for Drupal 9 latest subversion of it and Drupal 10 for sure, because lazy loading will be just available for you by default. And you just, you toggle, you toggle which images you choose to lazy load or not. But that's the great news, right, you can still potentially get this wrong in the later versions of Drupal, but it's just become a lot easier to get this right. And the same applies to next gen formats, right, the generic recommendation is to use that webpnavif, and there's a lot of work that has gone into the later versions of Drupal to make sure that this is also more readily available to you. I think with that pretty much in sort of in the interest of time maybe is probably all I had to show about that but if people have questions in the chat and I kind of lost track of the chat a little bit so if there's any questions in the chat or in the Q&A about the tool, about the vitals themselves. Yeah, one of the things. Surely won the challenge on the link between White House.gov and Drupal. Well done. That is, that is exactly right. And at different times there's, you know, been a variety of open source implementations there's been the White House on WordPress. There's been the White House on Drupal. There's a variety of other departments still there, and other organizations, the European Commission, the UN, NASA, all sorts of folks so nice nice little use direct there. And Adam, thanks for dropping in the link to the Drupal stack pack. Do you want to say a word about stack packs maybe you experienced with them like so folks understand what the process looks like. Yeah, I mean we've made some contributions there already I think to the Drupal stack back they do tend to be somewhat generic in the sense that they're provided. Based on an audit, there's not a lot of internal information so they sort of are generic like use a modern image format or for a script doesn't necessarily tell you how to solve the problem. But yeah in terms of updating them the project is actively maintained so if there's improvements that we can make there. Usually just opening up a full request gets gets attention from the team and we've been able to make improvements there but they do sort of have to be generic because of the way they're run the context that they're running. Yeah, so you'll see examples in there if you take a look at that link, folks. In fact, why don't I share screen really quickly. I don't see why not. If you are interested in sort of contributing to this which is a part of our theme for today is we want you to use these tools but also maybe to get back and help Drupal as a whole get better. Right. Yeah, there are these categories of things that might need improvement like using modern image formats, and then there's recommended steps. So you can go in and say oh I think there's a better set of instructions for CSS aggregation right. And so I want to provide a pull request to provide those better steps, or to include links to key documentation or things like that so there's a variety of ways for improvement there and these are what you'll see if you run lighthouse on your site and it's detecting things that you could improve in the Drupal space. I did see one raised hand. And I want to encourage who the participant who is doing that if you could throw a quite that question in the chat or the Q&A tab we can take a look at it. We're not doing sort of live panelists chat at the moment but again, the chat function of the Q&A should work if you did have a question there. So briefly before we move on to okay what have we actually done like what have we done in the Drupal community in partnership with Tag1 in partnership with Google to actually make improvements based on the kinds of things that we've seen previously in Drupal sites. Before we get there I want to encourage you to take a look at your own sites this tool that Andre showed us is something that you can use right now. You can go to hbspeed.web.dev. We'll get you there you can drop in a URL and you can begin to see some of these details on projects that you work on today. Rajab in the chat linked another tool that does some similar work incorporated. I believe that team has some added some more Drupal specific things and of course there's the lighthouse implementation as well. What I think we want to do, Adam, is maybe talk to you next to talk about, you know, what's the approach for an organization the size and the scale of Google to come collaborate with a CMS project like Drupal or like WordPress or anyone else. And, you know, what's what's kind of the structure and attitude towards figuring out how to create that collaboration and make these improvements. Sure. Yeah, so I mean our team is very much focused on the open source CMS space so that's what I'm going to focus on and so there are literally hundreds maybe thousands of CMSs around the world. And the idea is to help bring up the open web as a whole by, you know, improving the core of these CMSs and WordPress is obviously the largest one by numbers. So we've focused a lot there. Drupal is kind of, I would say number two in most markets. So I think also very important in certain verticals. And the idea is to, you know, make sure that those CMSs provide the right APIs the right tools for developers so that they can, you know, do the best job on for creating websites. And what we've seen like when you look at that field data that, you know, that I think we've seen like in these charts that overall CMSs aren't doing very well. Like compared to like on core web vitals, overall sites that are built in WordPress sites that are built in Drupal are doing a little better, but overall there's a lot of room for improvement. You know, there's a small percentage of sites that really pass these metrics. And I think you mentioned it before, you know, that what we're sort of competing with are the experiences that people have when they're using apps on their phones. And we all know how fast and responsive those experiences are. And the goal is to kind of bring the web up to where it functions just like an app does on your phone where things load instantly, they're responsive. And the core web vitals are just a great way to approach us because they really get at the user's experience and not just sort of the raw speed metrics that we've maybe used in the past. So in terms of our engagement, you know, what we've been doing in the last year plus a couple years is trying to work with directly with the CMSs in WordPress we've formed a performance team to focus on performance. And then also working with like agencies in the space to help us with deliver specific improvements that we've recognized. So, you know, that's tag one here in worked quite a bit in the WordPress space with with 10 up, which is another big agency in that space. And so trying to introduce those changes into core so that, you know, either every site's going to get faster or have better page experience or at least developers will have the tooling that they need to improve performance in the future. And I think there's a great example of how this approach has a broader impact that maybe even seems like it might at first because as you're as you say, you know, this focus is on these platforms as a whole open source CMS is make up a significant percentage of the web. You know, I've seen numbers as high as like 50% of all pages web pages are served on some of these open source CMS platforms are across the CMS space in general, and if the improvement is made on the platform level, you know, it's great to also give the site owners the tools to make changes to their specific site. But if, when you came to us and said hey we want to collaborate so that out of the box by default these improvements are just in Drupal for everyone. You know that rising tide raises all of the ships improves Drupal everywhere. And we've seen even even beyond that improvements that have gone just to the wider PHP ecosystem so we worked with another Googler, Ben Morse. Early in this process on one of the things you saw in the, the page speed audit this idea of using more modern image formats right and we were like, Hey, Avif would be a really cool thing to support and as we worked on it together we discovered oh you know it needs upstream support in PHP to make this possible. And because of that collaboration, you know that upstream support got into PHP and then got into Drupal and kind of made these sort of things possible so Yeah, we're, you know, what I really appreciate and why the Drupal Association is so committed to this kind of partnership is we're not in, we're not going one by one to improve individual websites we're trying to improve the web as a whole. So, speaking quickly about these partnerships and Andrea let you chime in as well. If you're out there in your partner organization of the Drupal Association. We want to hear from you because one of the things that we see our role as as the DA is to help connect potential partners to each other to advance these goals for Drupal specifically and for the open web in general. And so it was sort of my pleasure to help introduce Andre to the tag one team as one of the major contributors to Drupal and experts in performance as a way to help advance some of this collaboration. In addition to everything we were doing with the community out in the open and in the issue queues so Andrea I don't know if you want to say a few words about that partnership. So we'll keep it quick in order for time and then let Janice and Fabian tell us a little bit about what specific work they did to improve Drupal. Absolutely I think the work that Janice and Fabian are going to talk about will speak for itself but all I can say on our part has been a tremendous partnership with enjoyed the collaboration and this is exactly what we've been looking for the ability to innovate and the ability to find solutions for challenges that are not always obvious and we're looking for more of the same. We will continue our collaboration with tag one for sure. And as you said team we're really really open and we're really welcoming more ideas and in fact Adam has quickly mentioned the performance team were still keeping our fingers crossed for being able to spin up a similar initiative within the Drupal space so we can all participate in this together. Yeah, but with that. Also, yeah. Sorry, sorry. So with that I think it would be great to Janice I'd love to hand it over to you so we got together we have these lofty ideas about improving the open web we have core web vitals to use as our metrics to understand success. But what did we actually do when what is this conversation sort of actually achieved so far where did we go. Why don't you walk us through that. Sure. Thank you, Sam. So there, there are a lot of things that could be done, right, some of them, as you already mentioned is example of a VIP, which is a really nice idea but then it turned out that it's, you know, a longer term engagement longer term project because it involves bringing things into GD and then PHP and so on. And then on the other hand, there are really low hanging fruit that might not have such a big impact. Like one example that I can think of is I would recommend you to use modern image formats, and we could, for example, update to mommy, or standard install to convert all image styles to WebP, which is already in the core. But that wouldn't affect a lot of sites outside of mommy because people generally create their own. Yeah, exactly. Everybody using a demo but that's probably not the majority of live sites. Exactly. Exactly. But it's also worth mentioning that you have this functionality in core. And if you want to use this modern image formats WebP is there, and you can start using it today. But yeah, we have to talk what what we added to core. And as I said, we were trying to find something that is lower hanging fruit but still have a lot of impact. And we talked to the community, we look at the issue queues look at the open issues. And we saw that lazy loading came up a few times. And lazy loading is not the simplest thing to do, but it's also something if done right could automatically benefit every website, new installs and existing installs, like not just like changing the image styles in a mommy which would only change your moment, which by the way, is doing really good with Coral Web Widows. So we figured out that usually group of core comes with very good performance, and then we destroy it along the way. So we have to learn how not to do that. Ten modules willy nilly and just. Yeah, we've all done that. So yes, we decided that lazy loading is something we could and should look at. And we divided it into four steps. First step was enabling lazy loading for non responsive images. Second step was enabling lazy loading for responsive images, and then for enabling it for all embeds, and to enable it on things that are embedded into CK editor. And then lazy loading of non responsive images was committed and released with Drupal 9.2. So if your website is updated to 9.2 or greater, you have lazy loaded lazy loading of images enabled by default. And then we realized that we, while we do usually want lazy loading to be enabled for most images, there are some cases where you don't want to have that. And that is one example. The biggest example is like a hero image that appears at the top of the page immediately when the page loads that you don't want to lazy load you want to deliver it immediately. And that's why in 9.4 we added a possibility to configure whether the image, an image should be lazy loaded or not. So if you update to 9.4, you can go into image format or configuration and decide whether you want lazy loading or not. And that's great. But unfortunately, we still don't have lazy loading for responsive images available. But that was already committed, and it's coming out with Drupal 10.1, which we're super excited about. And yeah, if you are a little bit adventurous, maybe you can go and grab a patch and apply it to your Drupal 9 site and already leverage that. And I have to say that we've also done that with some of our client sites and it works great. Another thing that is coming out in 10.1 is lazy loading of all embeds. So if you are embedding like a social post or something like that, you can lazy load it. And I'm actually quite excited that I had to update the notes for this webinar, literally 15 minutes before we started it. So there was this last thing about lazy loading images that appear inside with rig inside CK editor that was still open yesterday. And just when I started to last minute, perhaps I saw that that issue was committed as well. So lazy loading of images that are in CK editor is coming to 10.1 as well. And it's implemented as a text filter, so you will configure it in your text format. And it's basically opt out. So by default images will laser load, but you can override it. So yeah, that's what we've done. We're really excited about it. And we're looking forward for Drupal's performance metrics to grow on those graphs that I believe we will see at some point today. Yeah. In fact, I think that's probably where we'll go next. So I'm going to put up on the screen a couple of, you know, we've talked about, hey, we've done this collaboration. This has been a between Google and the DA has been a multi year effort and a significant amount of time with Tag 1. And, you know, we've done educational campaigns at Drupal con in webinars like this one workshops, as well as these collaborations directly in Drupal core and it would be good to see how are we doing. Have we made an impact? Have we moved the needle? I think that's really important. And so there's another tool, data studio tool that Google provides where I'd love to share some of this data and get some color commentary here from Fabian about our success and what we're doing. So I have two reports that I want to show off really quick. Next is the Corp of vitals technology report showing Drupal against the most common enterprise level proprietary CMS ecosystems. So you can see here, the dark blue line here is sort of just the picture of all of the web and how it's kind of maybe generally doing right now. So here is in light blue AEM and pink and site core and orange here. And I'm really thrilled to see this for several reasons. One is, even from the start, we've sort of been better than the web on average in the Drupal ecosystem, but not only that, we've had some changes in the, you know, in our results in the quality of the core web vital scores for the Drupal sites that have been indexed by the system, such that it's almost 50%. It's almost one in two index sites have this passing kind of grade on the on the Corp of vitals which is a really impressive milestone. And, you know, not to not to be mean about it but I always love to see an open source ecosystem being so successful in comparison to close source ecosystems that have billions of dollars in funding that we don't have. And yet, you know, our focus on community collaboration on working with great partners. And sort of taking seriously the open web from a philosophical point of view and not just a business perspective has really paid off so I personally think that's that's really powerful. And then really quickly. This is Drupal in the context of other open source CMS platforms, and it also looks great. All of the CMS platforms have been increasing in their core web vitals the open web as a whole is is has been successful in these efforts to improve these performance metrics. But before we get a little too cocky about this. So our other open source CMS is and even in the PHP space that are still doing perhaps, oh, if it loads that are still doing perhaps a little better than us so, you know, you got to be careful how you pick your data but so we have some things that we can still learn in the Drupal space some more space to go to catch up with the likes of folks like type of three who've done a great job as well. And so what we're going to do here, a great signs of early progress, but also still more room to grow. So Fabian let me sort of give you the mic and anything you'd like to kind of add to this. Yeah. It would be cool if you could switch the client over quickly for mobile to desktop as suggested. Oh yes, absolutely. I didn't even notice that was success. There you go. This is also looking really good here we are going even over the 50%. So yeah, I agree with you that it's really nice to be as a little David against the goal yet to have such an impact on the open map. And it's really great collaboration it's also great how we can definitely see on the graph, especially on mobile that was visible, how we could change that all. And Adam said we should really quickly look at the settings tab. So that might be a good idea just to go over there real quick so and what is really important here on the settings tab is that we can can also look at the origins but what's much more important is what I alluded to earlier is a geographic where the geographic is coming from. Because for example if you're looking at your graphics just related to how is it looking like in the United States. Then it gives a different picture like if you for example to like South Africa. Yeah, we can try. Before so hopefully we'll be here. Live demos. So pretty good. And then there's that's other parts of what we can can focus on. But yeah there's lots of interesting stuff. And yeah, if you care about inclusion, it's definitely a very good idea to check and have an international audience like it's no one from the international ever visits your site it's fine to just focus on USA, because that's where you get the biggest bang for the buck for your performance optimizations that as soon as you go over to two other parts. It's definitely a good idea to just check hey how does my site even perform for visitors from from Asia and or from South Africa, or from South America, etc like that. And is there a difference between mainstream Europe and mainstream USA and then going to the other regions. So I find that one of the most important parts. But yeah, if you could go quickly back to mobile. Even though to put dry at two plus three is is is ahead and kind of like also optimized in in certain ways. There's more to come. Again, I want to thank Google for bringing an AVF support in the PHP ecosystem. This is kind of huge. It happened early, based on a conversation we had with some. There was like hey, if you really want AVF everywhere we need it in the GD because only then CMS can support it and that's kind of what someone from Google did. So shout outs to him. That was really great to to to get this and at one point it will go in and core but as you can see this is a quantifiable competitive advantages for every user of Drupal 9, Drupal 10 and hopefully will also help us get more people to Drupal because if you're doing a talk like why use Drupal for your manager for your client. However, this is the slide you can generate yourself and say like hey yeah if you say I'm you'll have 50% less better let's let's score in in certain metrics and yeah it's not a good idea. So that's part and so hopefully we have then this as an additional advantage in addition to the already great user experience we have and yeah and everything should be better so just focus on those core web titles. Fantastic, so we could clearly talk about this for a whole other hour and we are we're a little bit behind our schedule but our questions are really focused we do have one more section we want to talk about that will try and move through relatively which is what's next. You know, Google is committed to continuing to work with the Drupal community and other ecosystems, other open source projects to help improve the open web. And I want to talk about a little bit about why that is but then also specifically what we're doing we have some very interesting compelling project ideas for how we want to collaborate next. And as we talk about those I encourage you listening to this to think about, are you interested in participating are you interested in this notion of creating this sort of performance working group in Drupal. All these things that could accompany it. So first Andrea let me go to you. What, what is it that made you as we evaluated kind of, you know, a year's worth of collaboration and work together decide hey we want to keep doing this. I think in the shortest possible terms as bank for the buck. We. I think we knew what we were trying to invest in a year ago approximately. We had a fairly good idea of how this was supposed to turn out, and it exceeded our expectations. I mean you see the results speak for themselves. It's not only the changes that we've built together that push Drupal's performance higher, but we never expected that that to be the case that investment is only part of the overall surrounding work, you know, doing webinars and talking to the community visiting community events and generally raising the profile of user experience within the community and its importance that will keep driving it up. So that's it, you know, with this no no alternatives for us, we definitely want to be part of this journey. That's awesome. And I'm, you know, I'm, I'm certainly proud of that collaboration and what partners like who like tag one, like other partners of the association like our community contributors have been able to do over the course of this time. But to talk about, you know, a sort of proposed next step which has to do with, okay, we know the importance of performance but how can we make evaluation of performance sort of testing of performance integral to how we do ongoing development of Drupal so maybe you can start off with, you know, what is the kind of nature purpose and value of performance testing and kind of how does it work. And then you and Janice can talk about kind of what this opportunity is and what we're thinking of doing next. So performance testing is something that was originally proposed in, I think it was 2013. So it's great that in 2023, we finally get to it. I did a talk about it in Drupal contact 2013 I think it was. And so auto mind performance testing or tracking means essentially that it's like a CI system, you essentially ensure that things do not regress. It's so important, because at the problem with anyone that did sites without automated testing and then sites with automated testing will know is if you don't have automated testing, you better have a very, very good to a department that is then doing manual testing that automated tests will do. Because if you don't have on any, on any automated testing, then things can regress without you even noticing. And that's the same as performance tracking and one of the huge problems we had in Drupal always to that made automatic performance tracking pretty complicated was, we did not have a reassight. So we, if you were testing minimal, yeah, you would probably get some things but then if a template changes by a few milliseconds, who can who can know that is it impactful is it not obviously at the scale of thousands of seconds makes a huge difference because it's almost a second then etc like that. So this is, this is one of the, the huge problems that we, we ran into when we were originally doing that. And standard was, you had had a few modules but it was pretty light. It was not reassighted did not have that this umami all of that changed and actually I take one we already have a umami load test based on on goose which you can run it's open source it's free. So if you want to do some umami testing if you want to rack up a huge bill on your CDN, you can do it. We did so. And so, this is kind of what it's about you can think of it as like automate testing but for the specific metric of ensuring that performance does not regress. Awesome. And so this is going to require a collaboration between, you know, folks like you attack one who've done this before and have the expertise to help us as a community, figure out how to implement it and then of course all of the community members who are part of it, you know collaborating with folks like the Google team to understand it right okay so when we're creating our, you know, output of these tests, you know, getting our core web vitals metrics in there and all of those things. But Janice can you maybe, and I know we don't have much time but could you bullet quickly the different impacts that we hope this will have on the project. I should unmute myself. Yes. So, first and very important thing is that we get to data, like right now when core maintainers do manual performance testing. We don't have any historical data is just like one off testing. If, when we will start collecting this data from this automatic performance test, we will be able to compare which is very important will be able to identify which commit cost performance regression or which version and so on and so on. And by doing so, we will be able to quickly identify potential regressions problems, which will, and then by fixing them we will also not just speed the general through both sides but also triple development because if our testing will run faster. Our contributors will spend less time waiting, and we'll be able to focus more on actually contributing changes that matter. I'm going to provide some color there, a complete suite of the core test run takes about an hour and 20 minutes today on a 32 core 64 thread machine with 32 gigs of RAM and all these things right, like, that's, that's waiting time where someone has to switch gears wait for their test results to come back if that's, you know, if that's a little faster, that's time back that's quicker iteration. That's better improvement for everybody it's, it's a big deal. You know there's, there's probably 15,000 tests easily every month run on Drupal Association infrastructure between core and contrib. And that's hours and hours and hours of contributor time that we could optimize. And since you already mentioned it there is also environmental impact. Yeah, if we can speed up 15,000 tests each month. We will spend less CPU time which means less energy which means you know, it's better for the environment, which is a very important thing and why not do it if we can. Sorry, I'd love to see a version of the, the web vitals report that was, you know, something similar to that graph that's like a, here's the carbon reduction report of the web being faster, right, like I think that would be a really cool metric. Yeah, and then at the end, it's all the organization they're using Drupal and all the end users would benefit from this because the their websites, the organization's websites would be faster and the end users would get better experience. And then at the end, community benefits because we're better our users would be happier. We are saving the planet. Our developers are happier. So as Fabian said, it's about happiness. And if everybody's happier, which means that we've done something good. Yeah. So, in our last two minutes, I'm going to try and speed run through some of our final content here. If some of our panelists might have to hop off. If not, we'll try and answer a little bit of the questions here but there are other tools out there right this is not the only initiative but we do think that an investment in automated performance processing for Drupal has a significant potential for impact on end users on the community trying to contribute on the environment. There's many good reasons to do it. In addition to that, there's other initiatives. There's a great web profiler project led by Luca Luso. There was a tag one podcast about it that'll drop the link in the chat. That's another very cool project in a similar vein that would be something worth checking out and sort of general load testing and all of those things. And these are things that this collaboration can enable but also that we'll have to sort of fundraise to support it'll take infrastructure to manage and run automated load testing for the Drupal project, especially at the scale that we want to do it. So one of the things that I would ask each of you is to think about those Drupal Association memberships think about talking about your organizations updating their partnership levels and just ways to help support and fund these kinds of improvements that I think will have a really big impact. So very quickly, I know we're technically over time now I'd like each person to maybe give what one takeaway one action item that the audience can give so Janice maybe I'll start with you really quick. What would you like people coming away from this presentation to do next. Just update your Drupal Drupal sites to most recent version, if you didn't already and try using image lazy loading and if you're a feel a little bit adventurous, apply patches for the things that are coming out 10.1 and try using those. Awesome. Thank you or Adam. What would you have folks do coming out of this. Well, I'll be very obvious since we spent quite a bit of time talking about it use page speed that web.dev to test your site in your clients website now and figure out what needs to change that tomorrow. Awesome. I was going to say that I'll just say a good takeaway for me would be that the web vitals are really about how users experience your site and understanding the value of that and not just about speed. So my, I hope is that everyone will adopt a mindset of caring about their users. I think that's a really good point. Fabian, how about you. I stick to my point and just say make your users happy. Look at your call that fighters improve them and make them even happier. That's fantastic. So, and as I said before, if you're out there and listening, you can be part of these solutions. We are an open source community and open source project. Everyone here is involved because they're passionate about open source, you know, on top of, you know, that being part of their job role and things like that. And so we'd love to have your participation. So again, thank you everyone for attending. We'll say we've got one question here so we'll try and answer it really quickly. And then we'll, we'll let you all go so Rajab has asked. Will there be a built in intersection observer IO in Drupal core for better lazy loading effects or controls. Is there an API from Drupal for that. This is not something I know the answer to I wonder if Yanis or Fabian if you have heard any rumblings about that in the course of the implementations that have been happening so far I get the impression that this would be an enhancement beyond what we're already doing but but I'll let you answer. My answer would be I don't know about any initiative related to that, but I will let Fabian chime in. If you have any more info. No, I mean, we start kind of like this in official initiative on performance so it might be part of that but yeah we are not yet it's an official thing I think. Okay. Well, I would love to take more questions but to be completely honest I think that is all the time we have. And certainly we've been certainly we've been thankful for your time we've been thank you to have you here with us. We will send the recording information out after this presentation. I'd be happy to answer further questions so you can reach out to the Drupal Association by finding contact form on the Association staff page. You can reach out in the issue cues. You could to actually everyone present on this call is is available, either following some issues or in the Drupal Drupal slack. So we'd love to hear from you and if you want to be put in touch with anyone in particular, feel free to reach out to me specifically. But again, thank you very much for your time. Thank you to our speakers. And we're looking forward to coming back again and sharing with you the next wave of improvements in Drupal and for the open web, and talking about this further. Thanks everyone. Thank you. Bye.