Barry Pollard on web.dev

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

Optimize Time to First Byte

2023-01-19T00:00:00Z

Time to First Byte (TTFB) is a foundational web performance metric that precedes every other meaningful user experience metric such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP). This means that high TTFB values add time to the metrics that follow it.

It's recommended that your server responds to navigation requests quickly enough so that the 75th percentile of users experience an FCP within the "good" threshold. As a rough guide, most sites should strive to have a TTFB of 0.8 seconds or less.

Important

TTFB is not a Core Web Vitals metric, so it's not absolutely necessary that sites meet the "good" TTFB threshold, provided that it doesn't impede their ability to score well on the metrics that matter.

Websites vary in how they deliver content. A low TTFB is crucial for getting markup out to the client as soon as possible. However, if a website delivers the initial markup quickly, but that markup then requires JavaScript to populate it with meaningful content—as is the the case with Single Page Applications (SPAs)—then achieving the lowest possible TTFB is especially important so that the client-rendering of markup can occur sooner.

Conversely, a server-rendered site that does not require as much client-side work could have a higher TTFB, but better FCP and LCP values than an entirely client-rendered experience. This is why the TTFB thresholds are a “rough guide”, and will need to be weighed against how your site delivers its core content.

How to Measure TTFB #

Before you can optimize TTFB, you need to observe how it affects your website's users. You should rely on field data as a primary source of observing TTFB as it affected by redirects, whereas lab-based tools are often measured using the final URL therefore missing this extra delay.

PageSpeed Insights is a simple way to get both field and lab information for public websites that are available in the Chrome User Experience Report.

TTFB for real users is shown in the top Discover what your real users are experiencing section:

A subset of TTFB is shown in the server response time audit:

To find out more ways how to measure TTFB in both the field and the lab, consult the TTFB metric page.

Understanding high TTFB with `Server-Timing` #

The Server-Timing response header can be used in your application backend to measure distinct backend processes that could contribute to high latency. The header value's structure is flexible, accepting, at minimum, a handle that you define. Optional values include a duration value (via dur), as well as an optional human-readable description (via desc).

Serving-Timing can be used to measure many application backend processes, but there are some that you may want to pay special attention to:

Database queries
Server-side rendering time, if applicable
Disk seeks
Edge server cache hits/misses (if using a CDN)

All parts of a Server-Timing entry are colon-separated, and multiple entries can be separated by a comma:

// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2

The header can be set using your application backend's language of choice. In PHP, for example, you could set the header like so:

<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);

// Perform a database query and get results...
// ...

// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);

// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStarTime) / 1e+6;

// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>

When this header is set, it will surface information you can use in both the lab, and in the field.

In the field, any page with a Server-Timing response header set will populate the serverTiming property in the Navigation Timing API:

// Get the serverTiming entry for the first navigation request:
performance.getEntries("navigation")[0].serverTiming.forEach(entry => {
    // Log the server timing data:
    console.log(entry.name, entry.description, entry.duration);
});

In the lab, data from the Server-Timing response header will be visualized in the timings panel of the Network tab in Chrome DevTools:

Server-Timing response headers visualized in the network tab of Chrome DevTools. Here, Server-Timing is used to measure whether a request for a resource has hit the CDN cache, and how long it takes for the request to hit the CDN's edge server and then the origin.

Once you've determined that you have a problematic TTFB by analyzing the data available, then you can move onto fixing the problem.

Ways to optimize TTFB #

The most challenging aspect of optimizing TTFB is that, while the web's frontend stack will always be HTML, CSS, and JavaScript, backend stacks can vary significantly. There are numerous backend stacks and database products that each have their own optimization techniques. Therefore, this guide will focus on what applies to most architectures, rather than focusing solely on stack-specific guidance.

Platform-specific guidance #

The platform you use for your website can heavily impact TTFB. For example, WordPress performance is impacted by the number and quality of plugins, or what themes are used. Other platforms are similarly impacted when the platform is customized. You should consult the documentation for your platform for vendor-specific advice to supplement the more general performance advice in this post. The Lighthouse audit for reducing server response times also includes some limited stack-specific guidance.

Hosting, hosting, hosting #

Before you even consider other optimization approaches, hosting should be the first thing you consider. There's not much in the way of specific guidance that can be offered here, but a general rule of thumb is to ensure that your website's host is capable of handling the traffic you send to it.

Shared hosting will generally be slower. If you're running a small personal website that serves mostly static files, this is probably fine, and some of the optimization techniques that follow will help you get that TTFB down as much as possible.

However, if you're running a larger application with many users that involves personalization, database querying, and other intensive server-side operations, your choice of hosting becomes critical to lower TTFB in the field.

When choosing a hosting provider, these are some things to look out for:

How much memory is your application instance allocated? If your application has insufficient memory, it will thrash and struggle to serve pages up as fast as possible.
Does your hosting provider keep your backend stack up to date? As new versions of application backend languages, HTTP implementations, and database software are released, performance in that software will be improved over time. It's key to partner with a hosting provider that prioritizes this kind of crucial maintenance.
If you have very specific application requirements and want the lowest level access to server configuration files, ask if it makes sense to customize your own application instance's backend.

There are many hosting providers that will take care of these things for you, but if you start to observe long TTFB values even in dedicated hosting providers, it may be a sign that you might need to re-evaluate your current hosting provider's capabilities so that you can deliver the best possible user experience.

Use a Content Delivery Network (CDN) #

The topic CDN usage is a well-worn one, but for good reason: you could have a very well-optimized application backend, but users located far from your origin server may still experience high TTFB in the field.

CDNs solve the problem of user proximity from your origin server by using a distributed network of servers that cache resources on servers that are physically closer to your users. These servers are called edge servers.

CDN providers may also offer benefits beyond edge servers:

CDN providers usually offer extremely fast DNS resolution times.
A CDN will likely serve your content from edge servers using modern protocols such as HTTP/2 or HTTP/3.
HTTP/3 in particular solves the head-of-line blocking problem present in TCP (which HTTP/2 relies on) by using the UDP protocol.
A CDN will likely also provide modern versions of TLS, which lowers the latency involved in TLS negotiation time. TLS 1.3 in particular is designed to keep TLS negotiation as short as possible.
Some CDN providers provide a feature often called an "edge worker", which uses an API similar to that of the Service Worker API to intercept requests, programmatically manage responses in edge caches, or rewrite responses altogether.
CDN providers are very good at optimizing for compression. Compression is tricky to get right on your own, and may lead to slower response times in certain cases with dynamically generated markup, which must be compressed on the fly.
CDN providers will also automatically cache compressed responses for static resources, leading to the best mix of compression ratio and response time.

While adopting a CDN involves a varying amount of effort from trivial to significant, it should be a high priority to pursue in optimizing your TTFB if your website is not already using one.

Used cached content where possible #

CDNs allow content to be cached at edge servers which are located physically closer to visitors, provided the content is configured with the appropriate Cache-Control HTTP headers. While this is not appropriate for personalized content, requiring a trip all the way back to the origin can negate much of the value of a CDN.

For sites that frequently update their content, even a short caching time can result in noticeable performance gains for busy sites, since only the first visitor during that time experiences the fully latency back to the origin server, while all other visitors can reuse the cached resource from the edge server. Some CDNs allow cache invalidation on site releases allowing the best of both worlds—long cache times, but instant updates when needed.

Even where caching is correctly configured, this can be ignored through the use of unique query string parameters for analytics measurement. These may look like different content to the CDN despite being the same, and so the cached version will not be used.

Older or less visited content may also not be cached, which can result in higher TTFB values on some pages than others. Increasing caching times can reduce the impact of this, but be aware that with increased caching times comes a greater possibility of serving potentially stale content.

The impact of cached content does not just affect those using CDNs. Server infrastructure may need to generate content from costly database lookups when cached content cannot be reused. More frequently accessed data or precached pages can often perform better.

Avoid multiple page redirects #

One common contributor to a high TTFB is redirects. Redirects occur when a navigation request for a document receives a response that informs the browser that the resource exists at another location. One redirect can certainly add unwanted latency to a navigation request, but it can certainly get worse if that redirect points to another resource that results in another redirect—and so on. This can particularly impact sites that receive high volumes of visitors from advertisements or newsletters, since they often redirect via analytics services for measurement purposes. Eliminating redirects under your direct control can help to achieve a good TTFB.

There are two types of redirects:

Same-origin redirects, where the redirect occurs entirely on your website.
Cross-origin redirects, where the redirect occurs initially on another origin—such as from a social media URL shortening service, for example—before arriving at your website.

You want to focus on eliminating same-origin redirects, as this is something you will have direct control over. This would involve checking links on your website to see if any of them result in a 302 or 301 response code. Often this can be the result of not including the https:// scheme (so browsers default to http:// which then redirects) or because trailing slashes are not appropriately included or excluded in the URL (for example, visiting this page via https://web.dev/optimize-ttfb (without the final slash) works but requires a redirect to https://web.dev/optimize-ttfb/) (with the final slash).

Cross-origin redirects are trickier as these are often outside of your control, but try to avoid multiple redirects where possible—for example, by using multiple link shorteners when sharing links. Ensure the URL provided to advertisers or newsletters is the correct final URL, so as not to add another redirect to the ones used by those services.

Another important source of redirect time can come from HTTP-to-HTTPS redirects. One way you can get around this is to use the Strict-Transport-Security header (HSTS), which will enforce HTTPS on the first visit to an origin, and then will tell the browser to immediately access the origin through the HTTPS scheme on future visits.

Once you have a good HSTS policy in place, you can speed things up on the first visit to an origin by adding your site to the HSTS preload list.

Stream markup to the browser #

Browsers are optimized to process markup efficiently when it is streamed, meaning that markup is handled in chunks as it arrives from the server. This is crucial where large markup payloads are concerned, as it means the browser can parse that the chunks of markup incrementally, as opposed to waiting for the entire response to arrive before parsing can begin.

Though browsers are great at handling streaming markup, it's crucial to do all that you can to keep that stream flowing so those initial bits of markup are on their way as soon as possible. If the backend is holding things up, that's a problem. Because backend stacks are numerous, it would be beyond the scope of this guide to cover every single stack and the issues that could arise in each specific one.

React, for example—and other frameworks that can render markup on demand on the server—have used a synchronous approach to server-side rendering. However, newer versions of React have implemented server methods for streaming markup as it is being rendered. This means you don't have to wait for a React server API method to render the entire response before it's sent.

Another way to ensure markup is streamed to the browser quickly is to rely on static rendering which generates HTML files during build time. With the full file available immediately, web servers can start sending the file immediately and the inherent nature of HTTP will result in streaming markup. While this approach isn't suitable for every page on every website—such as those requiring a dynamic response as part of the user experience—it can be beneficial for those pages that don't require markup to be personalized to a specific user.

Use a service worker #

The Service Worker API can have a big impact on the TTFB for both documents and the resources they load. The reason for this is that a service worker acts as a proxy between the browser and the server—but whether there is an impact on your website's TTFB depends on how you set up your service worker, and if that setup aligns with your application requirements.

Use a stale-while-revalidate strategy for assets. If an asset is in the service worker cache—be it a document or a resource the document requires—the stale-while-revalidate strategy will service that resource from the cache first, then will download that asset in the background and serve it from the cache for future interactions.
- If you have document resources that don't change very often, using a stale-while-revalidate strategy can make a page's TTFB nearly instant. However, this doesn't work so well if your website sends dynamically generated markup—such as markup that changes based on whether a user is authenticated. In such cases, you'll always want to hit the network first, so the document is as fresh as possible.
- If your document loads non-critical resources that change with some frequency, but fetching the stale resource won't greatly affect the user experience—such as select images or other resources that aren't critical—the TTFB for those resources can be greatly reduced using a stale-while-revalidate strategy.
Use a streaming service worker architecture if possible. This service worker architecture uses an approach where parts of a document resource are stored in the service worker cache, and combined with content partials during the navigation request. The resulting effect of using this service worker pattern is that your navigation will be quite fast, while smaller HTML payloads are downloaded from the network. While this service worker pattern doesn't work for every website, TTFB times for document resources can be practically instant for sites that can use it.
Use the app shell model for client-rendered applications. This model fits best for SPAs where the "shell" of the page can be delivered instantly from the service worker cache, and the dynamic content of the page is populated and rendered later on in the page lifecycle.

Use `103 Early Hints` for render-critical resources #

No matter how well your application backend is optimized, there could still be a significant amount of work the server needs to do in order to prepare a response, including expensive (yet necessary) database work that delays the navigation response from arriving as quickly as it could. The potential effect of this is that some subsequent render-critical resources could be delayed, such as CSS or—in some cases—JavaScript that renders markup on the client.

The 103 Early Hints header is an early response code that the server can send to the browser while the backend is busy preparing markup. This header can be used to hint to the browser that there are render-critical resources the page should begin downloading while the markup is being prepared. For supporting browsers, the effect can be faster document rendering (CSS) and quicker availability of core page functionality (JavaScript).

Conclusion #

Since there are so many combinations of backend application stacks, there's no one article that can encapsulate everything you can do to lower your website's TTFB. However, these are some options you can explore to try and get things going just a little bit faster on the server side of things.

As with optimizing every metric, the approach is largely similar: measure your TTFB in the field, use lab tools to drill down into the causes, and then apply optimizations where possible. Not every single technique here may be viable for your situation, but some will be. As always, you'll need to keep a close eye on your field data, and make adjustments as needed to ensure the fastest possible user experience.

Hero image by Taylor Vick, sourced from 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

Why is CrUX data different from my RUM data?

2022-08-15T00:00:00Z

The Chrome User Experience Report (CrUX) provides user experience metrics for how real-world Chrome users experience popular destinations on the web. This data is automatically collected by Chrome from users who have opted in, and is made available based on the CrUX eligibility criteria.

CrUX data is therefore available for millions of websites. Many site owners have not had access to field data before, and CrUX has enabled many sites to see the value of this for the first time. As a public dataset, CrUX can also be used for competitive analysis and benchmarking of user experience metrics.

Real User Monitoring (RUM) is similar to CrUX, but instead of Chrome automatically collecting user-experience metrics, code is included on the websites to do this collection and feed it back to a RUM provider or analytics solution for further analysis.

With both solutions measuring user experience metrics, it is natural to assume that they should be equivalent. It can be confusing when we see differences. This guide will explain why that can happen, and offers suggestions for what to do when the numbers do not align.

Benefits of supplementing CrUX with a RUM solution #

CrUX is a great tool for a consistent view across sites and—as the official dataset for the Core Web Vitals program—sites will likely want to keep an eye on what it is showing. The aim of CrUX is to provide a statistically relevant overview of millions of websites for cross comparison.

However, for a deeper dive in investigating why data is showing the numbers it is, investing in a full RUM solution to supplement CrUX can give you access to more detailed information than can be made available in a publicly queryable dataset. This can help you explain and improve your metrics in a number of ways.

Deeper analysis to investigate issues #

CrUX can often be used to point out if you have a problem on your site, but not necessarily exactly where on your site the issue lies nor why. RUM solutions—whether home-grown through the likes of the web-vitals library or some of the many commercial products—can help bridge that gap.

Using a RUM solution gives you access to much more fine-grained data for all your pages, and on all browsers. It also allows you to slice and dice this data in ways CrUX does not, enabling you to drill down and investigate problem areas of the site. Are they affected by a particular segment of users? Or users who take certain actions? Exactly when did the problem start? These are questions that are much easier to answer with the additional data that a RUM tool can provide.

Correlating with other business metrics #

RUM also allows you to compare your web performance metrics directly with any business metrics, showing the value in investing in performance, and what other performance work to prioritize. We have numerous case studies with businesses doing this correlation, such as Farfetch or The Economic Times.

Collecting other performance data #

A RUM solution allows collection of other custom metrics, tied directly to your specific business. One of the more well-known examples is Twitter’s “Time to first Tweet” metric. These site-specific measures can then be correlated with Core Web Vital improvements and business metrics.

Differences between two sets of field data #

A man with a watch knows what time it is. A man with two watches is never sure.
Segal's Law

Whenever you have two sources of data, it can often be confusing and frustrating as to why they differ. In much the same way as it’s important to understand the difference between lab and field metrics, there can also be differences between two sources of field data. While the data would be the same in an ideal world, there are many reasons why they can differ.

Lab data versus field data #

The first thing to check is whether you are looking at lab (synthetic) metrics or field (RUM) metrics. While it’s natural to assume RUM products only look at field data, many offer a lab component as well.

Lab data is incredibly useful precisely because of the fixed conditions it measures under. It can be used to monitor unexpected changes or regressions in a production environment without the noise of a changing field population. However, lab data may not be representative of the real user experience, so field metrics can show quite different results.

Populations #

The datasets used by CrUX and RUM solutions may be different due to differences in which page visits are being measured depending on which browsers, users, sites, and devices are being compared.

Included browsers #

The Chrome User Experience Report, as its name suggests, is Chrome-only. While there are many Chromium-based browsers (Edge, Opera, and Brave to name a few) that also support the same metrics as Chrome given the shared core codebase, only Chrome users feed data into CrUX. This restriction also means Chrome users on iOS are not included, since it uses the underlying Webkit browser engine. Android WebViews also do not count as “Chrome”, so data from these users is not included—though Chrome Custom Tabs are included.

While Chrome is one of the world’s most popular browsers—and therefore would likely give a broad representation of your site’s performance in most cases—measuring just that browser is by no means a measure of all your users. This may explain one main difference between RUM and CrUX. This is particularly true for performance techniques that rely on APIs or image formats only available in Chrome, for example.

The lack of iOS data can also lead to bias. For example, as iOS users are typically on more performant devices or visiting from more countries with better network infrastructure, including them can lead to high overall performance metrics. On the other hand, excluding them—as CrUX does—can lead to data that is skewed to the lower end of site visitors (example case study). Android users typically cover a wider range of devices, device capabilities, and markets.

RUM solutions can get data for non-Chrome browsers, and in particular from Chromium-based browsers that often have the same metrics (such as Core Web Vitals) built in. Non-Chromium-based browsers are also measured by RUM solutions, but may have a more limited set of metrics. For example, Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) are currently only available in Chromium-based browsers and some other metrics can be measured quite differently (see later).

Opted-in users #

As well as being limited to Chrome users, CrUX is further restricted by only measuring a subset of Chrome users who have opted in to share CrUX data when the browser was installed.

RUM providers also only look at a subset of users, usually due to cookie banner prompts—asking users to opt into RUM data collection—or tracking blockers. This can adversely affect some initial page loads if the confirmation is not given until the second or subsequent page, when some of the site assets have already been cached from previous pages. If this happens frequently, the metrics may appear more favorable in RUM than they actually are if slower initial page loads are excluded in a sufficient number of cases.

Included sites #

CrUX is only intended to report on public websites, so there are other eligibility criteria that may result in data not being logged in CrUX. Most notable of these criteria is that the website must be publicly discoverable and sufficiently popular to ensure a minimal sample size from which to draw meaningful conclusions. In most cases, this will result in no data being available in CrUX. This is less of a confusing difference compared to the data being available but different, but explains why that happens.

However, if specific pages of a site are marked as indexable but others are not, then you may only see a subset of URLs in CrUX. If the origin is publicly discoverable, then all page views within that origin will be included in the origin-level data, but URL-level data may not be available.

Devices #

CrUX segments data by mobile, desktop, and tablet - though many tools concentrate on the first two and may not expose tablet data, or may include it within mobile or desktop. The performance characteristics on mobile versus desktop can be quite different—both in terms of the content delivered, and in the capabilities of the devices viewing them.

RUM data will allow segmenting traffic similarly, but often shows consolidated data by default. RUM may only allow segmenting by device type (for example, mobile) or browser (for example, Chrome) easily, but not both to only see mobile Chrome traffic. When comparing to CrUX data, ensure you are comparing like-for-like by filtering by device type and the Chrome browser.

Sampling #

RUM solutions typically allow adjusting the sampling rate of opted-in visitors where data is collected. This can be used to reduce the volume of data needed to be analyzed, and to reduce costs of commercial RUM services. If that sample size is too small and not representative of the wider population, then the resulting metrics will also be similarly skewed. Discuss with your RUM provider the appropriate sampling size for your site.

Aggregation of data #

Field data by its very nature will include many, many data points of the same metrics compared to lab data, which will give a single value. If this data is aggregated differently for reporting, it can lead to another reason for differences between CrUX and RUM.

Timespan #

CrUX data is based on a 28 day sliding window of traffic, and it is not possible to change this timeframe—though the BigQuery data is stored for each month, allowing you to see previous months.

RUM data typically allows much greater granularity to allow seeing the impact of changes much sooner. When choosing smaller periods, though, RUM data can be unduly impacted by fluctuations in website traffic and visitors. When comparing RUM data to CrUX data, always ensure you are looking at performance over 28 days. Once you are satisfied the data is similar, you can look at other time frames to drill into the RUM data.

Aggregation of statistics #

CrUX metrics are measured at the 75th percentile—that is, looking at the value that 75% of page views achieved. There will be extremes in field data and removing the worst 25% experiences, it is intended to give a value that the majority of visitors can reasonably be expected to achieve.

RUM products often give a wider number of options of how to aggregate the metrics, including 75th percentile, median and other percentiles. If comparing RUM values to CrUX data, it is necessary to ensure you are looking at 75th percentile data to compare like-for-like.

The histogram data in CrUX includes all available data—not just 75th percentile—and shows the number of page views in each rating, but the aggregate score will be based on 75th percentile. This CrUX data is surfaced in tools like PageSpeed Insights:

Differences in metrics #

There are many metrics used to measure web performance, so when comparing two different sets of data, it’s important to understand what metrics are being measured, and how those metrics are being used.

Metrics measured #

CrUX data is the official dataset of the Core Web Vitals initiative and primarily measures these three metrics (LCP, FID, and CLS), with a few additional metrics to complement these.

RUM tools usually include these Core Web Vitals, but often include many other metrics too. Some RUM providers also measure the user experience using their own combination of all these metrics perhaps to give a happiness index or such. When comparing RUM data to CrUX, ensure you are comparing like-for-like.

Tools that assess Core Web Vitals pass/fail status should consider a page passing if it meets the recommended targets at the 75th percentile for all Core Web Vitals. If FID is not present for pages with no interactions, then only LCP and CLS need to pass.

Metric differences across browsers #

CrUX only measures in Chrome browsers, and you can refer to the Web Vitals Changelog to see how these change with each version of Chrome.

RUM solutions, however, will measure from a wider variety of browsers. Chromium-based browsers (Edge, Opera, and so on) will likely be similar to Chrome, unless Chrome is implementing new changes as noted in the Changelog.

For non-Chromium browsers, the differences can be more pronounced. First Contentful Paint (FCP), for example, is available in Safari and Firefox, but is measured in a different way. This can lead to significant variances in the times reported. As stated previously, if you are wanting to compare RUM to CrUX, it is best to filter on just Chrome users to allow for a like-for-like comparison.

Metrics timing #

Core Web Vitals metrics are provided by web browser APIs, but that does not mean there is not a potential for differences of values reported using them. Exactly when the metric measurement is taken—at page load or throughout the full page life cycle—can lead to differences. RUM tools may not always measure metrics in the same way—even if using the same names—and the same browser APIs to get the data, which can be confusing.

Largest Contentful Paint (LCP) is a page-load metric. A number of LCP elements can be reported by the Web API if larger elements are loaded later after the initial render. The final LCP element is when the page finishes loading or the user interacts with the page. Therefore differences can arise if the LCP element is reported earlier than those two events.

Additionally, in field data, the LCP element can be different depending on how the page is loaded. For a default page load showing the top of the page content, the LCP element will depend primarily on the screen size. However, if the page is opened with an anchor link further down the document, or similarly opened with a deep-link into a Single Page App (SPA)—more on that later—then the LCP element can be different.

