Rick Viscomi on web.dev

Advancing Interaction to Next Paint

2023-05-10T00:00:00Z

Chrome's mission with the Web Vitals program is to help developers focus on the metrics that are essential to great user experiences—the Core Web Vitals. One important aspect of the user experience that we've been focusing on is responsiveness, which is the ability of a web page to react quickly to user interactions.

First Input Delay (FID) is the Core Web Vital metric that measures responsiveness, but as we've written in the past, there are known limitations of FID. This led us to explore and seek feedback on a (then) experimental metric that addresses these limitations more effectively. In 2022, we announced Interaction to Next Paint (INP) as that new metric, made it widely available in our tools, and started working with the community to test its efficacy.

After another year of testing and gathering feedback from the community, we're ready to take the training wheels off and announce that INP is no longer experimental. Furthermore, effective March 2024, we're also committed to promoting INP as the new Core Web Vital metric for responsiveness, replacing FID.

In this post, we'll cover more about the motivation behind the decision, exactly what's changing, and how to get started. For more on how this affects Google Search, refer to their blog post.

A better responsiveness metric #

FID was a huge step forward when we introduced it as a Core Web Vital in 2020. It offered developers a new way to measure responsiveness as real users experience it, which has always been an important part of the Web Vitals program. Unlike similar metrics that only approximate page interactivity—like Total Blocking Time (TBT) and Time To Interactive (TTI)—FID directly measures the user experience. Crucially, a page could have slow TBT or TTI and still be perceived as responsive, because of the way real users interact with the page.

While it did improve the way we measure responsiveness, FID wasn't without limitations. The name itself actually gives away two such limitations: "first input" and "delay". FID only reports the responsiveness of the first time a user interacts with the page. Even though first impressions are important, the first interaction is not necessarily representative of all interactions throughout the life of a page. Further, FID only measures the input delay portion of the first interaction, which is the amount of time the browser had to wait (due to main thread busyness) before even beginning to handle the interaction.

Enter INP. Rather than only measuring the first interaction, INP takes all interactions into account, reporting one of the slowest over the entire lifetime of the page. And, rather than only measuring the delay portion, INP measures the full duration from the start of the interaction, through the event handler, and until the browser is able to paint the next frame. Hence, Interaction to Next Paint. These implementation details make INP a much more comprehensive measure of user-perceived responsiveness than FID.

Evolving INP #

Starting today, INP is no longer experimental and will instead be considered a pending Core Web Vital metric. This is a new designation to indicate that INP has proven its readiness to replace FID—but we're not making the change just yet. To give the ecosystem time to adjust, INP will officially become a stable Core Web Vital metric in March 2024.

Graphic showing the timeline of INP phases.

Across our tools, you'll start to see INP without the experimental prefix or icon. If you programmatically consume INP data from any of the following APIs, you'll need to update your code to switch over to the non-experimental INP field.

Map of APIs to their old and new INP field name.
* Lighthouse will stop using the experimental INP field in version 11.
Tool	Deprecated field	New field
CrUX API	`experimental_interaction_to_next_paint`	`interaction_to_next_paint`
CrUX History API	`experimental_interaction_to_next_paint`	`interaction_to_next_paint`
CrUX BigQuery	`experimental.interaction_to_next_paint`	`interaction_to_next_paint`
PageSpeed Insights API	`experimental_interaction_to_next_paint`	`interaction_to_next_paint`
Lighthouse report*	`experimental-interaction-to-next-paint`	`interaction-to-next-paint`

To ease the transition and avoid breaking any downstream applications, these APIs will continue to serve the experimental INP field for another 90 days. API support for the experimental INP field will end on August 8, 2023.

Meanwhile, FID will remain a Core Web Vital until March 2024. At that time, INP will join Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) as the three stable Core Web Vitals. In a future update, we'll share more information about the precise timing of the change and the plan for FID after it's replaced as a Core Web Vital.

Getting started with INP #

Graphic showing the thresholds for good and poor INP.

Don't wait for INP to become a Core Web Vital in 2024 to start improving it. Your website may very well be in the 93% of sites that have good FID performance on mobile devices; however, you might be surprised to learn that only 65% of sites have good INP on mobile devices. INP paints a much more accurate picture of responsiveness, so these numbers help us to more clearly see the room for improvement ahead of us.

To find out whether your site has INP issues, how to address them, and all things INP, the best place to start is the INP optimization guide. Whether you're learning about responsiveness for the first time or you're a performance expert, we've added a lot of new guidance to make it as easy as possible for everyone to learn how to measure and optimize INP.

INP might take some time to learn, and that's just fine. To help you focus on the optimizations with the biggest ROI, earlier this year we published a blog post to distill our guidance down to the most effective recommendations to improve Core Web Vitals. Specifically, we wrote about three must-know techniques that apply equally to optimizing FID and INP: avoid or break up long tasks, avoid unnecessary JavaScript, and avoid large rendering updates. You can learn more about these and many other INP optimization techniques in our documentation.

The road ahead #

A new bar for responsiveness has been set, and we're excited to see the community rise to the challenge for a better user experience. The early feedback and case studies have been promising, but we know that for many, it may be a long and unfamiliar road ahead. We strive to make that journey as easy as possible with improved diagnostics, tools, and documentation to help developers along the way.

Stay tuned for updates on INP's exact graduation date in March 2024. And even though the metric is not experimental anymore, we're always open to feedback at web-vitals-feedback@googlegroups.com to help us improve INP and the Web Vitals program as a whole.

Hero image from Unsplash, by Agê Barros.

Using the Web Vitals extension to debug Core Web Vitals issues

2023-05-04T00:00:00Z

The Web Vitals extension provides easy access to Core Web Vitals diagnostic information to help developers measure, and address Core Web Vitals issues. It supplements the other tools provided by the Chrome team to aid developers in improving the experiences on their websites.

We have updated the extension to provide additional debug information to developers to make it easier to understand and address their performance problems.

Showing debug information in the console #

The Web Vitals extension has had a "Console Logging" debug option for some time now. It can be enabled in the Options screen:

Prior to the this last upgrade, this logged the outputs from the web-vitals library (that underpins the extension) in a JSON object:

This object could then be expanded to get the full details, and elements such as the LCP image, could be hovered over to highlight them in the main panel:

This was helpful, but the output format was not particularly user friendly, and we thought we could provide a better developer experience. So we have improved the extension to make the most important information more visible—while still including the full object for those wanting more details.

New debug information for each metric #

With the new release, we have added new debug information in a more readable format to help you find and address issues. Different information is provided for each of the metrics, as each one is different.

