Core Web Vitals: Google & Tag1 Improving Drupal's Performance, User Experience, and Your Bottom Line

[00:00:00] Brendan McNamara: Hello everyone, welcome, glad you're here for the session. We're here to talk about web performance and Core Web Vitals. Quick introductions: my name is Brendan McNamara, I'm from Google, I work on the Google Chrome team, and for Chrome I work on our open source support, mostly working in the CMS space, and also with some commerce platforms and CDNs. A consistency we see from the browser perspective is that performance is essential for any user regardless of where they are accessing the web, and that's why we're working with CMSes and Drupal in particular, to improve the web performance experience for end users as well as for developers who are bringing performance solutions to different customers.

[00:00:56] Janez Urevc: I'm Janez, I come from Tag1 Consulting. We teamed up with Google to improve Drupal's performance, both on the front end and on the back end. I've been with Drupal for a very long time. I love performance; I used to work with examiner.com, which used to be the biggest website on Drupal, and performance is dear to my heart. It was also interesting to work with the problems that presented to us.

[00:01:30] Brendan: We wanted to walk through a couple of things. First, an overview of what web performance includes and what the Core Web Vitals are. This is just a way of quantifying a user's experience so we're able to isolate the factors that can improve it. Then we wanted to bring that specifically to the Drupal context: what can sites built on Drupal do to improve their performance, and essentially why should they do that, so what's the association to the outcomes your business, nonprofit, or government is looking for, and how does performance play into those objectives.

[00:02:12] We also wanted to talk through the ways performance has been supported in the Drupal space and some of the collaboration our two teams have been doing. We also have an exciting project we've been contributing towards, which is making automated performance testing available through Drupal. So we want to associate how Core Web Vitals are important, but how do we act upon that, and this feature we've been developing is the way to do so. And then we'll go to questions.

[00:02:43] First I wanted to include a link that will bring you to an asset the Google team has created, web.dev vitals. In the talk we'll go through the overview of Core Web Vitals, but I wanted to point everybody to this place because it's where you can see many more assets about performance, case studies as well as the technical documentation.

[00:03:13] I recognize that for many developers, a topic like performance is something you understand and agree with, you think it's the right thing for the user and the organization, but the challenge is typically making that argument internally. Every organization is resource constrained, so it can be difficult to prioritize different advancements, performance being one of them. Many of the case studies on this page will prove and connect where there's a business connection to web performance, so you can help make a case internally for why investing in performance is good for an organization.

[00:03:56] From the Google side, performance has always been a challenge on the internet. For the Chrome browser team we use over 200 metrics to evaluate performance, which is quite a lot, more than what's really digestible and more than what is actionable. So in 2020 Google launched the Core Web Vitals, a way of quantifying user experiences around three different focus areas. The intention is that we wanted to create categories that are understandable as well as actionable, and provide a unified way of understanding performance for any developer, so if a developer is working with an agency or with a brand, nonprofit, or government, you can all use the same metrics and the same language.

[00:04:48] The first component we considered is the first thing that happens when you go to a site: you click a link, you go to a new page, and how quickly is that page rendering. We wanted to identify the time required for a good user experience, so the first metric is around loading. The second is around interactivity: once you're on that page, how responsive is it to the actions a user is driving. We've quantified that to identify the right thresholds for the expected interaction. And last but not least, we call this: does the page spark joy? This speaks to stability, are there movements on the page outside of the user's expectation? Think about when you're looking at an article and later an ad renders at the top and shifts the entire content down. It's not an action the user caused, but it still impacts how they're reading, and you may lose your place, or go to click a link and all of a sudden the page shifted.

[00:06:22] Let's go over the technical terms. Before going into the three, I wanted to point to the bottom, the traffic light, green, yellow, red. For each of the vitals we've identified what good looks like. A real motivation for Core Web Vitals is to have a quantified method for what creates a good user experience, and for a page to be considered passing Core Web Vitals, 75 percent of the origins have to meet the threshold that qualifies as good. For this first metric, loading, we've identified that 2.5 seconds makes a good user experience for a page to load, and for a site to have 75 percent of its origins meet that threshold is what qualifies as a good experience.

[00:07:18] A little more about this first metric for loading: Largest Contentful Paint is the formal, technical name. What it's identifying is the primary content for the page, which could be the largest image or the most substantial block of text, whatever the developer identifies as most critical. How quickly is that content rendering to the user? If it happens within 2.5 seconds, that's what we qualify as a good user experience.