Do not assume that the LCP timings provided in either CrUX nor RUM are based on the same element as lab tools. While CrUX will give you the overall LCP value per page or origin, RUM can segment this further to identify individual LCP problem sessions.

Cumulative Layout Shift (CLS) is measured throughout the life of the page, so the initial page-load CLS may not be representative of pages that cause greater shifts later after the page has loaded and the user has interacted with it. Taking the CLS value only after the page load—as many RUM products do—will therefore give a different result than taking the CLS value after the user finishes with the page.

First Input Delay (FID) requires an input to be measured, so it cannot be measured at page load. But—as its name implies—FID measures the first input only. The newer Interaction to Next Paint (INP) responsiveness metric measures all interactions throughout the life of the page, in a similar fashion to CLS, and so the reported value of INP may be very different if measured after the user has made a number of interactions on the page.

CrUX will follow the Core Web Vitals documentation and measure these through the full lifetime of the page. Many RUM providers choose instead to measure these metrics either after page load, or at some other time (for example, when a key call-to-action is clicked) for various reasons.

Getting an understanding from your RUM provider as to when Core Web Vitals are measured is important when seeing unexplained variances between the two data sources.

Single-page applications #

Single-page applications (SPA) work by updating the content on the current page, rather than performing traditional page navigation at the browser level. This means the browser does not see these as page navigations, despite users experiencing them as such. The Core Web Vitals APIs provided by the browser will not take these into consideration, and therefore CrUX does not currently support these page navigations. Work is currently underway to resolve this issue—see the Experimenting with measuring soft navigations post for more information.

Some RUM providers do attempt to detect "soft navigations" in SPAs, but if they're also attributing Core Web Vitals metrics to those "soft navigations" it will lead to differences with CrUX since the underlying APIs do not support this.

CrUX and Web API differences #

As well as the differences in which page views are measured, and what is measured, there are a few other, more complicated, scenarios to be aware of that can lead to differences in CrUX and RUM data. Some of these are due to limitations of the Web APIs used to measure the metrics, and some are where the results returned by the API need to be treated differently for certain scenarios. The Core Web Vitals documentation lists these differences for LCP, CLS, and FID but the main differences are noted below.

Back/forward cache #

CrUX considers Back/forward cache (or bfcache) restores as page navigations even though they do not result in a traditional page load. As the Web APIs do not treat these as a page load, RUM solutions need to take extra steps for these pages to be counted if they wish to match CrUX. These are considerably faster page loads that can result in overall better performance being reported for a site, so not including them can result in worse overall page performance metrics. Refer to your RUM solution to understand if they handle bfcache restored pages.

Iframes #

For security and privacy reasons, top-level pages do not have access to content within iframes (not even same-origin iframes). This means performance metrics for content in those can only be measured by the iframe itself, and not through the Web APIs on the framing page. If the iframe content includes the LCP element, or content that impacts the CLS, FID or INP experienced by the user, this will not be available to RUM solutions (including the Google web-vitals JavaScript library).

CrUX however, being measured by the Chrome browser itself rather than the page, does not have these limitations and so does measure metrics within iframes when reporting Core Web Vitals. This more accurately reflects what the user experiences, but can be another reason for differences for sites making use of iframes.

One concrete example of how this can lead to differences between LCP data in CrUX and RUM is embedded <video>. An autoplaying <video> element's first painted frame can count as an LCP candidate, but embeds for popular video streaming services—such as YouTube, for example—place these elements in an <iframe>. As of August 2023, CrUX can account for this, as it can access <iframe> contents, but RUM solutions cannot.

Cross-origin resources #

LCP media served from other domains do not give render time in the PerformanceObserver API—unless the Timing-Allow-Origin header (TAO) is provided—due to browser security restrictions to reduce timing attacks. This falls back to the load time of the resource but this may be quite different from when the content was actually painted.

Again, CrUX does report the render time data for Core Web Vitals. Sites are advised to limit cross-origin content that impacts the Core Web Vitals metrics and to enable TAO where possible if they wish to measure this more accurately. Other cross-origin resources may be subject to similar restrictions.

Background tabs and prerender #

When a page is not opened in the foreground—such as opening it in the background or if it uses prerender options (currently under development for Chrome)—they will still emit metrics via Web APIs. However, these are not reported by CrUX since they give timings that are inconsistent with the user experience. RUM solutions should also consider ignoring these, or at least explaining how these page views are treated.

So what can we do about it? #

We have shown why there may be differences between CrUX and RUM data, either due to differences in the methodology each uses or due to which users and page views are included or excluded. Ideally, both sets of data will still be representative of your site performance to be useful, but this article should outline why it is very unlikely to get the exact same numbers in each.

Where differences are slight (for example reporting a LCP of 2.0 seconds versus 2.2 seconds) both datasets will be useful and can usually be considered to be roughly in sync.

When pronounced differences make you question the accuracy of the data, you should try to understand those differences. Can the RUM data be filtered to be more closely aligned with CrUX (looking only at Chrome users, for desktop or mobile, with 75th percentile values over 28 days) to reduce these differences?

If so—and you can get the data to match more closely—then you should still ask why you are seeing these differences in the overall data and what this means. Are non-Chrome users skewing your metrics in a positive or negative way? Does this give you more insights into where you have performance issues that you can prioritize?

If your non-Chrome users are getting different results then you can use this valuable insight that RUM has given you to optimize differently. For example, certain APIs are not available on certain browsers, but you can consider alternatives for unsupported browsers to also improve their experiences. Or you can give a different, but more performant, experience to users on constrained devices or networks. CrUX is limited to Chrome data, but you should consider all your site visitors' experiences to help prioritize improvements. RUM data can fill that gap.

Once you understand the reasons for any differences, both tools can be incredibly useful to understand the user experiences of your website, and to help improve this even if the numbers are not identical. Use your RUM data to complement CrUX data and allow you to dig into what CrUX is telling you at a high level by segmenting your traffic to help you identify if it’s particular areas of your site or user base that need attention.

Looking at the trends to see your improvements are having the expected positive impacts is often more important than having each number match exactly between the two data sources. As mentioned above, RUM allows you to look at different time frames to get an advance look at what your 28 day CrUX scores will be—though looking at too short time frames can lead to noisy data, hence why CrUX uses 28 days.

Often there is no “right” or “wrong” answer in these different metrics - they are simply having a different lens on your users and how they are experiencing your site. As long as you understand why these differences happen, and what that can do to drive your decision making, that is what is more important to better serve your site visitors.

Acknowledgements #

Hero image by Steven Lelham on Unsplash

Time to First Byte (TTFB)

2021-10-26T00:00:00Z

Browser support

Chrome 43, Supported 43
Firefox 31, Supported 31
Edge 12, Supported 12
Safari 11, Supported 11

Source

What is TTFB? #

TTFB is a metric that measures the time between the request for a resource and when the first byte of a response begins to arrive.

A diagram of network request phases and their associated timings. TTFB measures the elapsed time between startTime and responseStart.

TTFB is the sum of the following request phases:

Redirect time
Service worker startup time (if applicable)
DNS lookup
Connection and TLS negotiation
Request, up until the point at which the first byte of the response has arrived

Reducing latency in connection setup time and on the backend will contribute to a lower TTFB.

What is a good TTFB score? #

Because TTFB precedes user-centric metrics such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP), it's recommended that your server responds to navigation requests quickly enough so that the 75th percentile of users experience an FCP within the "good" threshold. As a rough guide, most sites should strive to have Time To First Byte of 0.8 seconds or less.

Important

How to measure TTFB #

TTFB can be measured in the lab or in the field in the following ways.

Field tools #

Lab tools #

In the network panel of Chrome's DevTools
WebPageTest

Measure TTFB in JavaScript #

You can measure the TTFB of navigation requests in the browser with the Navigation Timing API. The following example shows how to create a PerformanceObserver that listens for a navigation entry and logs it to the console:

new PerformanceObserver((entryList) => {
  const [pageNav] = entryList.getEntriesByType('navigation');

  console.log(`TTFB: ${pageNav.responseStart}`);
}).observe({
  type: 'navigation',
  buffered: true
});

The web-vitals JavaScript library can also measure TTFB in the browser with less complexity:

import {onTTFB} from 'web-vitals';

// Measure and log TTFB as soon as it's available.
onTTFB(console.log);

Measuring resource requests #

TTFB applies to all requests, not just navigation requests. In particular, resources hosted on cross-origin servers can introduce latency due to the need to set up connections to those servers. To measure TTFB for resources in the field, use the Resource Timing API within a PerformanceObserver:

new PerformanceObserver((entryList) => {
  const entries = entryList.getEntries();

  for (const entry of entries) {
    // Some resources may have a responseStart value of 0, due
    // to the resource being cached, or a cross-origin resource
    // being served without a Timing-Allow-Origin header set.
    if (entry.responseStart > 0) {
      console.log(`TTFB: ${entry.responseStart}`, entry.name);
    }
  }
}).observe({
  type: 'resource',
  buffered: true
});

The above code snippet is similar to the one used to measure the TTFB for a navigation request, except instead of querying for 'navigation' entries, you query for 'resource' entries instead. It also accounts for the fact that some resources loaded from the primary origin may return a value of 0, since the connection is already open, or a resource is instantaneously retrieved from a cache.

How to improve TTFB #

An in-depth guide on optimizing TTFB has been published to give you more guidance on improving your website's TTFB.

Optimizing resource loading with the Fetch Priority API

2021-10-20T00:00:00Z

Browser support

Chrome 102, Supported 102
Firefox, Not supported
Edge 102, Supported 102
Safari preview, Preview

Source

When a browser parses a web page and begins to discover and download resources such as images, scripts, or CSS, it assigns them a fetch priority in an attempt to download resources in an optimal order. These priorities can depend on the kind of resource and where it is in the document. For example, in-viewport images may have a High priority while the priority for early loaded, render-blocking CSS via <link>s in the <head> could be Very High. Browsers are pretty good at assigning priorities that work well but may not be optimal in all cases.

In this article, we'll discuss the Fetch Priority API and the fetchpriority HTML attribute, which allow you to hint at the relative priority of a resource (high or low). Fetch Priority can help optimize the Core Web Vitals.

Fetch Priority improving Largest Contentful Paint from 2.6 s to 1.9 s in a test of Google Flights

Summary #

A few key areas where Fetch Priority can help:

Boost the priority of the LCP image by specifying fetchpriority="high" on the image element, causing LCP to happen sooner.
Increase the priority of async scripts using better semantics than the current hack that is commonly used (inserting a <link rel="preload"> for the async script).
Decrease the priority of late-body scripts to allow for better sequencing with images.

Historically, developers have had some, but limited, influence over resource priority using preload and preconnect. Fetch Priority complements these Resource Hints, but it's essential to understand where they all fit in. Preload lets you tell the browser about critical resources you want to load early before they are discovered naturally. This is especially useful for resources that are not easily discovered, such as fonts included in stylesheets, background images, or resources loaded from a script. Preconnect helps warm up connections to cross-origin servers and can help improve metrics like Time-to-first-byte and is useful when you know an origin but not necessarily the exact URL of a resource that will be needed.

Fetch Priority is a markup-based signal (available through the fetchpriority attribute) that developers can use to indicate the relative priority of a particular resource. You can also use these hints via JavaScript and the Fetch API with the priority property to influence the priority of resource fetches made for data. Fetch Priority can also complement preload. Take a Largest Contentful Paint image, which, when preloaded, will still get a low priority. If it is pushed back by other early low-priority resources, using Fetch Priority can help how soon the image gets loaded.

Fetch Priority is available in Chrome 101 or later.

Resource priority #

The resource download sequence depends on the browser's assigned priority for every resource on the page. Different factors can affect priority computation logic. For example,

CSS, fonts, scripts, images, and third-party resources are assigned different priorities.
The location or order in which you reference resources in the document also affects the priority of resources.
The preload resource hint helps the browser to discover a resource faster and thus load it before the document loads it and affects priority.
Priority computation changes for async or defer scripts.

The following table considers such factors to show how most resources are currently prioritized and sequenced in Chrome.

	Layout-blocking	Load in layout-blocking phase	Load one-at-a-time in layout-blocking phase
Blink Priority	VeryHigh	High	Medium	Low	VeryLow
DevTools Priority	Highest	High	Medium	Low	Lowest
	Main resource
	CSS* (early)		CSS* (late)		CSS (mismatch)
		Script (early** or not from preload scanner)	Script (**late)	Script (async)
	Font	Font (preload)
		Import
		Image (in viewport)		Image
				Media
				SVG document
					Prefetch
		Preload*
		XSL
	XHR (sync)	XHR/fetch* (async)

The browser downloads resources with the same computed priority in the order they are discovered. You can check the priority assigned to different resources when loading a page under the Chrome Dev Tools Network tab. (Ensure that you include the priority column by right-clicking on the table headings).

Priority for resource type = "font" on BBC news detail page

Priority for resource type = "script" on BBC news detail page

When would you need Fetch Priority? #

Knowledge of the browser's prioritization logic provides you with a few existing knobs to tweak the order of downloads. You can

Place resource tags such as <script> and <link> depending on the order you want to download them. Resources with the same priority are generally loaded in the order they are discovered.
Use the preload resource hint to download necessary resources earlier, particularly for resources that are not easily discovered early by the browser.
Use async or defer to download scripts without blocking other resources.
Lazy-load below-the-fold content so that the browser can use the available bandwidth for more critical above-the-fold resources.

These techniques help to control the browser's priority computation, thereby improving performance and Core Web Vitals. For example, when a critical background image is preloaded, it can be discovered much earlier, improving the Largest Contentful Paint (LCP).

Sometimes these handles may not be enough to prioritize resources optimally for your application. Here are some of the scenarios where Fetch Priority could be helpful:

You have several above-the-fold images, but all of them need not have the same priority. For example, in an image carousel, only the first visible image needs a higher priority compared to the others.
Hero images inside the viewport start at a "Low" priority. After the layout is complete, Chrome discovers they are in the viewport and boosts their priority (unfortunately, dev tools only shows the final priority—WebPageTest will show both). This usually adds a significant delay to loading the image. Providing the Fetch Priority in markup lets the image start at a "High" priority and start loading much earlier.

Note that preload is still required for the early discovery of LCP images included as CSS backgrounds and can be combined with Fetch Priority by including the fetchpriority='high' on the preload, otherwise it will still start with the default "Low" priority for images.
Declaring scripts as async or defer tells the browser to load them asynchronously. However, as seen in the figure above, these scripts are also assigned a "low" priority. You may want to bump up their priority while ensuring asynchronous download, particularly for any scripts that are critical for the user experience.
You may use the JavaScript fetch() API to fetch resources or data asynchronously. Fetch is assigned a "High" priority by the browser. There may be situations where you do not want all your fetches to be executed with "High" priority and prefer using different Fetch Priority instead. This can be helpful when running background API calls and mixing them with API calls that are responding to user input, like with autocomplete. The background API calls can be tagged as "Low" priority and the interactive API calls marked as "High" priority.
The browser assigns CSS and fonts a "High" priority, but all such resources may not be equally important or required for LCP. You can use Fetch Priority to lower the priority of some of these resources.

The `fetchpriority` attribute #

You can provide a Fetch Priority using the fetchpriority HTML attribute. You can use the attribute with link, img, and script tags. The attribute allows you to specify the priority for resource types such as CSS, fonts, scripts, and images when downloaded using the supported tags. The fetchpriority attribute accepts one of three values:

high: You consider the resource a high priority and want the browser to prioritize it as long as the browser's heuristics don't prevent that from happening.
low: You consider the resource a low priority and want the browser to deprioritize it if it's heuristics permit.
auto: This is the default value where you don't have a preference and let the browser decide the appropriate priority.

Here are a few examples of using the fetchpriority attribute in markup and the script-equivalent priority property.

<!-- We don't want a high priority for this above-the-fold image -->
<img src="/images/in_viewport_but_not_important.svg" fetchpriority="low" alt="I'm an unimportant image!">

<!-- We want to initiate an early fetch for a resource, but also deprioritize it -->
<link rel="preload" href="/js/script.js" as="script" fetchpriority="low">

<script>
  fetch('https://example.com/', {priority: 'low'})
  .then(data => {
    // Trigger a low priority fetch
  });
</script>

Browser priority and `fetchpriority` #

You can apply the fetchpriority attribute to different resources as shown in the following figure to potentially increase or reduce their computed priority. fetchpriority="auto" (◉) in each row denotes the default priority for that type of resource.

	Layout-blocking	Load in layout-blocking phase	Load one-at-a-time in layout-blocking phase
Blink Priority	VeryHigh	High	Medium	Low	VeryLow
DevTools Priority	Highest	High	Medium	Low	Lowest
Main Resource	◉
CSS* (early)	⬆◉	⬇
CSS* (late)		⬆	◉	⬇
Script (early** or not from preload scanner)		⬆◉		⬇
Script* (late)		⬆	◉	⬇
Script (async/defer)		⬆		◉⬇
Font	◉
Font (preload)		⬆◉		⬇
Import		◉
Image (in viewport)		⬆◉		⬇
Image		⬆		◉⬇
Media (video/audio)		⬆		◉⬇
SVG document		⬆		◉⬇
XHR (sync) - deprecated	◉
XHR/fetch* (async)		⬆◉		⬇
Preload*		⬆◉		⬇
Prefetch					◉
Favicon			◉
XSL		◉

* Preload using "as" or fetch using "type" use the priority of the type they are requesting (e.g., preload as="stylesheet" will use Highest priority). With no "as", they will behave like an XHR.
** "Early" is defined as being requested before any non-preloaded images have been requested ("late" is after).
*** CSS where the media type doesn't match is not fetched by the preload scanner and is only processed when the main parser reaches it, which usually means it will be fetched very late and with a "late" priority.
◉: fetchpriority="auto"
⬆: fetchpriority="high"
⬇: fetchpriority="low"
Images within the viewport start at "Low" priority and then at layout time are boosted to "High". By tagging it in markup using fetchpriority="high", it can start at "High" immediately and load much faster.

Note that fetchpriority sets the relative priority—that is it raises or lowers the default priority by an appropriate amount, rather than explicitly setting the priority to "High" or "Low" and the browser decides the relative priority. Often this is "High" or "Low", but not always. For example, critical CSS with fetchpriority="high" will still retain the "VeryHigh"/"Highest" priority, and using fetchpriority="low" on these will still retain the "High" priority—in neither case is the Priority explicitly set to "High" or "Low".

Use cases #

You can use the fetchpriority attribute to address scenarios where you may wish to provide the browser with an extra hint as to what priority to fetch a resource with.

Increase the priority of the LCP image #

You can specify fetchpriority="high" to boost the priority of the LCP or other critical images.

<img src="lcp-image.jpg" fetchpriority="high">

The following comparison shows the Google Flights page with an LCP background image loaded with and without Fetch Priority. With the priority set to high, the LCP improved from 2.6s to 1.9s.

An experiment conducted using Cloudflare workers to rewrite the Google Flights page to use Fetch Priority.

Lower the priority of above-the-fold images #

You can use fetchpriority="low" to lower the priority of above-the-fold images that may not be important for example in an image carousel.

<ul class="carousel">
  <img src="img/carousel-1.jpg" fetchpriority="high">
  <img src="img/carousel-2.jpg" fetchpriority="low">
  <img src="img/carousel-3.jpg" fetchpriority="low">
  <img src="img/carousel-4.jpg" fetchpriority="low">
</ul>

In an earlier experiment with the Oodle app, we used this to lower the priority of images that do not appear on load. It helped to cut down the load time by 2 seconds.

Lower the priority of preloaded resources #

To stop preloaded resources from competing with other critical resources, you could provide a hint to reduce their priority. You can use this technique with images, scripts, and CSS.

<!-- Lower priority only for non-critical preloaded scripts -->
<link rel="preload" as="script" href="critical-script.js">
<link rel="preload" href="/js/script.js" as="script" fetchpriority="low">

<!-- Preload CSS without blocking other resources -->
<link rel="preload" as="style" href="theme.css" fetchpriority="low" onload="this.rel='stylesheet'">

Reprioritize scripts #

Scripts required to make some parts of the page interactive are essential but should not block other resources. You can mark these as async with high priority.

<script src="async_but_important.js" async fetchpriority="high"></script>

Scripts cannot be marked as async if they rely on specific DOM states. However if they are lower down on the page, they may be downloaded with a lower priority as shown.

<script src="blocking_but_unimportant.js" fetchpriority="low"></script>

Lower the priority for non-critical data fetches #

The browser executes fetch with a high priority. If you have multiple fetches that may be fired simultaneously, you can use the high default priority for the more critical data fetches and lower it for less critical data.

// Important validation data (high by default)
let authenticate = await fetch('/user');

// Less important content data (suggested low)
let suggestedContent = await fetch('/content/suggested', {priority: 'low'});

Fetch Priority implementation notes #

Fetch Priority can improve performance in specific use cases, as discussed above. There are some things to be aware of:

The fetchpriority attribute is a hint and not a directive. The browser will try to respect the developer's preference. It is also possible that the browser will apply its preferences for resource priority as deemed necessary in case of conflicts.
Fetch Priority should not be confused with a preload. They are both distinct because:
- Preload is a mandatory fetch and not a hint.
- Preload allows the browser to discover the resource early, but it will still fetch it with the default priority. Conversely, Fetch Priority does not aid discoverability, but does allow you to increase or decrease the fetch priority.
- It is easier to observe and measure the effects of a preload.
Fetch Priority can complement preloads by increasing the granularity of prioritization. If you had already specified a preload as one of the first items in the <head> for an LCP image, then a high Fetch Priority may not result in significant gains. However, if the preload was after other resources, then a high Fetch Priority can improve the LCP. If a critical image is a CSS background image, you should preload it with fetchpriority = "high".
The noticeable gains due to prioritization will be more relevant in environments where more resources contend for the available network bandwidth. This is common for HTTP/1.x connections where parallel downloads are not possible or in low bandwidth HTTP/2 connections. Prioritization can resolve bottlenecks in these conditions.
CDNs do not uniformly implement HTTP/2 prioritization. Even if the browser communicates the priority suggested using Fetch Priority; the CDN may not reprioritize resources in the required order. This makes testing of Fetch Priority difficult. The priorities are applied both internally within the browser and with protocols that support prioritization (HTTP/2 and HTTP/3). It is still worth using even for just the internal browser prioritization independent of CDN or origin support, as that will often change when resources are requested by the browser—for example low priority resources like images are often held back from being requested while the browser processes the critical <head> items.
It may not be possible to introduce Fetch Priority as a best practice in your initial design. It is an optimization that you can apply later in the development cycle. You can check the priorities being assigned to different resources on the page, and if they do not match your expectations, you could introduce Fetch Priority for further optimization.

Using Preload after Chrome 95 #

The Fetch Priority feature was available for trial in Chrome 73 to 76 but was not released due to prioritization issues with preloads fixed in Chrome 95. Prior to Chrome 95, requests issued via <link rel=preload> always start before other requests seen by the preload scanner, even if the other requests have a higher priority.

With the fix in Chrome 95 and the enhancement for Fetch Priority, we hope that developers will start using preload for its intended purpose—to preload resources not detected by the parser (fonts, imports, background LCP images). The placement of the preload hint will affect when the resource is preloaded. Some key points on using preload are:

Including the preload in HTTP headers will cause it to jump ahead of everything else.
Generally, preloads will load in the order the parser gets to them for anything above "Medium" priority—so be careful if you are including preloads at the beginning of the HTML.
Font preloads will probably work best towards the end of the head or beginning of the body.
Import preloads (dynamic import() or modulepreload) should be done after the script tag that needs the import (so the actual script gets loaded/parsed first). Basically, if the script tag loads a script that will trigger the load of dependencies, make sure the <link rel=preload> for the dependencies is after the parent script tag, otherwise the dependencies may end up loading before the main script. In the proper order, the main script can be parsed/eval'd while the dependencies are loading.
Image preloads will have a "Low" priority (without Fetch Priority) and should be ordered relative to async scripts and other low or lowest priority tags.