LCP debug information #

For Largest Contentful Paint (LCP), we show both the element, and the breakdown of the 4 phases detailed in our Optimize LCP guide:

The LCP time (2,876 milliseconds—or about 2.9 seconds) is highlighted in amber as it is in the "Needs Improvement" category.

In this example, we see the Resource load time is the longest time, so to improve your LCP time you would look to optimize that - perhaps by avoiding hosting them on a separate domain, or by using smaller images or more efficient formats. In this case it's due to being artificially slowed down to demonstrate the output—web.dev is a fast site 😀

The element can also be hovered over to highlight the image:

Right clicking on the element also allows you to reveal it in the elements panel.

Here the LCP element is an image, and hovering over that in the console on the right, also highlights that element on the site on the left.

CLS debug information #

Shifts contributing to Cumulative Layout Shift (CLS) are now also listed, and can be hovered over to highlight the relevant element:

The above screenshot shows 2 shifts, the first made up of two elements (when the banner image is loaded and the content beneath it is shifted downloaded), and the second of 4 elements (when the dynamic ad is loaded and most of the page is shifted downwards).

The h2 element is being hovered over in this screenshot in the console on the right, and you can see this highlights the element on the site on the left.

FID debug information #

For First Input Delay (FID) we show the affected element (which again, can be hovered over to highlight it on the page) and the interaction type, along with the full JSON object as usual:

INP debug information #

For Interaction to Next Paint (INP), we have added two new logs:

INP - the longest interaction
Interactions - all interactions

INP metric #

First up, we highlight the INP metric when it changes:

Similar to LCP, the extension breaks down the INP time to show three phases:

Input delay
Processing time
Presentation delay

This helps you identify if the event was slow due to being held up by other events (input delay), as the event handler itself was slow due to your code (processing time), if the post-processing render delay was the reason (presentation delay), or a combination of two or more of these.

Interactions #

INP can be slow due to previous interactions blocking the main thread, and thus causing a high input delay. For this reason, we list all interactions in a similar format to the INP logging:

This allows you to "live trace" a website by interacting with it and seeing in the console which interactions, in which combinations, are likely to cause an INP problem.

This also allows you to identify multiple slow interactions, rather than just the largest INP interaction to help you avoid the feeling of chasing your tail when improving your responsiveness.

Filtering the console logs #

All this extra information, while useful, can be distracting if you are doing other development unrelated to Core Web Vitals, or are only interested in one particular Core Web Vital at that time.

You can use the Console filtering options in DevTools to filter out some or all of the messages:

To remove all the extension messages, you can either turn this off in the options or use the -Extension filter.
To look at just LCP you can use the Web Vitals Extension LCP filter.
To look at just INP and interactions you can use the Web Vitals Extension -LCP -CLS -FID filter.

We're trying to keep the number of options for this extension down, but do let us know by raising a GitHub issue if DevTools filtering is not sufficient and you would prefer options here.

Conclusion #

We hope you find the new debug options in the latest version of the extension useful and that they make it easier to identify and resolve Core Web Vitals issues, improving the user experiences on your website.

Do remember that your experiences, on your developer computer, may not be representative of what your real users are experiencing. Check out our previous blog post on how you can view the CrUX field data for your site in the extension to get a sense of how aligned your experiences are with your users.

We would be grateful to hear any feedback on these improvements, or any other suggestions on our GitHub issues tracker.

Acknowledgements #

Hero image by Farzad on Unsplash

Our top Core Web Vitals recommendations for 2023

2023-01-10T00:00:00Z

Over the years, we at Google have made a lot of recommendations to web developers on how to improve performance.

While each of these recommendations, individually, may improve performance for many sites, the full set of recommendations is admittedly overwhelming and, realistically, there's no way any one person or site could follow all of them.

Unless web performance is your day job, it's probably not obvious which recommendations are going to have the largest positive impact on your site. For example, you might have read that implementing critical CSS can improve load performance, and you may have also heard that it's important to optimize your images. But, if you don't have time to work on both things, how would you decide which one to pick?

On the Chrome team, we've spent the last year trying to answer this question: what are the most important recommendations we can give to developers to help them improve performance for their users?

To adequately answer this question we have to consider not just the technical merits of any given recommendation, but also human and organizational factors that influence the likelihood that developers will actually be able to adopt these recommendations. In other words, some recommendations may be hugely impactful in theory, but in reality very few sites will have the time or resources to implement them. Similarly, some recommendations are critical, but most websites are already following these practices.

In short, we wanted our list of top web performance recommendations to focus on:

Recommendations we believe will have the largest real-world impact
Recommendations that are relevant and applicable to most sites
Recommendations that are realistic for most developers to implement

Over the past year we've spent a lot of time auditing the full set of performance recommendations we make, and assessing each of them (both qualitatively and quantitatively) against the above three criteria.

This post outlines our top recommendations to improve performance for each of the Core Web Vitals metrics. If you're new to web performance, or if you're trying to decide what will give you the biggest bang for your buck, we think these recommendations are the best place to start.

Largest Contentful Paint (LCP) #

Our first set of recommendations are for Largest Contentful Paint (LCP), which is a measure of load performance. Of the three Core Web Vitals metrics, LCP is the one that the largest number of sites struggle with—only about half of all sites on the web today meet the recommended threshold—so let's start there.

Ensure the LCP resource is discoverable from the HTML source #

According to the 2022 Web Almanac by HTTP Archive, 72% of mobile pages have an image as their LCP element, which means that for most sites to optimize their LCP, they'll need to ensure those images can load quickly.

What may not be obvious to many developers is that the time it takes to load an image is just one part of the challenge. Another critical part is the time before an image starts loading, and HTTP Archive data suggests that's actually where many sites get tripped up.

In fact, of the pages where the LCP element was an image, 39% of those images had source URLs that were not discoverable from the HTML document source. In other words, those URLs were not found in standard HTML attributes (such as <img src="..."> or <link rel="preload" href="...">), which would allow the browser to quickly discover them and start loading them right away.

If a page needs to wait for CSS or JavaScript files to be fully downloaded, parsed, and processed before the image can even start loading, it may already be too late.

As a general rule, if your LCP element is an image, the image's URL should always be discoverable from the HTML source. Some tips to make that possible are:

Load the image using an <img> element with the src or srcset attribute. Do not use non-standard attributes like data-src that require JavaScript in order to render, as that will always be slower. 9% of pages obscure their LCP image behind data-src.
Prefer server-side rendering (SSR) over client-side rendering (CSR), as SSR implies that the full page markup (including the image) is present in the HTML source. CSR solutions require JavaScript to run before the image can be discovered.
If your image needs to be referenced from an external CSS or JS file, you can still include it in the HTML source via a <link rel="preload"> tag. Note that images referenced by inline styles are not discoverable by the browser's preload scanner, so even though they're found in the HTML source, discovery of them might still be blocked on the loading of other resources, so preloading can help in these cases.

To help you understand if your LCP image has discoverability problems, Lighthouse will be releasing a new audit in version 10.0 (expected January 2023).

Ensuring the LCP resource is discoverable from the HTML source can lead to measurable improvements and it also unlocks additional opportunities to prioritize the resource, which is our next recommendation.

Ensure the LCP resource is prioritized #

Making sure the LCP resource can be discovered from the HTML source is a critical first step in ensuring the LCP resource can start loading early, but another important step is ensuring that the loading of that resource is prioritized and doesn't get queued behind a bunch of other, less important resources.

For example, even if your LCP image is present in the HTML source using a standard <img> tag, if your page includes a dozen <script> tags in the <head> of your document before that <img> tag, it may be a while before your image resource starts loading.

The easiest way to solve this problem is to provide a hint to the browser about what resources are the highest priority by setting the new fetchpriority="high" attribute on the <img> or <link> tag that loads your LCP image. This instructs the browser to load it earlier, rather than waiting for those scripts to complete.

According to the Web Almanac, only 0.03% of eligible pages are taking advantage of this new API, meaning there is plenty of opportunity for most sites on the web to improve LCP with very little work. While the fetchpriority attribute is currently only supported in Chromium-based browsers, this API is a progressive enhancement that other browsers just ignore, so we strongly recommend developers use it now.

For non-Chromium browsers, the only way to ensure the LCP resource is prioritized above other resources is to reference it earlier in the document. Using the example again of a site with lots of <script> tags in the <head> of the document, if you wanted to ensure your LCP resource was prioritized ahead of those script resources, you could add a <link rel="preload"> tag before any of those scripts, or you could move those scripts to below the <img> later in the <body>. While this works, it's less ergonomic than using fetchpriority, so we hope other browsers add support soon.

Another critical aspect of prioritizing the LCP resource is to ensure you don't do anything that causes it to be deprioritized, such as adding the loading="lazy" attribute. Today, 10% of pages actually set loading="lazy" on their LCP image. Beware of image optimization solutions that indiscriminately apply lazy-loading behavior to all images. If they provide a way to override that behavior, be sure to use it for the LCP image. If you're not sure which image will be the LCP, try using heuristics to pick a reasonable candidate.

Deferring non-critical resources is another way to effectively boost the relative priority of the LCP resource. For example, scripts that are not powering the user interface (like analytics scripts or social widgets) can be safely postponed until after the load event fires, which ensures they won't compete with other critical resources (such as the LCP resource) for network bandwidth.

To summarize, you should follow these best practices to ensure that the LCP resource is loaded early, and at high priority:

Add fetchpriority="high" to the <img> tag of your LCP image. If the LCP resource is loaded via a <link rel="preload"> tag, fear not because you can also set fetchpriority="high" on that!
Never set loading="lazy" on the <img> tag of your LCP image. Doing this will deprioritize your image and delay when it starts loading.
Defer non-critical resources when possible. Either by moving them to the end of your document, using native lazy-loading for images or iframes, or loading them asynchronously via JavaScript.

Use a CDN to optimize document and resource TTFB #

The previous two recommendations focused on making sure your LCP resource is discovered early and prioritized so it can start loading right away. The final piece to this puzzle is making sure the initial document response arrives as quickly as possible too.

The browser cannot start loading any subresources until it receives the first byte of the initial HTML document response, and the sooner that happens, the sooner everything else can start happening as well.

This time is known as Time to First Byte (TTFB), and the best way to reduce TTFB is to:

Serve your content as geographically close to your users as possible
Cache that content so recently-requested content can be served again quickly.

The best way to do both of these things is to use a CDN. CDNs distribute your resources to edge servers, which are spread across the globe, thus limiting the distance those resources have to travel over the wire to your users. CDNs also usually have fine-grained caching controls that can be customized and optimized for your site's needs.

Many developers are familiar with using a CDN to host static assets, but CDNs can serve and cache HTML documents as well, even those that are dynamically generated.

According to the Web Almanac, only 29% of HTML document requests were served from a CDN, which means there is significant opportunity for sites to claim additional savings.

Some tips for configuring your CDNs are:

Consider increasing how long content is cached for (for example, is it actually critical that content is always fresh? Or can it be a few minutes stale?).
Consider maybe even caching content indefinitely, and then purging the cache if/when you make an update.
Explore whether you can move dynamic logic currently running on your origin server to the edge (a feature of most modern CDNs).

In general, any time you can serve content directly from the edge (avoiding a trip to your origin server) it's a performance win. And even in cases where you do have to make the journey all the way back to your origin server, CDNs are generally optimized to do that much more quickly, so it's a win either way.

Cumulative Layout Shift (CLS) #

The next set of recommendations are for Cumulative Layout Shift (CLS), which is a measure of visual stability on web pages. While CLS has improved a lot on the web since 2020, about a quarter of websites still do not meet the recommended threshold, so there remains a big opportunity for many sites to improve their user experience.

Set explicit sizes on any content loaded from the page #

Layout shifts usually happen when existing content moves after other content finishes loading. Therefore, the primary way to mitigate this is to reserve any required space in advance as much as possible.

The most straightforward way to fix layout shifts caused by unsized images is to explicitly set width and height attributes (or equivalent CSS properties). However, according to HTTP Archive, 72% of pages have at least one unsized image. Without an explicit size, browsers will initially set a default height of 0px and may cause a noticeable layout shift when the image is finally loaded and the dimensions are discovered. This represents both a huge opportunity for the collective web—and that opportunity requires much less effort than some of the other recommendations suggested in this article.

It's also important to keep in mind that images are not the only contributors to CLS. Layout shifts may be caused by other content that typically loads in after the page is initially rendered, including third-party ads or embedded videos. The aspect-ratio property can help combat this. It's a relatively new CSS feature that allows developers to explicitly provide an aspect ratio to images as well as non-image elements. This will allow you to set a dynamic width (for example based on screen size), and have the browser automatically calculate the appropriate height, in much the same way as they do for images with dimensions.