[00:07:52] The second metric is for interactivity, and I'm curious from the group, is this metric, INP, Interaction to Next Paint, something people are familiar with? Some mostly know. The reason I ask is because it's a new metric for interactivity. Just a few weeks ago Google announced that this is the metric that will formally become our interaction metric. Previously the metric we were using was First Input Delay, FID. The reason we changed over is that for interactions, 90 percent of a user's time on a page happens after the page has loaded. So if you go to a menu section or press a button, you expect it to respond naturally, and if it's not responding, that becomes an issue.

[00:08:57] First Input Delay was evaluating the interaction for the first input a user made on the page. Interaction to Next Paint takes into account all interactions that happen on a page, so it's a more holistic metric. While Google announced it a few weeks ago, this becomes formal in March of 2024, so there's a little less than a year for it to become the formal metric. Back on the web.dev article I mentioned, we have a ton of collateral explaining more about Interaction to Next Paint.

[00:09:40] Finally, for the metric of does this spark joy, this is about stability. Once the page is loaded, is it only adjusting based on a user's interactions? This is the example where an ad could render and shift the content. We wanted to quantify, when a page is shifting, how much of that is non-disruptive and how much actually impacts the user's experience. What we saw is in the green section, 0.1 indicates 10 percent, so if content is slightly moving, that doesn't interfere, but when you have say 50 percent of the content removing itself from above the fold and going below the fold, that's when it has a bearing on the experience.

[00:10:38] Now getting more into the Drupal section. This asset comes from HTTP Archive, an open resource that analyzes web data and shows performance metrics. It's pulling from the Chrome User Experience Report, also known as CrUX, and it's showing the Core Web Vitals passing metric for different technologies. The view I have is from the technology report, and it shows the bottom blue line is the entire web, so for the entire web about 40 to 50 percent of the time the internet is passing Core Web Vitals. Drupal, however, is substantially above that, so Drupal itself is a fairly performant platform.

[00:11:25] But because the web is in a position to improve overall performance, Drupal has a key role. Especially as a leader in the performance space, there are ways we can take learnings Drupal has applied and spread them more largely to open source environments, but there's also much more headroom to be made. If 50 percent of origins on Drupal are passing Core Web Vitals, that means there's 50 percent that still have the capacity to optimize.

[00:12:07] One interesting note about the technology report: at the very top, where it has the technologies selected, you can break this report down into a couple of different dimensions. Right now I have it filtered for Drupal technologies, but if you wanted to compare other technologies you're using, you can, like site builders, themes, hosting platforms, JavaScript libraries, or CDNs. That's a way to understand what within your tech stack is passing Core Web Vitals and which component has the capacity for additional optimization.

[00:12:57] This connects to the web.dev link I mentioned, but why does performance matter? Aside from a bearing on the user's experience, it also connects to business outcomes. We listed a number of optimizations and how they impact an organization, and I encourage you to reference that web.dev article, because we have different case studies that speak to each of these KPIs. You can see how loading, interaction, and stability all impact different business outcomes, so for your site, if user engagement is what's most critical, there's a way to associate certain performance optimizations towards that outcome.

[00:13:51] The final note here is about how these changes can be made quickly and easily, through another tool. This is PageSpeed Insights, and I'm curious, have people used PageSpeed Insights before? It looks like a good amount have. The way it works is it pulls in information from two sources: Google's Lighthouse, which uses lab data for measurement, and the Chrome User Experience Report, which uses live data from how sites are in a live environment. You include a domain, search for it, and it tells you the Core Web Vitals outcomes. For this example I pulled the conference site, events.drupal.org Pittsburgh 2023, and we can see where the site is performing well and where there's space for optimization.

[00:14:58] What's most critical about PageSpeed Insights is not just the observations but the actions we can take. If you're optimizing a site for yourself or a customer, you can observe where Core Web Vitals are passing and where there's space to improve. Right down here we can see, eliminate render-blocking resources, and we also have an estimated impact you'd see from making that optimization. Particularly when dealing with limited time and you want to maximize the outcome, this is a great way to see what specifically is impacting performance and how to act on it. As you'll see, we also have specific recommendations associated with the site as a Drupal site, so it refers you to ways to actually benefit, like render-blocking resources and how to make that adjustment.