History #

Fetch Priority was first experimented with in Chrome as an origin trial in 2018 and then again in 2021 using the importance attribute. At that time it was known as Priority Hints. The interface has since changed to fetchpriority for HTML and priority for JavaScript's Fetch API as part of the web standards process. To reduce confusion we now refer to this API as Fetch Priority.

Browser compatibility #

Browser support

Chrome 102, Supported 102
Firefox, Not supported
Edge 102, Supported 102
Safari preview, Preview

Source

As of this writing, Fetch Priority is only available in Chromium-based browsers. Other browser engines or earlier versions of Chromium browsers will ignore the attribute and use their default prioritization heuristics. Until another browser implements Fetch Priority, you may notice some references—such as MDN—mark this as Experimental, however Fetch Priority is now standardized and included in the HTML living standard and Fetch living standard.

Conclusion #

Developers are likely to be interested in Fetch Priority with the fixes in preload behavior and the recent focus on Core Web Vitals and LCP. They now have additional knobs available to achieve their desired loading sequence.

Core Web Vitals workflows with Google tools

2021-08-09T00:00:00Z

Core Web Vitals are a set of metrics that assess the user experience on criteria such as load performance, responsiveness to user input, and layout stability.

A workflow for improving Core Web Vitals for your website will be explored in this guide, but where that workflow begins depends on whether you're collecting your own field data. Where it ends may depend on which of Google's tools you'll find useful in diagnosing and fixing user experience problems.

Core Web Vitals are best measured in the field #

Core Web Vitals are specifically designed to measure how users experience your website—they are user centric metrics. Lab-based tools such as Lighthouse are diagnostic tools to highlight potential performance problems and best practices. Lab-based tools are run under certain, predefined conditions and may not reflect the real-life Core Web Vitals measurements your users experience.

For example, Lighthouse is a lab-based tool that runs tests with simulated throttling in a simulated desktop or mobile environment. While such simulations of slower network and device conditions are helpful when trying to diagnose performance problems, they're just a single slice of the large variety in network conditions and device capabilities, and so may not reflect what users on your sites are experiening.

Lab-based tools like Lighthouse also typically do a "cold load" of a webpage as a totally new visitor. This is often the slowest load, but in real life, visitors may have some assets cached if they have visited before, or when they are browsing around the site. New visitors, and tools, also may experience the site differently with cookie banners or other content present to them.

In short, while lab-based tools can give an indication of potential performance problems and help you debug and iterate, they may not represent how many of your visitors actually experience your website. Use field data for measuring real-world performance, and lab-based tools like Lighthouse for diagnostics of how to improve it. See also the When to use Lighthouse section.

Google measures Core Web Vitals through the Chrome User Experience Report (CrUX). This is a public dataset collected from real Chrome users. It is the backbone of many Google and third-party tools which report a site's Core Web Vitals.

CrUX has its limitations, though. It can often tell you when there is a problem, but often has insufficient data to tell you why.

Collect your own field data if possible #

The best dataset for improving website performance in the field is the one you build. That starts with collecting field data from your website's visitors. How you do this depends on the size of your organization, and whether you want to pay for a third-party solution or create your own.

Paid solutions will almost certainly measure Core Web Vitals (and other performance metrics) and usually provide a variety of tools to dig into the resulting data. In large organizations with significant resources, this may be the preferred method.

However, you may not be part of a large organization—or even one with the means to afford a third-party solution. In these cases, Google's web-vitals library will help you gather all Web Vitals. However, you'll be responsible for how that data is reported, stored, and analyzed.

If you're already using Google Analytics, but you haven't started collecting your own field data, there may be an opportunity for you to use the web-vitals library to send Web Vitals collected in the field to Google Analytics and use the BigQuery exports of GA4 to report on the data.

Understanding Google's tools #

Regardless of whether you're collecting your own field data, there are several Google tools that may be useful in analyzing Core Web Vitals. Before establishing a workflow, a high-level overview of each tool can help you to understand which tools may—or may not—be best for you.

Chrome User Experience Report (CrUX) #

As mentioned previously, CrUX is a public data set of field data gathered from a segment of real Google Chrome users from millions of websites. It includes Core Web Vital metrics and other metrics for websites with sufficient traffic.

CrUX is available as a monthly BigQuery dataset at the origin level, or as a daily API at the URL or origin-level, provided a URL or origin has enough samples in the CrUX dataset. The BigQuery data is also viewable in an easy to use CrUX Dashboard allowing sites to review historical trends for their site.

When to use CrUX #

Even if you gather your own field data, CrUX is still useful. Though CrUX represents a subset of Chrome users, it's helpful to compare your website's field data to see how it aligns with its CrUX data. There are advantages and disadvantages to each, which can result in differences. If you currently don't gather any field data for your website, CrUX is especially valuable to provide a high-level overview—provided your website is represented in its dataset.

You can use CrUX directly, or via another tool (including those mentioned below). Using the CrUX dataset directly, either via BigQuery or the API, is useful to surface data that is not currently shown in other tools—for example country-level data is often not available on other tools, or to view the additional metrics in CrUX which again are often not surfaced in other tooling.

When not to use CrUX #

CrUX only represents Chrome users, and even then, only a subset of Chrome users. A full RUM solution can include more experiences across Chrome and other browsers where they support the Web Vital metrics.

Websites that don't receive enough traffic are not represented in the CrUX dataset. If this is the case for you, you'll need to gather your own field data to understand how your website performs in the field, as CrUX won't be an option. Alternatively, you will need to depend on lab data, but with the limitations that it may not be representative above.

Since the data CrUX provides is a rolling average over the previous 28 days, it's not an ideal tool during development, as it will take a fair amount of time for improvements to be reflected in the CrUX dataset.

Finally, as a public dataset, CrUX is limited to how much information it can make available, and how this data can be queried. Capturing your own RUM data allows you to gather more details (for example, the LCP element), and slice and dice the data more to identify problems. Do logged in users experience better or worse Core Web Vitals than logged out users? Do users with a slow LCP have a particular LCP element? Which interactions are causing high FID and INP values?

PageSpeed Insights (PSI) #

PSI is a tool that reports field data from CrUX and lab from Lighthouse for a given page. See those individual sections for more details.

When to use PSI #

PSI is great for assessing CrUX performance at the page level or origin-level, for both mobile and desktop users. It's a good choice for an initial overview of Core Web Vitals for a page or site. It also allows you to easily view Core Web Vitals data for other sites like competitors.

PSI also provides Lighthouse data, which gives useful recommendations to improve your Core Web Vitals—if the metrics align. Where these do not align, Lighthouse recommendations may be less relevant.

Since Lighthouse is run from the server, it can form a more consistent baseline than running Lighthouse from DevTools.

When not to use PSI #

PSI is only available for public URLs. It cannot be used on development sites that are not publicly accessible.

CrUX data is only available when sites meet certain eligibility criteria, including site popularity thresholds. PSI is less useful when CrUX data is not available for a page or origin as it can only show the Lighthouse lab data in these cases.

Similarly, if you only have origin-level CrUX data rather than the specific URL being tested, then this also limits its usefulness of correlating the origin-level field data to the page-level lab diagnostics. Having the origin-level field data is still very useful information to have as a summary of the site's performance and the Lighthouse audits may help, but extra caution should be used in this case.

Finally, where page-level data is available in CrUX, but differs from the Lighthouse lab data, recommendations from Lighthouse may be of limited value. This can happen particularly for post-load CLS issues, and for interactivity Core Web Vitals (FID and INP) where lab-based audits are less useful.

Search Console #

Search Console measures your site's search traffic and performance, including Core Web Vitals. It is only available to site owners who have confirmed their ownership of the site.

A valuable feature of Search Console is that it groups similar pages (for example, pages that use the same template) into a single group assessment. Search Console also includes a Core Web Vitals report based on field data from CrUX.

When to use Search Console #

Search Console is well-suited for both developers and those in non-developer roles to assess both search and page performance in ways other Google tools don't. Its presentation of CrUX data and grouping of pages by similarity offers novel insight into how performance improvements impact entire categories of pages.

When not to use Search Console #

Search Console may not be a fit for projects that use different third-party tools which group pages by similarity, or if a website isn't represented in the CrUX dataset.

Page grouping can also be somewhat confusing when the example pages in a group have different characteristics than the rest of the group—for example, if the group fails particular Core Web Vitals overall, but the example pages all seem to pass the same Core Web Vitals. This can happen when a group contains a long tail or seldomly visited pages that may be slower to load, as they're less likely to be cached. When there are sufficient volumes of these pages in the long tail, they can influence the group's overall pass rate.

Lighthouse #

Lighthouse is a lab tool that provides specific opportunities for improving page performance. Lighthouse user flows also allow developers to script interaction flows for performance testing beyond page load.

Lighthouse-CI is a related tool that runs Lighthouse during project builds and deploys to assist with performance regression testing. It presents a Lighthouse report along with pull requests, and tracks performance metrics over time.

When to use Lighthouse #

Lighthouse is excellent for finding performance improvement opportunities during development in both local and staging environments. Lighthouse CI is similarly useful in the build and deploy phases to staging and production environments, where performance regression testing is needed to preserve good user experiences.

When not to use Lighthouse #

Lighthouse (or Lighthouse CI) is not a substitute for field data. Lighthouse is primarily a diagnostic tool listing potential issues and best practices from a predefined page load. The recommendations it surfaces may not always match the performance experienced by your users.

While Lighthouse can be used to diagnose production sites through tools like PageSpeed Insights, Lighthouse would ideally be used in development and continuous integration environments to address performance issues before they reach production.

Web Vitals extension #

The Web Vitals Chrome extension is a diagnostic tool that surfaces Core Web Vitals metrics as you browse the web. It also includes CrUX data for the current page if it is represented in the CrUX dataset, and provides debugging information to help you identify Core Web Vitals performance problems.

When to use the Web Vitals extension #

The Web Vitals extension can be used by anyone in any role to assess a page's Core Web Vitals at all points of the page lifecycle. It is useful as a "live" view of performance as you interact with the page to attempt to uncover performance issues—particularly for post-load issues you might see with the CLS and INP metrics.

When not to use the Web Vitals extension #

The Web Vitals extension isn't a holistic assessment of page performance. In addition, the metrics it reports are highly dependent the environment in which it runs, and developers often have higher powered machines or access to faster networks.

The Performance panel in Chrome DevTools #

Chrome DevTools is a collection of in-browser development tools, including the Performance panel. The Performance panel is a lab tool that profiles all page activity during page load or a recorded time period. It offers deep insight into everything it observes across dimensions such as network, rendering, painting, and scripting activity, as well as a page's Core Web Vitals.

When to use the Performance panel #

The Performance panel should be used by developers during development to gain deep insight into page performance. This is particularly useful to debug responsiveness issues affecting FID or INP. Once a poorly responding interaction is identified and repeatable, the Performance panel can provide a wealth of data as to what is going on in the browser to help understand the issue, from main thread blocking, to JavaScript call stacks, to rendering work.

When not to use the Performance panel #

The Performance panel is a developer tool that provides lab data only. It's not a substitute for field data. It contains a lot of debugging information, but because of that, it may not be easy to use for novice developers or those in non-developer roles.

A three step workflow for ensuring your website's Core Web Vitals stay healthy #

When working to improve the user experience, it's best to think of the process as a continuous cycle. For improving Core Web Vitals and other performance metrics, one approach could be:

Evaluate website health and identify pain points.
Debug and optimize.
Monitor with continuous integration tools to catch and prevent regressions.

Step 1: Evaluate website health and identify opportunities for improvement #

It is best to start with field data to evaluate website health.

Use PageSpeed Insights to view overall Core Web Vitals experience metrics on the origin, and specific information on an individual URL.
Search Console can be useful to identify pages which need improvement where its page grouping feature works well for your site.
If you have RUM data, then that is often the best option to be able to identify particular pages or traffic segments with issues.

Whether you analyze field data you collect yourself or CrUX data, this first step is vital. If you're not gathering field data, CrUX data may be enough to guide you—again, provided your website is represented in the dataset.

Analyze site performance with PageSpeed Insights #

PageSpeed Insights displays the CrUX data covering the last 28 days of user experience data at the 75th percentile. This means that if 75% of user experiences meet the threshold set for a given metric, then the experience is considered "good".

If you have a specific page in mind to look at the performance of, then use that. For an overall view of a site when you first start optimizing, you may wish to start with the home page, as it is typically one of the most popular pages on many sites.

Concentrate on the what your real users are experiencing section of PSI initially. You will see up to four views of the data: mobile and desktop for the URL entered and the whole origin. Compare these and see how they differ. Mobile is typically less performant than desktop since it is a more resource-constrained device operating under potentially less stable network conditions. If the URL and origin data are significantly different, then try to understand why: home pages are often the first pages visited (that is, a landing page) so can be slower than the origin users take the full brunt of an unprimed browser cache. Subsequent pages will likely load faster, as any shared assets will be cached, bringing down the aggregate origin-level data.

PSI also shows all three Core Web Vitals (LCP, CLS, and FID) and the pending INP metric, plus the diagnostic TTFB and FCP metrics. Are any of the Core Web Vitals failing, and by how much? This will indicate where to concentrate your efforts.

Understand the relationships between these numbers—particularly for LCP. If LCP is slow, as it is in this example, then look at TTFB and FCP which are both milestones to that metric. In this example we have a 1.8 second TTFB, which is going to make it very tough to meet the 2.5 second recommended threshold for good LCP. This suggests either a slow backend (server issues or a lack of CDN), slower networks, or redirects delaying the first HTML bytes. Look at the Optimize TTFB guide for more information. FCP takes another second on top of that, which again may be indicative of slower networks. LCP is not long after FCP in this example suggesting the LCP resource is well optimized once the page itself loads.

For CLS, look at the CrUX CLS and the Lighthouse CLS scores to see if this is a load CLS issue (which Lighthouse will catch and advise on), or a post-load CLS issue that Lighthouse won't catch. More for information see the Optimize CLS guide.

For responsiveness, look at the FID and INP scores. Look at the TBT audits in Lighthouse to see if a lot of JavaScript processing is happening during the initial page load, which is likely to impact INP. INP can be a tricky metric to improve, so consult the Optimize INP guide for more information.

Identify poorly performing pages in Search Console #

While PSI is useful when you have a specific URL you want to test or the site as a whole, Search Console can help target your efforts to particular types of pages. This is particularly useful if many pages share common themes or technologies and Search Console can successfully identify these.

The Core Web Vitals report in Search Console shows the big picture of your website's performance, but you can still drill down into specific pages that need attention. With Search Console, you can also:

Identify individual page groups that need improvement, and those that currently provide a good user experience.
Get granular data on performance by URL grouped by status, metric, and groups of similar web pages (such as product detail pages on an e-commerce website).
Get detailed reports that bucket URLs in each user experience quality category for both mobile and desktop.

Once you have some specific pages to look at, you can use PSI as explained previously to gather further understanding of the issues for those pages.

Step 2: Debug and optimize #

In step 1, you should have identified pages which require performance improvements, and also which of the Core Web Vitals metrics you want to improve. You can use the Google tooling to get further information to understand the root cause to identify the issue.

Run a Lighthouse audit to get page-level guidance
Use the Web Vitals extension to analyze Core Web Vitals in real time.
Use the Performance panel in Chrome DevTools to debug performance issues and test code changes.

For more detailed guidance, see these guides:

Uncover opportunities with Lighthouse #

PageSpeed Insights runs Lighthouse for you, but for local development it is also possible to run Lighthouse from Chrome DevTools, which is useful to validate fixes locally.

A key point is to validate that the Lighthouse audit replicates the issues you are trying to solve (for example, slow LCP, or CLS issues). Out of the box, Lighthouse only assesses the user experience during page load. Since it's a lab tool, it also excludes FID and INP in favor of TBT.

When the Lighthouse metrics suggest a similar problem as the one you are trying to solve, the wealth of information in its audits can help identify issues and suggest solutions.

You can filter the audits to just the Core Web Vitals you are interested in to focus on fixes for issues related to a specific metric:

For FID and INP, use the TBT audits to identify issues that can potentially affect those metrics, but be aware that without interactions, Lighthouse is limited in how much it can diagnose.

Analyze in real time with the Web Vitals extension #

The Web Vitals Chrome extension shows Core Web Vitals in real time during page load and while browsing a page. Because of this, it can capture FID and INP as well as layout shifts that occur after load. The debugging options show more detailed information on each metric:

It's best to think of the Web Vitals extension as a spot-checking tool to find performance issues, not a comprehensive debugging tool—that's a job for the Performance panel in Chrome DevTools.

Drill down with the Performance panel #

The Performance panel in Chrome DevTools profiles all page behavior during a recorded period of time.

Key timings—such as LCP, for example—are shown in the Timings track. Click on these for more details.

The Layout Shifts track highlights layout shifts and clicking on these provides more details about the elements that shifted for debugging CLS.

Long Tasks (that can lead to FID and INP issues) are also highlighted with red triangles.

These features—as well as information in other parts of the Performance panel—can help you determine whether fixes are having any effect on a page's Core Web Vitals.

Debug Core Web Vitals in the field #

Lab tools can't always identify the cause of all Core Web Vitals issues affecting your users. This is one reason why it's so important to collect your own field data, as it takes factors into account that lab data cannot.

See debug performance in the field for more information.

Step 3: Monitor for changes #

Once you have fixed any issues, you want to ensure they have the desired effect and that new issues do not disrupt your Core Web Vitals. This requires monitoring for performance issues as part of developer workflow to prevent performance issues being released to production, and monitoring the field data regularly to ensure this is the case.

Monitor for performance requisitions in Continuous Integration (CI) environments #

Lighthouse-CI allows you to automatically run Lighthouse audits on code commits to prevent performance regressions entering code. This can check performance timings (which are subject to variability), or for just the performance audits, as a linting tool to prevent bad practices in the code.

View website health trends with field data #

While you should aim to catch and fix all performance issues before they make it to production, monitoring your field data via RUM is essential to find any that slip through. There are many commercial RUM products available that can help with this. The web-vitals JavaScript library can automate a website's field data collection, and optionally use this data to power custom dashboards and alerting systems.

For sites without a RUM solution, you can use the CrUX Dashboard as a basic trend analysis of field data. It reports the following for sites in CrUX:

Site overview, which segments Core Web Vitals into desktop and mobile device types.
Historical trend by metric type, which is a distribution of metrics over time for each available monthly release of CrUX report data.
User demographics, which illustrates the distribution of page views across an entire origin for users in each demographic including device and effective connection types.

The CrUX Dashboard is based on the CrUX BigQuery dataset, which is updated once a month. This can be a good reminder to regularly check in on your Core Web Vitals.

Conclusion #

Ensuring fast and delightful user experiences requires a performance-first mindset and adoption of a workflow to ensure progress. With the right tools and processes to audit, debug, and monitor, building great user experiences and staying within the thresholds defined for good Core Web Vitals is within your reach.

Best practices for tags and tag managers

2021-07-29T00:00:00Z

Tags are snippets of third-party code that are inserted into a site, typically via a tag manager. Tags are most commonly used for marketing and analytics.

The performance impact of tags and tag managers varies wildly from site to site. Tag managers can be compared to an envelope: the tag manager provides a vessel—but what you fill it with and how you use it is mostly up to you.

This article discusses techniques for optimizing tags and tag managers for performance and Web Vitals. Although this article references Google Tag Manager, many of the ideas discussed are also applicable to other tag managers.

Impact on Core Web Vitals #

Tag Managers can often impact your Core Web Vitals indirectly by using up resources needed to load your page quickly and keep it responsive. Bandwidth can be spent downloading the tag manager JavaScript for your sites, or the subsequent calls this makes. CPU time on the main thread can be spent evaluating and executing JavaScript contained within the tag manager and the tags.

Largest Contentful Paint (LCP) is vulnerable to bandwidth contention during the critical page load time. Additionally, blocking the main thread can delay the LCP render time.

Cumulative Layout Shift (CLS) can be impacted, either by delaying loading critical resources before the first render, or by tag managers injecting content into the page.

First Input Delay (FID) is susceptible to CPU contention on the main thread. This can also impact the newer Interaction to Next Paint (INP) metric and we have seen a correlation between the size of tag managers, and poorer INP scores.

Tag types #

The impact of tags on performance varies by tag type. Generally speaking, image tags ("pixels") are the most performant, followed by custom templates, and lastly, custom HTML tags. Vendor tags vary depending on the functionality they allow.

However, keep in mind that how you use a tag greatly influences its performance impact. "Pixels" are highly performant largely because the nature of this tag type imposes tight restrictions on how they can be used; custom HTML tags aren't necessarily always bad for performance, but due to the level of freedom they offer users, they can be easy to misuse in a way that is bad for performance.

When thinking about tags, keep scale in mind: the performance impact of any single tag may be negligible—but can become significant when tens or hundreds of tags are used on the same page.

Not all scripts should be loaded using a tag manager #

Tag managers are typically not a good mechanism for loading resources that implement immediate visual or functional aspects of the user experience—for example, cookie notices, hero images, or site features. Using a tag manager to load these resources typically delays their delivery. This is bad for the user experience and can also increase metrics like LCP and CLS. In addition, keep in mind that some users block tag managers. Using a tag manager to implement UX features may result in a broken website for some of your users.

Be careful with Custom HTML tags #

Custom HTML tags have been around for many years and are heavily used on most sites. Custom HTML tags allow you to enter your own code with few restrictions as, despite the name, the main use of this tag is to add custom <script> elements to a page.

Custom HTML tags can be used in a wide variety of ways and their performance impact varies significantly. When measuring the performance of your site, be aware that most tools will attribute the performance impact of a Custom HTML tag to the tag manager that injected it—rather than the tag itself.

Custom HTML tags can insert an element into the surrounding page. The act of inserting elements into the page can be a source of performance issues, and in some cases, also cause layout shifts.

In most situations, if an element is inserted into the page, the browser must recalculate the size and position of each item on the page—this process is known as layout. The performance impact of a single layout is minimal, but when it occurs excessively it can become a source of performance issues. The impact of this phenomenon is larger on lower-end devices and pages with a high number of DOM elements.
If a visible page element is inserted into the DOM after the surrounding area has already been rendered, it can cause a layout shift. This phenomenon is not unique to tag managers—however, because tags typically load later than other parts of the page, it's common for them to be inserted into the DOM after the surrounding page has already been rendered.

Consider using Custom Templates #

Custom templates support some of the same operations as Custom HTML tags but are built upon a sandboxed version of JavaScript that provides APIs for common use cases like script injection and pixel injection. As the name implies, they allow a template to be created, by a power user who can build this with performance in mind. Less technical users can then use the template. This is often safer than providing full Custom HTML access.

Due to the greater restrictions imposed on custom templates, these tags are much less likely to exhibit performance or security issues; however, for these same reasons, custom templates will not work for all use cases.

Inject scripts correctly #

Using a tag manager to inject a script is a very common use case. The recommended way to do this is to use a Custom Template and the injectScript API.

For information on using the injectScript API to convert an existing Custom HTML tag, see Convert an existing tag.

If you must use a Custom HTML tag, here are some things to keep in mind:

Libraries and large third-party scripts should be loaded via a script tag that downloads an external file (for example, <script src="external-scripts.js">), rather than directly copy-pasting the script's contents into the tag. Although forgoing use of the <script> tag eliminates a separate round-trip to download the script's contents, this practice increases container size and prevents the script from being cached separately by the browser.
Many vendors recommend placing their <script> tag at the top of the <head>. However, for scripts loaded via tag manager, this recommendation is usually unnecessary: in most situations, the browser has already finished parsing the <head> by the time that the tag manager executes.

Use pixels #