Sometimes it's not possible to know the exact size of dynamic content since it is, by its very nature, dynamic. However, even if you don't know the exact size, you can still take steps to reduce the severity of layout shifts. Setting a sensible min-height is almost always better than allowing the browser to use the default height of 0px for an empty element. Using a min-height is also usually an easy fix as it still allows the container to grow to the final content height if needed—it has just reduced that amount of growth from the full amount to a hopefully more tolerable level.

Ensure pages are eligible for bfcache #

Browsers use a navigation mechanism called the back/forward cache—or bfcache for short—to instantly load a page from earlier or later in the browser history directly from a memory snapshot.

The bfcache is a significant browser-level performance optimization, and it entirely eliminates the layout shifts during page load, which for many sites is where most of their CLS occurs. The introduction of the bfcache caused the biggest improvement in CLS that we saw in 2022.

Despite this, a significant number of websites are ineligible for the bfcache and so are missing out on this free web performance win for a significant number of navigations. Unless your page is loading sensitive information that you don't want to be restored from memory, you'll want to make sure that your pages are eligible.

Site owners should check that their pages are eligible for the bfcache and work on any reasons why they are not. Chrome already has a bfcache tester in DevTools and this year we plan to enhance tooling here with a new Lighthouse audit performing a similar test and an API to measure this in the field.

While we have included the bfcache in the CLS section, as we saw the biggest gains there so far, the bfcache will generally also improve other Core Web Vitals too. It is one of a number of instant navigations available to drastically improve page navigations.

Avoid animations/transitions that use layout-inducing CSS properties #

Another common source of layout shifts is when elements are animated. For example, cookie banners or other notification banners that slide in from the top or bottom are often a contributor to CLS. This is particularly problematic when these banners push other content out of the way, but even when they don't, animating them can still impact CLS.

While HTTP Archive data can't conclusively connect animations to layout shifts, the data does show that pages that animate any CSS property that could affect layout are 15% less likely to have "good" CLS than pages overall. Some properties are associated with worse CLS than others. For instance, pages that animate margin or border widths have "poor" CLS at almost twice the rate that pages overall are assessed as poor.

This is perhaps not surprising, because any time you transition or animate any layout-inducing CSS property, it will result in layout shifts, and if those layout shifts are not within 500 milliseconds of a user interaction, they will impact CLS.

What may be surprising to some developers is that this is true even in cases where the element is taken outside of the normal document flow. For example, absolutely positioned elements that animate top or left will cause layout shifts, even if they aren't pushing other content around. However, if instead of animating top or left you animate transform:translateX() or transform:translateY(), it won't cause the browser to update page layout and thus won't produce any layout shifts.

Preferring animation of CSS properties that can be updated on the browser's compositor thread has long been a performance best practice because it moves that work onto the GPU and off the main thread. And in addition to it being a general performance best practice, it can also help improve CLS.

As a general rule, never animate or transition any CSS property that requires the browser to update the page layout, unless you're doing it in response to a user tap or key press (though not hover). And whenever possible, prefer transitions and animations using the CSS transform property.

The Lighthouse audit Avoid non-composited animations will warn when a page animates potentially slow CSS properties.

First Input Delay (FID) #

Our last set of recommendations are for First Input Delay (FID), which is a measure of a page's responsiveness to user interactions. While most sites on the web currently score very well on FID, we've documented shortcomings of the FID metric in the past, and we believe there is still a lot of opportunity for sites to improve their overall responsiveness to user interactions.

Our new Interaction to Next Paint (INP) metric is a possible successor to FID, and all of the recommendations below apply equally well to both FID and INP. Given that sites perform worse on INP than FID, especially on mobile, we encourage developers to seriously consider these responsiveness recommendations, despite having "good" FID.

Avoid or break up long tasks #

Tasks are any piece of discrete work that the browser does. Tasks include rendering, layout, parsing, and compiling and executing scripts. When tasks become long tasks—that is, 50 milliseconds or longer—they block the main thread from being able to respond quickly to user inputs.

Per the Web Almanac, there's plenty of evidence to suggest that developers could be doing more to avoid or break up long tasks. While breaking up long tasks may not be as low of an effort as other recommendations in this article, it's less effort than other techniques not offered in this article.

While you should always strive to do as little work as possible in JavaScript, you can help the main thread quite a bit by breaking up long tasks into smaller ones. You can accomplish this by yielding to the main thread often so that rendering updates and other user interactions can occur more quickly.

Another option is to consider using APIs such as isInputPending and the Scheduler API. isInputPending is a function that returns a boolean value that indicates whether a user input is pending. If it returns true, you can yield to the main thread so it can handle the pending user input.

The Scheduler API is a more advanced approach, which allows you to schedule work based on a system of priorities that take into account whether the work being done is user-visible or backgrounded.

By breaking up long tasks, you're giving the browser more opportunities to fit in critical user-visible work, such as dealing with interactions and any resulting rendering updates.

Avoid unnecessary JavaScript #

There's no doubt about it: websites are shipping more JavaScript than ever before, and the trend doesn't look like it's changing any time soon. When you ship too much JavaScript, you're creating an environment where tasks are competing for the main thread's attention. This can definitely affect your website's responsiveness, especially during that crucial startup period.

This is not an unsolvable problem, however. You do have some options:

Use the coverage tool in Chrome DevTools to find unused code in your website's resources. By reducing the size of the resources you need during startup, you can ensure your website spends less time parsing and compiling code, which leads to a smoother initial user experience.
Sometimes the unused code you find using the coverage tool is marked "unused" because it wasn't executed during startup, but is still necessary for some functionality in the future. This is code that you can move to a separate bundle via code splitting.
If you're using a tag manager, be sure to periodically check your tags to make sure they are optimized, or even if they're still being used. Older tags with unused code can be cleared out to make your tag manager's JavaScript smaller and more efficient.

Avoid large rendering updates #

JavaScript isn't the only thing that can affect your website's responsiveness. Rendering can be a type of expensive work in its own right—and when large rendering updates happen, they can interfere with your website's ability to respond to user inputs.

Optimizing rendering work isn't a straightforward process, and it often depends on what you're trying to achieve. Even so, there are some things you can do to ensure that your rendering updates are reasonable, and don't sprawl into long tasks:

Avoid using requestAnimationFrame() for doing any non-visual work. requestAnimationFrame() calls are handled during the rendering phase of the event loop, and when too much work is done during this step, rendering updates can be delayed. It's essential that any work you're doing with requestAnimationFrame() is reserved strictly for tasks that involve rendering updates.
Keep your DOM size small. DOM size and the intensity of layout work are correlated. When the renderer has to update the layout for a very large DOM, the work required to recalculate its layout can increase significantly.
Use CSS containment. CSS containment relies on the CSS contain property, which gives instructions to the browser about how to do layout work for the container the contain property is set on, including even isolating the scope of layout and rendering to a specific root in the DOM. It's not always an easy process, but by isolating areas containing complex layouts, you can avoid doing layout and rendering work for them that isn't necessary.