[00:16:06] Additionally, as an example, I wanted to pull an out-of-the-box Drupal site, a templated Drupal site that's not live. What we see is that in isolation it's passing Core Web Vitals pretty clearly, pretty strong, but it also shows there are other places we can still make optimizations. This relates to the project the Google team and Tag1 have been working on, by showing where the core platform is in place to make improvements. If we make an optimization to the overall Drupal core platform, that has resonance to every site built using the platform, and by seeing this out-of-the-box site it's good to know that Drupal is very strong in performance, but specifically there are other ways we can do, say, image optimization to improve performance for all sites built on Drupal.

[00:17:16] Connecting to what we're working on in Drupal core, we also wanted to talk through different optimizations our teams have been working on to improve Drupal at large. So, passing over to Janez.

[00:17:31] Janez: We worked on improving Core Web Vitals results directly in the past, and that project is, as you'll see, more or less done, and now we're working on another project, so we're continuing our collaboration. With this first step we focused on the lowest-hanging fruit to improve Core Web Vitals for all Drupal sites, and we focused on lazy loading, because that's one of the good ways to improve those metrics. As part of that effort we added the option to the image formatter to enable or disable lazy loading of the image. It's this selection here, where you can select if an image should be loaded eagerly, so immediately, or lazy loaded when it's needed.

[00:18:43] This was committed and it's already in core since 9.4, so you basically got it for free if you updated to something more recent than that. The recommendation we would give is to use lazy loading for all images except the one that is most prominent on page load, like a banner at the top, but for everything else you can enable lazy loading and get the benefit practically for free.

[00:19:14] Related to that, because that first one was for a standard image formatter, we also have responsive images, where you can use multiple sources and then let the browser decide which one to use, and we added the same configuration to the responsive image formatter. That feature was committed and is coming out in 10.1, and the guideline is the same: use it everywhere except for the topmost image on the page. You can wait until 10.1, or if you go to that issue you can take the patch and start using it before you upgrade.

[00:20:09] Then, staying on the lazy loading wagon, we also added a text filter to enable lazy loading of the images you've embedded into the CK Editor. If you want to leverage that, go to the text format configuration and enable this filter, called lazy load images, and then all images will be lazy loaded by default unless you put the loading eager attribute on the image. Just like the previous one, it's already committed into Drupal core and coming out in 10.1; if you'd like to use it before, go to the issue in the title and try the patch.

[00:21:18] Finally, lazy loading on iframes, this is on the formatter for oEmbed content, exactly the same as all the previous, so I won't repeat myself, and again it was committed and is coming out in 10.1. There's the issue if you want to patch it. So quite a lot of things, and if you keep your Drupal up to date you get all these new features for free, and we encourage you to start using them.

[00:21:48] Now we started working on another initiative, automated performance testing. When we were discussing how we could help and get the biggest impact, we realized we have this great quality assurance system for Drupal that runs all sorts of tests for every patch, but on the other hand, performance is tested in a very limited way. It was basically always done manually by core committers, usually before releasing a new release, which meant issues were identified later, when they're harder to fix. The example was a regression that got into the 9.5 release. Since it's manual, it takes a lot of precious time. So if we already have this automated system for quality assurance, why not test performance as well? We decided that would make a huge impact, so we're doing it.

[00:23:08] It's led by a core committer, Nathaniel Catchpole, known as catch. The goal is to have a framework for testing performance in Drupal's testing system, and then to have an initial set of tests that we'd run on every commit, at least initially. The limitation here is the infrastructure cost. We'd be very excited to extend this to every patch, but with the current funding it's simply not possible. Still, we thought testing on every commit would give us pretty frequent, early feedback about all the changes going into Drupal core. And we already identified problems; the issue linked there is about Umami and how it doesn't deal with the top banner image in a really nice way, and I think that was actually the top recommendation visible on PageSpeed Insights when Brendan showed it to you.

[00:24:35] This will run on Drupal Association infrastructure, just like the existing test bot, and could in theory be expanded to contrib. When the framework is done and the base classes for the tests are there, the only limitation is infra cost and, for maintainers of contributed modules, providing the performance tests. When this gets in, you could even use it in your own in-house pipelines for your projects to run these tests. So we really think it has enormous impact and a lot of potential.

[00:25:20] Which brings us to how we can work together to improve Drupal, because only if we work together will Drupal thrive. We need a lot of collaborators to have massive impact; if just a small portion of the community contributes, we can't achieve as much as if everybody comes together. There are many ways to contribute. We can improve tooling, that's a more technical side, like automated performance testing; if you want to get involved, there's a meta issue that links to other issues about specific improvements and tasks.