In some situations third-party scripts can be replaced with image or iframe "pixels". Compared to their script-based counterparts, pixels may support less functionality, so are often seen as a less-preferred implementation because of that. However, when used inside tag managers, pixels can be more dynamic as they can fire on triggers and pass different variables. They are the most performant and secure type of tag because there is no JavaScript execution after it is fired. Pixels have a very small resource size (less than 1 KB) and do not cause layout shifts.

Check with your third-party provider for more information on their support for pixels. Additionally, you can try inspecting their code for a <noscript> tag. If a vendor supports pixels, they will often include them within the <noscript> tag.

Alternatives to pixels #

Pixels became popular largely because at one time they were one of the cheapest and most reliable ways to make a HTTP request in situations where the server response is not relevant ( for example, when sending data to analytics providers). The navigator.sendBeacon() and fetch() keepalive APIs are designed to address this same use case but are arguably more reliable than pixels.

There is nothing wrong with continuing to use pixels—they are well supported and have minimal performance impact. However, if you are building your own beacons, it is worth considering using one of these APIs.

`sendBeacon()` #

The navigator.sendBeacon() API is designed for sending small amounts of data to web servers in situations where the server response does not matter.

const url = "https://example.com/analytics";
const data = JSON.stringify({
    event: "checkout",
    time: performance.now()
});

navigator.sendBeacon(url, data);

sendBeacon() has a limited API: it only supports making POST requests and does not support setting custom headers. It is supported by all modern browsers.

`fetch() keepalive` #

keepalive is a flag that allows the Fetch API to be used to make non-blocking requests like event reporting and analytics. It is used by including keepalive: true in the parameters passed to fetch().

const url = "https://example.com/analytics";
const data = JSON.stringify({
  event: "checkout",
  time: performance.now()
});

fetch(url, {
    method: 'POST',
    body: data,
    keepalive: true
});

If fetch() keepalive and sendBeacon() seem very similar, it's because they are. In fact, in Chromium browsers, sendBeacon() is now built upon fetch() keepalive.

When choosing between fetch() keepalive and sendBeacon(), it's important to consider the features and browser support that you need. The fetch() API is significantly more flexible; however, keepalive has less browser support than sendBeacon().

Get clarification #

Tags are often created by following guidance provided by a third-party vendor. If it is unclear what a vendor's code does—consider asking someone who knows. Getting a second opinion can help identify if a tag has the potential to create performance or security issues.

Labeling tags with an owner in the tag manager is also recommended. It is far too easy to forget who owns a tag, and be afraid to remove it just in case!

Triggers #

At a high-level, optimizing tag triggers generally consists of making sure to not trigger tags more than necessary and choosing a trigger that balances business needs with performance costs.

Triggers themselves are JavaScript code that will increase the size—and execution cost—of the tag manager. While most triggers are small, the cumulative effect can add up. Having many click events for example, or timer triggers can dramatically increase the workload of the tag manager.

Choose an appropriate trigger event #

The performance impact of a tag is not fixed: generally speaking, the earlier that a tag fires, the greater its impact on performance. Resources are typically constrained during the initial page load and therefore loading or executing a particular resource (or tag) takes resources away from something else.

Although it is important to choose appropriate triggers for all tags, it is particularly important for tags that load large resources or execute long scripts.

Tags can be triggered on Page Views (typically Page load, on DOM Ready, on Window Loaded), or based on a custom event. To avoid impacting page load, it is recommended to fire non-essential tags after Window Loaded.

Use custom events #

Custom events allow you to fire triggers in response to page events that aren't covered by Google Tag Manager's built-in triggers. For example, many tags use page view triggers; however, the time period between DOM Ready and Window Loaded can be lengthy on many pages and this can make it difficult to fine-tune when a tag fires. Custom events provide a solution to this problem.

To use custom events, first create a custom event trigger and update your tags to use this trigger.

To fire the trigger, push the corresponding event to the data layer.

// Custom event trigger that fires after 2 seconds
setTimeout(() => {
  dataLayer.push({
    'event' : 'my-custom-event'
  });
}, 2000);

Use specific trigger conditions #

Using specific trigger conditions helps avoid firing a tag unnecessarily. Although there are many ways to apply this concept, one of the simplest yet most useful things you can do is ensure that a tag only fires on pages where it is actually used.

Built-in variables can also be incorporated into trigger conditions to limit tag firing.

However, be aware that having complex trigger conditions or exceptions takes processing time in and off itself, so do not make them too complex.

Load your tag manager at an appropriate time #

Adjusting when you tag manager itself loads can have a significant impact on performance. Triggers, regardless of how they are configured, can't fire until after a tag manager loads. Although it is important to choose good triggers for individual tags (as explained above), experimenting with when you load your tag manager can often have an equal or greater impact given that this single decision will impact all tags on a page.

Loading the tag manager later also adds a layer of control and can avoid future performance issues as it will prevent a tag manager user inadvertently loading a tag too early, without realizing the impact this can have.

Variables #

Variables allow data to be read from the page. They are useful in triggers, and in tags themselves.

Like triggers, variables result in JavaScript code being added to the tag manager, and so can cause performance issues. Variables can be relatively simple built-in types that can, for example, read parts of the URL, cookies, data layer, or DOM. Or they can be custom JavaScript that is basically unlimited in what it can do.

Keep variables simple and to a minimum, since they will need to be evaluated continually by the tag manager. Remove old variables that are no longer used to reduce both the size of the tag manager script, and the processing time it uses.

Tag management #

Using the tags efficiently will reduce the risk of performance issues.

Use the data layer #

The data layer "contains all of the information that you want to pass to Google Tag Manager". More concretely, it is a JavaScript array of objects that contain information about the page. It can also be used to trigger tags.

// Contents of the data layer
window.dataLayer = [{
    'pageCategory': 'signup',
    'visitorType': 'high-value'
  }];

// Pushing a variable to the data layer
window.dataLayer.push({'variable_name': 'variable_value'});

// Pushing an event to the data layer
window.dataLayer.push({'event': 'event_name'});

Although Google Tag Manager can be used without the data layer, its use is strongly recommended. The data layer provides a way to consolidate the data being accessed by third-party scripts into a single place thereby providing better visibility into its usage. Amongst other things, this can help reduce redundant variable calculations and script execution. Using a data layer also controls the data being accessed by the tags, rather than giving full JavaScript variable or DOM access.

Remove duplicate and unused tags #

Duplicate tags can occur when a tag is included in a page's HTML markup in addition to being injected through a tag manager.

Unused tags should be paused or removed rather than blocked through use of a trigger exception. Pausing or removing a tag removes the code from the container; blocking does not.

When unused tags are removed, the triggers and variables should also be reviewed to see if any of them can be removed if they were only used by those tags.

Use allow and deny lists #

Allow and deny lists allow you to configure highly granular restrictions on the tags, triggers, and variables allowed on a page. This can be used to help enforce performance best practices and other policies.

Allow and deny lists are configured through the data layer.

window.dataLayer = [{
  'gtm.allowlist': ['<id>', '<id>', ...],
  'gtm.blocklist': ['customScripts']
}];

For example, it is possible to not allow any Custom HTML tags, JavaScript variables, or direct DOM access. This means only pixels and pre-defined tags can be used, with data from the data layer. While this is certainly restrictive, it can result in a much more performant, and secure, tag manager implementation.

Consider using server-side tagging #

Switching to server-side tagging is not a trivial task, but it is worth considering - particularly for larger sites that want more control over their data. Server-side tagging removes vendor code from the client, and with it, offloads processing from the client to the server.

For example, when using client-side tagging, sending data to multiple analytics accounts entails that the client initiates separate requests for each endpoint. By contrast, with server-side tagging, a single request is made by the client to the server-side container, and from there, this data is forwarded to different analytics accounts.

Keep in mind that server-side tagging only works with some tags; tag compatibility varies depending on vendor.

For more information, see An introduction to server-side tagging.

Containers #

Tag managers typically allow multiple instances or "containers" within their set up. This allows multiple containers to be controlled within the one tag manager account.

Use only one container per page #

Using multiple containers on a single page can create significant performance issues as it introduces additional overhead and script execution. At the very least it duplicates the core tag code itself which, as it is delivered as part of the container's JavaScript, cannot be reused between the containers.

It is rare for multiple containers to be used effectively. However, there can be instances when this can work—if controlled well—including:

Having a lighter "early load" container, and a heavier "later load" container, rather than one large container.
Having a restricted container used by less technical users, with a less restricted, but more tightly controlled, container for tags that cannot be used in the restricted container.

If you must use multiple containers per page, follow Google Tag manager guidance for setting up multiple containers.

Use separate containers if needed #

If you use a tag manager for multiple properties (for example, a web app and a mobile app)—the number of containers you use can help or hurt your workflow productivity. It can also impact performance.

Generally speaking, a single container can effectively be used across multiple sites if the sites are similar in use and structure. For example, although a brand's mobile and web apps might serve similar functions, it's likely that the apps will be structured differently, and therefore more effectively managed through separate containers.

Trying to reuse a single container too broadly typically unnecessarily increases the complexity and size of the container by forcing the adoption of complex logic to manage tags and triggers.

Keep an eye on container size #

The size of a container is determined by its tags, triggers, and variables. Although a small container may still negatively impact page performance, a large container almost certainly will.

Container size should not be your north-star metric when optimizing your tag usage; however, a large container size is often a warning sign that a container is not well maintained and possibly misused.

Google Tag Manager limits container size to 200 KB and will warn about container size starting at 140 KB. However, most sites should aim to keep their containers far smaller than this. For perspective, the median site container is around 50 KB.

To determine the size of your container, look at the size of the response returned by https://www.googletagmanager.com/gtag/js?id=YOUR_ID. This response contains the Google Tag Manager library plus the contents of the container. By itself, the Google Tag Manager library is around 33 KB compressed.

Name your container versions #

A container version is a snapshot of a container's content at a particular point in time. Using a meaningful name and along with including a short description of meaningful changes within can go a long way in making it easier to debug future performance issues.

Tagging workflows #

Managing changes to your tags is important to ensure they do not have a negative impact on page performance.

Test tags before deploying #

Testing your tags before deployment can help catch issues (performance and otherwise) before they ship.

Things to consider when testing a tag include:

Is the tag working correctly?
Does the tag cause any layout shifts?
Does the tag load any resources? How large are these resources?
Does the tag trigger a long-running script?

Preview mode #

Preview mode allows you to test tag changes on your actual site without having to deploy them to the public first. Preview mode includes a debugging console that provides information about tags.

The execution time of Google Tag Manager will be different (slightly slower) when run in Preview mode due to the additional overhead required to expose information in the debugging console. Thus, comparing Web Vitals measurements collected in preview mode to those collected in production is not recommended. However, this discrepancy should not affect the execution behavior of the tags themselves.

Standalone testing #

An alternative approach to testing tags is to set up an empty page containing a container with a single tag—the tag you are testing. This testing setup is less realistic and won't catch some issues (for example, whether a tag causes layout shifts)—however it can make it easier to isolate and measure the impact of the tag on things like script execution. Check out how Telegraph uses this isolation approach to improve performance of third-party code.

Monitor tag performance #

The Google Tag Manager Monitoring API can be used to gather information about the execution time of a particular tag. This information is reported to an endpoint of your choosing.

For more information, see How to build a Google Tag Manager Monitor.

Require approval for container changes #

First-party code typically goes through review and testing before deployment - treat your tags the same. Adding two-step verification, which requires administrator approval for container changes, is one way to do this. Alternatively, if you don't want to require two-step verification but would still like to keep an eye on changes, you can set up container notifications to receive email alerts about container events of your choosing.

Periodically audit tag usage #

One of the challenges of working with tags is that they tend to accumulate over time: tags get added but are rarely removed. Auditing tags periodically is one way to reverse this trend. The ideal frequency for doing this will depend on how often your site's tags are updated.

Labeling each tag so the owner is obvious allows easier identification of who is responsive for that tag and can say whether it is still needed.

When auditing tags, do not forget about cleaning up triggers and variables as well. They can easily be the cause of performance issues too.

For more information, see Keeping third-party scripts under control.

Best practices for fonts

2021-06-03T00:00:00Z

This article discusses performance best practices for fonts. There are a variety of ways in which web fonts impact performance:

Delayed text rendering: If a web font has not loaded, browsers typically delay text rendering. In many situations, this delays First Contentful Paint (FCP). In some situations, this delays Largest Contentful Paint (LCP).
Layout shifts: The practice of font swapping has the potential to cause layout shifts and so impact Cumulative Layout Shift (CLS). These layout shifts occur when a web font and its fallback font take up different amounts of space on the page.

This article is broken down into three sections: font loading, font delivery, and font rendering. Each section explains how that particular aspect of the font lifecycle works and provides corresponding best practices.

Font loading #

Fonts are typically important resources, as without them the user might be unable to view page content. Thus, best practices for font loading generally focus on making sure that fonts get loaded as early as possible. Particular care should be given to fonts loaded from third-party sites as downloading these font files requires separate connection setups.

If you're unsure if your page's fonts are being requested in time, check the Timing tab within the Network panel in Chrome DevTools for more information.

Understanding `@font-face` #

Before diving into best practices for font loading it's important to understand how @font-face works and how this impacts font loading.

The @font-face declaration is an essential part of working with any web font. At a minimum, it declares the name that will be used to refer to the font and indicates the location of the corresponding font file.

@font-face {
  font-family: "Open Sans";
  src: url("/fonts/OpenSans-Regular-webfont.woff2") format("woff2");
}

A common misconception is that a font is requested when a @font-face declaration is encountered—this is not true. By itself, @font-face declaration does not trigger font download. Rather, a font is downloaded only if it is referenced by styling that is used on the page. For example, like this:

@font-face {
  font-family: "Open Sans";
  src: url("/fonts/OpenSans-Regular-webfont.woff2") format("woff2");
}

h1 {
  font-family: "Open Sans"
}

In other words, in the example above, Open Sans would only be downloaded if the page contained a <h1> element.

Thus, when thinking about font optimization, it's important to give stylesheets just as much consideration as the font files themselves. Changing the contents or delivery of stylesheets can have a significant impact on when fonts arrive. Similarly, removing unused CSS and splitting stylesheets can reduce the number of fonts loaded by a page.

Inline font declarations #

Most sites would strongly benefit from inlining font declarations and other critical styling in the <head> of the main document rather than including them in an external stylesheet. This allows the browser to discover the font declarations sooner as the browser doesn't need to wait for the external stylesheet to download.

<head>
  <style>
    @font-face {
        font-family: "Open Sans";
        src: url("/fonts/OpenSans-Regular-webfont.woff2") format("woff2");
    }

    body {
        font-family: "Open Sans";
    }

    ...etc.

  </style>
</head>

Inlining critical CSS can be a more advanced technique that not all sites will be able to achieve. The performance benefits are clear, but it requires additional processes and build tools to ensure the necessarily CSS—and ideally only the critical CSS—is inlined correctly and that any additional CSS is delivered in a non-render blocking fashion.

Preconnect to critical third-party origins #

If your site loads fonts from a third-party site, it is highly recommended that you use the preconnect resource hint to establish early connection(s) with the third-party origin. Resource hints should be placed in the <head> of the document. The resource hint below sets up a connection for loading the font stylesheet.

<head>
  <link rel="preconnect" href="https://fonts.com">
</head>

To preconnect the connection that is used to download the font file, add a separate preconnect resource hint that uses the crossorigin attribute. Unlike stylesheets, font files must be sent over a CORS connection.

<head>
  <link rel="preconnect" href="https://fonts.com">
  <link rel="preconnect" href="https://fonts.com" crossorigin>
</head>

When using the preconnect resource hint, keep in mind that a font provider may serve stylesheets and fonts from separate origins. For example, this is how the preconnect resource hint would be used for Google Fonts.

<head>
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
</head>

Be cautious when using `preload` to load fonts #

Although preload is highly effective at making fonts discoverable early in the page load process, this comes at the cost of taking away browser resources from the loading of other resources.

Inlining font declarations and adjusting stylesheets may be a more effective approach. These adjustments come closer to addressing the root cause of late-discovered fonts—rather than just providing a workaround.

In addition, using preload as a font-loading strategy should also be used carefully as it bypasses some of the browser's built-in content negotiation strategies. For example, preload ignores unicode-range declarations, and if used prudently, should only be used to load a single font format.

However, when using external stylesheets, preloading the most important fonts can be very effective since the browser will not otherwise discover whether the font is needed until much later.

Font delivery #

Faster font delivery yields faster text rendering. In addition, if a font is delivered early enough, this can help eliminate layout shifts resulting from font swapping.

Using self-hosted fonts #

On paper, using a self-hosted font should deliver better performance as it eliminates a third-party connection setup. However, in practice, the performance differences between these two options is less clear cut: for example, the Web Almanac found that sites using third-party fonts had a faster render than fonts that used first-party fonts.

If you are considering using self-hosted fonts, confirm that your site is using a Content Delivery Network (CDN) and HTTP/2. Without use of these technologies, it is much less likely that self-hosted fonts will deliver better performance. For more information, see Content Delivery Networks.

If you use a self-hosted font, it is recommended that you also apply some of the font file optimizations that third-party font providers typically provide automatically—for example, font subsetting and WOFF2 compression. The amount of effort required to apply these optimizations will depend somewhat on the languages that your site supports. In particular, be aware that optimizing fonts for CJK languages can be particularly challenging.

Use WOFF2 #

Of the modern font fonts, WOFF2 is the newest, has the widest browser support, and offers the best compression. Because it uses Brotli, WOFF2 compresses 30% better than WOFF, leading to less data to download and therefore faster performance.

Given the browser support, experts now recommend only using WOFF2:

In fact, we think it is also time to proclaim: Use only WOFF2 and forget about everything else.

This will simplify your CSS and workflow massively and also prevents any accidental double or incorrect font downloads. WOFF2 is now supported everywhere. So, unless you need to support really ancient browsers, just use WOFF2. If you can't, consider not serving any web fonts to those older browsers at all. This will not be a problem if you have a robust fallback strategy in place. Visitors on older browsers will simply see your fallback fonts.
Bram Stein, from the 2022 Web Almanac

Subset fonts #

Font files typically include a large number of glyphs for all the various characters they support. But you may not need all the characters on your page and can reduce the size of font files by subsetting fonts.

The unicode-range descriptor in the @font-face declartion informs the browser which characters a font can be used for.

@font-face {
    font-family: "Open Sans";
    src: url("/fonts/OpenSans-Regular-webfont.woff2") format("woff2");
    unicode-range: U+0025-00FF;
}

A font file will be downloaded if the page contains one or more characters matching the unicode range. unicode-range is commonly used to serve different font files depending on the language used by page content.

unicode-range is often used in conjunction with the technique of subsetting. A subset font includes a smaller portion of the that were contained in the original font file. For example, rather than serve all characters to all users, a site might generate separate subset fonts for Latin and Cyrillic characters. The number of glyphs per font varies wildly: Latin fonts are usually on the magnitude of 100 to 1000 glyphs per font; CJK fonts may have over 10,000 characters. Removing unused glyphs can significantly reduce the filesize of a font.

Some font providers may provide different versions of fonts files with different subsets automatically. For example, Google Fonts does this by default:

/* devanagari */
@font-face {
  font-family: 'Poppins';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/poppins/v20/pxiEyp8kv8JHgFVrJJbecnFHGPezSQ.woff2) format('woff2');
  unicode-range: U+0900-097F, U+1CD0-1CF6, U+1CF8-1CF9, U+200C-200D, U+20A8, U+20B9, U+25CC, U+A830-A839, U+A8E0-A8FB;
}
/* latin-ext */
@font-face {
  font-family: 'Poppins';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/poppins/v20/pxiEyp8kv8JHgFVrJJnecnFHGPezSQ.woff2) format('woff2');
  unicode-range: U+0100-024F, U+0259, U+1E00-1EFF, U+2020, U+20A0-20AB, U+20AD-20CF, U+2113, U+2C60-2C7F, U+A720-A7FF;
}
/* latin */
@font-face {
  font-family: 'Poppins';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url(https://fonts.gstatic.com/s/poppins/v20/pxiEyp8kv8JHgFVrJJfecnFHGPc.woff2) format('woff2');
  unicode-range: U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}

When moving to self-hosting, this is an optimization that can easily be missed and lead to larger font files locally.

It is also possible to manually subset fonts if your font provider allows this, either through an API (Google Fonts supports this by providing a text parameter), or by manually editing the font files and then self-hosting. Tools for generating font subsets include subfont and glyphanger. However, do check the licence for the fonts you use allow subsetting and self-hosting.

Use fewer web fonts #

The fastest font to deliver is a font that isn't requested in the first place. System fonts and variable fonts are two ways to potentially reduce the number of web fonts used on your site.

A system font is the default font used by the user interface of a user's device. System fonts typically vary by operating system and version. Because the font is already installed, the font does not need to be downloaded. System fonts can work particularly well for body text.

To use the system font in your CSS, list system-ui as the font-family:

font-family: system-ui

The idea behind variable fonts is that a single variable font can be used as a replacement for multiple font files. Variable fonts work by defining a "default" font style and providing "axes" for manipulating the font. For example, a variable font with a Weight axis could be used to implement lettering that would previously require separate fonts for light, regular, bold, and extra bold.

Not everyone will benefit from switching to variable fonts. Variable fonts contain many styles, so typically have larger file sizes than individual non-variable fonts that only contain one style. Sites that will see the largest improvement from using variable fonts are those that use (and need to use) a variety of font styles and weights.

Font rendering #

When faced with a web font that has not yet loaded, the browser is faced with a dilemma: should it hold off on rendering text until the web font has arrived? Or should it render the text in a fallback font until the web font arrives?

Different browsers handle this scenario differently. By default, Chromium-based and Firefox browsers will block text rendering for up to 3 seconds if the associated web font has not loaded; Safari will block text rendering indefinitely.

This behavior can be configured by using the font-display attribute. This choice can have significant implications: font-display has the potential to impact LCP, FCP, and layout stability.

Choose an appropriate `font-display` strategy #

font-display informs the browser how it should proceed with text rendering when the associated web font has not loaded. It is defined per font-face.

@font-face {
  font-family: Roboto, Sans-Serif
  src: url(/fonts/roboto.woff) format('woff'),
  font-display: swap;
}

There are five possible values for font-display:

Value	Block period	Swap period
Auto	Varies by browser	Varies by browser
Block	2-3 seconds	Infinite
Swap	0ms	Infinite
Fallback	100ms	3 seconds
Optional	100ms	None

Block period: The block period begins when the browser requests a web font. During the block period, if the web font is not available, the font is rendered in an invisible fallback font and thus the text will not be visible to the user. If the font is not available at the end of the block period, it will be rendered in the fallback font.
Swap period: The swap period comes after the block period. If the web font becomes available during the swap period, it will be "swapped" in.

font-display strategies reflect different viewpoints about the tradeoff between performance and aesthetics. As such it's difficult to give a recommended approach as it does depend on individual preferences, how important the web font is to the page and brand, and how jarring a late-arriving font can be when swapped in.

For most sites, these are the three strategies that will be most applicable:

If performance is a top priority: Use font-display: optional. This is the most "performant" approach: text render is delayed for no longer than 100ms and there is assurance that there will be no font-swap related layout shifts. However, the downside here is the web font will not be used if it arrives late.
If displaying text quickly is a top priority, but you want to still ensure the web-font is used: Use font-display: swap but make sure to deliver the font early enough that it does not cause a layout shift. The downside of this option is the jarring shift when the font arrives late.
If ensuring text is displayed in a web font is a top priority: Use font-display: block but make sure to deliver the font early enough that it minimises the delay of the text. The downside of this is the initial text display will be delayed. Note despite this deplay, it can still cause a layout shift as the text is actually drawn invisible, and the fallback font space is therefore user to reserver the space. Once the web font loads, this may require difference space and hence a shift. This may, however, be a less jarring shift than font-display: swap as the text itself will not be seen to shift.

Also keep in mind that these two approaches can be combined: for example, use font-display: swap for branding and other visually distinctive page elements; use font-display: optional for fonts used in body text.

Reduce the shift between your fallback font and your webfont #

To reduce the CLS impact, you can use the new size-adjust attributes. For more information see this article. This is a very new addition to our toolset, so is more advanced and a bit manual at present. But definitely one to experiment with and watch for tooling improvements in the future!

Conclusion #

Web fonts still be a performance bottleneck but we have an ever-growing range of options to allow us to optimize them to reduce this bottleneck as much as possible.

Back/forward cache

2020-11-10T00:00:00Z

Back/forward cache (or bfcache) is a browser optimization that enables instant back and forward navigation. It significantly improves the browsing experience for users—especially those with slower networks or devices.

As web developers, it's critical to understand how to optimize your pages for bfcache across all browsers, so your users can reap the benefits.

Browser compatibility #

bfcache has been supported in both Firefox and Safari for many years, across desktop and mobile.

Starting in version 86, Chrome enabled bfcache for cross-site navigations on Android for a small percentage of users. In subsequent releases, additional support slowly rolled out. Since version 96, bfcache is enabled for all Chrome users across desktop and mobile.

bfcache basics #

bfcache is an in-memory cache that stores a complete snapshot of a page (including the JavaScript heap) as the user is navigating away. With the entire page in memory, the browser can quickly and easily restore it if the user decides to return.

How many times have you visited a website and clicked a link to go to another page, only to realize it's not what you wanted and click the back button? In that moment, bfcache can make a big difference in how fast the previous page loads:

Without bfcache enabled	A new request is initiated to load the previous page, and, depending on how well that page has been optimized for repeat visits, the browser might have to re-download, re-parse, and re-execute some (or all) of resources it just downloaded.
With bfcache enabled	Loading the previous page is essentially instant, because the entire page can be restored from memory, without having to go to the network at all

Check out this video of bfcache in action to understand the speed up it can bring to navigations:

In the video above, the example with bfcache is quite a bit faster than the example without it.

bfcache not only speeds up navigation, it also reduces data usage, since resources do not have to be downloaded again.

Chrome usage data shows that 1 in 10 navigations on desktop and 1 in 5 on mobile are either back or forward. With bfcache enabled, browsers could eliminate the data transfer and time spent loading for billions of web pages every single day!

How the "cache" works #

The "cache" used by bfcache is different from the HTTP cache (which is also useful in speeding up repeat navigations). The bfcache is a snapshot of the entire page in memory (including the JavaScript heap), whereas the HTTP cache contains only the responses for previously made requests. Since it's quite rare that all requests required to load a page can be fulfilled from the HTTP cache, repeat visits using bfcache restores are always faster than even the most well-optimized non-bfcache navigations.

Creating a snapshot of a page in memory, however, involves some complexity in terms of how best to preserve in-progress code. For example, how do you handle setTimeout() calls where the timeout is reached while the page is in the bfcache?

The answer is that browsers pause running any pending timers or unresolved promises—essentially all pending tasks in the JavaScript task queues—and resume processing tasks when (or if) the page is restored from the bfcache.

In some cases this is fairly low-risk (for example, timeouts or promises), but in other cases it might lead to very confusing or unexpected behavior. For example, if the browser pauses a task that's required as part of an IndexedDB transaction, it can affect other open tabs in the same origin (since the same IndexedDB databases can be accessed by multiple tabs simultaneously). As a result, browsers will generally not attempt to cache pages in the middle of an IndexedDB transaction or using APIs that might affect other pages.

For more details on how various API usage affects a page's bfcache eligibility, see Optimize your pages for bfcache below.

APIs to observe bfcache #

While bfcache is an optimization that browsers do automatically, it's still important for developers to know when it's happening so they can optimize their pages for it and adjust any metrics or performance measurement accordingly.

The primary events used to observe bfcache are the page transition events—pageshow and pagehide—which have been around as long as bfcache has and are supported in pretty much all browsers in use today.

The newer Page Lifecycle events—freeze and resume—are also dispatched when pages go in or out of the bfcache, as well as in some other situations. For example when a background tab gets frozen to minimize CPU usage. Note, the Page Lifecycle events are currently only supported in Chromium-based browsers.

Observe when a page is restored from bfcache #

The pageshow event fires right after the load event when the page is initially loading and any time the page is restored from bfcache. The pageshow event has a persisted property which will be true if the page was restored from bfcache (and false if not). You can use the persisted property to distinguish regular page loads from bfcache restores. For example:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('This page was restored from the bfcache.');
  } else {
    console.log('This page was loaded normally.');
  }
});