Conclusion #

Improving page performance can seem like a daunting task, especially given that there is a mountain of guidance across the web to consider. By focusing on these recommendations, however, you can approach the problem with focus and purpose, and hopefully move the needle for your website's Core Web Vitals.

While the recommendations listed here are by no means exhaustive, we do believe—based on careful analysis of the state of the web—that these recommendations are the most effective ways that sites can improve their Core Web Vitals performance in 2023.

If you'd like to go beyond the recommendations listed here, check out these optimization guides for more information:

Here's to a new year, and a faster web for all! May your sites be fast for your users in all the ways that matter most.

Photo by Devin Avery

The performance effects of too much lazy loading

2021-07-15T00:00:00Z

Lazy loading is a technique to defer downloading a resource until it's needed, which conserves data and reduces network contention for critical assets. It became a web standard in 2019 and today loading="lazy" for images is supported by most major browsers. That sounds great, but is there such a thing as too much lazy loading?

This post summarizes how we analyzed publicly available web transparency data and ad hoc A/B testing to understand the adoption and performance characteristics of native image lazy loading. What we found is that lazy loading can be an amazingly effective tool for reducing unneeded image bytes, but overuse can negatively affect performance. Concretely, our analysis shows that more eagerly loading images within the initial viewport—while liberally lazy loading the rest—can give us the best of both worlds: fewer bytes loaded and improved Core Web Vitals.

Adoption #

According to the most recent data in HTTP Archive, native image lazy loading is used by 17% of websites and adoption is growing rapidly. This much of a foothold in the ecosystem is remarkable for a relatively new API.

Breakdown of the types of websites that make use of native image lazy loading. (Source)

Querying the raw data in the HTTP Archive project gives us a clearer understanding of what kinds of websites are driving adoption: 84% of sites that use native image lazy loading use WordPress, 2% use another CMS, and the remaining 14% don't use a known CMS. These results make clear how WordPress is leading the charge in adoption.

Breakdown of the types of websites that make use of native image lazy loading. (Source)

The rate of adoption is also worth noting. One year ago in July 2020, WordPress sites that use lazy loading made up tens of thousands websites in the corpus of about 6 million (1% of total). Lazy loading adoption in WordPress alone has since grown to over 1 million websites (14% of total).

Correlational performance #

Digging deeper into HTTP Archive, we can compare how pages with and without native image lazy loading perform with the Largest Contentful Paint (LCP) metric. The LCP data comes from real-user experiences from the Chrome User Experience Report (CrUX) as opposed to synthetic testing in the lab. The chart below uses a box-and-whisker plot to visualize the distributions of each pages' 75th percentile LCP: the lines represent the 10th and 90th percentiles and the boxes represent the 25th and 75th percentiles.

Distribution of all pages' 75th percentile LCP experience, broken down by whether they use native image lazy loading. (Source)

The median page without lazy loading has a 75th percentile LCP of 2,922 ms, compared to 3,546 ms for the median page with lazy loading. Overall, websites that use lazy loading tend to have worse LCP performance.

It's important to point out that these are correlational results and they don't necessarily point to lazy loading as being the cause of the slower performance. Hypothetically, if WordPress sites tend to be a bit slower, and given how much they make up the lazy loading cohort, that could explain the difference. So let's try to eliminate that variability by looking only at WordPress sites.

Distribution of WordPress pages' 75th percentile LCP experience, broken down by whether they use native image lazy loading. (Source)

Unfortunately, the same pattern emerges when we drill down into WordPress pages; those that use lazy loading tend to have slower LCP performance. The median WordPress page without lazy loading has a 75th percentile LCP of 3,495 ms, compared to 3,768 ms for the median page with lazy loading.

This still doesn't prove that lazy loading causes pages to get slower, but using it does coincide with having slower performance. To try to answer the causality question, we set up a lab-based A/B test.

Causal performance #

The goal for the A/B test was to prove or disprove the hypothesis that native image lazy loading, as implemented in WordPress core, resulted in slower LCP performance and fewer image bytes. The methodology we used was to test a demo WordPress website with the twentytwentyone theme. We tested both archive and single page types, which are like the home and article pages, on desktop and emulated mobile devices using WebPageTest. We tested each combination of pages with and without lazy loading enabled and ran each test nine times to get the median LCP value and number of image bytes.

Change in LCP (ms) by disabling native image lazy loading on sample WordPress pages.
Series	default	disabled	Difference from default
twentytwentyone-archive-desktop	2,029	1,759	-13%
twentytwentyone-archive-mobile	1,657	1,403	-15%
twentytwentyone-single-desktop	1,655	1,726	4%
twentytwentyone-single-mobile	1,352	1,384	2%

The results above compare the median LCP in milliseconds for tests on archive and single pages for desktop and mobile. When we disabled lazy loading on archive pages, we observed LCP improving by a significant margin. On single pages, however, the difference was more neutral.

It's worth noting that the effect of disabling lazy loading actually appears to make the single pages slightly faster. However, the difference in LCP is less than one standard deviation for both desktop and mobile tests, so we attribute this to variance and consider the change neutral overall. By comparison, the difference for archive pages is more like two to three standard deviations.

Change in the number of image bytes (KB) by disabling native image lazy loading on sample WordPress pages.
Series	default	disabled	Difference from default
twentytwentyone-archive-desktop	577	1173	103%
twentytwentyone-archive-mobile	172	378	120%
twentytwentyone-single-desktop	301	850	183%
twentytwentyone-single-mobile	114	378	233%

The results above compare the median number of image bytes (in KB) for each test. As expected, lazy loading has a very clear positive effect on reducing the number of image bytes. If a real user were to scroll the entire page down, all images would load anyway as they cross into the viewport, but these results show the improved performance of the initial page load.

To summarize the results of the A/B test, the lazy loading technique used by WordPress very clearly helps reduce image bytes but at the cost of a delayed LCP.

Testing a fix #

Before we get into how the fix was implemented, let's look at how lazy loading works in WordPress today. The most important aspect of the current implementation is that it lazy-loads images above the fold (within the viewport). The CMS blog post acknowledges this as a pattern to avoid, but experimental data at the time indicated that the effect on LCP was minimal and worth simplifying the implementation in WordPress core.