[00:26:10] One way to help is to improve Drupal-specific recommendations for Lighthouse, which then show up on PageSpeed Insights, like the recommendation we saw. There's a repository of recommendations for every platform, a public GitHub repo, so if you want to contribute that way you can provide better recommendations to point people to the right modules or to documentation pages. We can build new contributed modules, maybe a module that displays your Core Web Vitals metrics, something you could install like the SEO Checklist but for Core Web Vitals. And you can also help with promotions, webinars, blog posts, and podcasts to raise awareness about this topic and the projects going on.

[00:27:18] If you're more into technical stuff, there are a bunch of issues in the core queue that would improve performance, like adding support for contemporary image formats. AVIF and WebP are already supported, we can use WebP in image styles, but the standard installation profile still doesn't use it, so maybe help do that and improve the out-of-the-box performance of standard Drupal this way. There are other things like preloading images and minifying core JavaScript, so if you're interested in these topics, check out these issues. If you have any questions, ideas, or comments, please get in touch; our email inboxes are open for anything that could improve Drupal as a whole. I'll be happy to take some questions.

[00:28:39] (Question from the audience about the 9.5 regression causing a dip in the chart.) The question was about the 9.5 regression, yeah, I think so. With the HTTP Archive, especially being able to observe the trends over time, I find it pretty informative. Generally we hope and do see performance trending upward, but we can see where there are inflection points, so whenever there's a major release that has something specific to performance, we notice where overall performance has that. But on the counter, it could be an opportunity to identify a noticeable regression, so this is a better time to check in on that.

[00:29:34] (Question from the audience about the URL for HTTP Archive.) Yes, we do. That itself is the URL, so just HTTP Archive, and more specifically what we were looking at was the technology report, so I'd recommend looking at the technology report, and you can customize it by the technology breakdown, which is when we can analyze one CMS versus another. It should be httparchive.org. So this is it: reports, then Core Web Vitals technology report. Here's what it looks like with other CMSes included, and then we can specify for Drupal.

[00:32:01] (Question from the audience about frameworks and tag manager.) So the first was around frameworks, is that correct, and tag manager. For both of those, I think that with Drupal contributing towards performance, it does make more noise around performance, so when we're looking to create a culture of performance and we have specific issues that Drupal as an organization is looking to improve, that can be a way to surface what's important for one of the largest platforms. On those two specifically, I'd be happy to bring that back to some of our engineering teams to speak with them, so happy to talk about it.

[00:33:03] (Question from the audience about why testing runs on commits.) The question was why we decided to do automated testing on commits initially. These are, we're currently focusing on Drupal core, and core doesn't have that many commits actually. It has a lot of activity in the issue queue, which is the majority of the load of the current testing framework, but there can be days with no commits at all, or maybe 10 or 20 commits per day. The biggest number of commits would happen on a DrupalCon sprint, for example, but it's never that big of a number, so we thought that's the best trade-off between the impact and the infrastructure needs. We're not doing every commit to every contributed project at this point; we'd love to, but that would require much more infrastructure.

[00:34:32] (Question from the audience about base classes for performance tests.) The question was about base classes for performance tests. That issue there, the meta issue for the automated performance testing, links to another issue that's creating a test base class for performance tests. If you're familiar with tests in Drupal, you have base classes for unit tests, kernel tests, and functional tests; this will be just another one like those, so if you wanted to create your own performance test you would extend that class and write a test. That's the idea, and it's still not in; the issue is still active. If you're interested, go to the meta issue, and then there's another linked issue about adding this base class, which already has a patch and discussion.

[00:36:04] (Question from the audience about breaking out the report by CDN.) The report itself you could break out. The one I showed, PageSpeed Insights, would take a site in isolation, so if that site is using a CDN or a specific hosting platform, all of that is inclusive in the insights. But for HTTP Archive there's a way to break it out by the different CDN providers, so you could see one relative to another. So there is a way, yes.

[00:36:51] (Question from the audience about the teams involved.) Yes, and it's part of an extended team. From Google we're from the web platform side, so the Chromium open source project, and we work with a number of organizations in the Drupal space, Tag1 being one of them. And from Tag1 it's part of a larger extended team as well. Thank you, any other questions? Wonderful, thank you.