In browsers that support the Page Lifecycle API, the resume event will also fire when pages are restored from bfcache (immediately before the pageshow event), though it will also fire when a user revisits a frozen background tab. If you want to restore a page's state after it's frozen (which includes pages in the bfcache), you can use the resume event, but if you want to measure your site's bfcache hit rate, you'd need to use the pageshow event. In some cases, you might need to use both.

Observe when a page is entering bfcache #

The pagehide event is the counterpart to the pageshow event. The pageshow event fires when a page is either loaded normally or restored from the bfcache. The pagehide event fires when the page is either unloaded normally or when the browser attempts to put it into the bfcache.

The pagehide event also has a persisted property, and if it's false then you can be confident a page is not about to enter the bfcache. However, if the persisted property is true, it doesn't guarantee that a page will be cached. It means that the browser intends to cache the page, but there may be factors that make it impossible to cache.

window.addEventListener('pagehide', (event) => {
  if (event.persisted) {
    console.log('This page *might* be entering the bfcache.');
  } else {
    console.log('This page will unload normally and be discarded.');
  }
});

Similarly, the freeze event will fire immediately after the pagehide event (if the event's persisted property is true), but again that only means the browser intends to cache the page. It may still have to discard it for a number of reasons explained below.

Optimize your pages for bfcache #

Not all pages get stored in bfcache, and even when a page does get stored there, it won't stay there indefinitely. It's critical that developers understand what makes pages eligible (and ineligible) for bfcache to maximize their cache-hit rates.

The following sections outline the best practices to make it as likely as possible that the browser can cache your pages.

Never use the `unload` event #

The most important way to optimize for bfcache in all browsers is to never use the unload event. Ever!

The unload event is problematic for browsers because it predates bfcache and many pages on the internet operate under the (reasonable) assumption that a page will not continue to exist after the unload event has fired. This presents a challenge because many of those pages were also built with the assumption that the unload event would fire any time a user is navigating away, which is no longer true (and hasn't been true for a long time).

So browsers are faced with a dilemma, they have to choose between something that can improve the user experience—but might also risk breaking the page.

On desktop, Chrome and Firefox have chosen to make pages ineligible for bfcache if they add an unload listener, which is less risky but also disqualifies a lot of pages. Safari will attempt to cache some pages with an unload event listener, but to reduce potential breakage it will not run the unload event when a user is navigating away, which makes the event very unreliable.

On mobile, Chrome and Safari will attempt to cache pages with an unload event listener since the risk of breakage is lower due to the fact that the unload event has always been extremely unreliable on mobile. Firefox treats pages that use unload as ineligible for the bfcache, except on iOS, which requires all browsers to use the WebKit rendering engine, and so it behaves like Safari.

Instead of using the unload event, use the pagehide event. The pagehide event fires in all cases where the unload event currently fires, and it also fires when a page is put in the bfcache.

In fact, Lighthouse has a no-unload-listeners audit, which will warn developers if any JavaScript on their pages (including that from third-party libraries) adds an unload event listener.

Only add `beforeunload` listeners conditionally #

The beforeunload event will not make your pages ineligible for bfcache in Chrome or Safari, but it will make them ineligible in Firefox, so avoid using it unless absolutely necessary.

Unlike the unload event, however, there are legitimate uses for beforeunload. For example, when you want to warn the user that they have unsaved changes they'll lose if they leave the page. In this case, it's recommended that you only add beforeunload listeners when a user has unsaved changes and then remove them immediately after the unsaved changes are saved.

Don't

window.addEventListener('beforeunload', (event) => {
  if (pageHasUnsavedChanges()) {
    event.preventDefault();
    return event.returnValue = 'Are you sure you want to exit?';
  }
});

The code above adds a beforeunload listener unconditionally.

function beforeUnloadListener(event) {
  event.preventDefault();
  return event.returnValue = 'Are you sure you want to exit?';
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  window.addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  window.removeEventListener('beforeunload', beforeUnloadListener);
});

The code above only adds the beforeunload listener when it's needed (and removes it when it's not).

Minimize use of `Cache-Control: no-store` #

Cache-Control: no-store is an HTTP header web servers can set on responses that instructs the browser not to store the response in any HTTP cache. This should be used for resources containing sensitive user information, for example pages behind a login.

Though bfcache is not an HTTP cache, historically, when Cache-Control: no-store is set on the page resource itself (as opposed to any subresource), browsers have chosen not to store the page in bfcache. There is work currently underway to change this behavior for Chrome in a privacy-preserving manner, but at present any pages using Cache-Control: no-store will not be eligible for bfcache.

Since Cache-Control: no-store restricts a page's eligibility for bfcache, it should only be set on pages that contain sensitive information where caching of any sort is never appropriate.

For pages that wish to always serve up-to-date content—and that content does not contain sensitive information—use Cache-Control: no-cache or Cache-Control: max-age=0. These directives instruct the browser to revalidate the content before serving it, and they do not affect a page's bfcache eligibility.

Note that when a page is restored from bfcache, it is restored from memory, not from the HTTP cache. As a result, directives like Cache-Control: no-cache or Cache-Control: max-age=0 are not taken into account, and no revalidation occurs before the content is displayed to the user.

This is still likely a better user experience, however, as bfcache restores are instant and—since pages do not stay in the bfcache for very long—it's unlikely that the content is out of date. However, if your content does change minute-by-minute, you can fetch any updates using the pageshow event, as outlined in the next section.

Update stale or sensitive data after bfcache restore #

If your site keeps user state—especially any sensitive user information—that data needs to be updated or cleared after a page is restored from bfcache.

For example, if a user navigates to a checkout page and then updates their shopping cart, a back navigation could potentially expose out-of-date information if a stale page is restored from bfcache.

Another, more critical example is if a user signs out of a site on a public computer and the next user clicks the back button. This could potentially expose private data that the user assumed was cleared when they logged out.

To avoid situations like this, it's good to always update the page after a pageshow event if event.persisted is true.

The following code checks for the presence of a site-specific cookie in the pageshow event and reloads if the cookie is not found:

window.addEventListener('pageshow', (event) => {
  if (event.persisted && !document.cookie.match(/my-cookie/)) {
    // Force a reload if the user has logged out.
    location.reload();
  }
});

Avoid `window.opener` references #

In some browsers (including Chromium-based browsers) if a page was opened using window.open() or (in Chromium-based browsers prior to version 88) from a link with target=_blank—without specifying rel="noopener"—then the opening page will have a reference to the window object of the opened page.

In addition to being a security risk, a page with a non-null window.opener reference cannot safely be put into the bfcache because that could break any pages attempting to access it.

As a result, it's best to avoid creating window.opener references. You can do this by using rel="noopener" whenever possible. If your site requires opening a window and controlling it through window.postMessage() or directly referencing the window object, neither the opened window nor the opener will be eligible for the bfcache.

Always close open connections before the user navigates away #

As mentioned above, when a page is put into the bfcache all scheduled JavaScript tasks are paused and then resumed when the page is taken out of the cache.

If these scheduled JavaScript tasks are only accessing DOM APIs—or other APIs isolated to just the current page—then pausing these tasks while the page is not visible to the user is not going to cause any problems.

However, if these tasks are connected to APIs that are also accessible from other pages in the same origin (for example: IndexedDB, Web Locks, WebSockets, etc.) this can be problematic because pausing these tasks may prevent code in other tabs from running.

As a result, some browsers will not attempt to put a page in bfcache in the following scenarios:

Pages with an open IndexedDB connection
Pages with in-progress fetch() or XMLHttpRequest
Pages with an open WebSocket or WebRTC connection

If your page is using any of these APIs, it's best to always close connections and remove or disconnect observers during the pagehide or freeze event. That will allow the browser to safely cache the page without the risk of it affecting other open tabs.

Then, if the page is restored from the bfcache, you can re-open or re-connect to those APIs (in the pageshow or resume event).

The following example shows how to ensure your pages are eligible for bfcache when using IndexedDB by closing an open connection in the pagehide event listener:

let dbPromise;
function openDB() {
  if (!dbPromise) {
    dbPromise = new Promise((resolve, reject) => {
      const req = indexedDB.open('my-db', 1);
      req.onupgradeneeded = () => req.result.createObjectStore('keyval');
      req.onerror = () => reject(req.error);
      req.onsuccess = () => resolve(req.result);
    });
  }
  return dbPromise;
}

// Close the connection to the database when the user is leaving.
window.addEventListener('pagehide', () => {
  if (dbPromise) {
    dbPromise.then(db => db.close());
    dbPromise = null;
  }
});

// Open the connection when the page is loaded or restored from bfcache.
window.addEventListener('pageshow', () => openDB());

Test to ensure your pages are cacheable #

Chrome DevTools can help you test your pages to ensure they're optimized for bfcache, and identify any issues that may be preventing them from being eligible.

To test a particular page, navigate to it in Chrome and then in DevTools go to Application > Back-forward Cache. Next click the Run Test button and DevTools will attempt to navigate away and back to determine whether the page could be restored from bfcache.

If successful, the panel will report "Restored from back-forward cache":

If unsuccessful, the panel will indicate the page was not restored and list the reason why. If the reason is something you as a developer can address, that will also be indicated:

In the screenshot above, the use of an unload event listener is preventing the page from being eligible for bfcache. You can fix that by switching from unload to using pagehide instead:

Don't

window.addEventListener('unload', ...);

window.addEventListener('pagehide', ...);

Lighthouse 10.0 also added a bfcache audit, which performs a similar test to the one DevTools does, and also provides reasons why the page is ineligible if the audit fails. Take a look at the bfcache audit's docs for more information.

How bfcache affects analytics and performance measurement #

If you track visits to your site with an analytics tool, you will likely notice a decrease in the total number of pageviews reported as Chrome continues to enable bfcache for more users.

In fact, you're likely already underreporting pageviews from other browsers that implement bfcache since most of the popular analytics libraries do not track bfcache restores as new pageviews.

If you don't want your pageview counts to go down due to Chrome enabling bfcache, you can report bfcache restores as pageviews (recommended) by listening to the pageshow event and checking the persisted property.

The following example shows how to do this with Google Analytics; the logic should be similar for other analytics tools:

// Send a pageview when the page is first loaded.
gtag('event', 'page_view');

window.addEventListener('pageshow', (event) => {
  // Send another pageview if the page is restored from bfcache.
  if (event.persisted) {
    gtag('event', 'page_view');
  }
});

Measuring your bfcache hit ratio #

You may also wish to track whether the bfcache was used, to help identify pages that are not utilizing the bfcache. For example, with an event:

window.addEventListener('pageshow', (event) => {
  // You can measure bfcache hit rate by tracking all bfcache restores and
  // other back/forward navigations via a separate event.
  const navigationType = performance.getEntriesByType('navigation')[0].type;
  if (event.persisted || navigationType == 'back_forward' ) {
    gtag('event', 'back_forward_navigation', {
      'isBFCache': event.persisted,
    });
  }
});

It is important to realize that there are a number of scenarios, outside of the site owners control, when a Back/Forward navigation will not use the bfcache, including:

when the user quits the browser and starts it again
when the user duplicates a tab
when the user closes a tab and uncloses it

Even without those exclusions the bfcache will be discarded after a period to conserve memory.

So, website owners should not be expecting a 100% bfcache hit ratio for all back_forward navigations. However, measuring their ratio can be useful to identify pages where the page itself is preventing bfcache usage for a high proportion of back and forward navigations.

The Chrome team is working on a NotRestoredReasons API to help expose the reasons why the bfcache was not used to help developers understand the reasoning the cache was not used and if this is something they can work on to improve for their sites.

Performance measurement #

bfcache can also negatively affect performance metrics collected in the field, specifically metrics that measure page load times.

Since bfcache navigations restore an existing page rather than initiate a new page load, the total number of page loads collected will decrease when bfcache is enabled. What's critical, though, is that the page loads being replaced by bfcache restores would likely have been some of the fastest page loads in your dataset. This is because back and forward navigations, by definition, are repeat visits, and repeat page loads are generally faster than page loads from first time visitors (due to HTTP caching, as mentioned earlier).

The result is fewer fast page loads in your dataset, which will likely skew the distribution slower—despite the fact that the performance experienced by the user has probably improved!

There are a few ways to deal with this issue. One is to annotate all page load metrics with their respective navigation type: navigate, reload, back_forward, or prerender. This will allow you to continue to monitor your performance within these navigation types—even if the overall distribution skews negative. This approach is recommended for non-user-centric page load metrics like Time to First Byte (TTFB).

For user-centric metrics like the Core Web Vitals, a better option is to report a value that more accurately represents what the user experiences.

Impact on Core Web Vitals #

Core Web Vitals measure the user's experience of a web page across a variety of dimensions (loading speed, interactivity, visual stability), and since users experience bfcache restores as faster navigations than traditional page loads, it's important that the Core Web Vitals metrics reflect this. After all, a user doesn't care whether or not bfcache was enabled, they just care that the navigation was fast!

Tools like the Chrome User Experience Report, that collect and report on the Core Web Vitals metrics treat bfcache restores as separate page visits in their dataset.

And while there aren't (yet) dedicated web performance APIs for measuring these metrics after bfcache restores, their values can be approximated using existing web APIs.

For Largest Contentful Paint (LCP), you can use the delta between the pageshow event's timestamp and the timestamp of the next painted frame (since all elements in the frame will be painted at the same time). Note that in the case of a bfcache restore, LCP and FCP will be the same.
For First Input Delay (FID), you can re-add the event listeners (the same ones used by the FID polyfill) in the pageshow event, and report FID as the delay of the first input after the bfcache restore.
For Cumulative Layout Shift (CLS), you can continue to keep using your existing Performance Observer; all you have to do is reset the current CLS value to 0.

For more details on how bfcache affects each metric, refer to the individual Core Web Vitals metric guides pages. And for a specific example of how to implement bfcache versions of these metrics in code, refer to the PR adding them to the web-vitals JS library.

Additional Resources #

Firefox Caching (bfcache in Firefox)
Page Cache (bfcache in Safari)
Back/forward cache: web exposed behavior (bfcache differences across browsers)
bfcache tester (test how different APIs and events affect bfcache in browsers)
Performance Game Changer: Browser Back/Forward Cache (a case study from Smashing Magazine showing dramatic Core Web Vitals improvements by enabling bfcache)

Optimize Largest Contentful Paint

2020-05-05T00:00:00Z

Largest Contentful Paint (LCP) is one of the three Core Web Vitals metrics, and it represents how quickly the main content of a web page is loaded. Specifically, LCP measures the time from when the user initiates loading the page until the largest image or text block is rendered within the viewport.

To provide a good user experience, sites should strive to have an LCP of 2.5 seconds or less for at least 75% of page visits.

There are a number of factors that can affect how quickly the browser is able to load and render a web page, and delays across any of them can have a significant impact on LCP.

It's rare that a quick fix to a single part of a page will result in a meaningful improvement to LCP. To improve LCP you have to look at the entire loading process and make sure every step along the way is optimized.

Understanding your LCP metric #

Before optimizing LCP, developers should seek to understand if they even have an LCP issue, and the extent of any such issue.

LCP can be measured in a number of tools and not all of these measure LCP in the same way. To understand LCP of real users, we should look at what real users are experiencing, rather than what a lab-based tool like Lighthouse or local testing shows. These lab-based tools can give a wealth of information to explain and help you improve LCP, but be aware that lab tests alone may not be entirely representative of what your actual users experience.

LCP data based on real users can be surfaced from Real User Monitoring (RUM) tools installed on a site, or via the Chrome User Experience Report (CrUX) which collect anonymous data from real Chrome users for millions of websites.

Using PageSpeed Insights CrUX LCP data #

PageSpeed Insights provides access to CrUX data in the top section labeled Discover what your real users are experiencing. More detailed lab-based data is available in the bottom section labeled Diagnose performance issues. If CrUX data is available for your website, always concentrate on the real user data first.

PageSpeed Insights shows up to four different CrUX data:

Mobile data for This URL
Desktop data for This URL
Mobile data for the whole Origin
Desktop data for the whole Origin

These can be toggled in the controls at the top, and top right-hand side of this section. Be aware that where a URL does not have sufficient data to be shown at the URL level—but does have data for the origin—PageSpeed Insights will automatically show this.

The LCP for the whole origin may be very different to an individual page's LCP depending on how the LCP is loaded on that page compared to other pages on that origin. It can also be affected by how visitors navigate to these pages. Home pages tend to be visted by new users and so may often be loaded "cold", without any cached content and so are often the slowest pages on a website.

Looking at the four different categories of CrUX data can help you understand whether an LCP issue is specific to this page, or a more general site-wide issue. Similarly, it can show which device types have LCP issues.

Using PageSpeed Insights CrUX supplementary metrics #

Those looking to optimize LCP should also use the First Contentful Paint (FCP) and Time to First Byte (TTFB) timings, which are good diagnostic metrics that can provide valuable insights into LCP.

TTFB is the time when the visitor starting to navigate to a page (for example, clicking on a link), until the first bytes of the HTML document are received. A high TTFB can make achieving a 2.5 second LCP challenging, or even impossible.

A high TTFB can be due to mutiple server redirects, visitors located far away from the nearest site server, visitors on poor network conditions, or an inability to use cached content due to query parameters.

Once a page starts rendering, there may be an initial paint (for example, the background color), followed by some content appearing (for example, the site header). The appearance of the initial content is measured by FCP. The delta between FCP and other metrics can be very telling.

A large delta between TTFB and FCP could indicate that the browser needs to download a lot of render-blocking assets. It can also be a sign it must complete a lot of work to render any meaningful content—a classic sign of a site that relies heavily on client-side rendering.

A large delta between FCP and LCP indicates that the LCP resource is either not immediately available for the browser to prioritize (for example, text or images that are managed by JavaScript rather than being available in the initial HTML), or that the browser is completing other work before it can display the LCP content.

Using PageSpeed Insights Lighthouse data #

The Lighthouse section of PageSpeed Insights offers some guidance to improving LCP, but first you should check if the LCP given is broadly inline with real user data provided by CrUX.

If Lighthouse is showing no LCP issue, but the CrUX data is, then any Lighthouse suggestions may not be relevant. The opposite is also true—if Lighthouse is showing a really poor LCP time, but CrUX data is showing your users mostly have a good LCP, then you may wish to consider the priority of optimizing LCP further, or if time is better spent on other performance improvements. Also be sure to check that the CrUX data is for this page and not for the full origin as detailed above.

If both sources of data are showing an LCP that should be improved than the Lighthouse section can provide valuable guidance on ways to improve LCP. Use the LCP filter to only show audits relevant to LCP:

As well as the Opportunities to improve, there is Diagnostic information that may provide more information to help diagnose the issue. The Largest Contentful Paint element diagnostic shows a useful breakdown of the various timings that made up the LCP:

We will delve into these sub-parts next.

LCP breakdown #

Optimizing for LCP can be a more complex task when PageSpeed Insights does not give you the answer on how to improve this metric. With complex tasks it's generally better to break them down into smaller, more manageable tasks and address each separately. This guide will present a methodology for how to break down LCP into its most critical sub-parts and then present specific recommendations and best practices for how to optimize each part.

Most page loads typically include a number of network requests, but for the purposes of identifying opportunities to improve LCP, you should start by looking at just two:

The initial HTML document
The LCP resource (if applicable)

While other requests on the page can affect LCP, these two requests—specifically the times when the LCP resource begins and ends—reveal whether or not your page is optimized for LCP.