Given this new data, we created an experimental fix that avoids lazy loading images that are above the fold and we tested it under the same conditions as the first A/B test.

Change in LCP (ms) by the proposed fix for native image lazy loading on sample WordPress pages.
Series	default	disabled	fix	Difference from default	Difference from disabled
twentytwentyone-archive-desktop	2,029	1,759	1,749	-14%	-1%
twentytwentyone-archive-mobile	1,657	1,403	1,352	-18%	-4%
twentytwentyone-single-desktop	1,655	1,726	1,676	1%	-3%
twentytwentyone-single-mobile	1,352	1,384	1,342	-1%	-3%

These results are much more promising. Lazy loading only the images below the fold results in a complete reversal of the LCP regression and possibly even a slight improvement over disabling LCP entirely. How could it be faster than not lazy loading at all? One explanation is that by not loading below-the-fold images, there's less network contention with the LCP image, which enables it to load more quickly.

Change in the number of image bytes (KB) by the proposed fix for native image lazy loading on sample WordPress pages.
Series	default	disabled	fix	Difference from default	Difference from disabled
twentytwentyone-archive-desktop	577	1173	577	0%	-51%
twentytwentyone-archive-mobile	172	378	172	0%	-54%
twentytwentyone-single-desktop	301	850	301	0%	-65%
twentytwentyone-single-mobile	114	378	114	0%	-70%

In terms of image bytes, the fix has absolutely no change as compared to the default behavior. This is great because that was one of the strengths of the current approach.

There are some caveats with this fix. WordPress determines which images to lazy-load on the server-side, which means that it doesn't know anything about the user's viewport size or whether images will initially load within it. So the fix uses heuristics about the images' relative location in the markup to guess whether it will be in the viewport. Specifically, if the image is the first featured image on the page or the first image in the main content, it's assumed to be above the fold (or close to it), and it will not be lazy-loaded. Page-level conditions like the number of words in the heading or the amount of paragraph text early in the main content may affect whether the image is within the viewport. There are also user-level conditions that may affect the accuracy of the heuristics, especially the viewport size and the usage of anchor links that change the scroll position of the page. For those reasons, it's important to acknowledge that the fix is only calibrated to provide good performance in the general case and fine-tuning may be needed to make these results applicable to all real-world scenarios.

Rolling it out #

Now that we've identified a better way to lazy-load images, all of the image savings and faster LCP performance, how can we get sites to start using it? The highest priority change is to submit a patch to WordPress core to implement the experimental fix. We'll also be updating the guidance in the Browser-level lazy-loading for CMSs blog post to clarify the negative effects of above-the-fold lazy loading and how CMSs can use heuristics to avoid it.

Since these best practices are applicable to all web developers, it may also be worth flagging lazy loading antipatterns in tools like Lighthouse. Refer to the feature request on GitHub if you're interested to follow along with progress on that audit. Until then, one thing developers could do to find instances of LCP elements being lazy-loaded is to add more detailed logging to their field data.