To identify the LCP resource, you can use developer tools (such as PageSpeed Insights discussed above, Chrome DevTools, or WebPageTest) to determine the LCP element. From there, you can match the URL (again, if applicable) loaded by the element on a network waterfall of all resources loaded by the page.

For example, the following visualization shows these resources highlighted on a network waterfall diagram from a typical page load, where the LCP element requires an image request to render.

For a well-optimized page, you want your LCP resource request to start loading as early as it can, and you want the LCP element to render as quickly as possible after the LCP resource finishes loading. To help visualize whether or not a particular page is following this principle, you can break down the total LCP time into the following sub-parts:

This table explains each of these LCP sub-parts in more detail:

* If the LCP element does not require a resource load to render (for example, if the element is a text node rendered with a system font), this time will be 0.
LCP sub-part	Description
Time to first byte (TTFB)	The time from when the user initiates loading the page until when the browser receives the first byte of the HTML document response. (See the TTFB metric doc for more details.)
Resource load delay	The delta between TTFB and when the browser starts loading the LCP resource. *
Resource load time	The time it takes to load the LCP resource itself. *
Element render delay	The delta between when the LCP resource finishes loading until the LCP element is fully rendered.

Every single page can have its LCP value broken down into these four sub-parts. There is no overlap or gap between them, and collectively they add up to the full LCP time.

When optimizing LCP, it's helpful to try to optimize these sub-parts individually. But it's also important to keep in mind that you need to optimize all of them. In some cases, an optimization applied to one part will not improve LCP, it will just shift the time saved to another part.

For example, in the earlier network waterfall, if you reduced the file size of our image by compressing it more or switching to a more optimal format (such as AVIF or WebP), that would reduce the resource load time, but it would not actually improve LCP because the time would just shift to the element render delay sub-part:

The reason this happens is because, on this page, the LCP element is hidden until the JavaScript code finishes loading, and then everything is revealed at once.

This example helps illustrate the point that you need to optimize all of these sub-parts in order to achieve the best LCP outcomes.

Optimal sub-part times #

In order to optimize each sub-part of LCP, it's important to understand what the ideal breakdown of these sub-parts is on a well-optimized page.

Of the four sub-parts, two have the word "delay" in their names. That is a clue that you want to get these times as close to zero as possible. The other two parts involve network requests, which by their very nature take time.

LCP sub-part	% of LCP
Time to first byte (TTFB)	~40%
Resource load delay	<10%
Resource load time	~40%
Element render delay	<10%
TOTAL	100%

Note that these time breakdowns are not strict rules, they're guidelines. If the LCP times on your pages are consistently within 2.5 seconds, then it doesn't really matter what the relative proportions are. But if you're spending a lot of unnecessary time in either of the "delay" portions, then it will be very difficult to constantly hit the 2.5 second target.

A good way to think about the breakdown of LCP time is:

The vast majority of the LCP time should be spent loading the HTML document and LCP source.
Any time before LCP where one of these two resources is not loading is an opportunity to improve.

How to optimize each part #

Now that you understand how each of the LCP sub-part times should break down on a well-optimized page, you can start optimizing your own pages.

The next four sections will present recommendations and best practices for how to optimize each part. They're presented in order, starting with the optimizations that are likely to have the biggest impact.

1. Eliminate resource load delay #

The goal in this step is to ensure the LCP resource starts loading as early as possible. While in theory the earliest a resource could start loading is immediately after TTFB, in practice there is always some delay before browsers actually start loading resources.

A good rule of thumb is that your LCP resource should start loading at the same time as the first resource loaded by that page. Or, to put that another way, if the LCP resource starts loading later than the first resource, then there's opportunity for improvement.

Generally speaking, there are two factors that affect how quickly an LCP resource can be loading:

When the resource is discovered.
What priority the resource is given.

Optimize when the resource is discovered #

To ensure your LCP resource starts loading as early as possible, it's critical that the resource is discoverable in the initial HTML document response by the browser's preload scanner. For example, in the following cases, the browser can discover the LCP resource by scanning the HTML document response:

The LCP element is an <img> element, and its src or srcset attributes are present in the initial HTML markup.
The LCP element requires a CSS background image, but that image is preloaded via <link rel="preload"> in the HTML markup (or via a Link header).
The LCP element is a text node that requires a web font to render, and the font is loaded via <link rel="preload"> in the HTML markup (or via a Link header).

Here are some examples where the LCP resource cannot be discovered from scanning the HTML document response:

The LCP element is an <img> that is dynamically added to the page via JavaScript.
The LCP element is lazily loaded with a JavaScript library that hides its src or srcset attributes (often as data-src or data-srcset).
The LCP element requires a CSS background image.

In each of these cases, the browser needs to run the script or apply the stylesheet—which usually involves waiting for network requests to finish—before it can discover the LCP resource and could start loading it. This is never optimal.

To eliminate unnecessary resource load delay, your LCP resource should always be discoverable from the HTML source. In cases where the resource is only referenced from an external CSS or JavaScript file, then the LCP resource should be preloaded, with a high fetch priority (more on fetch priority in the next section); for example:

<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">

<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">

Optimize the priority the resource is given #

Even if the LCP resource is discoverable from the HTML markup, it still may not start loading as early as the first resource. This can happen if the browser preload scanner's priority heuristics do not recognize that the resource is important, or if it determines that other resources are more important.

For example, you can delay your LCP image via HTML if you set loading="lazy" on your <img> element. Using lazy loading means that the resource will not be loaded until after layout confirms the image is in the viewport and so may begin loading later than it otherwise would.

Even without lazy loading, images are not initially loaded with the highest priority by browsers as they are not render-blocking resources. You can hint to the browser as to which resources are most important via the fetchpriority attribute for resources that could benefit from a higher priority:

<img fetchpriority="high" src="/path/to/hero-image.webp">

It's a good idea to set fetchpriority="high" on an <img> element if you think it's likely to be your page's LCP element—but limit this to just one or two images (based on common desktop and mobile viewport sizes), otherwise the signal becomes meaningless. You can also lower the priority of images that may be early in the document response, but isn't visible due to styling, such as images in carousel slides that are not visible at startup:

<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">

Deprioritizing certain resources can afford more bandwidth to resources that need it more—but be careful. Always check resource priority in DevTools and test changes with lab and field tools.

After you have optimized your LCP resource priority and discovery time, your network waterfall should look like this (with the LCP resource starting at the same time as the first resource):

2. Eliminate element render delay #

The goal in this step is to ensure the LCP element can render immediately after its resource has finished loading, no matter when that happens.

The primary reason the LCP element wouldn't be able to render immediately after its resource finishes loading is if rendering is blocked for some other reason:

Rendering of the entire page is blocked due to stylesheets or synchronous scripts in the <head> that are still loading.
The LCP resource has finished loading, but the LCP element has not yet been added to the DOM (it's waiting for some JavaScript code to load).
The element is being hidden by some other code, such as an A/B testing library that's still determining what experiment the user should be in.
The main thread is blocked due to long tasks, and rendering work needs to wait until those long tasks complete.

The following sections explain how to address the most common causes of unnecessary element render delay.

Reduce or inline render-blocking stylesheets #

Stylesheets loaded from the HTML markup will block rendering of all content that follows them, which is good, since you generally do not want to render unstyled HTML. However, if the stylesheet is so large that it takes significantly longer to load than the LCP resource, then it will prevent the LCP element from rendering—even after its resource has finished loading, as shown in this example:

To fix this, your options are to either:

inline the stylesheet into the HTML to avoid the additional network request; or,
reduce the size of the stylesheet.

In general, inlining your stylesheet is only recommended if your stylesheet is small since inlined content in the HTML cannot benefit from caching in subsequent page loads. If a stylesheet is so large that it takes longer to load than the LCP resource, then it's unlikely to be a good candidate for inlining.

In most cases, the best way to ensure the stylesheet does not block rendering of the LCP element is to reduce its size so that it's smaller than the LCP resource. This should ensure it's not a bottleneck for most visits.

Some recommendations to reduce the size of the stylesheet are:

Remove unused CSS: use Chrome DevTools to find CSS rules that aren't being used and can potentially be removed (or deferred).
Defer non-critical CSS: split your stylesheet out into styles that are required for initial page load and then styles that can be loaded lazily.
Minify and compress CSS: for styles that are critical, make sure you're reducing their transfer size as much as possible.

Defer or inline render-blocking JavaScript #

It is almost never necessary to add synchronous scripts (scripts without the async or defer attributes) to the <head> of your pages, and doing so will almost always have a negative impact on performance.

In cases where JavaScript code needs to run as early as possible in the page load, it's best to inline it so rendering isn't delayed waiting on another network request. As with stylesheets, though, you should only inline scripts if they're very small.

Don't

<head>
  <script src="/path/to/main.js"></script>
</head>

<head>
  <script>
    // Inline script contents directly in the HTML.
    // IMPORTANT: only do this for very small scripts.
  </script>
</head>

Use server-side rendering #

Server-side rendering (SSR) is the process of running your client-side application logic on the server and responding to HTML document requests with the full HTML markup.

From the perspective of optimizing LCP, there are two primary advantage of SSR:

Your image resources will be discoverable from the HTML source (as discussed in step 1 earlier).
Your page content will not require additional JavaScript requests to finish before it can render.

The main downside of SSR is it requires additional server processing time, which can slow down your TTFB. This trade-off is usually worth it though because server processing times are within your control, whereas the network and device capabilities of your users are not.

A similar option to SSR is called static site generation (SSG) or prerendering. This is the process of generating your HTML pages in a build step rather than on-demand. If prerendering is possible with your architecture, it's generally a better choice for performance.

Break up long tasks #

Even if you've followed the above advice, and your JavaScript code is not render-blocking nor is it responsible for rendering your elements, it can still delay LCP.

The most common reason this happens is when pages load large JavaScript files, which need to be parsed and executed on the browser's main thread. This means that, even if your image resource is fully downloaded, it may still have to wait until an unrelated script finishes executing before it can render.

All browsers today render images on the main thread, which means anything that blocks the main thread can also lead to unnecessary element render delay.

3. Reduce resource load time #

The goal of this step is to reduce the time spent transferring the bytes of the resource over the network to the user's device. In general, there are three ways to do that:

Reduce the size of the resource.
Reduce the distance the resource has to travel.
Reduce contention for network bandwidth.
Eliminate the network time entirely.

Reduce the size of the resource #

The LCP resource of a page (if it has one) will either be an image or a web font. The following guides go into great detail about how to reduce the size of both:

Reduce the distance the resource has to travel #

In addition to reducing the size of a resource, you can also reduce the load times by getting your servers as geographically close to your users as possible. And the best way to do that is to use a content delivery network (CDN).

In fact, image CDNs in particular are a great choice because they not only reduce the distance the resource has to travel, but they also generally reduce the size of the resource—automatically implementing all of the size-reduction recommendations from earlier for you.

Reduce contention for network bandwidth #

Even if you've reduced the size of your resource and the distance it has to travel, a resource can still take a long time to load if you're loading many other resources at the same time. This problem is known as network contention.

If you've given your LCP resource a high fetchpriority and started loading it as soon as possible then the browser will do its best to prevent lower-priority resources from competing with it. However, if you're loading many resources with high fetchpriority, or if you're just loading a lot of resources in general, then it could affect how quickly the LCP resource loads.

Eliminate the network time entirely #

The best way to reduce resource load times is to eliminate the network entirely from the process. If you serve your resources with an efficient cache-control policy, then visitors who request those resources a second time will have them served from the cache—bringing the resource load time to essentially zero!

And if your LCP resource is a web font, in addition to reducing web font size, you should also consider whether you need to block rendering on the web font resource load. If you set a font-display value of anything other than auto or block, then text will always be visible during load, and LCP will not be blocked on an additional network request.

Finally, if your LCP resource is small, it may make sense to inline the resources as a data URL, which will also eliminate the additional network request. However, using data URLs comes with caveats because then the resources cannot be cached and in some cases can lead to longer render delays because of the additional decode cost.

4. Reduce time to first byte #

The goal of this step is to deliver the initial HTML as quickly as possible. This step is listed last because it's often the one developers have the least control over. However, it's also one of the most important steps because it directly affects every step that comes after it. Nothing can happen on the frontend until the backend delivers that first byte of content, so anything you can do to speed up your TTFB will improve every other load metric as well.

A common cause of a slow TTFB for an otherwise fast site is making visitors wade through several redirects before finally arriving at the final URL. This can happen when you have visitors from advertisements, or via URL shorteners. Always try to minimize the number of redirects a visitor must wait through.

Another common cause is when cached content cannot be used from a CDN edge server, and all requests must be directed all the way back to the origin server. This can happen if unique URL parameters are used by visitors for analytics—even if they do not result in different pages.

For specific guidance on this topic, see Optimize TTFB.

Monitor LCP breakdown in JavaScript #

The timing information for all of the LCP sub-parts discussed above is available to you in JavaScript through a combination of the following performance APIs:

The benefit to computing these timing values in JavaScript is it allows you to send them to an analytics provider or log them to your developer tools to help with debugging and optimizing.

For example, the following screenshot uses the performance.measure() method from the User Timing API to add bars to the Timings track in the Chrome DevTools Performance panel.

Visualizations in the timings track are particularly helpful when looked at alongside the Network and Main thread tracks, because you can see at a glance what else is happening on the page during these timespans.

In addition to visualizing the LCP sub-parts in the timings track, you can also use JavaScript to compute what percentage each sub-part is of the total LCP time. With that information, you can determine whether your pages are meeting the recommended percentage breakdowns described earlier.

This screenshot shows an example that logs the total time of each LCP sub-part, as well as its percentage of the total LCP time to the console.

Both of these visualizations were created with the following code:

const LCP_SUB_PARTS = [
  'Time to first byte',
  'Resource load delay',
  'Resource load time',
  'Element render delay',
];

new PerformanceObserver((list) => {
  const lcpEntry = list.getEntries().at(-1);
  const navEntry = performance.getEntriesByType('navigation')[0];
  const lcpResEntry = performance
    .getEntriesByType('resource')
    .filter((e) => e.name === lcpEntry.url)[0];

  // Ignore LCP entries that aren't images to reduce DevTools noise.
  // Comment this line out if you want to include text entries.
  if (!lcpEntry.url) return;

  // Compute the start and end times of each LCP sub-part.
  // WARNING! If your LCP resource is loaded cross-origin, make sure to add
  // the `Timing-Allow-Origin` (TAO) header to get the most accurate results.
  const ttfb = navEntry.responseStart;
  const lcpRequestStart = Math.max(
    ttfb,
    // Prefer `requestStart` (if TOA is set), otherwise use `startTime`.
    lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0
  );
  const lcpResponseEnd = Math.max(
    lcpRequestStart,
    lcpResEntry ? lcpResEntry.responseEnd : 0
  );
  const lcpRenderTime = Math.max(
    lcpResponseEnd,
    // Use LCP startTime (which is the final LCP time) as sometimes
    // slight differences between loadTime/renderTime and startTime
    // due to rounding precision.
    lcpEntry ? lcpEntry.startTime : 0
  );

  // Clear previous measures before making new ones.
  // Note: due to a bug this does not work in Chrome DevTools.
  LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part));

  // Create measures for each LCP sub-part for easier
  // visualization in the Chrome DevTools Performance panel.
  const lcpSubPartMeasures = [
    performance.measure(LCP_SUB_PARTS[0], {
      start: 0,
      end: ttfb,
    }),
    performance.measure(LCP_SUB_PARTS[1], {
      start: ttfb,
      end: lcpRequestStart,
    }),
    performance.measure(LCP_SUB_PARTS[2], {
      start: lcpRequestStart,
      end: lcpResponseEnd,
    }),
    performance.measure(LCP_SUB_PARTS[3], {
      start: lcpResponseEnd,
      end: lcpRenderTime,
    }),
  ];

  // Log helpful debug information to the console.
  console.log('LCP value: ', lcpRenderTime);
  console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
  console.table(
    lcpSubPartMeasures.map((measure) => ({
      'LCP sub-part': measure.name,
      'Time (ms)': measure.duration,
      '% of LCP': `${
        Math.round((1000 * measure.duration) / lcpRenderTime) / 10
      }%`,
    }))
  );
}).observe({type: 'largest-contentful-paint', buffered: true});

You can use this code as-is for local debugging, or modify it to send this data to an analytics provider so you can get a better understanding of what the breakdown of LCP is on your pages for real users.

Monitor LCP breakdown via the Web Vitals extension #

The Web Vitals extension will log the LCP time, LCP element, and these four sub-parts in the console logging, to easily allow you to see this breakdown.

Summary #

LCP is complex, and its timing can be affected by a number of factors. But if you consider that optimizing LCP is primarily about optimizing the load of the LCP resource, it can significantly simplify things.

At a high level, optimizing LCP can be summarized in four steps:

Ensure the LCP resource starts loading as early as possible.
Ensure the LCP element can render as soon as its resource finishes loading.
Reduce the load time of the LCP resource as much as you can without sacrificing quality.
Deliver the initial HTML document as fast as possible.

If you’re able to follow these steps on your pages, then you should feel confident that you’re delivering an optimal loading experience to your users, and you should see that reflected in your real-world LCP scores.

Optimize Cumulative Layout Shift

2020-05-05T00:00:00Z

"I was about to click that! Why did it move? 😭"

Cumulative Layout Shift (CLS) is one of the three Core Web Vitals metrics, and it measures the instability of content by summing shift scores across layout shifts that don't occur within 500 milliseconds of user input. It looks at how much visible content shifted in the viewport as well as the distance the elements impacted were shifted.

Layout shifts can be distracting to users. Imagine you've started reading an article when all of a sudden elements shift around the page, throwing you off and requiring you to find your place again. This is very common on the web, including when reading the news, or trying to click those 'Search' or 'Add to Cart' buttons. Such experiences are visually jarring and frustrating. They're often caused when visible elements are forced to move because another element was suddenly added to the page or resized.

To provide a good user experience, sites should strive to have a CLS of 0.1 or less for at least 75% of page visits.

Unlike the other Core Web Vitals, which are time-based values measured in seconds or milliseconds, the CLS score is a unitless value based on a calculation of how much content is shifting and by how far.

In this guide, we'll cover optimizing common causes of layout shifts.

The most common causes of a poor CLS are:

Images without dimensions
Ads, embeds, and iframes without dimensions
Dynamically injected content such as ads, embeds, and iframes without dimensions
Web fonts

Understanding where your shifts are coming from #

Before we start looking at solutions to common CLS issues, it's always important to understand your CLS score and where the shifts are coming from. A big part of the problem is understanding your CLS score—the fix afterwards is often the easier part!

CLS in lab tools versus field #

It is quite common to hear developers think the CLS measured by the Chrome UX Report (CrUX) is incorrect as it does not match the CLS they measure using Chrome DevTools or other lab tools. Web performance lab tools like Lighthouse may not show the full CLS of a page as they typically do a simple load of the page to measure some web performance metrics and provide some guidance (though Lighthouse user flows do allow you measure beyond the default page load audit).

CrUX is the official dataset of the Web Vitals program, and for that, CLS is measured throughout the full life of the page and not just during the initial page load that lab tools typically measure.

Layout shifts are very common during page load, as all the necessary resources are fetched to initially render the page, but layout shifts can also happen after the initial load. Many post-load shifts may occur as the result of a user interaction and therefore will be excluded from the CLS score as they are expected shifts—as long as they occur within 500 milliseconds of that interaction.

However, other post-load shifts that are unexpected by the user may be included where there was no qualifying interaction—for example, if you scroll down the page and lazy-loaded content is loaded and that causes shifts. Other common causes of post-load CLS are on interactions of transitions, for example on Single Page Apps, which take longer than the 500 millisecond grace period.

PageSpeed Insights will show both the user-perceived CLS from a URL where it exists in the "Discover what your real users are experiencing" section, and also the lab-based load CLS in the "Diagnose performance issues" section beneath. If you see a difference between these, this is likely caused by post-load CLS.

Identifying load CLS issues #

When the CrUX and Lighthouse CLS scores of PageSpeed Insights are broadly in line, this usually indicates there is a load CLS issue that was detected by Lighthouse. In this case Lighthouse will help with two audits to provide more information on images causing CLS due to missing width and height, and also list all the elements that shifted for the page load along with their CLS contribution. You can see these audits by filtering on the CLS audits:

The Performance panel in DevTools also highlights layout shifts in the Experience section. The Summary view for a Layout Shift record includes the cumulative layout shift score as well as a rectangle overlay showing the affected regions. This is particularly helpful to get more detail on load CLS issues since this is easily replicated with a reload performance profile.

After recording a new trace in the Performance panel, the Experience section of the results is populated with a red-tinted bar displaying a Layout Shift record. Clicking the record allows you to drill down into impacted elements (e.g. note the moved from/to entries).

Identifying post-load CLS issues #

When the CrUX and Lighthouse CLS scores of PageSpeed Insights are not in line, then this likely indicates post-load CLS. Without field data helping to identify the reason (that we will cover next), these can be more tricky to track down.

The Web Vitals Chrome extension can be used to monitor CLS as you interact with a page, either in a heads up display, or in the console—where you can get more details above the elements shifted.

As an alternative to using the extension, you can browse your web page while recording layout shifts using a Performance Observer pasted into the console.

Once you are monitoring shifts you can try to replicate any post-load CLS issues. Scolling down a page is a common place for CLS to occur if content is lazy loaded and does not have space reserved for it. Content shifting on hover is another common post-load CLS cause. Both of these "interactions" are ineligible for the 500 milliseconds grace period as CLS during these periods are seen as being "unexpected shifts", despite the user interaction, as they should not cause content to shift. Other interactions—such as clicks or taps—do have that grace period, but a common reason for CLS in these cases is taking longer than that 500 milliseconds to move or add content.

We have a more detailed posted on debugging layout shifts for more information.

Once you have identified any common causes of CLS, the timespans user flow mode of Lighthouse can also be used to ensure typical user flows do not regress by introducing layout shifts.

Measuring CLS elements in the field #

It is also recommended to monitor CLS in the field. This can be used to measure both the CLS and—perhaps more importantly—the elements impacting your CLS score in the field and feed them back to your analytics service.

This can be invaluable in pointing you in the right direction of where the issue is as it can remove much of the guess work discribed above when you are trying to understand under what circumstances CLS is occuring. Again, be aware that this will measure the elements that shifted, rather than the root causes of those shifts, but this is often sufficient to identify the cause or at least to narrow down the problem.

Measuring CLS in the field can also be used to rank the issues in order of importance based on most frequently experienced issues.

The attribution functionality of the web-vitals library allows this additional information to be collected. Read our Debug performance in the field post for more information on how to do this. Other RUM providers have also started collecting and presenting this data similarly.

Common causes of CLS #

Once you have identified the causes of CLS, you can start working on fixing the issues. In this section we will show some of the more common reasons for CLS, and what you can do to avoid them.

Images without dimensions #

Always include width and height size attributes on your images and video elements. Alternatively, reserve the required space with CSS aspect-ratio or similar. This approach ensures that the browser can allocate the correct amount of space in the document while the image is loading.

Images without width and height specified.

Images with width and height specified.

Lighthouse 6.0 impact of setting image dimensions on CLS.

History of `width` and `height` attributes on images #

In the early days of the web, developers would add width and height attributes to their <img> tags to ensure sufficient space was allocated on the page before the browser started fetching images. This would minimize reflow and re-layout.

<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

You may notice width and height above do not include units. These "pixel" dimensions would ensure a 640x360 area would be reserved. The image would stretch to fit this space, regardless of whether the true dimensions matched or not.

When Responsive Web Design was introduced, developers began to omit width and height and started using CSS to resize images instead:

img {
  width: 100%; /* or max-width: 100%; */
  height: auto;
}

A downside to this approach is space could only be allocated for an image once it began to download and the browser could determine its dimensions. As images loaded in, the page would reflow as each image appeared on screen. It became common for text to suddenly pop down the screen. This wasn't a great user experience at all.

This is where aspect ratio comes in. The aspect ratio of an image is the ratio of its width to its height. It's common to see this expressed as two numbers separated by a colon (for example 16:9 or 4:3). For an x:y aspect ratio, the image is x units wide and y units high.

This means if we know one of the dimensions, the other can be determined. For a 16:9 aspect ratio:

If puppy.jpg has a 360px height, width is 360 x (16 / 9) = 640px
If puppy.jpg has a 640px width, height is 640 x (9 / 16) = 360px

Knowing the aspect ratio allows the browser to calculate and reserve sufficient space for the height and associated area.

Modern best practice for setting image dimensions #

Modern browsers now set the default aspect ratio of images based on an image's width and height attributes so developers just need to set these, and include the above CSS, to prevent layout shifts:

<!-- set a 640:360 i.e a 16:9 aspect ratio -->
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">

All browsers will then add a default aspect ratio based on the element's existing width and height attributes.

This calculates an aspect ratio based on the width and height attributes before the image has loaded. It provides this information at the very start of layout calculation. As soon as an image is told to be a certain width (for example width: 100%), the aspect ratio is used to calculate the height.

This aspect-ratio value is calculated by major browsers as the HTML is processed, rather than with a default User Agent stylesheet (see this post for a deep dive into why), so the value is displayed a little differently. For example, Chrome displays it like this in the Styles section of the Element panel:

img[Attributes Style] {
  aspect-ratio: auto 640 / 360;
}

Safari behaves similarly by using a HTML Attributes style source. Firefox does not currently display this calculated aspect-ratio at all in it's Inspector panel, but does use it for layout.

The auto part of the above code is important as it causes the 640 / 360 to be overriden with the image dimensions once the image is downloaded. If the image dimensions are different this will still cause some layout shift after the image loads, but this ensures the image aspect ratio is still used ultimately when it becomes available—as it was in the past—in case the HTML is incorrect. Plus, the shift is likely to be a lot smaller than the 0x0 default image size when dimensions are not provided!

Tip: If you're having a hard time understanding aspect ratio, a handy calculator is available to help.

For a fantastic deep-dive into aspect ratio with further thinking around responsive images, see jank-free page loading with media aspect ratios.

If your image is in a container, you can use CSS to resize the image to the width of this container. We set height: auto; to avoid the image height being a fixed value (for example 360px).

img {
  height: auto;
  width: 100%;
}

What about responsive images? #

When working with responsive images, srcset defines the images you allow the browser to select between and what size each image is. To ensure <img> width and height attributes can be set, each image should use the same aspect ratio.

<img
  width="1000"
  height="1000"
  src="puppy-1000.jpg"
  srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"
  alt="Puppy with balloons"
/>

What about art direction?

Pages may wish to include a cropped shot of an image on narrow viewports with the full image displayed on desktop.

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" />
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" />
  <img src="puppy-800w.jpg" alt="Puppy with balloons" />
</picture>

It's very possible these images could have different aspect ratios. Chrome, Firefox, and Safari now support setting width and height on the source children of the picture element:

<picture>
  <source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" width=480 height=400/>
  <source media="(min-width: 800px)" srcset="puppy-800w.jpg" width=800 height=400/>
  <img src="puppy-800w.jpg" alt="Puppy with balloons" width=800 height=400/>
</picture>

Ads, embeds, and other late-loaded content #

As we have seen, images have special considerations. However, images are not the only type of content that can cause layout shifts. Ads, embeds, iframes, and other dynamically injected content can all cause content after these to shift down, increasing your CLS.

Ads are one of the largest contributors to layout shifts on the web. Ad networks and publishers often support dynamic ad sizes. Ad sizes increase performance/revenue due to higher click rates and more ads competing in the auction. Unfortunately, this can lead to a suboptimal user experience due to ads pushing visible content you're viewing down the page.

Embeddable widgets allow you to include portable web content in your page, such as videos from YouTube, maps from Google Maps, and social media posts. These widgets often aren't aware in advance just how large their contents will be. For example, in the case of a social media post, it might have an embedded image, video, multiple rows of text, or a number of other unpredictable factors. As a result, platforms offering embeds do not always reserve space for their widgets and so cause layout shifts when they finally load.

The techniques for dealing with these are all similar. The major differences are how much control you have over the content that will be inserted. If this is inserted by a third-party like an ad partner, you may not know the exact size of content that will be inserted, nor be able to control any layout shifts happening within those embeds.

Statically reserve space for late-loading content #

When placing late-loading content in the content flow, layout shifts can be avoided by reserving the space for them in the initial layout.

This can be as simple as adding a min-height styling to reserve space or, for responsive content such as ads, using the new aspect-ratio CSS property in a similar manner to the way browsers automatically use this for images with dimensions provided.

Reserving space for ads can prevent layout shifts

You may need to account for subtle differences in ad or placeholder sizes across form factors using media queries.

For content that may not have a fixed height—like ads—you may not be able to reserve the exact amount of space needed to eliminate the layout shift entirely. If a smaller ad is served, a publisher can style the (larger) container to avoid layout shifts, or choose the most likely size for the ad slot based on historical data. The downside to this approach is that it will increase the amount of blank space, so keep in mind the trade-off here.

Alternatively, set the initial size to the smallest size that will be used, and accept some level of shift for larger content. Using min-height, as suggested above, will allow the parent element to grow as necessary. This will not fully eliminate CLS, but will hopefully reduce the impact of it to a more managable level. The default size of an empty element is 0px which gives maximum CLS, so any size is better than that!

Try to avoid collapsing the reserved space if, for example, there is no ad returned, by showing a placeholder. Removing the space set aside for elements can cause just as much CLS as inserting content!

Avoid placing late-loading content near the top of the viewport #

Dynamically injected content near the top of the viewport may cause a greater layout shift than those at the middle. This is because elements inserted at the top generally have more content lower down, meaning more elements move when the late-loading content causes a shift.

Conversely, dynamically injected content near the middle of the viewport may not shift as many elements as the content above it is less likely to move, but will still cause some CLS. Even content injected at the bottom of the screen will cause CLS as the content it replace is moved off-screen.

The ideal scenario is not to shift any other content so reserving the appropriate space is preferred. Where this is not possible, minimizing the shifts can at least reduce the impact—both to your users and your CLS scores.

Avoid inserting new content without a user interaction #

You've probably experienced layout shifts due to UI that pops-in at the top or bottom of the viewport when you're trying to load a site. Similar to ads, this often happens with banners and forms that shift the rest of the page's content:

"Sign-up to our newsletter!" (whoa, slow down! we just met!)
"Related content"
"Install our [iOS/Android] app"
"We're still taking orders"
"GDPR notice"

Dynamic content without space reserved.

If you need to display these types of UI affordances, reserve sufficient space in the viewport for it in advance (for example, using a placeholder or skeleton UI) so that when it loads, it does not cause content in the page to surprisingly shift around. Alternatively, ensure the element is not part of the document flow by overlaying the content where this makes sense. See the Best practices for cookie notices post for more recommendations on these types of components.

In some cases adding content dynamically is an important part of user experience. For example, when loading more products to a list of items or when updating live feed content. There are several ways to avoid unexpected layout shifts in those cases:

Replace the old content with the new content within a fixed size container or use a carousel and remove the old content after the transition. Remember to disable any links and controls until the transition has completed to prevent accidental clicks or taps while the new content is coming in.
Have the user initiate the load of new content, so they are not surprised by the shift (for example with a "Load more" or "Refresh" button). It's recommended to prefetch the content before the user interaction so that it shows up immediately. As a reminder, layout shifts that occur within 500 milliseconds of user input are not counted towards CLS.
Seamlessly load the content offscreen and overlay a notice to the user that it's available (for example, with a "Scroll up" button).

Examples of dynamic content loading without causing unexpected layout shifts. Left: Live feed content loading on Twitter. Right: "Load More" example on Chloé website. Check out how the YNAP team optimized for CLS when loading more content.

Animations #

Changes to CSS property values can require the browser to react to these changes. A number of values trigger re-layout, paint, and composite such as box-shadow and box-sizing. Try to avoid animating these.

A number of CSS properties can be changed in a much more performant manner. For example, transform animations can be used to translate, scale, rotate, or skew without triggering a re-layout and so completely avoiding layout shifts.

When animations are instead done by changing top and left CSS properties instead of using translate, layout shifts occur. This happens even when the element being moved is in it's own layer and so does not cause shifts to other elements. Composited animations via translate are exempt from CLS as they cannot impact other elements. There are also other considerable performance benefits of using non-composited animations since they do no cause re-layout and therefore are much less work for the browser.

To learn more about what CSS properties trigger layout see High-performance animations.

Web fonts #

Downloading and rendering web fonts is typically handled in one of two ways before the web font is downloaded:

The fallback font is swapped with the web font (FOUT—flash of unstyled text)
"Invisible" text is displayed using the fallback font until a web font is available and the text is made visible (FOIT—flash of invisible text)

It is important to understand that both of these can cause layout shifts. Even though the text is invisible, it is laid out using the fallback font. This means the text block using the font, and the surrounding content, shifts when the web font loads—in the exact same way as for the visible font for FOUT.

The following tools can help you minimize this:

font-display: optional can avoid a re-layout as the web font is only used if it is available by the time of initial layout.
Ensure the appropriate fallback font is used. For example, using font-family: "Google Sans", sans-serif; will ensure the browser's sans-serif fallback font is used while "Google Sans" is loaded. Not specifying a fallback font using just font-family: "Google Sans" will mean the default font is used, which on Chrome is "Times"—a serif font which is a worse match than the default sans-serif font.
Minimize the size differences between the fallback font and the web font using the new size-adjust, ascent-override, descent-override, and line-gap-override APIs as detailed in the Improved font fallbacks post.
The Font Loading API can reduce the time it takes to get necessary fonts.
Load critical web fonts as early as possible using <link rel=preload>. A preloaded font will have a higher chance to meet the first paint, in which case there's no layout shifting.

Read Best practices for fonts for other font best practices.

Reduce CLS by ensuring pages are eligible for the bfcache #

A highly effective technique for keeping CLS scores low is to ensure your web pages are eligible for the back/forward cache (bfcache).

The bfcache keeps pages in browsers memory for a short period after you navigate away so if you return to them, then they will be restored exactly as you left them. This means the fully loaded page is instantly available—without any shifts which may be normally seen during load due to any of the reasons above.

While this does potentially still mean the initial page load encounters layout shifts, when a user goes back through pages they are not seeing the same layout shifts repeatedly. You should always aim to avoid the shifts even on the initial load, but where that is more tricky to resolve fully, you can at least reduce the impact by avoiding them on any bfcache navigations.

Back and forward navigations are common on many sites. For example, returning to a contents page, or a category page, or search results.

When this was rolled out to Chrome, we saw noticeable improvements in CLS.

The bfcache is used by default by all browsers, but some sites are ineligible for the bfcache due to a variety of reasons. Read the bfcache article for more details on how to test and identify any issues preventing bfcache usage to ensure you are making full use of this feature to help your overall CLS score for your site.

Conclusion #

There are a number of techniques to identify and improve CLS as detailed above. There are allowances built into Core Web Vitals, so even if you cannot eliminate CLS completely, using some of these techniques should allow you to reduce the impact. This will be better for your users and hopefully allow you to stay within those limits.

That's it for this guide. We hope it helps keep your pages just a little less shifty :)

Preloading responsive images

2019-09-30T00:00:00Z

Browser support

Chrome 73, Supported 73
Firefox 78, Supported 78
Edge 79, Supported 79
Safari, Not supported

This article gives me an opportunity to discuss two of my favorite things: responsive images and preload. As someone who was heavily involved in developing both of those features, I'm super excited to see them working together!

Responsive images overview #

Suppose you're browsing the web on a screen that's 300 pixels wide, and the page just requested an image that's 1500 pixels wide. That page just wasted a lot of your cellular data because your screen can't do anything with all of that extra resolution. Ideally, the browser should fetch a version of the image that's just a little wider than your screen size, say 325 pixels. This ensures a high-resolution image without wasting data. And, even better, the image will load faster. Responsive images enable browsers to fetch different image resources to different devices. If you don't use an image CDN you need to save multiple dimensions for each image and specify them in the srcset attribute. The w value tells the browser the width of each version. Depending on the device, the browser can choose the appropriate one:

<img src="small.jpg" srcset="small.jpg 500w, medium.jpg 1000w, large.jpg 1500w" alt="…">

Preload overview #

Preload lets you tell the browser about critical resources that you want to load as soon as possible, before they are discovered in HTML. This is especially useful for resources that are not easily discoverable, such as fonts included in stylesheets, background images, or resources loaded from a script.

<link rel="preload" as="image" href="important.png">

Responsive images + preload = faster image loads #

Responsive images and preload have been available for the last few years, but at the same time something was missing: there was no way to preload responsive images. Starting in Chrome 73, the browser can preload the right variant of responsive images specified in srcset before it discovers the img tag!

Depending on your site's structure, that could mean significantly faster image display! We ran tests on a site that uses JavaScript to lazy-load responsive images. Preloading resulted in images loading 1.2 seconds faster.

`imagesrcset` and `imagesizes` #

To preload responsive images, new attributes were recently added to the <link> element: imagesrcset and imagesizes. They are used with <link rel="preload"> and match the srcset and sizes syntax used in <img> element.

For example, if you want to preload a responsive image specified with:

<img src="wolf.jpg" srcset="wolf_400px.jpg 400w, wolf_800px.jpg 800w, wolf_1600px.jpg 1600w" sizes="50vw" alt="A rad wolf">

You can do that by adding the following to your HTML's <head>:

<link rel="preload" as="image" href="wolf.jpg" imagesrcset="wolf_400px.jpg 400w, wolf_800px.jpg 800w, wolf_1600px.jpg 1600w" imagesizes="50vw">

This kicks off a request using the same resource selection logic that srcset and sizes will apply.

Use cases #

Preloading dynamically-injected responsive images #

Let's say you're dynamically-loading hero images as part of a slideshow and know which image will be displayed first. In that case, you probably want to avoid waiting for the script before loading the image in question, as that would delay when users can see it.

You can inspect this issue on a website with a dynamically-loaded image gallery:

Open this example website in a new tab.
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
In the Throttling drop-down list, select Fast 3G.
Disable the Disable cache checkbox.
Reload the page.

This waterfall shows that the images only start loading after the browser has finished running the script, introducing unnecessary delay to the time the image is initially displayed to the user.

Using preload helps here because the image starts loading ahead of time and is likely to already be there when the browser needs to display it.

This waterfall shows that the first image started loading at the same time as the script, avoiding unnecessary delays and resulting in faster displaying images.

To see the difference that preloading makes, you can inspect the same dynamically-loaded image gallery but with preloaded first image by following the steps from the first example.

Preloading background images using image-set #

If you have different background images for different screen densities, you can specify them in your CSS with the image-set syntax. The browser can then choose which one to display based on the screen's DPR.

background-image: image-set( "cat.png" 1x, "cat-2x.png" 2x);

The problem with CSS background images is that they are discovered by the browser only after it has downloaded and processed all the CSS in the page's <head>, which can be a lot of CSS…

You can inspect this issue on an example website with responsive background image.

In this example, the image download doesn't start until the CSS is fully downloaded, resulting in unnecessary lag to the image's display.

Responsive image preloading provides a simple and hack-free way to load those images faster.

<link rel="preload" as="image" imagesrcset="cat.png 1x, cat-2x.png 2x">

Note that by excluding the href attribute, you can ensure the browsers that do not support imagesrcset on the <link> element, but do support image-set in CSS, will not download an incorrect source. However, they will also not benefit from the preload in this case.

You can inspect how the previous example behaves with preloaded responsive background image.

Here the image and CSS start downloading at the same time, avoiding delays and resulting in a faster loading image.

Preloading responsive images in action #

Preloading your responsive images can speed them up in theory, but what does it do in practice?

To answer that I created two copies of a demo PWA shop: one that does not preload images, and one that preloads some of them. Since the site lazy loads images using JavaScript, it's likely to benefit from preloading the ones that will be in the initial viewport.