new PerformanceObserver((list) => {
  const latestEntry = list.getEntries().at(-1);

  if (latestEntry?.element?.getAttribute('loading') == 'lazy') {
    console.warn('Warning: LCP element was lazy loaded', latestEntry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

The JavaScript snippet above will evaluate the most recent LCP element and log a warning if it was lazy-loaded.

This also highlights a sharp edge of the lazy loading technique and the potential for API improvements at the platform level. For example, there's an open issue in Chromium to experiment with natively loading the first few images eagerly, similar to the fix, despite the loading attribute.

Wrapping it up #

If your site uses native image lazy loading, check how it's implemented and run A/B tests to better understand its performance costs. It may benefit from more eagerly loading images above the fold. If you have a WordPress site, there will hopefully be a patch landing in WordPress core soon. And if you're using another CMS, make sure they're aware of the potential performance issues described here.

Trying out relatively new web platform APIs can come with both risks and rewards—they're called cutting edge features for a reason. While we're starting to get a sense of the thorniness of native image lazy loading, we're also seeing the upsides of how to use it to achieve better performance.

Photo by Frankie Lopez on Unsplash

Find your way with field data in the Web Vitals extension update

2021-07-02T00:00:00Z

Core Web Vitals are the most important metrics to measure to understand your users' experiences, because when users have good experiences, good things happen! The Web Vitals extension for Chrome is one tool in the Web Vitals toolbox that shows you performance data about the pages you visit as you browse the web.

Page performance depends on many factors, including hardware and network quality. How you experience a page on your machine may be very different from how the majority of users experience it. That's why version 1.0 of the Web Vitals extension includes a new feature that integrates real-user data from the Chrome UX Report (CrUX) with your local Core Web Vitals measurements. This feature displays your local measurements in the context of how other users have experienced the same pages. It comes with a sparkly new UI and I'm excited to show you how it works.

Field data from CrUX #

CrUX is a public dataset of real-user experiences in Chrome. It powers some of the critical tools in the Core Web Vitals workflow like Search Console and PageSpeed Insights. The raw data for millions of websites is also publicly queryable in the CrUX dataset on BigQuery and the CrUX API. This Web Vitals extension update integrates the page and origin-level desktop data from the CrUX API.

User experience data is broken down into three qualitative ratings: good, needs improvement, and poor. The thresholds used for each rating are documented in the guides for each of the Core Web Vitals metrics: LCP, FID, and CLS. So for example, the CrUX API can tell you that 16% of real-user experiences on a given page are evaluated as having good LCP under 2.5 seconds.

New extension UI #

Screenshot of the Web Vitals extension showing an explanation of how the local LCP experience relates to real-user desktop data from the field.

In the new Web Vitals extension interface, your local experience is layered on top of the broader distribution of real-user experiences. It's like when you're in an expansive place like a shopping mall and there's a big map with all of the stores and a pin labeled "YOU ARE HERE" to help you orient yourself and find where you're going.

The distributions of real-user data from CrUX are laid out on a horizontal bar for each metric. Your local experiences are displayed as single points on those horizontal bars. The position of your local experience on the horizontal bar indicates where that experience falls relative to the real-user distributions. This should make it immediately apparent when your local experience is very different from other users'. For example, if you have a slow LCP experience and only 1% of users have similar experiences, something unusual must have happened.

Falling back to origin-level data #

Screenshot of the Web Vitals extension showing origin-level desktop field data with "Waiting for input…" for the FID results.

Some pages don't have URL-level data in the CrUX dataset. This can happen because the page is so new that it hasn't been picked up yet or because the page has insufficient traffic to be included in the dataset. In cases like these, Web Vitals extension falls back to more granular origin-level data whenever possible. This data represents the aggregate user experiences on all pages of the website, so while it may not be immediately relevant to your particular page experience, it should still offer some insight into how users experience the site as a whole.

Another common case is to see a "Waiting for input…" message. This is because FID is the only Core Web Vital that requires user interaction to be measured, so the extension won't have any local FID data to show until you interact with the page.

Edge cases #

Screenshot of the Web Vitals extension showing only local data; field data is unavailable.

There are some less common edge cases that you may run into while using the extension.

It can happen that entire origins have insufficient data. In that case, the extension will just show you how your local experiences performed.

How you interact with the page may also affect the relevance of the data. For example, loading the page in a background tab will count against the LCP metric the entire time until you foreground the page. If it takes you 90 seconds to switch to the tab, the LCP might appear as 91.5 seconds. When this happens, a little warning icon will appear next to your LCP value to warn you of the artificial inflation. Note that these kinds of irrelevant LCP values are ignored in the CrUX dataset.

One last edge case to be aware of is specific to FID. Because it depends on user interactions, that makes it less likely to be available in the dataset for pages and websites with fewer page views. So if you're visiting a page like that, you may only see field data for LCP and CLS. It's worth noting for the sake of completeness that the same could happen for LCP or CLS in extremely rare situations, but this issue is predominantly affected by FID.

Comparing field data from phones #

Screenshot of the Web Vitals extension showing local metrics compared to phone field data.

By default, all of the data in the Web Vitals extension corresponds to real desktop users' experiences from the field. After all, this extension is only available on desktop versions of Chrome, so it'd be most relevant to see how users under similar conditions experience the page or origin.

It's important to understand phone users' experiences too, so the extension has an advanced setting on the Options page that lets you see how your local experience compares to phone data from the field.

To enable phone data in the extension, follow these steps:

Right click on the extension icon in the toolbar and select Options.
Check the Compare local experiences to phone field data option.

The UI will update in a few places to indicate which mode you're in. Be aware that real phone users' experiences can be very different from that of desktop users, so use this feature with discretion.

Get the Web Vitals extension #

To start using the latest version of the Web Vitals extension, head over to the Chrome Web Store to install it. Or if you're an existing user of the extension, you should be upgraded to version 1.0 automatically. If you have any feedback about your experience with the extension (feature requests, bug reports, anything), let us know in the open-source repository on GitHub. I hope it helps you better understand where your local experiences are in relation to other real users from the field!

Image credit: Mark Garlick/Science Photo Library/Getty Images

Using the Chrome UX Report to look at performance in the field

2020-07-13T00:00:00Z

The Chrome UX Report (informally known as CrUX) is a public dataset of real user experience data on millions of websites. Unlike lab data, CrUX data actually comes from opted-in users in the field. It measures the Core Web Vitals metrics, including Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS), as well as diagnostic metrics like Time to First Byte (TTFB) and First Contentful Paint (FCP).

The dataset also contains qualitative dimensions about the user experience, for example, the device and connection types, which enables drilling down into user experiences grouped by similar technologies. See the CrUX documentation for the full list of metrics.

Using this data, developers are able to understand the wide distribution of real world user experiences between websites, segments of the web, or the web as a whole. This is a big deal! The Chrome UX Report dataset is the first of its kind to enable web developers to compare their real user performance against the competition and industry.

How to use it #

There are four primary ways to extract insights from the Chrome UX Report, ranging in complexity. For quick and easy analysis of website performance, the CrUX Dashboard and PageSpeed Insights are the recommended tools. BigQuery trades some of the simplicity of the analysis for the power of customization and more granular insights. And the API enables the integration of high-level data with other applications, and the History API provides historical data for trend analysis.

CrUX Dashboard #

The CrUX Dashboard is a customizable data visualization tool of websites' historical performance built on Looker Studio. The data is sourced from the BigQuery dataset and all of the SQL queries are handled for you under the hood. The dashboard shows the distribution of user experiences, as captured by key performance metrics, and how it changes over time. It also shows how the distributions of qualitative metrics like device type and effective connection type change over time. Try the Looker Studio Dashboard guide.

PageSpeed Insights #

PageSpeed Insights (PSI) shows the most recent performance distributions broken down by desktop and mobile users. Performance data is available for individual web pages (in addition to entire origins) and is aggregated for the most recent 28 days of data (as opposed to the previous calendar month on BigQuery). Using this tool is as easy as entering a URL or origin in the search box on the web interface, and the field performance data is displayed alongside prescriptive suggestions to optimize the page. Try the PageSpeed Insights guide.

CrUX on BigQuery #

The CrUX database on BigQuery, part of the Google Cloud Platform (GCP) with a web and command line interface, hosts the raw data that aggregates key UX performance metrics for top origins on the web. New tables are periodically added to the database covering the previous calendar month. Developers can handcraft queries to mine the dataset for specific insights. BigQuery requires knowledge of SQL and a GCP project with billing enabled to run the queries. This is an especially useful tool for power users who require low-level access to the data to create custom reports, benchmarks, and reports about the state of the web. Try the BigQuery guide.

CrUX API #

The CrUX API is a free and RESTful interface for looking up origin or URL-level user experience data. The data is updated daily and aggregates the previous 28 days of data, similar to PageSpeed Insights. You can use this API to build your own applications on top of the real-user experience data in CrUX. Try the CrUX API guide.

CrUX History API #

The CrUX History API is a free and RESTful interface, similar to the daily API, for looking up origin or URL-level user experience data. The data is updated weekly and aggregates the previous 28 days of data, over a period of 6 months. You can use this API to build your own applications on top of the real-user experience data in CrUX. Try the CrUX History API guide.

How to get help #

If you need any kind of support, there are a few channels to reach someone who can help. The CrUX Google Group is a public forum for users of the dataset to ask questions and share analyses. There is also a CrUX tag for Stack Overflow if you need programming help with SQL or API access. And finally, @ChromeUXReport is the Twitter account you can follow to ask questions and listen for product announcements.

See it in action #

To get more acquainted with the available data, walk through step-by-step guides for using Looker Studio Dashboard, PageSpeed Insights, Bigquery, and both the daily and history API:

Fixing layout instability

2019-09-30T00:00:00Z

In an earlier post I wrote about measuring Cumulative Layout Shift (CLS) in WebPageTest. CLS is an aggregation of all layout shifts, so in this post I thought it'd be interesting to dive deeper and inspect each individual layout shift on a page to try to understand what could be causing the instability and actually try to fix the issue(s).

Measuring layout shifts #

Using the Layout Instability API, we can get a list of all layout shift events on a page:

new Promise(resolve => {
  new PerformanceObserver(list => {
    resolve(list.getEntries().filter(entry => !entry.hadRecentInput));
  }).observe({type: "layout-shift", buffered: true});
}).then(console.log);

This produces an array of layout shifts that are not preceded by input events:

[
  {
    "name": "",
    "entryType": "layout-shift",
    "startTime": 210.78500000294298,
    "duration": 0,
    "value": 0.0001045969445437389,
    "hadRecentInput": false,
    "lastInputTime": 0
  }
]

In this example there was a single very tiny shift of 0.01% at 210ms.

Knowing the time and severity of the shift is useful to help narrow down what could have caused the shift. Let's turn back to WebPageTest for a lab environment to do more testing.

Measuring layout shifts in WebPageTest #

Similar to measuring CLS in WebPageTest, measuring individual layout shifts will require a custom metric. Fortunately, the process is easier now that Chrome 77 is stable. The Layout Instability API is enabled by default, so you should be able to execute that JS snippet on any website within Chrome 77 and get results immediately. In WebPageTest, you can use the default Chrome browser and not have to worry about command line flags or using Canary.

So let's modify that script to produce a custom metric for WebPageTest:

[LayoutShifts]
return new Promise(resolve => {
  new PerformanceObserver(list => {
    resolve(JSON.stringify(list.getEntries().filter(entry => !entry.hadRecentInput)));
  }).observe({type: "layout-shift", buffered: true});
});

The promise in this script resolves to a JSON representation of the array rather than the array itself. This is because custom metrics can only produce primitive data types like strings or numbers.

The website I'll use for the test is ismyhostfastyet.com, a site I built to compare real world loading performance of web hosts.

Identifying causes of layout instability #

In the results we can see the LayoutShifts custom metric has this value:

[
  {
    "name": "",
    "entryType": "layout-shift",
    "startTime": 3087.2349999990547,
    "duration": 0,
    "value": 0.3422101449275362,
    "hadRecentInput": false,
    "lastInputTime": 0
  }
]

To summarize, there is a single layout shift of 34.2% happening at 3087ms. To help identify the culprit, let's use WebPageTest's filmstrip view.

Two cells in the filmstrip, showing screenshots before and after the layout shift.

Scrolling to the ~3 second mark in the filmstrip shows us exactly what the cause of the 34% layout shift is: the colorful table. The website asynchronously fetches a JSON file, then renders it to a table. The table is initially empty, so waiting to fill it up when the results are loaded is causing the shift.

Web font header appearing out of nowhere.

But that's not all. When the page is visually complete at ~4.3 seconds, we can see that the <h1> of the page "Is my host fast yet?" appears out of nowhere. This happens because the site uses a web font and hasn't taken any steps to optimize rendering. The layout doesn't actually appear to shift when this happens, but it's still a poor user experience to have to wait so long to read the title.

Fixing layout instability #

Now that we know the asynchronously generated table is causing one-third of the viewport to shift, it's time to fix it. We don't know the contents of the table until the JSON results are actually loaded, but we can still populate the table with some kind of placeholder data so that the layout itself is relatively stable when the DOM is rendered.

Here's the code to generate placeholder data:

function getRandomFiller(maxLength) {
  var filler = '█';
  var len = Math.ceil(Math.random() * maxLength);
  return new Array(len).fill(filler).join('');
}

function getRandomDistribution() {
  var fast = Math.random();
  var avg = (1 - fast) * Math.random();
  var slow = 1 - (fast + avg);
  return [fast, avg, slow];
}

// Temporary placeholder data.
window.data = [];
for (var i = 0; i < 36; i++) {
  var [fast, avg, slow] = getRandomDistribution();
  window.data.push({
    platform: getRandomFiller(10),
    client: getRandomFiller(5),
    n: getRandomFiller(1),
    fast,
    avg,
    slow
  });
}
updateResultsTable(sortResults(window.data, 'fast'));

The placeholder data is generated randomly before being sorted. It includes the "█" character repeated a random number of times to create visual placeholders for the text and a randomly generated distribution of the three main values. I also added some styles to desaturate all color from the table to make it clear that the data is not fully loaded yet.

The appearance of the placeholders you use don't matter for layout stability. The purpose of the placeholders is to assure users that content is coming and the page isn't broken.

Here's what the placeholders look like while the JSON data is loading:

The data table is rendered with placeholder data.

Addressing the web font issue is much simpler. Because the site is using Google Fonts, we just need to pass in the display=swap property in the CSS request. That's all. The Fonts API will add the font-display: swap style in the font declaration, enabling the browser to render text in a fallback font immediately. Here's the corresponding markup with the fix included:

<link href="https://fonts.googleapis.com/css?family=Chivo:900&display=swap" rel="stylesheet">

Verifying the optimizations #

After rerunning the page through WebPageTest, we can generate a before and after comparison to visualize the difference and measure the new degree of layout instability:

WebPageTest filmstrip showing both sites loading side-by-side with and without layout optimizations.

[
  {
    "name": "",
    "entryType": "layout-shift",
    "startTime": 3070.9349999997357,
    "duration": 0,
    "value": 0.000050272187989256116,
    "hadRecentInput": false,
    "lastInputTime": 0
  }
]

According to the custom metric, there is still a layout shift occurring at 3071ms (about the same time as before) but the severity of the shift is much smaller: 0.005%. I can live with this.

It's also clear from the filmstrip that the <h1> font is immediately falling back to a system font, enabling users to read it sooner.

Conclusion #

Complex websites will probably experience many more layout shifts than in this example, but the remediation process is still the same: add layout instability metrics to WebPageTest, cross-reference the results with the visual loading filmstrip to identify the culprits, and implement a fix using placeholders to reserve the screen real estate.

(One more thing) Measuring layout instability experienced by real users #

It's nice to be able to run WebPageTest on a page before and after an optimization and see an improvement to a metric, but what really matters is that the user experience is actually getting better. Isn't that why we're trying to make the site better in the first place?

So what would be great is if we start measuring the layout instability experiences of real users along with our traditional web performance metrics. This is a crucial piece of the optimization feedback loop because having data from the field tells us where the problems are and whether our fixes made a positive difference.

In addition to collecting your own layout instability data, check out the Chrome UX Report, which includes Cumulative Layout Shift data from real user experiences on millions of websites. It allows you to find out how you (or your competitors) are performing, or you can use it to explore the state of layout instability across the web.