That gave me the following results for no preload and for image preload. Looking at the raw numbers we see that Start Render stayed the same, Speed Index slightly improved (273 ms, as images arrive faster, but don't take up a huge chunk of the pixel area), but the real metric which captures the difference is the Last Painted Hero metric, which improved by 1.2 seconds. 🎉🎉

Of course, nothing captures the visual difference quite like a filmstrip comparison:

The filmstrip shows that images arrive significantly faster when preloaded, resulting in a hugely-improved user experience.

Preload and `<picture>`? #

If you're familiar with responsive images, you may be wondering "What about <picture>?".

The Web Performance Working Group is talking about adding a preload equivalent for srcset and sizes, but not the <picture> element, which tackles the "art direction" use-case.

Why is this use-case being "neglected"?

While there's interest in solving that use case as well, there are still a number of technical issues to sort out which means that a solution here would have significant complexity. On top of that, it seems like for the most part, the use-case can be addressed today, even if in a hacky way (see below).

Given that, the Web Performance WG decided to ship srcset first and see if the demand for equivalent picture support arises.

If you do find yourself in a position to preload <picture> you may be able to use the following technique as a workaround.

Given the following scenario:

<picture>
    <source srcset="small_cat.jpg" media="(max-width: 400px)">
    <source srcset="medium_cat.jpg" media="(max-width: 800px)">
    <img src="large_cat.jpg">
</picture>

The <picture> element's logic (or the image source selection logic, to be precise), would be to go over the media attributes of the <source> elements in order, find the first one that matches, and use the attached resource.

Because responsive preload has no notion of "order" or "first match", the breakpoints need to be translated into something like:

<link rel="preload" href="small_cat.jpg" as="image" media="(max-width: 400px)">
<link rel="preload" href="medium_cat.jpg" as="image" media="(min-width: 400.1px) and (max-width: 800px)">
<link rel="preload" href="large_cat.jpg" as="image" media="(min-width: 800.1px)">

Preload and `type` #

The <picture> element also supports matching on the first type, to allow different image formats to be provided and the browser to pick the first image format it supports. This use case is not currently supported with preload.

For sites using this, avoiding preload is the best option, and instead having the preload scanner pick these up from the <picture> and <source> elements instead. This is a best practice anyway, particular with the support of Priority Hints which allows the appropriate image to be prioritised in a better manner than preload alone.

Effects on Largest Contentful Paint (LCP) #

Since images can be candidates for Largest Contentful Paint (LCP), preloading them may improve your website's LCP. Using the techniques above, you can also ensure that your responsive images will load more quickly.

Regardless of whether the image you're preloading is responsive, be aware that preloads work especially well when the image resource isn't discoverable in the initial markup payload. For websites that send complete markup from the server, you may not realize a huge benefit. However, if your website renders markup on the client—which sidesteps the browser's preload scanner—there's an opportunity on the table to preload potential LCP images to improve performance.

Summary #

Responsive image preload gives us new and exciting possibilities to preload responsive images in ways that were previously only possible using hacks. It's an important new addition to the speed-conscious developer's toolbox and enables us to make sure the important images we want to get in front of our users as soon as possible will be there when we need them.

Use image CDNs to optimize images

2019-08-14T00:00:00Z

Why use an image CDN? #

Image content delivery networks (CDNs) are excellent at optimizing images. Switching to an image CDN can yield a 40–80% savings in image file size. In theory, it's possible to achieve the same results using only build scripts, but it's rare in practice.

What's an image CDN? #

Image CDNs specialize in the transformation, optimization, and delivery of images. You can also think of them as APIs for accessing and manipulating the images used on your site. For images loaded from an image CDN, an image URL indicates not only which image to load, but also parameters like size, format, and quality. This makes it easy to create variations of an image for different use cases.

Examples of transformations image CDNs can perform based on parameters in image URLs.

Image CDNs are different from build-time image optimization scripts in that they create new versions of images as they're needed. As a result, CDNs are generally better suited to creating images that are heavily customized for each individual client than build scripts are.

How image CDNs use URLs to indicate optimization options #

Image URLs used by image CDNs convey important information about an image and the transformations and optimizations that should be applied to it. URL formats will vary depending on image CDN, but at a high-level, they all have similar features. Let's walk through some of the most common features.

Origin #

An image CDN can live on your own domain or the domain of your image CDN. Third-party image CDNs typically offer the option of using a custom domain for a fee. Using your own domain makes it easier to switch image CDNs at a later date because no URL changes will be needed.

The example above uses the image CDN's domain ("example-cdn.com") with a personalized subdomain, rather than a custom domain.

Image #

Image CDNs can usually be configured to automatically retrieve images from their existing locations when they're needed. This capability is often achieved by including the complete URL of the existing image within the URL for the image generated by the image CDN. For example, you might see a URL that looks like this: https://my-site.example-cdn.com/https://flowers.com/daisy.jpg/quality=auto. This URL would retrieve and optimize the image that exists at https://flowers.com/daisy.jpg.

Another widely supported way of uploading images to an image CDN is to send them via an HTTP POST request to the image CDN's API.

Security key #

A security key prevents other people from creating new versions of your images. If this feature is enabled, each new version of an image requires a unique security key. If someone tries to change the parameters of the image URL but doesn't provide a valid security key, they won't be able to create a new version. Your image CDN will take care of the details of generating and tracking security keys for you.

Transformations #

Image CDNs offer tens, and in some cases hundreds, of different image transformations. These transformations are specified via the URL string, and there are no restrictions on using multiple transformations at the same time. In the context of web performance, the most important image transformations are size, pixel density, format, and compression. These transformations are the reason why switching to an image CDN typically results in a significant reduction in image size.

There tends to be an objectively best setting for performance transformations, so some image CDNs support an "auto" mode for these transformations. For example, instead of specifying that images be transformed to the WebP format, you could allow the CDN to automatically select and serve the optimal format. Signals that an image CDN can use to determine the best way to transform an image include:

Client hints (for example, viewport width, DPR, and image width)
The Save-Data header
The User-Agent request header
The Network Information API

For example, the image CDN might serve AVIF to a Chrome browser, WebP to an Edge browser, and JPEG to a very old browser. Auto settings are popular because they allow you to take advantage of image CDNs' significant expertise in optimizing images without the need for code changes to adopt new technologies once they're supported by the image CDN.

Types of Image CDNs #

Image CDNs can be broken down into two categories: self-managed and third-party-managed.

Self-managed image CDNs #

Self-managed CDNs can be a good choice for sites with engineering staff who are comfortable maintaining their own infrastructure.

Thumbor is the most popular self-managed image CDN. While it is open-source and free to use, it generally has fewer features than most commercial CDNs, and its documentation is somewhat limited. Wikipedia, Square, and 99designs are three sites that use Thumbor. See the How to install the Thumbor image CDN post for instructions on setting it up.
Imaginary
Imagor

Third-party image CDNs #

Third-party image CDNs provide image CDNs as a service. Just as cloud providers provide servers and other infrastructure for a fee; image CDNs provide image optimization and delivery for a fee. Because third-party image CDNs maintain the underlying technology, getting started is fairly simple and can usually be accomplished in 10-15 minutes, although a complete migration for a large site might take far longer. Third-party image CDNs are typically priced based on usage tiers, with most image CDNs providing either a free tier or a free trial to give you an opportunity to try out their product.

Choosing an image CDN #

There are many good options for image CDNs. Some will have more features than others, but all of them will probably help you save bytes on your images and therefore load your pages faster. Besides feature sets, other factors to consider when choosing an image CDN are cost, support, documentation, and ease of setup or migration.

Trying them out yourself before making a decision can also be helpful. Below you can find codelabs with instructions on how to quickly get started with several image CDNs.

Effects on Largest Contentful Paint (LCP) #

Images are a vital part of the user experience on many websites, and thus factor into how well sites do when it comes to Largest Contentful Paint. Here are a few things to keep in mind if you decide to use an image CDN:

Images served from CDNs may come from a cross-origin server, which involves extra connection setup time. When possible, try to use an image CDN that proxies through the primary origin so that you're not adding extra origins for the browser to connect to. This has the same effect as self-hosting images on the primary origin.
Consider using a fetchpriority attribute value of "high" on the LCP image element so that the browser can begin loading that image as soon as possible.
If an image is not immediately discoverable in the initial HTML, consider using a rel=preload hint for your LCP candidate image so that the browser can load that image ahead of time.
If proxying through your origin is not possible, and the exact image to be loaded will not be known until later during page load, you should set up a connection to the cross-origin image CDN as early as possible to shorten the resource loading phase of what could be your page's LCP candidate image.

Image CDNs are indispensable tools that eliminate the toil of manually optimizing images, and should be considered. As always, though, there are trade-offs to consider, and keeping an eye on your website's LCP candidate images and adding hints as appropriate can mitigate any added latency to those key requests.

Largest Contentful Paint (LCP)

2019-08-08T00:00:00Z

Browser support

Chrome 77, Supported 77
Firefox, Not supported
Edge 79, Supported 79
Safari, Not supported

Source

Historically, it's been a challenge for web developers to measure how quickly the main content of a web page loads and is visible to users.

Older metrics like load or DOMContentLoaded are not good because they don't necessarily correspond to what the user sees on their screen. And newer, user-centric performance metrics like First Contentful Paint (FCP) only capture the very beginning of the loading experience. If a page shows a splash screen or displays a loading indicator, this moment is not very relevant to the user.

In the past we've recommended performance metrics like First Meaningful Paint (FMP) and Speed Index (SI) (both available in Lighthouse) to help capture more of the loading experience after the initial paint, but these metrics are complex, hard to explain, and often wrong—meaning they still do not identify when the main content of the page has loaded.

Sometimes simpler is better. Based on discussions in the W3C Web Performance Working Group and research done at Google, we've found that a more accurate way to measure when the main content of a page is loaded is to look at when the largest element was rendered.

What is LCP? #

The Largest Contentful Paint (LCP) metric reports the render time of the largest image or text block visible within the viewport, relative to when the page first started loading.

What is a good LCP score? #

To provide a good user experience, sites should strive to have Largest Contentful Paint of 2.5 seconds or less. To ensure you're hitting this target for most of your users, a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.

What elements are considered? #

As currently specified in the Largest Contentful Paint API, the types of elements considered for Largest Contentful Paint are:

<img> elements
<image> elements inside an <svg> element
<video> elements with a poster image (the poster image load time is used)
An element with a background image loaded via the url() function (as opposed to a CSS gradient)
Block-level elements containing text nodes or other inline-level text elements children.
The first frame painted for autoplaying <video> elements (as of August 2023)
The first frame of an animated image format, such as animated GIFs (as of August 2023)

As well as only considering some elements, certain heurisitics are applied to exclude certain elements that are likely to be seen as "non-contentful" to users. For Chromium-based browsers, these include:

Elements with an opacity of 0, that are invisible to the user
Elements that cover the full viewport, that are likely considered as background rather than content
Placeholder images or other images with a low entropy, that likely do not reflect the true content of the page

Browsers are likely to continue to improve these heuristics to ensure we match user expectations of what the largest contentful element is.

These "contentful" heuristics may differ from those used by First Contentful Paint (FCP), which may consider some of these elements, such as placeholder images or full viewport images, even if they are ineligible to be LCP candidates. Despite both using "contentful" in their name, the aim of these metrics is different. FCP measures when any content is painted to screen and LCP when the main content is painted so LCP is intented to be more selective.

How is an element's size determined? #

The size of the element reported for Largest Contentful Paint is typically the size that's visible to the user within the viewport. If the element extends outside of the viewport, or if any of the element is clipped or has non-visible overflow, those portions do not count toward the element's size.

For image elements that have been resized from their intrinsic size, the size that gets reported is either the visible size or the intrinsic size, whichever is smaller. For example, images that are shrunk down to a much smaller than their intrinsic size will only report the size they're displayed at, whereas images that are stretched or expanded to a larger size will only report their intrinsic sizes.

For text elements, only the size of their text nodes is considered (the smallest rectangle that encompasses all text nodes).

For all elements, any margin, padding, or border applied via CSS is not considered.

When is largest contentful paint reported? #

Web pages often load in stages, and as a result, it's possible that the largest element on the page might change.

To handle this potential for change, the browser dispatches a PerformanceEntry of type largest-contentful-paint identifying the largest contentful element as soon as the browser has painted the first frame. But then, after rendering subsequent frames, it will dispatch another PerformanceEntry any time the largest contentful element changes.

For example, on a page with text and a hero image the browser may initially just render the text—at which point the browser would dispatch a largest-contentful-paint entry whose element property would likely reference a <p> or <h1>. Later, once the hero image finishes loading, a second largest-contentful-paint entry would be dispatched and its element property would reference the <img>.

It's important to note that an element can only be considered the largest contentful element once it has rendered and is visible to the user. Images that have not yet loaded are not considered "rendered". Neither are text nodes using web fonts during the font block period. In such cases a smaller element may be reported as the largest contentful element, but as soon as the larger element finishes rendering, it'll be reported via another PerformanceEntry object.

In addition to late-loading images and fonts, a page may add new elements to the DOM as new content becomes available. If any of these new elements is larger than the previous largest contentful element, a new PerformanceEntry will also be reported.

If an element that is currently the largest contentful element is removed from the viewport (or even removed from the DOM), it will remain the largest contentful element unless a larger element is rendered.

The browser will stop reporting new entries as soon as the user interacts with the page (via a tap, scroll, or keypress), as user interaction often changes what's visible to the user (which is especially true with scrolling).

For analysis purposes, you should only report the most recently dispatched PerformanceEntry to your analytics service.

Load time vs. render time #

For security reasons, the render timestamp of images is not exposed for cross-origin images that lack the Timing-Allow-Origin header. Instead, only their load time is exposed (since this is already exposed via many other web APIs).

The usage example below shows how to handle elements whose render time is not available. But, when possible, it's always recommended to set the Timing-Allow-Origin header, so your metrics will be more accurate.

How are element layout and size changes handled? #

To keep the performance overhead of calculating and dispatching new performance entries low, changes to an element's size or position do not generate new LCP candidates. Only the element's initial size and position in the viewport is considered.

This means images that are initially rendered off-screen and then transition on-screen may not be reported. It also means elements initially rendered in the viewport that then get pushed down, out of view will still report their initial, in-viewport size.

Examples #

Here are some examples of when the Largest Contentful Paint occurs on a few popular websites:

In both of the timelines above, the largest element changes as content loads. In the first example, new content is added to the DOM and that changes what element is the largest. In the second example, the layout changes and content that was previously the largest is removed from the viewport.

While it's often the case that late-loading content is larger than content already on the page, that's not necessarily the case. The next two examples show the Largest Contentful Paint occurring before the page fully loads.

In the first example, the Instagram logo is loaded relatively early and it remains the largest element even as other content is progressively shown. In the Google search results page example, the largest element is a paragraph of text that is displayed before any of the images or logo finish loading. Since all the individual images are smaller than this paragraph, it remains the largest element throughout the load process.

How to measure LCP #

LCP can be measured in the lab or in the field, and it's available in the following tools:

Field tools #

Lab tools #

Measure LCP in JavaScript #

To measure LCP in JavaScript, you can use the Largest Contentful Paint API. The following example shows how to create a PerformanceObserver that listens for largest-contentful-paint entries and logs them to the console.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('LCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

In the above example, each logged largest-contentful-paint entry represents the current LCP candidate. In general, the startTime value of the last entry emitted is the LCP value—however, that is not always the case. Not all largest-contentful-paint entries are valid for measuring LCP.

The following section lists the differences between what the API reports and how the metric is calculated.

Differences between the metric and the API #

The API will dispatch largest-contentful-paint entries for pages loaded in a background tab, but those pages should be ignored when calculating LCP.
The API will continue to dispatch largest-contentful-paint entries after a page has been backgrounded, but those entries should be ignored when calculating LCP (elements may only be considered if the page was in the foreground the entire time).
The API does not report largest-contentful-paint entries when the page is restored from the back/forward cache, but LCP should be measured in these cases since users experience them as distinct page visits.
The API does not consider elements within iframes but the metric does as they are part of the user experience of the page. In pages with an LCP within an iframe—for example a poster image on an embedded video—this will show as a difference between CrUX and RUM. To properly measure LCP you should consider them. Sub-frames can use the API to report their largest-contentful-paint entries to the parent frame for aggregation.

Rather than memorizing all these subtle differences, developers can use the web-vitals JavaScript library to measure LCP, which handles these differences for you (where possible):

import {onLCP} from 'web-vitals';

// Measure and log LCP as soon as it's available.
onLCP(console.log);

You can refer to the source code for onLCP() for a complete example of how to measure LCP in JavaScript.

What if the largest element isn't the most important? #

In some cases the most important element (or elements) on the page is not the same as the largest element, and developers may be more interested in measuring the render times of these other elements instead. This is possible using the Element Timing API, as described in the article on custom metrics.

How to improve LCP #

A full guide on optimizing LCP is available to guide you through the process of identifying LCP timings in the field and using lab data to drill down and optimize them.

Additional resources #

Lessons learned from performance monitoring in Chrome by Annie Sullivan at performance.now() (2019)

CHANGELOG #

Occasionally, bugs are discovered in the APIs used to measure metrics, and sometimes in the definitions of the metrics themselves. As a result, changes must sometimes be made, and these changes can show up as improvements or regressions in your internal reports and dashboards.

To help you manage this, all changes to either the implementation or definition of these metrics will be surfaced in this CHANGELOG.

If you have feedback for these metrics, you can provide it in the web-vitals-feedback Google group.

Browser-level image lazy loading for the web

2019-08-06T00:00:00Z

Browser-level support for lazy loading images is now supported on the web! This video shows a demo of the feature:

You can use the loading attribute to lazy-load images without the need to write custom lazy loading code or use a separate JavaScript library. Let's dive into the details.

Browser compatibility #

Browser support

Chrome 77, Supported 77
Firefox 75, Supported 75
Edge 79, Supported 79
Safari 15.4, Supported 15.4

Source

Browsers that do not support the loading attribute simply ignore it without side effects.

Why browser-level lazy loading? #

According to the HTTP Archive, images are the most requested asset type for most websites and usually take up more bandwidth than any other resource. At the 90th percentile, sites send over 5 MB of images on desktop and mobile. That's a lot of cat pictures.

Previously, there were two ways to defer the loading of off-screen images:

Using the Intersection Observer API
Using scroll, resize, or orientationchange event handlers

Either option can let developers include lazy loading functionality, and many developers have built third-party libraries to provide abstractions that are even easier to use. With lazy loading supported directly by the browser, however, there's no need for an external library. Browser-level lazymloading also ensures that deferred loading of images still works even if JavaScript is disabled on the client.

The `loading` attribute #

Chrome loads images at different priorities depending on where they're located with respect to the device viewport. Images below the viewport are loaded with a lower priority, but they're still fetched as the page loads.

You can use the loading attribute to completely defer the loading of offscreen images that are reached by scrolling:

<img src="image.png" loading="lazy" alt="…" width="200" height="200">

Here are the supported values for the loading attribute:

lazy: Defer loading of the resource until it reaches a calculated distance from the viewport.
eager: Default loading behavior of the browser, which is the same as not including the attribute and means the image is loaded regardless of where it's located on the page. While this is the default, it can be useful to explicitly set this if your tooling automatically adds loading="lazy" if there is no explicit value, or if your linter complains if it is not explicitly set.

Relationship between the `loading` attribute and fetch priority #

The eager value is simply an instruction to load the image as usual, without delaying the load further if it is off-screen. It does not imply that the image is loaded any quicker than another image without the loading="eager" attribute.

Browsers prioritize resources based on various heuristics, and the loading attribute just states when the image resource is queued, not how it is prioritized in that queue. eager just implies the usual eager queueing browsers use by default.

If you want to increase the fetch priority of an important image (for example the LCP image), then Fetch Priority should be used with fetchpriority="high".

Note that an image with loading="lazy" and fetchpriority="high" will still be delayed while it is off-screen, and then fetched with a high priority when it is nearly within the viewport. It would likely be fetched with a high priority in this case anyway, so this combination should not really be needed nor used.

Distance-from-viewport thresholds #

All images that are above the fold—that is, immediately viewable without scrolling—load normally. Those that are far below the device viewport are only fetched when the user scrolls near them.

Chromium's implementation of lazy loading tries to ensure that offscreen images are loaded early enough so that they have finished loading once the user scrolls near to them. By fetching nearby images well before they become visible in the viewport, we maximize the chance they are already loaded by the time they become visible.

Compared to JavaScript lazy loading libraries, the thresholds for fetching images that scroll into view may be considered conservative.

The distance threshold is not fixed and varies depending on several factors:

The type of image resource being fetched
The effective connection type

You can find the default values for the different effective connection types in the Chromium source. These numbers, and even the approach of fetching only when a certain distance from the viewport is reached, may change in the future as the Chrome team improves heuristics to determine when to begin loading.

Improved data-savings and distance-from-viewport thresholds #

As of July 2020, Chrome has made significant improvements to align the image lazy loading distance-from-viewport thresholds to better meet developer expectations.

On fast connections (4G), we reduced Chrome's distance-from-viewport thresholds from 3000px to 1250px and on slower connections (3G or lower), changed the threshold from 4000px to 2500px. This change achieves two things:

<img loading=lazy> behaves closer to the experience offered by JavaScript lazy loading libraries.
The new distance-from-viewport thresholds still allow us to guarantee images have probably loaded by the time a user has scrolled to them.

You can find a comparison between the old vs. new distance-from-viewport thresholds for one of our demos on a fast connection (4G) below:

Old thresholds. vs new thresholds:

and the new thresholds vs. LazySizes (a popular JS lazy loading library):

We are committed to working with the web standards community to explore better alignment in how distance-from-viewport thresholds are approached across different browsers.

Images should include dimension attributes #

While the browser loads an image, it does not immediately know the image's dimensions, unless these are explicitly specified. To enable the browser to reserve sufficient space on a page for images, it is recommended that all <img> tags include both width and height attributes. Without dimensions specified, layout shifts can occur, which are more noticeable on pages that take some time to load.

<img src="image.png" loading="lazy" alt="…" width="200" height="200">

Alternatively, specify their values directly in an inline style:

<img src="image.png" loading="lazy" alt="…" style="height:200px; width:200px;">

The best practice of setting dimensions applies to <img> tags regardless of whether or not they are being loaded lazily. With lazy loading, this can become more relevant. Setting width and height on images in modern browsers also allows browsers to infer their intrinsic size.

In most scenarios images still lazy-load if dimensions are not included, but there are a few edge cases you should be aware of. Without width and height specified, image dimensions are 0×0 pixels at first. If you have a gallery of such images, the browser may conclude that all of them fit inside the viewport at the start, as each takes up practically no space and no image is pushed offscreen. In this case the browser determines that all of them are visible to the user and decides to load everything.

Also, specifying image dimensions decreases the chances of layout shifts happening. If you are unable to include dimensions for your images, lazy loading them can be a trade-off between saving network resources and potentially being more at risk of layout shift.

While lazy loading in Chromium is implemented in a way such that images are likely to be loaded once they are visible, there is still a small chance that they might not be loaded yet. In this case, missing width and height attributes on such images increase their impact on Cumulative Layout Shift.

Images that are defined using the <picture> element can also be lazy-loaded:

<picture>
  <source media="(min-width: 800px)" srcset="large.jpg 1x, larger.jpg 2x">
  <img src="photo.jpg" loading="lazy">
</picture>

Although a browser will decide which image to load from any of the <source> elements, the loading attribute only needs to be included to the fallback <img> element.

Avoid lazy loading images that are in the first visible viewport #

You should avoid setting loading=lazy for any images that are in the first visible viewport. This is particularly relevant for LCP images. See the article The performance effects of too much lazy-loading for more information.

It is recommended to only add loading=lazy to images which are positioned below the fold, if possible. Images that are eagerly loaded can be fetched right away, while images which are loaded lazily the browser currently needs to wait until it knows where the image is positioned on the page, which relies on the IntersectionObserver to be available.

Generally, any images within the viewport should be loaded eagerly using the browser's defaults. You do not need to specify loading=eager for this to be the case for in-viewport images.

<!-- visible in the viewport -->
<img src="product-1.jpg" alt="..." width="200" height="200">
<img src="product-2.jpg" alt="..." width="200" height="200">
<img src="product-3.jpg" alt="..." width="200" height="200">

<!-- offscreen images -->
<img src="product-4.jpg" loading="lazy" alt="..." width="200" height="200">
<img src="product-5.jpg" loading="lazy" alt="..." width="200" height="200">
<img src="product-6.jpg" loading="lazy" alt="..." width="200" height="200">

Graceful degradation #

Browsers that do not support the loading attribute will ignore its presence. While these browsers will of course not get the benefits of lazy loading, including the attribute has no negative impact on them.

FAQ #

Are there plans to automatically lazy-load images in Chrome? #

Previously, Chromium automatically lazy-loaded any images that were well suited to being deferred if Lite mode was enabled on Chrome for Android and the loading attribute was either not provided or set as loading="auto". However, Lite mode has been deprecated (as was the non-standard loading="auto") and there are currently no plans to provide automatically lazy-load of images in Chrome.

Can I change how close an image needs to be before a load is triggered? #

These values are hardcoded and can't be changed through the API. However, they may change in the future as browsers experiment with different threshold distances and variables.

Can CSS background images take advantage of the `loading` attribute? #

No, it can currently only be used with <img> tags.

Is there a downside to lazy loading images that are within the device viewport? #

It is safer to avoid putting loading=lazy on above-the-fold images, as Chrome won't preload loading=lazy images in the preload scanner and will also delay fetching such images until all layout is complete. See Avoid lazy-loading images that are in the first visible viewport for more information.

How does the `loading` attribute work with images that are in the viewport but not immediately visible (for example: behind a carousel, or hidden by CSS for certain screen sizes)? #

Using loading="lazy" may prevent them being loaded when they are not visible but within the calculated-distance. For example, Chrome, Safari and Firefox do not load images using display: none; styling—either on the image element or on a parent element. However, other techniques to hide images—such as using opacity:0 styling—will still result in the images being loaded. Always test your implementation thoroughly to ensure it's acting as intended.

What if I'm already using a third-party library or a script to lazy-load images? #

With full support of native lazy loading now available in modern browsers, you may wish to reconsider if you still need a third-party library or script to lazy-load images.

One reason to continue to use a third-party library along with loading="lazy" is to provide a polyfill for browsers that do not support the attribute, or to have more control over when lazy loading is triggered.

How do I handle browsers that don't support lazy loading? #

Create a polyfill or use a third-party library to lazy-load images on your site. The loading property can be used to detect if the feature is supported in the browser:

if ('loading' in HTMLImageElement.prototype) {
  // supported in browser
} else {
  // fetch polyfill/third-party library
}

For example, lazysizes is a popular JavaScript lazy loading library. You can detect support for the loading attribute to load lazysizes as a fallback library only when loading isn't supported. This works as follows:

Replace <img src> with <img data-src> to avoid an eager load in unsupported browsers. If the loading attribute is supported, swap data-src for src.
If loading is not supported, load a fallback (lazysizes) and initiate it. As per lazysizes docs, you use the lazyload class as a way to indicate to lazysizes which images to lazy-load.

<!-- Let's load this in-viewport image normally -->
<img src="hero.jpg" alt="…">

<!-- Let's lazy-load the rest of these images -->
<img data-src="unicorn.jpg" alt="…" loading="lazy" class="lazyload">
<img data-src="cats.jpg" alt="…" loading="lazy" class="lazyload">
<img data-src="dogs.jpg" alt="…" loading="lazy" class="lazyload">

<script>
  if ('loading' in HTMLImageElement.prototype) {
    const images = document.querySelectorAll('img[loading="lazy"]');
    images.forEach(img => {
      img.src = img.dataset.src;
    });
  } else {
    // Dynamically import the LazySizes library
    const script = document.createElement('script');
    script.src =
      'https://cdnjs.cloudflare.com/ajax/libs/lazysizes/5.1.2/lazysizes.min.js';
    document.body.appendChild(script);
  }
</script>

Here's a demo of this pattern. Try it out in an older browser to see the fallback in action.

Is lazy loading for iframes also supported in browsers? #

Browser support

Chrome 77, Supported 77
Firefox, Not supported
Edge 79, Supported 79
Safari 16.4, Supported 16.4

<iframe loading=lazy> has also been standardized and is already implemented in Chromium and Safari. This allows you to lazy-load iframes using the loading attribute. See this dedicated article about iframe lazy-loading for more information.

How does browser-level lazy loading affect advertisements on a web page? #

All ads displayed to the user in the form of an image or iframe lazy-load just like any other image or iframe.

How are images handled when a web page is printed? #

All images and iframes are immediately loaded if the page is printed. See issue #875403 for details.

Does Lighthouse recognize browser-level lazy loading? #

Lighthouse 6.0 and above factor in approaches for offscreen image lazy loading that may use different thresholds, allowing them to pass the Defer offscreen images audit.

Conclusion #

Baking in support for lazy loading images can make it significantly easier for you to improve the performance of your web pages.

Are you noticing any unusual behavior with this feature enabled in Chrome? File a bug!

Barry Pollard on web.dev

Using the Web Vitals extension to debug Core Web Vitals issues

Showing debug information in the console #

New debug information for each metric #

LCP debug information #

CLS debug information #

FID debug information #

INP debug information #

INP metric #

Interactions #

Filtering the console logs #

Conclusion #

Acknowledgements #

Optimize Time to First Byte

How to Measure TTFB #

Understanding high TTFB with Server-Timing #

Ways to optimize TTFB #

Platform-specific guidance #

Hosting, hosting, hosting #

Use a Content Delivery Network (CDN) #

Used cached content where possible #

Avoid multiple page redirects #

Stream markup to the browser #

Use a service worker #

Use 103 Early Hints for render-critical resources #

Conclusion #

Our top Core Web Vitals recommendations for 2023

Largest Contentful Paint (LCP) #

Ensure the LCP resource is discoverable from the HTML source #

Ensure the LCP resource is prioritized #

Use a CDN to optimize document and resource TTFB #

Cumulative Layout Shift (CLS) #

Set explicit sizes on any content loaded from the page #

Ensure pages are eligible for bfcache #

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

First Input Delay (FID) #

Avoid or break up long tasks #

Avoid unnecessary JavaScript #

Avoid large rendering updates #

Conclusion #

Why is CrUX data different from my RUM data?

Benefits of supplementing CrUX with a RUM solution #

Deeper analysis to investigate issues #

Correlating with other business metrics #

Collecting other performance data #

Differences between two sets of field data #

Lab data versus field data #

Populations #

Included browsers #

Opted-in users #

Included sites #

Devices #

Sampling #

Aggregation of data #

Timespan #

Aggregation of statistics #

Differences in metrics #

Metrics measured #

Metric differences across browsers #

Metrics timing #

Single-page applications #

CrUX and Web API differences #

Back/forward cache #

Iframes #

Cross-origin resources #

Background tabs and prerender #

So what can we do about it? #

Acknowledgements #

Time to First Byte (TTFB)

What is TTFB? #

What is a good TTFB score? #

How to measure TTFB #

Field tools #

Lab tools #

Measure TTFB in JavaScript #

Measuring resource requests #

How to improve TTFB #

Optimizing resource loading with the Fetch Priority API

Summary #

Resource priority #

Understanding high TTFB with `Server-Timing` #

Use `103 Early Hints` for render-critical resources #

The `fetchpriority` attribute #

Browser priority and `fetchpriority` #

`sendBeacon()` #

`fetch() keepalive` #