Katie Hempenius on web.dev

Best practices for using third-party embeds

2021-10-05T00:00:00Z

Many sites use third-party embeds to create an engaging user experience by delegating some sections of a web page to another content provider. The most common examples of third-party content embeds are video players, social-media feeds, maps, and advertisements.

Third-party content can impact the performance of a page in many ways. It can be render-blocking, contend with other critical resources for network and bandwidth, or affect the Core Web Vitals metrics. Third-party embeds may also cause layout shifts as they load. This article discusses performance best practices that you can use when loading third-party embeds, efficient loading techniques, and the Layout Shift Terminator tool that helps reduce layout shifts for popular embeds.

What is an embed #

A third-party embed is any content displayed on your site that is:

Not authored by you
Served from third-party servers

Embeds are frequently used in the following:

Websites related to sports, news, entertainment, and fashion use videos to augment textual content.
Organizations with active Twitter or social media accounts embed feeds from these accounts to their web pages to engage and reach out to more people.
Restaurant, park, and event venue pages often embed maps.

Third-party embeds are typically loaded in <iframe> elements on the page. Third-party providers offer HTML snippets often consisting of an <iframe> that pulls in a page composed of markup, scripts, and stylesheets. Some providers also use a script snippet that dynamically injects an <iframe> to pull other content in. This can make the third-party embeds heavy and affect the performance of the page by delaying its first-party content.

Performance impact of third-party embeds #

Many popular embeds include over 100 KB of JavaScript, sometimes even going up to 2 MB. They take more time to load and keep the main thread busy when executing. Performance monitoring tools such as Lighthouse and Chrome DevTools help to measure the impact of third-party embeds on performance.

Reduce the impact of third-party code Lighthouse audit shows the list of third-party providers a page uses, with size and main-thread blocking time. The audit is available through Chrome DevTools under the Lighthouse tab.

It is a good practice to periodically audit the performance impact of your embeds and third-party code because embed source code may change. You can use this opportunity to remove any redundant code.

Loading best practices #

Third-party embeds can negatively impact performance, but they also offer important functionalities. To efficiently use third-party embeds and reduce their performance impact, follow the guidelines below.

Script ordering #

In a well-designed page, the key first-party content will be the focus of the page, while the third-party embeds will occupy side-bars or appear after the first-party content.

For the best user experience, the main content should load quickly and before any other supporting content. For example, the news text on a news page should load before embeds for a Twitter feed or advertisements.

Requests for third-party embeds can get in the way of loading first-party content, so the position of a third-party script tag is important. Scripts can affect the loading sequence because the DOM construction pauses while scripts are executed. Place third-party script tags after the key first-party tags and use async or defer attributes to load them asynchronously.

<head>
   <title>Order of Things</title>
   <link rel="stylesheet" media="screen" href="/assets/application.css">
   <script src="index.js"></script>
   <script src="https://example.com/3p-library.js" async></script>
</head>

Lazy-loading #

Since third-party content usually comes after the primary content, it may not be visible in the viewport when the page loads. In that case, downloading third-party resources may be deferred until the user scrolls down to that part of the page. This not only helps optimize the initial page load but also reduces the download costs for users on fixed data plans and slow network connections.

Delaying the download of content until it is actually needed is called lazy-loading. Depending on the requirements and the type of embed, you can use different lazy-loading techniques explained below.

Native lazy-loading for `<iframe>` #

For third-party embeds loaded through <iframe> elements, you can use browser-level lazy-loading to defer loading offscreen iframes until users scroll near them. The loading attribute for <iframe> is available in Chrome 77 and above and has also been introduced to other Chromium-based browsers.

<iframe src="https://example.com"
       loading="lazy"
       width="600"
       height="400">
</iframe>

The loading attribute supports the following values:

lazy: Indicates that the browser should defer loading the iframe. The browser will load the iframe when it is nearing the viewport. Use if the iframe is a good candidate for lazy-loading.
eager: Loads the iframe immediately. Use if the iframe is not a good candidate for lazy-loading. If the loading attribute has not been specified, this is the default behavior—except in Lite mode.
auto: The browser determines whether to lazy-load this frame.

Browsers that don’t support the loading attribute ignore it, so you can apply native lazy-loading as a progressive enhancement. Browsers that support the attribute may have different implementations for the distance-from-viewport threshold (the distance at which the iframe starts loading).

Following are some ways in which you can lazy load iframes for different types of embeds.

YouTube videos: To lazy-load a YouTube video player iframe, include the loading attribute to the embed code provided by YouTube. Lazy loading the YouTube embed can save approximately 500 KB on the initial page load.

<iframe src="https://www.youtube.com/embed/aKydtOXW8mI"
   width="560" height="315"
   loading="lazy"
   title="YouTube video player"
   frameborder="0"
   allow="accelerometer; autoplay; clipboard-write;
            encrypted-media; gyroscope; picture-in-picture"
   allowfullscreen>
</iframe>

Google Maps: To lazy-load a Google Map iframe, include the loading attribute in the code for the iframe embed generated by the Google Maps Embed API. Following is an example of the code with a placeholder for the Google Cloud API key.

<iframe src="https://www.google.com/maps/embed/v1/place?key=API_KEY&q=PLACE_ID"
   width="600" height="450"
   style="border:0;"
   allowfullscreen=""
   loading="lazy">
</iframe>

lazysizes library #

Because browsers use an embed’s distance-from-viewport, in addition to signals like effective connection type and Lite-mode, to decide when an iframe should be loaded, native lazy-loading can be inconsistent. If you need better control on the distance thresholds or you want to provide a consistent lazy-loading experience across browsers, you can use the lazysizes library.

lazysizes is a fast, SEO-friendly lazy loader for both images and iframes. Once you have downloaded the component, it can be used with an iframe for a YouTube embed as follows.

<script src="lazysizes.min.js" async></script>

<iframe data-src="https://www.youtube.com/embed/aKydtOXW8mI"
   width="560" height="315"
   class="lazyload"
   title="YouTube video player"
   frameborder="0"
   allow="accelerometer; autoplay; clipboard-write;
        encrypted-media; gyroscope; picture-in-picture"
   allowfullscreen>
</iframe>

Similarly, lazysizes may be used with iframes for other third-party embeds.

Note that lazysizes uses the Intersection Observer API to detect when an element becomes visible.

Using data-lazy in Facebook #

Facebook provides different types of social plugins that can be embedded. This includes posts, comments, videos, and the most popular Like button. All plugins include a setting for data-lazy. Setting it to true ensures that the plugin will use the browser's lazy-loading mechanism by setting the loading="lazy" iframe attribute.

Lazy-loading Instagram feeds #

Instagram provides a block of markup and a script as part of the embed. The script injects an <iframe> into the page. Lazy-loading this <iframe> can improve performance as the embed can be over 100 KB gzipped in size. Many Instagram plugins for WordPress sites like WPZoom and Elfsight provide the lazy-loading option.

Replace embeds with facades #

While interactive embeds add value to the page, many users may not interact with them. For example, not every user browsing a restaurant page will click, expand, scroll, and navigate the map embed. Similarly, not every user to a telecom service providers page will interact with the chatbot. In these cases, you can avoid loading or lazy-loading the embed altogether by displaying a facade in its place.

A map embed with a zoom in and out feature.

A map facade that is an image.

A facade is a static element that looks similar to the actual embedded third-party but is not functional and, therefore, much less taxing on the page load. Following are a few strategies to load such embeds optimally while still providing some value to the user.

Use static images as facades #

Static images can be used instead of map embeds where you might not need to make the map interactive. You can zoom in on the area of interest on the map, capture an image, and use this instead of the interactive map embed. You can also use DevTools Capture node screenshot functionality to capture a screenshot of the embedded iframe element, as shown below.

DevTools captures the image as a png, but you can also consider converting it to WebP format for better performance.

Use dynamic images as facades #

This technique allows you to generate images corresponding to an interactive embed at run time. Following are some of the tools that allow you to generate static versions of embeds on your pages.

Maps Static API: The Google Maps Static API service generates a map based on the URL parameters included in a standard HTTP request and returns the map as an image you can display on your web page. The URL needs to include the Google Maps API key and must be placed in the <img> tag on the page as the src attribute.

The Static map maker tool helps to configure the parameters required for the URL and gives you the code for the image element in real-time.

The following snippet shows code for an image with the source set to a Maps Static API URL. It has been included in a link tag that ensures that the actual map can be accessed by clicking on the image. (Note: API key attribute is not included in the url)
```
<a href="https://www.google.com/maps/place/Albany,+NY/">
<img src="https://maps.googleapis.com/maps/api/staticmap?center=Albany,+NY&zoom=13&scale=1&size=600x300&maptype=roadmap&format=png&visual_refresh=true" alt="Google Map of Albany, NY">
</a>
```
Twitter screenshots: Similar to map screenshots, this concept allows you to dynamically embed a Twitter screenshot instead of the live feed. Tweetpik is one of the tools that can be used to take screenshots of tweets. Tweetpik API accepts the URL of the tweet and returns an image with its contents. The API also accepts parameters to customize the background, colors, borders, and dimensions of the image.

Use click-to-load to enhance facades #

The click-to-load concept combines lazy-loading and facades. The page initially loads with the facade. When the user interacts with the static placeholder by clicking on it, the third-party embed is loaded. This is also known as the import on interaction pattern and can be implemented using the following steps.

On page load: Facade or static element is included on the page.
On mouseover: Facade preconnects to the third-party embed provider.
On click: The facade is replaced by the third-party product.

Facades may be used with third-party embeds for video players, chat widgets, authentication services, and social media widgets. YouTube video embeds that are just images with a play button are facades that we come across frequently. The actual video loads only when you click on the image.

You can build a custom click-to-load facade using the import on interaction pattern or use one of the following open source facades available for different types of embeds.

YouTube facade

Lite-youtube-embed is a recommended facade for the YouTube player, which looks like the real player but is 224 times faster. It can be used by downloading the script and stylesheet and then using the <lite-youtube> tag in HTML or JavaScript. Custom player parameters supported by YouTube may be included through the params attribute.
```
<lite-youtube videoid="ogfYd705cRs" playlabel="Play: Keynote (Google I/O '18)"></lite-youtube>
```
Following is a comparison between the lite-youtube-embed and the actual embed.

A lite-YouTube embed

A YouTube embed

Other similar facades available for YouTube and Vimeo players are lite-youtube, lite-vimeo-embed, and lite-vimeo.
Chat widget facade

React-live-chat-loader loads a button that looks like a chat embed instead of the embed itself. It can be used with various chat provider platforms such as Intercom, Help Scout, Messenger, and so on. The look-alike widget is much lighter than the chat-widget and loads faster. It can be replaced by the actual chat widget when the user hovers or clicks on the button or if the page has been idle for a long time. The Postmark case study explains how they implemented react-live-chat-loader and performance improvements they achieved.

Remove or replace embeds with links #

If you find that some third-party embeds result in poor loading performance and using any of the techniques above is not an option, the simplest thing that you can do is remove the embed entirely. If you still want your users to be able to access the content in the embed, you can provide a link to it with target="_blank" so that the user can click and view it in another tab.

Layout stability #

While dynamically loading embedded content can improve the loading performance of a page, it can sometimes cause unexpected movement of page content. This is known as layout shift.

Since visual stability is important to guarantee a smooth user experience, Cumulative Layout Shift (CLS) measures how often those shifts happen and how disruptive they are.

Layout shifts can be avoided by reserving space during page load for elements that are going to be dynamically loaded later. The browser can determine the space to be reserved if it knows the width and height of the elements. You can ensure this by specifying the width and height attributes of iframes or by setting a fixed size for static elements where the third-party embed will be loaded. For example, an iframe for a YouTube embed should have width and height specified as follows.

<iframe src="https://www.youtube.com/embed/aKydtOXW8mI" width="560" height="315">
</iframe>

Popular embeds like YouTube, Google Maps, and Facebook provide the embed code with size attributes specified. However, there may be providers who do not include this. For example, this code snippet does not indicate the dimensions of the resulting embed.

<a class="twitter-timeline" href="https://twitter.com/ChannelNewsAsia?ref_src=twsrc%5Etfw" data-tweet-limit="1">Tweets by ChannelNewsAsia</a>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

You can use DevTools to inspect the injected iframe after this page is rendered. As seen in the following snippet, the height of the injected iframe is fixed while the width is specified in percentage.

<iframe id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" allowfullscreen="true" class="twitter-timeline twitter-timeline-rendered" style="position: static; visibility: visible; display: inline-block; width: 100%; padding: 0px; border: none; max-width: 1000px; min-width: 180px; margin-top: 0px; margin-bottom: 0px; min-height: 200px; height: 6238.31px;" data-widget-id="profile:ChannelNewsAsia" title="Twitter Timeline">
</iframe>

This information can be used to set the size of the containing element to ensure that the container does not expand on loading the feed and there is no layout shift. Following snippet may be used to fix the size of the embed included previously.

<style>
    .twitterfeed { display: table-cell;  vertical-align: top; width: 100vw; }
    .twitter-timeline {height: 400px !important; }
</style>
<div class=twitterfeed>
       <a class="twitter-timeline" href="https://twitter.com/ChannelNewsAsia?ref_src=twsrc%5Etfw" data-tweet-limit="1">Tweets by ChannelNewsAsia</a>
       <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
</div>

Layout Shift Terminator #

Since third-party embeds often omit the dimensions (width, height) for the final content they render, they can cause significant layout shifts on a page. This problem can be tricky to address without manually inspecting the final sizes using DevTools at a variety of different viewport sizes.

Now there’s an automated tool, Layout Shift Terminator, that can help you reduce layout shifts from popular embeds, such as from Twitter, Facebook, and other providers.

Layout Shift Terminator:

Loads the embed client-side in an iframe.
Resizes the iframe to various popular viewport sizes.
For each popular viewport, captures the dimensions of the embed to later generate media queries and container queries.
Sizes a min-height wrapper around the embed markup using media queries (and container queries) until the embed initializes (after which the min-height styles are removed).
Generates an optimized embed snippet that can be copy/pasted where you would otherwise be including the embed in your page.

Try out the Layout Shift Terminator, and feel free to leave any feedback on GitHub. The tool is in a beta state and aims to improve over time with further refinements.

Conclusion #

Third-party embeds can provide a lot of value to users, but as the number and size of embeds on a page increases, performance can suffer. That’s why it is necessary to measure, judge, and use appropriate loading strategies for embeds based on their position, relevance, and potential users' needs.

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.

CSS for Web Vitals

2021-06-02T00:00:00Z

The way you write your styles and build layouts can have a major impact on Core Web Vitals. This is particularly true for Cumulative Layout Shift (CLS) and Largest Contentful Paint (LCP).

This article covers CSS-related techniques for optimizing Web Vitals. These optimizations are broken down by different aspects of a page: layout, images, fonts, animations, and loading. Along the way, we'll explore improving an example page:

Layout #

Inserting content into the DOM #

Inserting content into a page after the surrounding content has already loaded pushes everything else on the page down. This causes layout shifts.

Cookie notices, particularly those placed at the top of the page, are a common example of this problem. Other page elements that often cause this type of layout shift when they load include ads and embeds.

Identify #

The Lighthouse "Avoid large layout shifts" audit identifies page elements that have shifted. For this demo, the results look like this:

The cookie notice is not listed in these findings because the cookie notice itself isn't shifting when it loads. Rather, it causes the items below it on the page (that is, div.hero and article) to shift. For more information on identifying and fixing layout shifts, see Debugging Layout Shifts.

Fix #

Place the cookie notice at the bottom of the page using absolute or fixed positioning.

Before:

.banner {
  position: sticky;
  top: 0;
}

After:

.banner {
  position: fixed;
  bottom: 0;
}

Another way to fix this layout shift would be to reserve space for the cookie notice at the top of the screen. This approach is equally effective. For more information, see Cookie notice best practices.

Images #

Images and Largest Contentful Paint (LCP) #

Images are commonly the Largest Contentful Paint (LCP) element on a page. Other page elements that can be the LCP element include text blocks and video poster images. The time at which the LCP element loads determines LCP.

It's important to note that a page's LCP element can vary from page load to page load depending on the content that is visible to the user when the page is first displayed. For example, in this demo, the background of the cookie notice, the hero image, and the article text are some of the potential LCP elements.

In the example site, the background image of the cookie notice is actually a large image. To improve LCP, you could instead paint the gradient in CSS, rather than load an image to create the effect.

Fix #

Change the .banner CSS to use a CSS gradient rather than an image:

Before:

background: url("https://cdn.pixabay.com/photo/2015/07/15/06/14/gradient-845701\_960\_720.jpg")

After:

background: linear-gradient(135deg, #fbc6ff 20%, #bdfff9 90%);

Images and layout shifts #

Browsers can only determine the size of an image once the image loads. If the image load occurs after the page has been rendered, but no space has been reserved for the image, a layout shift occurs when the image appears. In the demo, the hero image is causing a layout shift when it loads.

Identify #

To identify images without explicit width and height, use Lighthouse's "Image elements have explicit width and height" audit.

In this example, both the hero image and article image are missing width and height attributes.

Fix #

Set the width and height attributes on these images to avoid layout shifts.

Before:

<img src="https://source.unsplash.com/random/2000x600" alt="image to load in">
<img src="https://source.unsplash.com/random/800x600" alt="image to load in">

After:

<img src="https://source.unsplash.com/random/2000x600" width="2000" height="600" alt="image to load in">
<img src="https://source.unsplash.com/random/800x600" width="800" height="600" alt="image to load in">

The image now loads without causing a layout shift.

Fonts #

Fonts can delay text rendering and cause layout shifts. As a result, it is important to deliver fonts quickly.

Delayed text rendering #

By default, a browser will not immediately render a text element if its associated web fonts have not loaded yet. This is done to prevent a "flash of unstyled text" (FOUT). In many situations, this delays First Contentful Paint (FCP). In some situations, this delays Largest Contentful Paint (LCP).

Layout shifts #

Font swapping, while excellent for displaying content to the user quickly, has the potential to cause layout shifts. These layout shifts occur when a web font and its fallback font take up different amounts of space on the page. Using similarly proportioned fonts will minimize the size of these layout shifts.

In this example, font swapping caused page elements to shift upwards by five pixels.

Identify #

To see the fonts that are being loaded on a particular page, open the Network tab in DevTools and filter by Font. Fonts can be large files, so only using fewer fonts is generally better for performance.

To see how long it takes for the font to be requested, click on the Timing tab. The sooner that a font is requested, the sooner it can be loaded and used.

To see the request chain for a font, click on the Initiator tab. Generally speaking, the shorter the request chain, the sooner the font can be requested.

Fix #

This demo uses the Google Fonts API. Google Fonts provides the option to load fonts via <link> tags or an @import statement. The <link> code snippet includes a preconnect resource hint. This should result in faster stylesheet delivery than using the @import version.

At a very high-level, you can think of resource hints as a way to hint to the browser that it will need to set up a particular connection or download a particular resource. As a result, the browser will prioritize these actions. When using resource hints, keep in mind that prioritizing a particular action takes away browser resources from other actions. Thus, resource hints should be used thoughtfully and not for everything. For more information, see Establish network connections early to improve perceived page speed.

Remove the following @import statement from your stylesheet:

@import url('https://fonts.googleapis.com/css2?family=Montserrat:wght@400&family=Roboto:wght@300&display=swap');

Add the following <link> tags to the <head> of the document:

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Roboto:wght@100&display=swap" rel="stylesheet">

These link tags instruct the browser to establish an early connection to the origins used by Google Fonts and to load the stylesheet that contains the font declaration for Montserrat and Roboto. These <link> tags should be placed as early in the <head> as possible.

Animations #

The primary way that animations affect Web Vitals is when they cause layout shifts. There are two types of animations that you should avoid using: animations that trigger layout and "animation-like" effects that move page elements. Typically these animations can be replaced with more performant equivalents by using CSS properties like transform, opacity, and filter. For more information, see How to create high-performance CSS animations.

Identify #

The Lighthouse "Avoid non-composited animations" audit may be helpful for identifying non-performant animations.

Fix #

Change the slideIn animation sequence to use transform: translateX() rather than transitioning themargin-left property.

Before:

.header {
  animation: slideIn 1s 1 ease;
}

@keyframes slideIn {
  from {
    margin-left: -100%;
  }
  to {
    margin-left: 0;
  }
}

After:

.header {
  animation: slideIn 1s 1 ease;
}

@keyframes slideIn {
  from {
    transform: translateX(-100%);
  }

  to {
    transform: translateX(0);
  }
}

Critical CSS #

Stylesheets are render-blocking. This means that the browser encounters a stylesheet, it will stop downloading other resources until the browser has downloaded and parsed the stylesheet. This may delay LCP. To improve performance, consider removing unused CSS, inlining critical CSS, and deferring non-critical CSS.

Conclusion #

Although there is still room for further improvements (for example, using image compression to deliver images more quickly), these changes have significantly improved the Web Vitals of this site. If this were a real site, the next step would be to collect performance data from real users to assess whether it is meeting the Web Vitals thresholds for most users. For more information about Web Vitals, see Learn Web Vitals.

Best practices for cookie notices

2021-03-30T00:00:00Z

This article discusses how cookie notices can affect performance, performance measurement, and user experience.

Performance #

Cookie notices can have a significant impact on page performance due to the fact that they are typically loaded early in the page load process, are shown to all users, and can potentially influence the loading of ads and other page content.

Here's how cookie notices can impact Web Vitals metrics:

Largest Contentful Paint (LCP): Most cookie consent notices are fairly small and therefore typically don't contain a page's LCP element. However, this can happen—particularly on mobile devices. On mobile devices, a cookie notice typically takes up a larger portion of the screen. This usually occurs when a cookie notice contains a large block of text (text blocks can be LCP elements too).
First Input Delay (FID): Generally speaking, your cookie consent solution in and of itself should have a minimal impact on FID—cookie consent requires little JavaScript execution. However, the technologies that these cookies enable—namely advertising and tracking scripts—may have a significant impact on page interactivity. Delaying these scripts until cookie acceptance can serve as a technique to decrease First Input Delay (FID).
Cumulative Layout Shift (CLS): Cookie consent notices are a very common source of layout shifts.

Generally speaking, you can expect a cookie notice from third-party providers to have a greater impact on performance than a cookie notice that you build yourself. This is not a problem unique to cookie notices—but rather the nature of third-party scripts in general.

Best practices #

The best practices in this section focus on third-party cookie notices. Some, but not all, of these best practices will also be applicable to first-party cookie notices.

Cookie notice scripts should be loaded asynchronously. To do this, add the async attribute to the script tag.

<script src="https://cookie-notice.com/script.js" async>

Scripts that are not asynchronous block the browser parser. This delays page load and LCP. For more information, see Efficiently load third-party JavaScript.

Cookie notice scripts should be loaded "directly" by placing the script tag in the HTML of the main document—rather than loaded by a tag manager or other script. Using a tag manager or secondary script to inject the cookie notice script delays the loading of the cookie notice script: it obscures the script from the browser's lookahead parser and it prevents the script from loading before JavaScript execution.

All sites that load their cookie notice scripts from a third-party location should use either the dns-prefetch or preconnect resource hints to help establish an early connection with the origin that hosts cookie notice resources. For more information, see Establish network connections early to improve perceived page speed.

<link rel="preconnect" href="https://cdn.cookie-notice.com/">

Some sites would benefit from using the preload resource hint to load their cookie notice script. The preload resource hint informs the browser to initiate an early request for the specified resource.

<link rel="preload" href="https://www.cookie-notice.com/cookie-script.js">

preload is most powerful when its usage is limited to fetching a couple key resources per page. Thus, the usefulness of preloading the cookie notice script will vary depending on the situation.

Customizing the look and feel of a third-party cookie notice may incur additional performance costs. For example, third-party cookie notices aren't always able to reuse the same resources (for example, web fonts) that are used elsewhere on the page. In addition, third-party cookie notices tend to load styling at the end of long request chains. To avoid any surprises, be aware of how your cookie notice loads and applies styling and related resources.

Avoid layout shifts #

These are some of the most common layout shift issues associated with cookie notices:

Top-of-screen cookie notices: Top-of-screen cookie notices are a very common source of layout shift. If a cookie notice is inserted into the DOM after the surrounding page has already rendered, it will push the page elements below it further down the page. This type of layout shift can be eliminated by reserving space in the DOM for the consent notice. If this is not a feasible solution—for example, if the dimensions of your cookie notice vary by geography, consider using a sticky footer or modal to display the cookie notice. Because both of these alternative approaches display the cookie notice as an "overlay" on top of the rest of the page, the cookie notice should not cause content shifts when it loads.
Animations: Many cookie notices use animations—for example, "sliding in" a cookie notice is a common design pattern. Depending on how these effects are implemented, they can cause layout shifts. For more information, see Debugging layout shifts.
Fonts: Late-loading fonts can block render and or cause layout shifts. This phenomena is more apparent on slow connections.

Advanced loading optimizations #

These techniques take more work to implement but can further optimize the loading of cookie notice scripts:

Caching and serving third-party cookie notice scripts from your own servers can improve the delivery speed of these resources.
Using service workers can allow you more control over the fetching and caching of third-party scripts such as cookie notice scripts.

Performance measurement #

Cookie notices can impact performance measurements. This section discusses some of these implications and techniques for mitigating them.

Real User Monitoring (RUM) #

Some analytics and RUM tools use cookies to collect performance data. In the event that a user declines usage of cookies these tools cannot capture performance data.

Sites should be aware of this phenomenon; it is also worthwhile to understand the mechanisms that your RUM tooling uses to collect its data. However, for the typical site this discrepancy probably isn't a cause for alarm given the direction and magnitude of the data skew. Cookie usage is not a technical requirement for performance measurement. The web-vitals JavaScript library is an example of a library that does not use cookies.

Depending on how your site uses cookies to collect performance data (that is, whether the cookies contain personal information), as well as the legislation in question, the use of cookies for performance measurement might not be subject to the same legislative requirements as some of the cookies used on your site for other purposes—for example, advertising cookies. Some sites choose to break out performance cookies as a separate category of cookies when asking for user consent.

Synthetic monitoring #

Without custom configuration, most synthetic tools (such as Lighthouse and WebPageTest) will only measure the experience of a first-time user who has not responded to a cookie consent notice. However, not only do variations in cache state (for example, an initial visit versus a repeat visit) need to be considered when collecting performance data, but also variations in cookie acceptance state—accepted, rejected, or unresponded.

The following sections discuss WebPageTest and Lighthouse settings that can be helpful for incorporating cookie notices into performance measurement workflows. However, cookies and cookie notices are just one of many factors that can be difficult to perfectly simulate in lab environments. For this reason, it is important to make RUM data the cornerstone of your performance benchmarking, rather than synthetic tooling.

Scripting #

You can use scripting to have a WebPageTest "click" the cookie consent banner while collecting a trace.

Add a script by going to the Script tab. The script below navigates to the URL to be tested and then clicks the DOM element with the id cookieButton.

combineSteps
navigate    %URL%
clickAndWait    id=cookieButton

When using this script be aware that:

combineSteps tells WebPageTest to "combine" the results of the scripting steps that follow into a single set of traces and measurements. Running this script without combineSteps can also be useful—separate traces make it easy to see whether resources were loaded before or after cookie acceptance.
%URL% is a WebPageTest convention that refers to the URL that is being tested.
clickAndWait tells WebPageTest to click on the element indicated by attribute=value and wait for the subsequent browser activity to complete. It follows the format clickAndWait attribute=Value.

If you've configured this script correctly, the screenshot taken by WebPageTest should not show a cookie notice (the cookie notice has been accepted).

For more information on WebPageTest scripting, check out WebPageTest documentation.

Set cookies #

To run WebPageTest with a cookie set, go to the Advanced tab and add the cookie header to the Custom headers field:

Change the test location #

To change the test location used by WebPageTest, click the Test Location dropdown located on the Advanced Testing tab.

Setting cookies on a Lighthouse run can serve as a mechanism for getting a page into a particular state for testing by Lighthouse. Lighthouse's cookie behavior varies slightly by context (DevTools, CLI, or PageSpeed Insights).

DevTools #

Cookies are not cleared when Lighthouse is run from DevTools. However, other types of storage are cleared by default. This behavior can be changed by using the Clear Storage option in the Lighthouse settings panel.

CLI #

Running Lighthouse from the CLI uses a fresh Chrome instance, so no cookies are set by default. To run Lighthouse from the CLI with a particular cookie set, use the following command:

lighthouse <url> --extra-headers "{\"Cookie\":\"cookie1=abc; cookie2=def; \_id=foo\"}"

For more information on setting custom request headers in Lighthouse CLI, see Running Lighthouse on Authenticated Pages.

PageSpeed Insights #

Running Lighthouse from PageSpeed Insights uses a fresh Chrome instance and does not set any cookies. PageSeed Insights cannot be configured to set particular cookies.

User experience #

The user experience (UX) of different cookie consent notices is primarily the result of two decisions: the location of the cookie notice within the page and the extent to which the user can customize a site's use of cookies. This section discusses potential approaches to these two decisions.

When considering potential designs for your cookie notice, here are some things to think about:

UX: Is this a good user experience? How will this particular design affect existing page elements and user flows?
Business: What is your site's cookie strategy? What are your goals for the cookie notice?
Legal: Does this comply with legal requirements?
Engineering: How much work would this be to implement and maintain? How difficult would it be to change?

Placement #

Cookie notices can be displayed as a header, inline element, or footer. They can also be displayed on top of page content using a modal or served as an interstitial.

Cookie notices are commonly placed in the header or footer. Of these two options, the footer placement is generally preferable because it is unobtrusive, does not compete for attention with banner ads or notifications, and typically does not cause CLS. In addition, it is a common place for placing privacy policies and terms of use.

Although inline cookie notices are an option, they can be difficult to integrate into existing user interfaces, and therefore are uncommon.

Modals #

Modals are cookie consent notices that are displayed on top of page content. Modals can look and perform quite differently depending on their size.

Smaller, partial-screen modals can be a good alternative for sites that are struggling to implement cookie notices in a way that doesn't cause layout shifts.

On the other hand, large modals that obscure the majority of page content should be used carefully. In particular, smaller sites may find that users bounce rather than accept the cookie notice of an unfamiliar site with obscured content. Although they are not necessarily synonymous concepts, if you are considering using a full-screen cookie consent modal, you should be aware of legislation regarding cookie walls.

Configurability #

Cookie notice interfaces give users varying levels of control over which cookies they accept.

No configurability #

These notice-style cookie banners do not present users with direct UX controls for opting out of cookies. Instead, they typically include a link to the site's cookie policy which may provide users with information about managing cookies using their web browser. These notices typically include either a "dismiss" and/or "Accept" button.

Some configurability #

These cookie notices give the user the option of declining cookies but do not support more granular controls. This approach to cookie notices is less common.

Full configurability #

These cookie notices provide users with more fine-grained controls for configuring the cookie usage that they accept.

UX: Controls for configuring cookie usage are most commonly displayed using a separate modal that is launched when the user responds to the initial cookie consent notice. However, if space permits, some sites will display these controls inline within the initial cookie consent notice.
Granularity: The most common approach to cookie configurability is to allow users to opt-in to cookies by cookie "category". Examples of common cookie categories include functional, targeting, and social media cookies.

However, some sites will go a step further and allow users to opt-in on a per-cookie basis. Alternatively, another way of providing users with more specific controls is to break down cookie categories like "advertising" into specific use cases—for example, allowing users to separately opt-in to "basic ads" and "personalized ads".

Debug layout shifts

2021-03-11T00:00:00Z

The first part of this article discusses tooling for debugging layout shifts, while the second part discusses the thought process to use when identifying the cause of a layout shift.

Tooling #

Layout Instability API #

The Layout Instability API is the browser mechanism for measuring and reporting layout shifts. All tools for debugging layout shifts, including DevTools, are ultimately built upon the Layout Instability API. However, using the Layout Instability API directly is a powerful debugging tool due to its flexibility.

Usage #

The same code snippet that measures Cumulative Layout Shift (CLS) can also serve to debug layout shifts. The snippet below logs information about layout shifts to the console. Inspecting this log will provide you information about when, where, and how a layout shift occurred.

let cls = 0;
new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    if (!entry.hadRecentInput) {
      cls += entry.value;
      console.log('Current CLS value:', cls, entry);
    }
  }
}).observe({type: 'layout-shift', buffered: true});

When running this script be aware that:

The buffered: true option indicates that the PerformanceObserver should check the browser's performance entry buffer for performance entries that were created before the observer's initialization. As a result, the PerformanceObserver will report layout shifts that happened both before and after it was initialized. Keep this in mind when inspecting the console logs. An initial glut of layout shifts can reflect a reporting backlog, rather than the sudden occurrence of numerous layout shifts.
To avoid impacting performance, the PerformanceObserver waits until the main thread is idle to report on layout shifts. As a result, depending on how busy the main thread is, there may be a slight delay between when a layout shift occurs and when it is logged in the console.
This script ignores layout shifts that occurred within 500 ms of user input and therefore do not count towards CLS.

Information about layout shifts is reported using a combination of two APIs: the LayoutShift and LayoutShiftAttribution interfaces. Each of these interfaces are explained in more detail in the following sections.

LayoutShift #

Each layout shift is reported using the LayoutShift interface. The contents of an entry look like this:

duration: 0
entryType: "layout-shift"
hadRecentInput: false
lastInputTime: 0
name: ""
sources: (3) [LayoutShiftAttribution, LayoutShiftAttribution, LayoutShiftAttribution]
startTime: 11317.934999999125
value: 0.17508567530168798

The entry above indicates a layout shift during which three DOM elements changed position. The layout shift score of this particular layout shift was 0.175.

These are the properties of a LayoutShift instance that are most relevant to debugging layout shifts:

Property	Description
`sources`	The `sources` property lists the DOM elements that moved during the layout shift. This array can contain up to five sources. In the event that there are more than five elements impacted by the layout shift, the five largest (as measured by impact on layout stability) sources of layout shift are reported. This information is reported using the LayoutShiftAttribution interface (explained in more detail below).
`value`	The `value` property reports the layout shift score for a particular layout shift.
`hadRecentInput`	The `hadRecentInput` property indicates whether a layout shift occurred within 500 milliseconds of user input.
`startTime`	The `startTime` property indicates when a layout shift occurred. `startTime` is indicated in milliseconds and is measured relative to the time that the page load was initiated.
`duration`	The `duration` property will always be set to `0`. This property is inherited from the `PerformanceEntry` interface (the `LayoutShift` interface extends the `PerformanceEntry` interface). However, the concept of duration does not apply to layout shift events, so it is set to `0`. For information on the `PerformanceEntry` interface, refer to the spec.

LayoutShiftAttribution #

The LayoutShiftAttribution interface describes a single shift of a single DOM element. If multiple elements shift during a layout shift, the sources property contains multiple entries.

For example, the JSON below corresponds to a layout shift with one source: the downward shift of the <div id='banner'> DOM element from y: 76 to y:246.

// ...
  "sources": [
    {
      "node": "div#banner",
      "previousRect": {
        "x": 311,
        "y": 76,
        "width": 4,
        "height": 18,
        "top": 76,
        "right": 315,
        "bottom": 94,
        "left": 311
      },
      "currentRect": {
        "x": 311,
        "y": 246,
        "width": 4,
        "height": 18,
        "top": 246,
        "right": 315,
        "bottom": 264,
        "left": 311
      }
    }
  ]

The node property identifies the HTML element that shifted. Hovering on this property in DevTools highlights the corresponding page element.

The previousRect and currentRect properties report the size and position of the node.

The x and y coordinates report the x-coordinate and y-coordinate respectively of the top-left corner of the element
The width and height properties report the width and height respectively of the element.
The top, right, bottom, and left properties report the x or y coordinate values corresponding to the given edge of the element. In other words, the value of top is equal to y; the value of bottom is equal to y+height.

If all properties of previousRect are set to 0 this means that the element has shifted into view. If all properties of currentRect are set to 0 this means that the element has shifted out of view.

One of the most important things to understand when interpreting these outputs is that elements listed as sources are the elements that shifted during the layout shift. However, it's possible that these elements are only indirectly related to the "root cause" of layout instability. Here are a few examples.

Example #1

This layout shift would be reported with one source: element B. However, the root cause of this layout shift is the change in size of element A.

Example #2

The layout shift in this example would be reported with two sources: element A and element B. The root cause of this layout shift is the change in position of element A.

Example #3

The layout shift in this example would be reported with one source: element B. Changing the position of element B resulted in this layout shift.

Example #4

Although element B changes size, there is no layout shift in this example.

Check out a demo of how DOM changes are reported by the Layout Instability API.

DevTools #

Performance panel #

The Experience pane of the DevTools Performance panel displays all layout shifts that occur during a given performance trace—even if they occur within 500 ms of a user interaction and therefore don't count towards CLS. Hovering over a particular layout shift in the Experience panel highlights the affected DOM element.

To view more information about the layout shift, click on the layout shift, then open the Summary drawer. Changes to the element's dimensions are listed using the format [width, height]; changes to the element's position are listed using the format [x,y]. The Had recent input property indicates whether a layout shift occurred within 500 ms of a user interaction.

For information on the duration of a layout shift, open the Event Log tab. The duration of a layout shift can also be approximated by looking in the Experience pane for the length of the red layout shift rectangle.

For more information on using the Performance panel, refer to Performance Analysis Reference.

Highlight layout shift regions #

Highlighting layout shift regions can be a helpful technique for getting a quick, at-a-glance feel for the location and timing of the layout shifts occurring on a page.

To enable Layout Shift Regions in DevTools, go to Settings > More Tools > Rendering > Layout Shift Regions then refresh the page that you wish to debug. Areas of layout shift will be briefly highlighted in purple.

Thought process for identifying the cause of layout shifts #

You can use the steps below to identify the cause of layout shifts regardless of when or how the layout shift occurs. These steps can be supplemented with running Lighthouse—however, keep in mind that Lighthouse can only identify layout shifts that occurred during the initial page load. In addition, Lighthouse also can only provide suggestions for some causes of layout shifts—for example, image elements that do not have explicit width and height.

Identifying the cause of a layout shift #

Layout shifts can be caused by the following events:

Changes to the position of a DOM element
Changes to the dimensions of a DOM element
Insertion or removal of a DOM element
Animations that trigger layout

In particular, the DOM element immediately preceding the shifted element is the element most likely to be involved in "causing" layout shift. Thus, when investigating why a layout shift occurred consider:

Did the position or dimensions of the preceding element change?
Was a DOM element inserted or removed before the shifted element?
Was the position of the shifted element explicitly changed?

If the preceding element did not cause the layout shift, continue your search by considering other preceding and nearby elements.

In addition, the direction and distance of a layout shift can provide hints about root cause. For example, a large downward shift often indicates the insertion of a DOM element, whereas a 1 px or 2 px layout shift often indicates the application of conflicting CSS styles or the loading and application of a web font.

In this example, font swapping caused page elements to shift upwards by five pixels.

These are some of the specific behaviors that most frequently cause layout shift events:

Changes to the position of an element (that aren't due to the movement of another element) #

This type of change is often a result of:

Stylesheets that are loaded late or overwrite previously declared styles.
Animation and transition effects.

Changes to the dimensions of an element #

This type of change is often a result of:

Stylesheets that are loaded late or overwrite previously declared styles.
Images and iframes without width and height attributes that load after their "slot" has been rendered.
Text blocks without width or height attributes that swap fonts after the text has been rendered.

The insertion or removal of DOM elements #

This is often the result of:

Insertion of ads and other third-party embeds.
Insertion of banners, alerts, and modals.
Infinite scroll and other UX patterns that load additional content above existing content.

Animations that trigger layout #

Some animation effects can trigger layout. A common example of this is when DOM elements are 'animated' by incrementing properties like top or left rather than using CSS's transform property. Read How to create high-performance CSS animations for more information.

Reproducing layout shifts #

You can't fix layout shifts that you can't reproduce. One of the simplest, yet most effective things you can do to get a better sense of your site's layout stability is take 5-10 minutes to interact with your site with the goal triggering layout shifts. Keep the console open while doing this and use the Layout Instability API to report on layout shifts.

For hard to locate layout shifts, consider repeating this exercise with different devices and connection speeds. In particular, using a slower connection speed can make it easier to identify layout shifts. In addition, you can use a debugger statement to make it easier to step through layout shifts.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    if (!entry.hadRecentInput) {
      cls += entry.value;
      debugger;
      console.log('Current CLS value:', cls, entry);
    }
  }
}).observe({type: 'layout-shift', buffered: true});

Lastly, for layout issues that aren't reproducible in development, consider using the Layout Instability API in conjunction with your front-end logging tool of choice to collect more information on these issues. Check out the example code for how to track the largest shifted element on a page.

Best practices for carousels

2021-01-26T00:00:00Z

A carousel is a UX component that displays content in slideshow-like manner. Carousels can "autoplay" or be navigated manually by users. Although carousels can be used elsewhere, they are most frequently used to display images, products, and promotions on homepages.

This article discusses performance and UX best practices for carousels.

Performance #

A well-implemented carousel, in and of itself, should have very minimal or no impact on performance. However, carousels often contain large media assets. Large assets can impact performance regardless of whether they are displayed in a carousel or elsewhere.

LCP (Largest Contentful Paint)

Large, above-the-fold carousels often contain the page's LCP element, and therefore can have a significant impact on LCP. In these scenarios, optimizing the carousel may significantly improve LCP. For an in-depth explanation of how LCP measurement works on pages containing carousels, refer to the LCP measurement for carousels section.
FID (First Input Delay)

Carousels have minimal JavaScript requirements and therefore should not impact page interactivity. If you discover that your site's carousel has long-running scripts, you should consider replacing your carousel tooling.
CLS (Cumulative Layout Shift)

A surprising number of carousels use janky, non-composited animations that can contribute to CLS. On pages with autoplaying carousels, this has the potential to cause infinite CLS. This type of CLS typically isn't apparent to the human eye, which makes the issue easy to overlook. To avoid this issue, avoid using non-composited animations in your carousel (for example, during slide transitions).

Performance best practices #

Load carousel content using HTML #

Carousel content should be loaded via the page's HTML markup so that it is discoverable by the browser early in the page load process. Using JavaScript to initiate the loading of carousel content is probably the single biggest performance mistake to avoid when using carousels. This delays image loading and can negatively impact LCP.

<div class="slides">
  <img src="https://example.com/cat1.jpg">
  <img src="https://example.com/cat2.jpg">
  <img src="https://example.com/cat3.jpg">
</div>

Don't

const slides = document.querySelector(".slides");
const newSlide = document.createElement("img");
newSlide.src = "htttp://example.com/cat1.jpg";
slides.appendChild(newSlide);

For advanced carousel optimization, consider loading the first slide statically, then progressively enhancing it to include navigation controls and additional content. This technique is most applicable to environments where you have a user's prolonged attention—this gives the additional content time to load. In environments like home pages, where users may only stick around for a second or two, only loading a single image may be similarly effective.

Avoid layout shifts #

Slide transitions and navigation controls are the two most common sources of layout shifts in carousels:

Slide transitions: Layout shifts that occur during slide transitions are usually caused by updating the layout-inducing properties of DOM elements. Examples of some of these properties include: left, top, width, and marginTop. To avoid layout shifts, instead use the CSS transform property to transition these elements. This demo shows how to use transform to build a basic carousel.
Navigation controls: Moving or adding/removing carousel navigation controls from the DOM can cause layout shifts depending on how these changes are implemented. Carousels that exhibit this behavior typically do so in response to user hover.

These are some of the common points of confusion regarding CLS measurement for carousels:

Autoplay carousels: Slide transitions are the most common source of carousel-related layout shifts. In a non-autoplay carousel these layout shifts typically occur within 500ms of a user interaction and therefore do not count towards Cumulative Layout Shift (CLS). However, for autoplay carousels, not only can these layout shifts potentially count towards CLS - but they can also repeat indefinitely. Thus, it is particularly important to verify that an autoplay carousel is not a source of layout shifts.
Scrolling: Some carousels allow users to use scrolling to navigate through carousel slides. If an element's start position changes but its scroll offset (that is, scrollLeft or scrollTop) changes by the same amount (but in the opposite direction) this is not considered a layout shift provided that they occur in the same frame.

For more information on layout shifts, see Debug layout shifts.

Use modern technology #

Many sites use third-party JavaScript libraries to implement carousels. If you currently use older carousel tooling, you may be able to improve performance by switching to newer tooling. Newer tools tend to use more efficient APIs and are less likely to require additional dependencies like jQuery.

However, depending on the type of carousel you are building, you may not need JavaScript at all. The new Scroll Snap API makes it possible to implement carousel-like transitions using only HTML and CSS.

Here are some resources on using scroll-snap that you may find helpful:

Optimize carousel content #

Carousels often contain some of a site's largest images, so it can be worth your time to make sure that these images are fully optimized. Choosing the right image format and compression level, using an image CDN, and using srcset to serve multiple image versions are all techniques that can reduce the transfer size of images.

Performance measurement #

This section discusses LCP measurement as it relates to carousels. Although carousels are treated no differently than any other UX element during LCP calculation, the mechanics of calculating LCP for autoplaying carousels is a common point of confusion.

LCP measurement for carousels #

These are the key points to understanding how LCP calculation works for carousels:

LCP considers page elements as they are painted to the frame. New candidates for the LCP element are no longer considered once the user interacts (taps, scrolls, or keypresses) with the page. Thus, any slide in an autoplaying carousel has the potential to be the final LCP element—whereas in a static carousel only the first slide would be a potential LCP candidate.
If two equally sized images are rendered, the first image will be considered the LCP element. The LCP element is only updated when the LCP candidate is larger than the current LCP element. Thus, if all carousel elements are equally sized, the LCP element should be the first image that is displayed.
When evaluating LCP candidates, LCP considers the "visible size or the intrinsic size, whichever is smaller." Thus, if an autoplaying carousel displays images at a consistent size, but contains images of varying intrinsic sizes that are smaller than the display size, the LCP element may change as new slides are displayed. In this case, if all images are displayed at the same size, the image with the largest intrinsic size will be considered the LCP element. To keep LCP low, you should ensure that all items in an autoplaying carousel are the same intrinsic size.

Changes to LCP calculation for carousels in Chrome 88 #

As of Chrome 88, images that are later removed from the DOM are considered as potential largest contentful paints. Prior to Chrome 88, these images were excluded from consideration. For sites that use autoplaying carousels, this definition change will either have a neutral or positive impact on LCP scores.

This change was made in response to the observation that many sites implement carousel transitions by removing the previously displayed image from the DOM tree. Prior to Chrome 88, each time that a new slide was presented, the removal of the previous element would trigger an LCP update. This change only affects autoplaying carousels-by definition, potential largest contentful paints can only occur before a user first interacts with the page.

Other considerations #

This section discusses UX and product best practices that you should keep in mind when implementing carousels. Carousels should advance your business goals and present content in a way that is easy to navigate and read.

Carousel navigation controls should be easy to click and highly visible. This is something that is rarely done well-most carousels have navigation controls that are both small and subtle. Keep in mind that a single color or style of navigation control will rarely work in all situations. For example, an arrow that is clearly visible against a dark background might be difficult to see against a light background.

Carousel navigation controls should provide context about the total number of slides and the user's progress through them. This information makes it easier for the user to navigate to a particular slide and understand which content has already been viewed. In some situations providing a preview of upcoming content—whether it be an excerpt of the next slide or a list of thumbnails-can also be helpful and increase engagement.

Support mobile gestures #

On mobile, swipe gestures should be supported in addition to traditional navigation controls (such as on screen buttons).

Because it's unlikely that most users will engage with all carousel content, the content that carousel slides link to should be accessible from other navigation paths.

Readability best practices #

Don't use autoplay #

The use of autoplay creates two almost paradoxical problems: on-screen animations tend to distract users and move the eyes away from more important content; simultaneously, because users often associate animations with ads, they will ignore carousels that autoplay.

Thus, it's rare that autoplay is a good choice. If content is important, not using autoplay will maximize its exposure; if carousel content is not important, then the use of autoplay will detract from more important content. In addition, autoplaying carousels can be difficult to read (and annoying, too). People read at different speeds, so it's rare that a carousel consistently transitions at the "right" time for different users.

Ideally, slide navigation should be user-directed via navigation controls. If you must use autoplay, autoplay should be disabled on user hover. In addition, the slide transition rate should take slide content into account-the more text that a slide contains, the longer it should be displayed on screen.

Keep text and images separate #

Carousel text content is often "baked into" the corresponding image file, rather than displayed separately using HTML markup. This approach is bad for accessibility, localization, and compression rates. It also encourages a one-size-fits-all approach to asset creation. However, the same image and text formatting is rarely equally readable across desktop and mobile formats.

Be concise #

You only have a fraction of a second to catch a user's attention. Short, to-the-point copy will increase the odds that your message gets across.

Product best practices #

Carousels work well in situations where using additional vertical space to display additional content is not an option. Carousels on product pages are often a good example of this use case.

However, carousels are not always used effectively.

Carousels, particularly if they contain promotions or advance automatically, are easily mistaken for advertisements by users. Users tend to ignore advertisements—a phenomenon known as banner blindness.
Carousels are often used to placate multiple departments and avoid making decisions about business priorities. As a result, carousels can easily turn into a dumping ground for ineffective content.

Test your assumptions #

The business impact of carousels, particularly those on homepages, should be evaluated and tested. Carousel clickthrough rates can help you determine whether a carousel and its content is effective.

Be relevant #

Carousels work best when they contain interesting and relevant content that is presented with a clear context. If content wouldn't engage a user outside of a carousel—placing it in a carousel won't make it perform any better. If you must use a carousel, prioritize content and ensure that each slide is sufficiently relevant that a user would want to click through to the subsequent slide.

Signed Exchanges (SXGs)

2020-10-14T00:00:00Z

Signed exchanges (SXG) are a delivery mechanism that makes it possible to authenticate the origin of a resource independently of how it was delivered. Implementing SXG can improve Largest Contentful Paint (LCP) by enabling privacy-preserving cross-origin prefetch. Additionally, this decoupling advances a variety of use cases such as offline internet experiences and serving from third-party caches.

This article provides a comprehensive overview of SXG: how it works, use cases, and tooling.

Browser compatibility #

SXG is supported by Chromium-based browsers (starting with versions: Chrome 73, Edge 79, and Opera 64).

Overview #

As its primary use case, SXG uses a cache to prefetch and serve content that has been cryptographically signed by the origin. This helps speed cross origin navigations from referer sites while also ensuring that pages remain unaltered and properly attributed to their origin. Any potentially identifying information is hidden until after the user navigates to a site thereby protecting the user’s privacy. Google Search is an early adopter of SXG prefetching capabilities and for sites that receive a large portion of their traffic from Google Search, SXG can be an important tool for delivering faster page loads to users. Over time, we hope this impact will expand to additional referrers.

How it Works #

A site signs a request/response pair (an "HTTP exchange") in a way that makes it possible for the browser to verify the origin and integrity of the content independently of how the content was distributed. As a result, the browser can display the URL of the origin site in the address bar, rather than the URL of the server that delivered the content.

Historically, the only way for a site to use a third-party to distribute its content while maintaining attribution has been for the site to share its SSL certificates with the distributor. This has security drawbacks; moreover, it is a far stretch from making content truly portable.

The SXG format #

An SXG is encapsulated in a binary-encoded file that has two primary components: an HTTP exchange and a signature that covers the exchange. The HTTP exchange consists of a request URL, content negotiation information, and an HTTP response.

Here's an example of a decoded SXG file.

format version: 1b3
request:
  method: GET
  uri: https://example.org/
  headers:
response:
  status: 200
  headers:
    Cache-Control: max-age=604800
    Digest: mi-sha256-03=kcwVP6aOwYmA/j9JbUU0GbuiZdnjaBVB/1ag6miNUMY=
    Expires: Mon, 24 Aug 2020 16:08:24 GMT
    Content-Type: text/html; charset=UTF-8
    Content-Encoding: mi-sha256-03
    Date: Mon, 17 Aug 2020 16:08:24 GMT
    Vary: Accept-Encoding
signature:
    label;cert-sha256=*ViFgi0WfQ+NotPJf8PBo2T5dEuZ13NdZefPybXq/HhE=*;
    cert-url="https://test.web.app/ViFgi0WfQ-NotPJf8PBo2T5dEuZ13NdZefPybXq_HhE";
    date=1597680503;expires=1598285303;integrity="digest/mi-sha256-03";sig=*MEUCIQD5VqojZ1ujXXQaBt1CPKgJxuJTvFlIGLgkyNkC6d7LdAIgQUQ8lC4eaoxBjcVNKLrbS9kRMoCHKG67MweqNXy6wJg=*;
    validity-url="https://example.org/webpkg/validity"
header integrity: sha256-Gl9bFHnNvHppKsv+bFEZwlYbbJ4vyf4MnaMMvTitTGQ=

The exchange has a valid signature.
payload [1256 bytes]:
<!doctype html>
<html>
<head>
    <title>SXG example</title>
    <meta charset="utf-8" />
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <style type="text/css">
    body {
        background-color: #f0f0f2;
        margin: 0;
        padding: 0;
    }
    </style>
</head>
<body>
<div>
    <h1>Hello</h1>
</div>
</body>
</html>

The expires parameter in the signature indicates a SXG's expiration date. A SXG may be valid for at most 7 days. Find more information on the signature header in the Signed HTTP Exchanges spec.

Support for server-side personalization #

An SXG containing a Vary: Cookie header will be shown only to users who don't have cookies for the signed request URL. If your site presents different HTML to its logged-in users, you can use this feature to take advantage of SXGs without altering that experience. See details on server-side personalization with Dynamic SXG.

Web Packaging #

SXG is part of the broader Web Packaging spec proposal family. In addition to SXGs, the other major component of the Web Packaging spec is Web Bundles ("bundled HTTP exchanges"). Web Bundles are a collection of HTTP resources and the metadata necessary to interpret the bundle.

The relationship between SXGs and Web Bundles is a common point of confusion. SXG and Web Bundles are two distinct technologies that don't depend on each other—Web Bundles can be used with both signed and unsigned exchanges. A common goal advanced by both SXGs and Web Bundles is the creation of a "web packaging" format that allows sites to be shared in their entirety for offline consumption.

Speeding up Page Loads with Signed Exchanges #

Enabling Signed Exchanges can help speed up web page performance and thereby impact your site’s Core Web Vitals, in Particular Largest Contentful Paint (LCP). As an early adopter, Google Search uses SXG to provide users with a faster page load experience for pages loaded from the search results page.

Google Search crawls and caches SXGs when available and prefetches SXG that the user is likely to visit—for example, the page corresponding to the first search result.

SXG works best in tandem with other performance optimizations such as use of CDNs and reduction of render-blocking subresources. After implementing, follow these recommendations to maximize the LCP benefit from prefetching SXGs. In many cases, such optimization can result in nearly instant page loads coming from Google Search:

Impact of Signed Exchanges #

From past experiments we have observed an average of 300ms to 400ms reduction in LCP from SXG-enabled prefetches. This helps sites make a better first-impression on users and often has a positive impact on business metrics.

Several global brands and sites have already benefited from Signed Exchanges. As a case study, lets look at how implementing Signed Exchanges helped RebelMouse, a prominent Content Management System (CMS), improve their customers' performance and business metrics:

Narcity improved LCP by 41%
Paper Magazine noticed a 27% increase in Sessions per user
MLT Blog decreased Page Load time by 21%

Cloudflare found that SXG improved TTFB for 98% of sites it tested, and improved LCP for 85% of sites, with a median improvement of over 20% in SXG-eligible page loads.

Indexing #

The SXG and non-SXG representations of a page are not ranked or indexed differently by Google Search. SXG is ultimately a delivery mechanism—it does not change the underlying content.

AMP #

AMP content can be delivered using SXG. SXG allows AMP content to be prefetched and displayed using its canonical URL, rather than its AMP URL.AMP has its own separate tooling for generating SXGs.Learn how to serve AMP using signed exchanges on amp.dev.

Debugging SXGs with Chrome DevTools #

To see a SXG firsthand, use a Chromium browser, open DevTools, open the Network panel, and visit this example search page. Signed Exchanges can be identified by looking for signed-exchange in the Type column.

The Network panel in DevTools

The Preview tab provides more information about the contents of a SXG.

The Preview tab in DevTools

Tooling #

Implementing SXGs consists of generating the SXG corresponding to a given URL and then serving that SXG to requestors (usually crawlers).

Certificates #

To generate a SXG you will need a certificate that can sign SXGs, although some tools acquire these automatically. This page lists the certificate authorities that can issue this type of certificate. Certificates can be obtained automatically from the Google certificate authority using any ACME client. Web Packager Server has a built-in ACME client, and sxg-rs will soon.

Platform-specific SXG tooling #

These tools support specific technology stacks. If you are already using a platform supported by one of these tools, you may find it easier to set up than a general-purpose tool.

sxg-rs/cloudflare_worker runs on Cloudflare Workers.
sxg-rs/fastly_compute runs on Fastly Compute@Edge.
Automatic Signed Exchanges is a Cloudflare feature that automatically acquires certificates and generates Signed Exchanges.
NGINX SXG module generates and serves SXGs for sites that use nginx. Setup instructions can be found here.
Envoy SXG Filter generates and serves SXGs for sites that use Envoy.

General-purpose SXG tooling #

sxg-rs HTTP server #

The sxg-rs http_server acts as a reverse proxy for serving SXGs. For requests from SXG crawlers, http_server will sign the responses from the backend and respond with an SXG. For installation instructions, see the README.

Web Packager Server #

The Web Packager Server, webpkgserver, is an alternative to sxg-rs http_server, written in Go. For instructions on setting up the Web Packager server, see How to set up signed exchanges using Web Packager.

Web Packager CLI #

The Web Packager CLI generates a SXG corresponding to a given URL.

webpackager \
    --private\_key=private.key \
    --cert\_url=https://example.com/certificate.cbor \
    --url=https://example.com

Once the SXG file has been generated, upload it to your server and serve it with the application/signed-exchange;v=b3 MIME type. In addition, you will need to serve the SXG certificate as application/cert-chain+cbor.

SXG libraries #

These libraries could be used to build your own SXG generator:

sxg_rs is a Rust library for generating SXGs. It is the most featureful SXG library and is used as the basis for the cloudflare_worker and fastly_compute tools.
libsxg is a minimal C library for generating SXGs. It is used as the basis for the NGINX SXG module and the Envoy SXG Filter.
go/signed-exchange is a minimal Go library provided by the webpackage specification as a reference implementation of generating SXGs. It is used as the basis for its reference CLI tool, gen-signedexchange and the more featureful Web Packager tools.

Content negotiation #

Servers should serve SXG when the Accept header indicates that the q-value for application/signed-exchange is greater than or equal to the q-value for text/html. In practice, this means that an origin server will serve SXG to crawlers, but not browsers. Many of the above tools do this by default, but for other tools, the following regular expression can be used to match the Accept header of requests that should be served as SXG:

Accept: /(^|,)\s\*application\/signed-exchange\s\*;\s\*v=[[:alnum:]\_-]+\s\*(,|$)/

This recommendation includes examples for Apache and nginx.

Update cache API #

The Google SXG Cache has an API that site owners can use to remove SXGs from the cache before they've expired due to Cache-Control: max-age. See the update cache API reference for details.

Linking to SXG #

Any site can cache, serve, and prefetch SXGs of the pages that it links to, where available, using the and tags:

<a href="https://example.com/article.html.sxg">
<link rel="prefetch" as="document" href="https://example.com/article.html.sxg">

This article illustrates how to use nginx to distribute SXGs.

Unique Advantages #

SXG is one of many possible technologies to enable cross-origin prefetching. When deciding which technology to use, you may need to trade off between optimizing different aspects. The following sections illustrate a few of the unique values that SXG provides in the space of possible solutions. These factors may change over time as the space of available solutions evolves.

Fewer requests to serve #

With cross-site prefetching, your server may need to serve additional requests. This corresponds to cases where a page was prefetched, but either the user didn't visit the page, or the prefetched bytes couldn't be shown to the user. For SXG, these additional unused requests can be significantly reduced:

SXGs are cached and may be sent to users until they expire. Thus, many prefetches can be handled solely by the cache server.
SXGs can be shown to users both with and without cookies on your site. Thus, there are fewer times when the page will need to be fetched again after navigation.

Page speed improvement #

You may see additional page speed improvement due to the prefetch surfaces and capabilities it currently supports:

SXGs can be shown to users with cookies for your site.
SXG also prefetches subresources for your pages, such as JavaScript, CSS, fonts, and images, when specified using a Link header.
In the near future, SXG prefetching from Google Search will be available on more search result types.

Conclusion #

Signed Exchanges are a delivery mechanism that make it possible to verify the origin and validity of a resource independently of how the resource was delivered. As a result, SXGs can be distributed by third-parties while maintaining full publisher attribution.

Content delivery networks (CDNs)

2020-09-22T00:00:00Z

Content delivery networks (CDNs) improve site performance by using a distributed network of servers to deliver resources to users. Because CDNs reduce server load, they reduce server costs and are well-suited to handling traffic spikes. This article discusses how CDNs work and provides platform-agnostic guidance on choosing, configuring, and optimizing a CDN setup.

Overview #

A content delivery network consists of a network of servers that are optimized for quickly delivering content to users. Although CDNs are arguably best known for serving cached content, CDNs can also improve the delivery of uncacheable content. Generally speaking, the more of your site delivered by your CDN, the better.

At a high-level, the performance benefits of CDNs stem from a handful of principles: CDN servers are located closer to users than origin servers and therefore have a shorter round-trip time (RTT) latency; networking optimizations allow CDNs to deliver content more quickly than if the content was loaded "directly" from the origin server; lastly, CDN caches eliminate the need for a request to travel to the origin server.

Resource delivery #

Although it may seem non-intuitive, using a CDN to deliver resources (even uncacheable ones) will typically be faster than having the user load the resource "directly" from your servers.

When a CDN is used to deliver resources from the origin, a new connection is established between the client and a nearby CDN server. The remainder of the journey (in other words, the data transfer between the CDN server and origin) occurs over the CDN's network - which often includes existing, persistent connections with the origin. The benefits of this are twofold: terminating the new connection as close to the user as possible eliminates unnecessary connection setup costs (establishing a new connection is expensive and requires multiple roundtrips); using a pre-warmed connection allows data to be immediately transferred at the maximum possible throughput.

Some CDNs improve upon this even further by routing traffic to the origin through multiple CDN servers spread across the Internet. Connections between CDN servers occur over reliable and highly optimized routes, rather than routes determined by the Border Gateway Protocol (BGP). Although BGP is the internet's de facto routing protocol, its routing decisions are not always performance-oriented. Therefore, BGP-determined routes are likely to be less performant than the finely-tuned routes between CDN servers.

Caching #

Caching resources on a CDN's servers eliminates the need for a request to travel all the way to the origin in order to be served. As a result, the resource is delivered more quickly; this also reduces the load on the origin server.

Adding resources to the cache #

The most commonly used method of populating CDN caches is to have the CDN "pull" resources as they are needed - this is known as "origin pull". The first time that a particular resource is requested from the cache the CDN will request it from the origin server and cache the response. In this manner, the contents of the cache are built-up over time as additional uncached resources are requested.

Removing resources from the cache #

CDNs use cache eviction to periodically remove not-so-useful resources from the cache. In addition, site owners can use purging to explicitly remove resources.

Cache eviction

Caches have a finite storage capacity. When a cache nears its capacity, it makes room for new resources by removing resources that haven't been accessed recently, or which take up a lot of space. This process is known as cache eviction. A resource being evicted from one cache does not necessarily mean that it has been evicted from all caches in a CDN network.
Purging

Purging (also known as "cache invalidation") is a mechanism for removing a resource from a CDN's caches without having to wait for it to expire or be evicted. It is typically executed via an API. Purging is critical in situations where content needs to be retracted (for example, correcting typos, pricing errors, or incorrect news articles). On top of that, it can also play a crucial role in a site's caching strategy.

If a CDN supports near instant purging, purging can be used as a mechanism for managing the caching of dynamic content: cache dynamic content using a long TTL, then purge the resource whenever it is updated. In this way, it is possible to maximize the caching duration of a dynamic resource, despite not knowing in advance when the resource will change. This technique is sometimes referred to as "hold-till-told caching".

When purging is used at scale it is typically used in conjunction with a concept known as "cache tags" or "surrogate cache keys". This mechanism allows site owners to associate one or more additional identifiers (sometimes referred to as "tags") with a cached resource. These tags can then be used to carry out highly granular purging. For example, you might add a "footer" tag to all resources (for example, /about, /blog) that contain your site footer. When the footer is updated, instruct your CDN to purge all resources associated with the "footer" tag.

Cacheable resources #

If and how a resource should be cached depends on whether it is public or private; static or dynamic.

Private and public resources #

Private Resources

Private resources contain data intended for a single user and therefore should not be cached by a CDN. Private resources are indicated by the Cache-Control: private header.
Public Resources

Public resources do not contain user-specific information and therefore are cacheable by a CDN. A resource may be considered cacheable by a CDN if it does not have a Cache-Control: no-store or Cache-Control: private header. The length of time that a public resource can be cached depends on how frequently the asset changes.

Dynamic and static content #

Dynamic content

Dynamic content is content that changes frequently. An API response and a store homepage are examples of this content type. However, the fact that this content changes frequently doesn't necessarily preclude it from being cached. During periods of heavy traffic, caching these responses for very short periods of time (for example, 5 seconds) can significantly reduce the load on the origin server, while having minimal impact on data freshness.
Static content

Static content changes infrequently, if ever. Images, videos, and versioned libraries are typically examples of this content type. Because static content does not change, it should be cached with a long Time to Live (TTL) - for example, 6 months or 1 year.

Choosing a CDN #

Performance is typically a top consideration when choosing a CDN. However, the other features that a CDN offers (for example, security and analytics features), as well as a CDN's pricing, support, and onboarding are all important to consider when choosing a CDN.

Performance #

At a high-level, a CDN's performance strategy can be thought of in terms of the tradeoff between minimizing latency and maximizing cache hit ratio. CDNs with many points of presence (PoPs) can deliver lower latency but may experience lower cache hit ratios as a result of traffic being split across more caches. Conversely, CDNs with fewer PoPs may be located geographically further from users, but can achieve higher cache hit ratios.

As a result of this tradeoff, some CDNs use a tiered approach to caching: PoPs located close to users (also known as "edge caches") are supplemented with central PoPs that have higher cache hit ratios. When an edge cache can't find a resource, it will look to a central PoP for the resource. This approach trades slightly greater latency for a higher likelihood that the resource can be served from a CDN cache - though not necessarily an edge cache.

The tradeoff between minimizing latency and maximizing cache hit ratio is a spectrum. No particular approach is universally better; however, depending on the nature of your site and its user base, you may find that one of these approaches delivers significantly better performance than the other.

It's also worth noting that CDN performance can vary significantly depending on geography, time of day, and even current events. Although it's always a good idea to do your own research on a CDN's performance, it can be difficult to predict the exact performance you'll get from a CDN.

Additional features #

CDNs typically offer a wide variety of features in addition to their core CDN offering. Commonly offered features include: load balancing, image optimization, video streaming, edge computing, and security products.

How to setup and configure a CDN #

Ideally you should use a CDN to serve your entire site. At a high-level, the setup process for this consists of signing up with a CDN provider, then updating your CNAME DNS record to point at the CDN provider. For example, the CNAME record for www.example.com might point to example.my-cdn.com. As a result of this DNS change, traffic to your site will be routed through the CDN.

If using a CDN to serve all resources is not an option, you can configure a CDN to only serve a subset of resources - for example, only static resources. You can do this by creating a separate CNAME record that will only be used for resources that should be served by the CDN. For example, you might create a static.example.com CNAME record that points to example.my-cdn.com. You would also need to rewrite the URLs of resources being served by the CDN to point to the static.example.com subdomain that you created.

Although your CDN will be set up at this point, there will likely be inefficiencies in your configuration. The next two sections of this article will explain how to get the most out of your CDN by increasing cache hit ratio and enabling performance features.

Improving cache hit ratio #

An effective CDN setup will serve as many resources as possible from the cache. This is commonly measured by cache hit ratio (CHR). Cache hit ratio is defined as the number of cache hits divided by the number of total requests during a given time interval.

A freshly initialized cache will have a CHR of 0 but this increases as the cache is populated with resources. A CHR of 90% is a good goal for most sites. Your CDN provider should supply you with analytics and reporting regarding your CHR.

When optimizing CHR, the first thing to verify is that all cacheable resources are being cached and cached for the correct length of time. This is a simple assessment that should be undertaken by all sites.

The next level of CHR optimization, broadly speaking, is to fine tune your CDN settings to make sure that logically equivalent server responses aren't being cached separately. This is a common inefficiency that occurs due to the impact of factors like query params, cookies, and request headers on caching.

Initial audit #

Most CDNs will provide cache analytics. In addition, tools like WebPageTest and Lighthouse can also be used to quickly verify that all of a page's static resources are being cached for the correct length of time. This is accomplished by checking the HTTP Cache headers of each resource. Caching a resource using the maximum appropriate Time To Live (TTL) will avoid unnecessary origin fetches in the future and therefore increase CHR.

At a minimum, one of these headers typically needs to be set in order for a resource to be cached by a CDN:

Cache-Control: max-age=
Cache-Control: s-maxage=
Expires

In addition, although it does not impact if or how a resource is cached by a CDN, it is good practice to also set the Cache-Control: immutable directive.Cache-Control: immutable indicates that a resource "will not be updated during its freshness lifetime". As a result, the browser will not revalidate the resource when serving it from the browser cache, thereby eliminating an unnecessary server request. Unfortunately, this directive is only supported by Firefox and Safari - it is not supported by Chromium-based browsers. This issue tracks Chromium support for Cache-Control: immutable. Starring this issue can help encourage support for this feature.

For a more detailed explanation of HTTP caching, refer to Prevent unnecessary network requests with the HTTP Cache.

Fine tuning #

A slightly simplified explanation of how CDN caches work is that the URL of a resource is used as the key for caching and retrieving the resource from the cache. In practice, this is still overwhelmingly true, but is complicated slightly by the impact of things like request headers and query params. As a result, rewriting request URLs is an important technique for both maximizing CHR and ensuring that the correct content is served to users. A properly configured CDN instance strikes the correct balance between overly granular caching (which hurts CHR) and insufficiently granular caching (which results in incorrect responses being served to users).

Query params #

By default, CDNs take query params into consideration when caching a resource. However, small adjustments to query param handling can have a significant impact on CHR. For example:

Unnecessary query params

By default, a CDN would cache example.com/blog and example.com/blog?referral_id=2zjk separately even though they are likely the same underlying resource. This is fixed by adjusting a CDN's configuration to ignore the referral\_id query param.
Query param order

A CDN will cache example.com/blog?id=123&query=dogs separately from example.com/blog?query=dogs&id=123. For most sites, query param order does not matter, so configuring the CDN to sort the query params (thereby normalizing the URL used to cache the server response) will increase CHR.

Vary #

The Vary response header informs caches that the server response corresponding to a particular URL can vary depending on the headers set on the request (for example, the Accept-Language or Accept-Encoding request headers). As a result, it instructs a CDN to cache these responses separately. The Vary header is not widely supported by CDNs and may result in an otherwise cacheable resource not being served from a cache.

Although the Vary header can be a useful tool, inappropriate usage hurts CHR. In addition, if you do use Vary, normalizing request headers will help improve CHR. For example, without normalization the request headers Accept-Language: en-US and Accept-Language: en-US,en;q=0.9 would result in two separate cache entries, even though their contents would likely be identical.

Cookies #

Cookies are set on requests via the Cookie header; they are set on responses via the Set-Cookie header. Unnecessary use of Set-Cookie header should be avoided given that caches will typically not cache server responses containing this header.

Performance features #

This section discusses performance features that are commonly offered by CDNs as part of their core product offering. Many sites forget to enable these features, thereby losing out on easy performance wins.

Compression #

All text-based responses should be compressed with either gzip or Brotli. If you have the choice, choose Brotli over gzip. Brotli is a newer compression algorithm, and compared to gzip, it can achieve higher compression ratios.

There are two types of CDN support for Brotli compression: "Brotli from origin" and "automatic Brotli compression".

Brotli from origin #

Brotli from origin is when a CDN serves resources that were Brotli-compressed by the origin. Although this may seem like a feature that all CDNs should be able to support out of the box, it requires that a CDN be able to cache multiple versions (in other words, gzip-compressed and Brotli-compressed versions) of the resource corresponding to a given URL.

Automatic Brotli compression #

Automatic Brotli compression is when resources are Brotli compressed by the CDN. CDNs can compress both cacheable and non-cacheable resources.

The first time that a resource is requested it is served using "good enough" compression - for example, Brotli-5. This type of compression is applicable to both cacheable and non-cacheable resources.

Meanwhile, if a resource is cacheable, the CDN will use offline processing to compress the resource at a more powerful but far slower compression level - for example, Brotli-11. Once this compression completes, the more compressed version will be cached and used for subsequent requests.

Compression best practices #

Sites that want to maximize performance should apply Brotli compression at both their origin server and CDN. Brotli compression at the origin minimizes the transfer size of resources that can't be served from the cache. To prevent delays in serving requests, the origin should compress dynamic resources using a fairly conservative compression level - for example, Brotli-4; static resources can be compressed using Brotli-11. If an origin does not support Brotli, gzip-6 can be used to compress dynamic resources; gzip-9 can be used to compress static resources.

TLS 1.3 #

TLS 1.3 is the newest version of Transport Layer Security (TLS), the cryptographic protocol used by HTTPS. TLS 1.3 provides better privacy and performance compared to TLS 1.2.

TLS 1.3 shortens the TLS handshake from two roundtrips to one. For connections using HTTP/1 or HTTP/2, shortening the TLS handshake to one roundtrip effectively reduces connection setup time by 33%.

HTTP/2 and HTTP/3 #

HTTP/2 and HTTP/3 both provide performance benefits over HTTP/1. Of the two, HTTP/3 offers greater potential performance benefits. HTTP/3 isn't fully standardized yet, but it will be widely supported once this occurs.

HTTP/2 #

If your CDN hasn't already enabled HTTP/2 by default, you should consider turning it on. HTTP/2 provides multiple performance benefits over HTTP/1 and is supported by all major browsers. Performance features of HTTP/2 include: multiplexing, stream prioritization, server push, and header compression.

Multiplexing

Multiplexing is arguably the most important feature of HTTP/2. Multiplexing enables a single TCP connection to serve multiple request-response pairs at the same time. This eliminates the overhead of unnecessary connection setups; given that the number of connections that a browser can have open at a given time is limited, this also has the implication that the browser is now able to request more of a page's resources in parallel. Multiplexing theoretically removes the need for HTTP/1 optimizations like concatenation and sprite sheets - however, in practice, these techniques will remain relevant given that larger files compress better.
Stream prioritization

Multiplexing enables multiple concurrent streams; stream prioritization provides an interface for communicating relative priority of each of these streams. This helps the server to send the most important resources first - even if they weren't requested first.

Stream prioritization is expressed by the browser via a dependency tree and is merely a statement of preference: in other words, the server is not obligated to meet (or even consider) the priorities supplied by the browser. Stream prioritization becomes more effective when more of a site is served through a CDN.

CDN implementations of HTTP/2 resource prioritization vary wildly. To identify whether your CDN fully and properly supports HTTP/2 resource prioritization, check out Is HTTP/2 Fast Yet?.

Although switching your CDN instance to HTTP/2 is largely a matter of flipping a switch, it's important to thoroughly test this change before enabling it in production. HTTP/1 and HTTP/2 use the same conventions for request and response headers - but HTTP/2 is far less forgiving when these conventions aren't adhered to. As a result, non-spec practices like including non-ASCII or uppercase characters in headers may begin causing errors once HTTP/2 is enabled. If this occurs, a browser's attempts to download the resource will fail. The failed download attempt will be visible in the "Network" tab of DevTools. In addition, the error message "ERR_HTTP2_PROTOCOL_ERROR" will be displayed in the console.

HTTP/3 #

HTTP/3 is the successor to HTTP/2. As of September 2020, all major browsers have experimental support for HTTP/3 and some CDNs support it. Performance is the primary benefit of HTTP/3 over HTTP/2. Specifically, HTTP/3 eliminates head-of-line blocking at the connection level and reduces connection setup time.

Elimination of head-of-line blocking

HTTP/2 introduced multiplexing, a feature that allows a single connection to be used to transmit multiple streams of data simultaneously. However, with HTTP/2, a single dropped packet blocks all streams on a connection (a phenomena known as a head-of-line blocking). With HTTP/3, a dropped packet only blocks a single stream. This improvement is largely the result of HTTP/3 using UDP (HTTP/3 uses UDP via QUIC) rather than TCP. This makes HTTP/3 particularly useful for data transfer over congested or lossy networks.

Reduced connection setup time

HTTP/3 uses TLS 1.3 and therefore shares its performance benefits: establishing a new connection only requires a single round-trip and resuming an existing connection does not require any roundtrips.

HTTP/3 will have the biggest impact on users on poor network connections: not only because HTTP/3 handles packet loss better than its predecessors, but also because the absolute time savings resulting from a 0-RTT or 1-RTT connection setup will be greater on networks with high latency.

Image optimization #

CDN image optimization services typically focus on image optimizations that can be applied automatically in order to reduce image transfer size. For example: stripping EXIF data, applying lossless compression, and converting images to newer file formats (for example, WebP). Images make up ~50% of the transfer bytes on the median web page, so optimizing images can significantly reduce page size.

Minification #

Minification removes unnecessary characters from JavaScript, CSS, and HTML. It's preferable to do minification at the origin server, rather than the CDN. Site owners have more context about the code to be minified and therefore can often use more aggressive minification techniques than those employed by CDNs. However, if minifying code at the origin is not an option, minification by the CDN is a good alternative.

Conclusion #

Use a CDN: CDNs deliver resources quickly, reduce load on the origin server, and are helpful for dealing with traffic spikes.
Cache content as aggressively as possible: Both static and dynamic content can and should be cached - albeit for varying durations. Periodically audit your site to make sure that you are optimally cacheing content.
Enable CDN performance features: Features like Brotli, TLS 1.3, HTTP/2, and HTTP/3 further improve performance.

Performance monitoring with Lighthouse CI

2020-07-27T00:00:00Z

Lighthouse CI is a suite of tools for using Lighthouse during continuous integration. Lighthouse CI can be incorporated into developer workflows in many different ways. This guide covers the following topics:

Using the Lighthouse CI CLI.
Configuring your CI provider to run Lighthouse CI.
Setting up a GitHub Action and status check for Lighthouse CI. This will automatically display Lighthouse results on GitHub pull requests.
Building a performance dashboard and data store for Lighthouse reports.

Overview #

Lighthouse CI is a suite of free tools that facilitate using Lighthouse for performance monitoring. A single Lighthouse report provides a snapshot of a web page's performance at the time that it is run; Lighthouse CI shows how these findings have changed over time. This can be used to identify the impact of particular code changes or ensure that performance thresholds are met during continuous integration processes. Although performance monitoring is the most common use case for Lighthouse CI, it can be used to monitor other aspects of the Lighthouse report - for example, SEO or accessibility.

The core functionality of Lighthouse CI is provided by the Lighthouse CI command line interface. (Note: This is a separate tool than the Lighthouse CLI.) The Lighthouse CI CLI provides a set of commands for using Lighthouse CI. For example, the autorun command executes multiple Lighthouse runs, identifies the median Lighthouse report, and uploads the report for storage. This behavior can be heavily customized by passing additional flags or customizing Lighthouse CI's configuration file, lighthouserc.js.

Although the core functionality of Lighthouse CI is primarily encapsulated in the Lighthouse CI CLI, Lighthouse CI is typically used through one of the following approaches:

Running Lighthouse CI as part of continuous integration
Using a Lighthouse CI GitHub Action that runs and comments on every pull request
Tracking performance over time via the dashboard provided by Lighthouse Server.

All of these approaches are built upon the Lighthouse CI CLI.

Alternatives to Lighthouse CI include third-party performance monitoring services or writing your own script to collect performance data during the CI process. You should consider using a third-party service if you'd prefer to let someone else handle the management of your performance monitoring server and test devices, or, if you want notification capabilities (such as email or Slack integration) without having to build these features yourself.

Use Lighthouse CI locally #

This section explains how to run and install the Lighthouse CI CLI locally and how to configure lighthouserc.js. Running the Lighthouse CI CLI locally is the easiest way to make sure that your lighthouserc.js is configured correctly.

Install the Lighthouse CI CLI.
```
npm install -g @lhci/cli
```
Lighthouse CI is configured by placing a lighthouserc.js file in the root of your project's repo. This file is mandatory and will contain Lighthouse CI related configuration information. Although Lighthouse CI can be configured to be used without a git repo, the instructions in this article assume that your project repo is configured to use git.
In the root of your repository, create a lighthouserc.js configuration file.
```
touch lighthouserc.js
```

Add the following code to lighthouserc.js. This code is an empty Lighthouse CI configuration. You will be adding to this configuration in later steps.

module.exports = {
  ci: {
    collect: {
      /* Add configuration here */
    },
    upload: {
      /* Add configuration here */
    },
  },
};

Every time that Lighthouse CI runs, it starts a server to serve your site. This server is what enables Lighthouse to load your site even when no other servers are running. When Lighthouse CI finishes running, it will automatically shutdown the server. To ensure that serving works correctly, you should configure either the staticDistDir or startServerCommand properties.

If your site is static, add the staticDistDir property to the ci.collect object to indicate where your static files are located. Lighthouse CI will use its own server to serve these files while testing your site. If your site is not static, add the startServerCommand property to the ci.collect object to indicate the command that starts your server. Lighthouse CI will start a new server process during testing and shut it down after.
```
// Static site example
collect: {
  staticDistDir: './public',
}
```
```
// Dynamic site example
collect: {
  startServerCommand: 'npm run start',
}
```
Add the url property to the ci.collect object to indicate URL(s) that Lighthouse CI should run Lighthouse against. The value of the url property should be provided as an array of URLs; this array can contain one or more URLs. By default, Lighthouse CI will run Lighthouse three times against each URL.
```
collect: {
  // ...
  url: ['http://localhost:8080']
}
```
Note: These URLs should be serveable by the server you configured in the previous step. Thus, if you're running Lighthouse CI locally, these URLs should probably include localhost rather than your production host.
Add the target property to the ci.upload object and set the value to 'temporary-public-storage'. The Lighthouse report(s) collected by Lighthouse CI will be uploaded to temporary public storage. The report will remain there for seven days and then be automatically deleted. This setup guide uses the "temporary public storage" upload option because it is quick to setup. For information on other ways of storing Lighthouse reports, refer to the documentation.
```
upload: {
  target: 'temporary-public-storage',
}
```
The storage location of the report will be similar to this:
```
https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1580152437799-46441.report.html
```
(This URL won't work because the report has already been deleted.)
Run the Lighthouse CI CLI from the terminal using the autorun command. This will run Lighthouse three times and upload the median Lighthouse report.
```
lhci autorun
```
If you've correctly configured Lighthouse CI, running this command should produce output similar to this:
```
✅  .lighthouseci/ directory writable
✅  Configuration file found
✅  Chrome installation found
⚠️   GitHub token not set
Healthcheck passed!

Started a web server on port 65324...
Running Lighthouse 3 time(s) on http://localhost:65324/index.html
Run #1...done.
Run #2...done.
Run #3...done.
Done running Lighthouse!

Uploading median LHR of http://localhost:65324/index.html...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1591720514021-82403.report.html
No GitHub token set, skipping GitHub status check.

Done running autorun.
```
You can ignore the GitHub token not set message in the console output. A GitHub token is only necessary if you want to use Lighthouse CI with a GitHub Action. How to setup a GitHub Action is explained later in this article.

Clicking on the link in the output that begins with https://storage.googleapis.com... will take you to the Lighthouse report corresponding to the median Lighthouse run.

The defaults used by autorun can be overridden via the command line or lighthouserc.js. For example, the lighthouserc.js configuration below indicates that five Lighthouse runs should be collected every time autorun executes.

Update lighthouserc.js to use the numberOfRuns property:

module.exports = {
    // ...
    collect: {
      numberOfRuns: 5
    },
  // ...
  },
};

Re-run the autorun command:

lhci autorun

The terminal output should show that Lighthouse has been run five times rather than the default three:

✅  .lighthouseci/ directory writable
✅  Configuration file found
✅  Chrome installation found
⚠️   GitHub token not set
Healthcheck passed!

Automatically determined ./dist as `staticDistDir`.
Set it explicitly in lighthouserc.json if incorrect.

Started a web server on port 64444...
Running Lighthouse 5 time(s) on http://localhost:64444/index.html
Run #1...done.
Run #2...done.
Run #3...done.
Run #4...done.
Run #5...done.
Done running Lighthouse!

Uploading median LHR of http://localhost:64444/index.html...success!
Open the report at https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1591716944028-6048.report.html
No GitHub token set, skipping GitHub status check.

Done running autorun.

To learn about other configuration options, refer to the Lighthouse CI configuration documentation.

Setup your CI process to run Lighthouse CI #

Lighthouse CI can be used with your favorite CI tool. The Configure Your CI Provider section of the Lighthouse CI documentation contains code samples showing how to incorporate Lighthouse CI into the configuration files of common CI tools. Specifically, these code samples show how to run Lighthouse CI to collect performance measurements during the CI process.

Using Lighthouse CI to collect performance measurements is a good place to start with performance monitoring. However, advanced users may want to go a step further and use Lighthouse CI to fail builds if they don't meet pre-defined criteria such as passing particular Lighthouse audits or meeting all performance budgets. This behavior is configured through the assert property of the lighthouserc.js file.

Lighthouse CI supports three levels of assertions:

off: ignore assertions
warn: print failures to stderr
error: print failures to stderr and exit Lighthouse CI with a non-zero exit code

Below is an example of a lighthouserc.js configuration that includes assertions. It sets assertions for the scores of Lighthouse's performance and accessibility categories. To try this out, add the assertions shown below to your lighthouserc.js file, then rerun Lighthouse CI.

module.exports = {
  ci: {
    collect: {
      // ...
    },
    assert: {
      assertions: {
        'categories:performance': ['warn', {minScore: 1}],
        'categories:accessibility': ['error', {minScore: 1}]
      }
    },
    upload: {
      // ...
    },
  },
};

The console output that it generates looks like this:

For more information on Lighthouse CI assertions, refer to the documentation.

Set up a GitHub Action to run Lighthouse CI #

A GitHub Action can be used to run Lighthouse CI. This will generate a new Lighthouse report every time that a code change is pushed to any branch of a GitHub repository. Use this in conjunction with a status check to display these results on each pull request.

In the root of your repository, create a directory named .github/workflows. The workflows for your project will go in this directory. A workflow is a process that runs at a predetermined time (for example, when code is pushed) and is composed of one or more actions.
```
mkdir .github
mkdir .github/workflows
```
In .github/workflows create a file named lighthouse-ci.yaml. This file will hold the configuration for a new workflow.
```
touch lighthouse-ci.yaml
```

Add the following text to lighthouse-ci.yaml.

name: Build project and run Lighthouse CI
on: [push]
jobs:
  lhci:
    name: Lighthouse CI
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Use Node.js 10.x
        uses: actions/setup-node@v1
        with:
          node-version: 10.x
      - name: npm install
        run: |
          npm install
      - name: run Lighthouse CI
        run: |
          npm install -g @lhci/cli@0.3.x
          lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"

This configuration sets up a workflow consisting of a single job that will run whenever new code is pushed to the repository. This job has four steps:

Check out the repository that Lighthouse CI will be run against
Install and configure Node
Install required npm packages
Run Lighthouse CI and upload the results to temporary public storage.

Commit these changes and push them to GitHub. If you've correctly followed the steps above, pushing code to GitHub will trigger running the workflow you just added.
To confirm that Lighthouse CI has triggered and to view the report it generated, go to the Actions tab of your project. You should see the Build project and Run Lighthouse CI workflow listed under your most recent commit.

You can navigate to the Lighthouse report corresponding to a particular commit from the Actions tab. Click on the commit, click on the Lighthouse CI workflow step, then expand the results of the run Lighthouse CI step.

You've just set up a GitHub Action to run Lighthouse CI. This will be most useful when used in conjunction with a GitHub status check.

Set up a GitHub status check #

A status check, if configured, is a message that appears on every PR and typically includes information such as the results of a test or the success of a build.

The steps below explain how to set up a status check for Lighthouse CI.

Go to the Lighthouse CI GitHub App page and click Configure.
(Optional) If you're part of multiple organizations on GitHub, choose the organization that owns the repository for which you want to use Lighthouse CI.
Select All repositories if you want to enable Lighthouse CI in all repositories or select Only select repositories if you only want to use it in specific repositories, and then select the repositories. Then click Install & Authorize.
Copy the token that is displayed. You'll use it in the next step.
To add the token, navigate to the Settings page of your GitHub repository, click Secrets, then click Add a new secret.
Set the Name field to LHCI_GITHUB_APP_TOKEN and set the Value field to the token that you copied in the last step and then click the Add secret button.
Go to the lighthouse-ci.yaml file and add the new environment secret to the "run Lighthouse CI" command.

          - name: run Lighthouse CI
            run: |
              npm install -g @lhci/cli@0.3.x
              lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"
+            env:
+              LHCI_GITHUB_APP_TOKEN: $

The status check is ready for use. To test it, create a new pull request or push a commit to an existing pull request.

Set up the Lighthouse CI Server #

The Lighthouse CI server provides a dashboard for exploring historical Lighthouse reporting. It can also act as a private, long-term datastore for Lighthouse reports.

Choose which commits to compare.
The amount that the Lighthouse score has changed between the two commits.
This section only shows metrics that have changed between the two commits.
Regressions are highlighted in pink.
Improvements are highlighted in blue.

Lighthouse CI Server is best-suited to users who are comfortable deploying and managing their own infrastructure.

For information on setting up the Lighthouse CI server, including recipes for using Heroku and Docker for deployment, refer to these instructions.

Find out more #

Lighthouse CI GitHub repo

Getting started with measuring Web Vitals

2020-05-27T00:00:00Z

Collecting data on your site's Web Vitals is the first step towards improving them. A well-rounded analysis will collect performance data from both real-world and lab environments. Measuring Web Vitals requires minimal code changes and can be accomplished using free tooling.

Measuring Web Vitals using RUM data #

Real User Monitoring (RUM) data, also known as field data, captures the performance experienced by a site's actual users. RUM data is what Google uses to determine whether a site meets the recommended Core Web Vitals thresholds.

Getting started #

If you don't have a RUM setup, the following tools will quickly provide you with data about the real-world performance of your site. These tools are all based on the same underlying data set (the Chrome User Experience Report), but have slightly different use cases:

PageSpeed Insights (PSI): PageSpeed Insights reports on the aggregate page-level and origin-level performance over the past 28 days. In addition, it provides suggestions on how to improve performance. If you're looking for a single action to take in order to get started with measuring and improving your site's Web Vitals, we recommend using PSI to audit your site. PSI is available on the web and as an API.
Search Console: Search Console reports performance data on a per-page basis. This makes it well-suited for identifying specific pages that need improvement. Unlike PageSpeed Insights, Search Console reporting includes historical performance data. Search Console can only be used with sites that you own and have verified ownership of.
CrUX dashboard: CrUX dashboard is a pre-built dashboard that surfaces CrUX data for an origin of your choosing. It is built on top of Data Studio and the setup process takes about a minute. Compared to PageSpeed Insights and Search Console, CrUX dashboard reporting includes more dimensions - for example, data can be broken down by device and connection type.

It's worth noting that although the tools listed above are well-suited for "getting started" with measuring Web Vitals, they can be useful in other contexts as well. In particular, both CrUX and PSI are available as an API and can be used to build dashboards and other reporting.

Collecting RUM data #

Although CrUX-based tools are a good starting point for investigating Web Vitals performance, we strongly recommend supplementing it with your own RUM. RUM data that you collect yourself can provide more detailed and immediate feedback on your site's performance. This makes it easier to identify issues and test possible solutions.

You can collect your own RUM data by using a dedicated RUM provider, or, by setting up your own tooling.

Dedicated RUM providers specialize in collecting and reporting RUM data. To use Core Web Vitals with these services, ask your RUM provider about enabling Core Web Vitals monitoring for your site.

If you don't have a RUM provider, you may be able to augment your existing analytics setup to collect and report on these metrics by using the web-vitals JavaScript library. This method is explained in more detail below.

The web-vitals JavaScript library #

If you're implementing your own RUM setup for Web Vitals, the easiest way to collect Web Vitals measurements is to use the web-vitals JavaScript library. web-vitals is a small, modular library (~1KB) that provides a convenient API for collecting and reporting each of the field-measurable Web Vitals metrics.

The metrics that make up Web Vitals are not all directly exposed by the browser's built-in performance APIs - but rather built on top of them. For example, Cumulative Layout Shift (CLS) is implemented using the Layout Instability API. By using web-vitals, you don't need to worry about implementing these metrics yourself; it also ensures that the data you collect matches the methodology and best practices for each metric.

For more information on implementing web-vitals, refer to the documentation and the Best practices for measuring Web Vitals in the field guide.

Data aggregation #

It is essential that you report the measurements collected by web-vitals. If this data is measured but not reported, you'll never see it. The web-vitals documentation includes examples showing how to send the data to a generic API endpoint, Google Analytics, or Google Tag Manager.

If you already have a favorite reporting tool, consider using that. If not, Google Analytics is free and can be used for this purpose.

When considering which tool to use, it is helpful to think about who will need to have access to the data. Businesses typically achieve the biggest performance wins when the whole company, rather than a single department, is interested in improving performance. See Fixing website speed cross-functionally to learn how to get buy-in from different departments.

Data interpretation #

When analyzing performance data, it's important to pay attention to the tails of the distribution. RUM data often reveals that performance varies widely - some users have fast experiences, others have slow experiences. However, using the median to summarize data can easily mask this behavior.

With regards to Web Vitals, Google uses the percentage of "good" experiences, rather than statistics like medians or averages, to determine whether a site or page meets the recommended thresholds. Specifically, for a site or page to be considered as meeting the Core Web Vitals thresholds, 75% of page visits should meet the "good" threshold for each metric.

Measuring Web Vitals using lab data #

Lab data, also known as synthetic data, is collected from a controlled environment, rather than actual users. Unlike RUM data, lab data can be collected from pre-production environments and therefore incorporated into developer workflows and continuous integration processes. Examples of tools that collect synthetic data are Lighthouse and WebPageTest.

Considerations #

There will always be discrepancies between RUM data and lab data - particularly if the network conditions, device type, or location of the lab environment differs significantly from that of users. However, when it comes to collecting lab data on Web Vitals metrics in particular, there are a couple specific considerations that are important to note:

Cumulative Layout Shift (CLS): The Cumulative Layout Shift measured in lab environments can be artificially lower than the CLS observed in RUM data. CLS is defined as the "sum total of all individual layout shift scores for every unexpected layout shift that occurs during the entire lifespan of the page." However, the lifespan of a page is typically very different depending on whether it is being loaded by a real user or a synthetic performance measurement tool. Many lab tools only load the page - they don't interact with it. As a result, they only capture layout shifts that occur during initial page load. By contrast, the CLS measured by RUM tools captures unexpected layout shifts that occur throughout the entire lifespan of the page.
First Input Delay (FID): First Input Delay can't be measured in lab environments because it requires user interactions with the page. As a result, Total Blocking Time (TBT) is the recommended lab proxy for FID. TBT measures the "total amount of time between First Contentful Paint and Time to Interactive during which the page is blocked from responding to user input". Although FID and TBT are calculated differently, they are both reflections of a blocked main thread during the bootstrap process. When the main thread is blocked, the browser is delayed in responding to user interactions. FID measures the delay, if any, that occurs the first time a user tries to interact with a page.

Tooling #

These tools can be used to gather lab measurements of Web Vitals:

Web Vitals Chrome Extension: The Web Vitals Chrome extension measures and reports the Core Web Vitals (LCP, FID, and CLS) for a given page. This tool is intended to provide developers with real-time performance feedback as they make code changes.
Lighthouse: Lighthouse reports on LCP, CLS, and TBT, and also highlights possible performance improvements. Lighthouse is available in Chrome DevTools, as a Chrome Extension, and as an npm package. Lighthouse can also be incorporated into continuous integration workflows via Lighthouse CI.
WebPageTest: WebPageTest includes Web Vitals as a part of its standard reporting. WebPageTest is useful for gathering information on Web Vitals under particular device and network conditions.

Fix an overloaded server

2020-03-31T00:00:00Z

Overview #

This guide shows you how to fix an overloaded server in 4 steps:

Assess: Determine the server's bottleneck.
Stabilize: Implement quick fixes to mitigate impact.
Improve: Augment and optimize server capabilities.
Monitor: Use automated tools to help prevent future issues.

Assess #

When traffic overloads a server, one or more of the following can become a bottleneck: CPU, network, memory, or disk I/O. Identifying which of these is the bottleneck makes it possible to focus efforts on the most impactful mitigations.

CPU: CPU usage that is consistently over 80% should be investigated and fixed. Server performance often degrades once CPU usage reaches ~80-90%, and becomes more pronounced as usuage gets closer to 100%. The CPU utilization of serving a single request is negligible, but doing this at the scale encountered during traffic spikes can sometimes overwhelm a server. Offloading serving to other infrastructure, reducing expensive operations, and limiting the quantity of requests will reduce CPU utilization.
Network: During periods of high traffic, the network throughput required to fulfill user requests can exceed capacity. Some sites, depending on the hosting provider, may also hit caps regarding cumulative data transfer. Reducing the size and quantity of data transferred to and from the server will remove this bottleneck.
Memory: When a system doesn't have enough memory, data has to be offloaded to disk for storage. Disk is considerably slower to access than memory, and this can slow down an entire application. If memory becomes completely exhausted, it can result in Out of Memory (OOM) errors. Adjusting memory allocation, fixing memory leaks, and upgrading memory can remove this bottleneck.
Disk I/O: The rate at which data can be read or written from disk is constrained by the disk itself. If disk I/O is a bottleneck, increasing the amount of data cached in memory can alleviate this issue (at the cost of increased memory utilization). If this doesn't work, it may be necessary to upgrade your disks.

The techniques in this guide focus on addressing CPU and network bottlenecks. For most sites, CPU and network will be the most relevant bottlenecks during a traffic spike.

Running top on the affected server is a good starting place for investigating bottlenecks. If available, supplement this with historical data from your hosting provider or monitoring tooling.

Stabilize #

An overloaded server can quickly lead to cascading failures elsewhere in the system. Thus, it's important to stabilize the server before attempting to make more significant changes.

Rate Limiting #

Rate limiting protects infrastructure by limiting the number of incoming requests. This is increasingly important as server performance degrades: as response times increase, users tend to aggressively refresh the page - increasing the server load even further.

Fix #

Although rejecting a request is relatively inexpensive, the best way to protect your server is to handle rate limiting somewhere upstream from it - for instance, via a load balancer, reverse proxy, or CDN.

Instructions:

HTTP Caching #

Look for ways to more aggressively cache content. If a resource can be served from an HTTP cache (whether it's the browser cache or a CDN), then it doesn't need to be requested from the origin server, which reduces server load.

HTTP headers like Cache-Control, Expires, and ETag indicate how a resource should be cached by an HTTP cache. Auditing and fixing these headers will improve caching.

Although service workers can also be used for caching, they utilize a separate cache and are a supplement, rather than a replacement, for proper HTTP caching. For this reason, when handling an overloaded server, efforts should be focused on optimizing HTTP caching.

Diagnose #

Run Lighthouse and look at the Serve static assets with an efficient cache policy audit to view a list of resources with a short to medium time to live (TTL). For each listed resource, consider if the TTL should be increased. As a rough guideline:

Static resources should be cached with a long TTL (1 year).
Dynamic resources should be cached with a short TTL (3 hours).

Fix #

Set the Cache-Control header's max-age directive to the appropriate number of seconds.

Instructions:

Note: The max-age directive is just one of many caching directives. There are many other directives and headers that will affect the caching behavior of your application. For a more in-depth explanation of caching strategy it is highly recommended that you read HTTP Caching.

Graceful Degradation #

Graceful degradation is the strategy of temporarily reducing functionality in order to shed excess load from a system. This concept can be applied in many different ways: for example, serving a static text page instead of a full-featured application, disabling search or returning fewer search results, or disabling certain expensive or non-essential features. Emphasis should be placed on removing functionalities that can be safely and easily removed with minimal business impact.

Improve #

Use a content delivery network (CDN) #

Serving static assets can be offloaded from your server to a content delivery network (CDN), thereby reducing the load.

The primary function of a CDN is to deliver content to users quickly by providing a large network of servers that are located close to users. However, most CDNs also offer additional performance-related features like compression, load balancing, and media optimization.

Set up a CDN #

CDNs benefit from scale, so operating your own CDN rarely makes sense. A basic CDN configuration is fairly quick to set up (~30 minutes) and consists of updating DNS records to point at the CDN.

Optimize CDN Usage #

Diagnose #

Identify resources that are not being served from a CDN (but should be) by running WebPageTest. On the results page, click on the square above 'Effective use of CDN' to see the list of resources that should be served from a CDN.

WebPageTest results

Fix #

If a resource is not being cached by the CDN, check that the following conditions are met:

It has a Cache-Control: public header.
It has a Cache-Control: s-maxage, Cache-Control: max-age, or Expires header.
It has a Content-Length, Content-Range, or Transfer-Encoding header.

Scale compute resources #

The decision to scale compute resources should be made carefully. Although it is often necessary to scale compute resources, doing so prematurely can generate unnecessary architectural complexity and financial costs.

Diagnose #

A high Time To First Byte (TTFB) can be a sign that a server is nearing its capacity. You can find this information in the Lighthouse Reduce server response times (TTFB) audit.

To investigate further, use a monitoring tool to assess CPU usage. If current or anticipated CPU usage exceeds 80% you should consider increasing your servers.

Fix #

Adding a load balancer makes it possible to distribute traffic across multiple servers. A load balancer sits in front of a pool of servers and routes traffic to the appropriate server. Cloud providers offer their own load balancers (GCP, AWS, Azure) or you can set up your own using HAProxy or NGINX. Once a load balancer is in place, additional servers can be added.

In addition to load balancing, most cloud providers offer autoscaling (GCP, AWS, Azure). Autoscaling works in conjunction with load balancing - autoscaling automatically scales compute resources up and down given demand at a given time. That being said, autoscaling is not magical - it takes time for new instances to come online and it requires significant configuration. Because of the additional complexity that autoscaling entails, a simpler load balancer-based setup should be considered first.

Enable compression #

Text-based resources should be compressed using gzip or brotli. Gzip can reduce the transfer size of these resources by ~70%.

Diagnose #

Use the Lighthouse Enable text compression audit to identify resources that should be compressed.

Fix #

Enable compression by updating your server configuration. Instructions:

Optimize images and media #

Images make up the majority of the file size of most websites; optimizing images can quickly and significantly reduce the size of a site.

Diagnose #

Lighthouse has a variety of audits that flag potential image optimizations. Alternatively, another strategy is to use DevTools to identify the largest image files - these images will likely be good candidates for optimization.

Relevant Lighthouse audits:

Chrome DevTools workflow:

Log network activity
Click Img to filter out non-image resources
Click the Size column to sort the image files by size

Fix #

If you have limited time…

Focus your time on Identifying large and frequently loaded images and manually optimizing them with a tool like Squoosh. Hero images are often good candidates for optimization.

Things to keep in mind:

Size: Images should be no larger than necessary.
Compression: Generally speaking, a quality level of 80-85 will have a minimal effect on image quality while yielding a 30-40% reduction in file size.
Format: Use JPEGs for photos rather than PNG; use MP4 for animated content rather than GIF.

If you have more time…

Consider setting up an image CDN if images make up a substantial portion of your site. Image CDNs are designed for serving and optimizing images and they will offload image serving from the origin server. Setting up an image CDN is straightforward but requires updating existing image URLs to point at the image CDN.

Minify JS and CSS #

Minification removes unnecessary characters from JavaScript and CSS.

Diagnose #

Use the Minify CSS and Minify JavaScript Lighthouse audits to identify resources that are in need of minification.

Fix #

If you have limited time, focus on minifying your JavaScript. Most sites have more JavaScript than CSS, so this will be more impactful.

Monitor #

Server monitoring tools provide data collection, dashboards, and alerting regarding server performance. Their usage can help prevent and mitigate future server performance issues.

A monitoring setup should be kept as simple as possible. Excessive data collection and alerting has its costs: the greater the scope or frequency of data collection, the more expensive it is to collect and store; excessive alerting inevitably leads to ignored pages.

Alerting should use metrics that consistently and accurately detect issues. Server response time (latency) is a metric that works particularly well for this: it catches a wide variety of issues and correlates directly with user experience. Alerting based on lower-level metrics like CPU usage can be a useful supplement but will catch a smaller subset of issues. In addition, alerting should be based on the performance observed at the tail (in the other words the 95th or 99th percentiles), rather than averages. Otherwise, averages can easily obscure issues that don't affect all users.

Fix #

All major cloud providers offer their own monitoring tooling (GCP, AWS, Azure). In addition, Netdata is an excellent free and open-source alternative. Regardless of which tool you choose, you will need to install the tool's monitoring agent on each server that you want to monitor. Once complete, make sure to set up alerting.

Instructions:

How to set up Signed Exchanges using Web Packager

2020-02-19T00:00:00Z

A signed exchange (SXG) is a delivery mechanism that makes it possible to authenticate the origin of a resource independently of how it was delivered. The following instructions explain how to set up Signed Exchanges using Web Packager. Instructions are included for both self-signed and CanSignHttpExchanges certificates.

Serve SXGs using a self-signed certificate #

Using a self-signed certificate to serve SXGs is primarily used for demonstration and testing purposes. SXGs signed with a self-signed certificate will generate error messages in the browser when used outside of testing environments and should not be served to crawlers.

Prerequisites #

To follow these instructions you will need to have openssl and Go installed in your development environment.

Generate a self-signed certificate #

This section explains how to generate a self-signed certificate that can be used with signed exchanges.

Instructions #

Generate a private key.
```
openssl ecparam -out priv.key -name prime256v1 -genkey
```
The private key will be saved as a file named priv.key.
Create a certificate signing request (CSR).
```
openssl req -new -sha256 -key priv.key -out cert.csr -subj '/O=Web Packager Demo/CN=example.com'
```
A certificate signing request is a block of encoded text that conveys the information necessary to request a certificate from a certificate authority(CA). Although you will not be requesting a certificate from a CA, it is still necessary to create a certificate signing request.

The command above creates a certificate signing request for an organization named Web Packager Demo that has the common name example.com. The common name should be the fully qualified domain name of the site that contains the content that you want to package as SXG.

In a production SXG setup, this would be a site that you own. However, in a testing environment like the one described in these instructions, it can be any site.
Create a certificate that has the CanSignHttpExchanges extension.
```
openssl x509 -req -days 90 -in cert.csr -signkey priv.key -out cert.pem -extfile <(echo -e "1.3.6.1.4.1.11129.2.1.22 = ASN1:NULL\nsubjectAltName=DNS:example.com")
```
This command uses the private key and the CSR created in steps 1 and 2 to create the certificate file cert.pem. The -extfile flag associates the certificate with the CanSignHttpExchanges certificate extension (1.3.6.1.4.1.11129.2.1.22 is the object identifier for the CanSignHttpExchanges extension). In addition, the -extfile flag also defines example.com as a Subject Alternative Name.

If you are curious about the contents of cert.pem, you can view them using the following command:
```
openssl x509 -in cert.pem -noout -text
```
You are done creating private keys and certificates. You will need the priv.key and cert.pem files in the next section.

Setup the Web Packager server for testing #

Prerequisites #

Install Web Packager.

git clone https://github.com/google/webpackager.git

Build webpkgserver.
```
cd webpackager/cmd/webpkgserver
go build .
```
webpkgserver is a specific binary within the Web Packager project.
Verify that webpkgserver has been installed correctly.
```
./webpkgserver --help
```
This command should return information about the usage of webpkgserver. If this does not work, a good first troubleshooting step is to verify that your GOPATH is configured correctly.

Instructions #

Navigate to the webpkgserver directory (you might already be in this directory).
```
cd /path/to/cmd/webpkgserver
```
Create a webpkgsever.toml file by copying the example.
```
cp ./webpkgserver.example.toml ./webpkgserver.toml
```
This file contains the configuration options for webpkgserver.
Open webpkgserver.toml with an editor of your choice and make the following changes:
- Change the line #AllowTestCert = false to AllowTestCert = true.
- Change the line PEMFile = 'path/to/your.pem' to reflect the path to the PEM certificate, cert.pem, that you created. Do not change the line mentioning TLS.PEMFile—this is a different configuration option.
- Change the line KeyFile = 'priv.key' to reflect the path of the private key, priv.key, that you created. Do not change the line mentioning TLS.KeyFile—this is a different configuration option.
- Change the line #CertURLBase = '/webpkg/cert' to CertURLBase = 'data:'. CertURLBase indicates the serving location of the SXG certificate. This information is used to set the cert-url parameter in the Signature header of the SXG. In production environments, CertURLBase is used like this: CertURLBase = 'https://mysite.com/'. However, for local testing, CertURLBase = 'data:' can be used to instruct webpkgserver to use a data URL to inline the certificate in the cert-url field. For local testing, this is the most conveninent way to serve the SXG certificate.
- Change the line Domain = 'example.org' to reflect the domain that you created a certificate for. If you have followed the instructions in this article verbatim, this should be changed to example.com. webpkgserver will only fetch content from the domain indicated by webpkgserver.toml. If you try to fetch pages from a different domain without updating webpkgserver.toml, the webpkgserver logs will show the error message URL doesn't match the fetch targets.
Optional

If you want to enable or disable subresource preloading, the following webpkgserver.toml configuration options are relevant:
- To have webpkgserver insert directives for preloading stylesheet and script subresources as SXGs, change the line #PreloadCSS = false to PreloadCSS = true. In addition, change the line #PreloadJS = false to PreloadJS = true.
  
  As an alternative to using this configuration option, you can manually add Link: rel="preload" headers and <link rel="preload"> tags to a page's HTML.
- By default, webpkgserver replaces existing <link rel="preload"> tags with the equivalent <link> tags necessary for fetching this content as SXG. In doing so, webpkgserver will set the allowed-alt-sxg and header-integrity directives as needed—HTML authors do not need to add these by hand. To override this behavior and keep existing non-SXG preloads, change #KeepNonSXGPreloads (default = false) to KeepNonSXGPreloads = true. Keep in mind that enabling this option may make the SXG ineligible for the Google SXG cache per these requirements.
Start webpkgserver.
```
./webpkgserver
```
If the server has started successfully, you should see the following log messages:
```
Listening at 127.0.0.1:8080
Successfully retrieved valid OCSP.
Writing to cache in /private/tmp/webpkg
```
Your log messages may look slightly different. In particular, the directory that webpkgserver uses to cache certificates varies by operating system.

If you do not see these messages, a good first troubleshooting step is to double-check webpkgserver.toml.

If you update webpkgserver.toml you should restart webpkgserver.
Launch Chrome using the following command:
```
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
--user-data-dir=/tmp/udd \
--ignore-certificate-errors-spki-list=`openssl x509 -noout -pubkey -in cert.pem | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | base64`
```
This command instructs Chrome to ignore the certificate errors associated with cert.pem. This makes it possible to test SXGs using a test certificate. If Chrome is launched without this command, inspecting the SXG in DevTools will display the error Certificate verification error: ERR_CERT_INVALID.

Note:

You may need to adjust this command to reflect the location of Chrome on your machine, as well as the location of cert.pem. If you've done this correctly, you should see a warning displayed below the address bar. The warning should be similar to this: You are using an unsupported command-line flag: --ignore-certificate-errors-spki-list=9uxADcgc6/ho0mJLRMBcOjfBaN21k0sOInoMchr9CMY=.

If the warning does not include a hash string, you have not correctly indicated the location of the SXG certificate.
Open the DevTools Network tab, then visit the following URL: http://localhost:8080/priv/doc/https://example.com.

This makes a request to the webpackager instance running at http://localhost:8080 for a SXG containing the contents of https://example.com. /priv/doc/ is the default API endpoint used by webpackager.

The following resources are listed in the Network tab:

A resource with the type signed-exchange. This is the SXG.
A resource with the type cert-chain+cbor. This the SXG certificate. SXG certificates must use the application/cert-chain+cbor format.
A resource with the type document. This is the content that has been delivered via SXG.

If you don't see these resources, try clearing the browser cache, then reloading http://localhost:8080/priv/doc/https://example.com.

Click on the Preview tab to see more information about the Signed Exchange and its signature.

Serve signed exchanges using a `CanSignHttpExchanges` certificate #

The instructions in this section explain how to serve SXGs using a CanSignHttpExchanges certificate. Production use of SXGs requires a CanSignHttpExchanges certificate.

For the sake of brevity, these instructions are written with the assumption that you understand the concepts discussed in the Setup Signed Exchanges using a self-signed certificate section.

Prerequisites #

You have a CanSignHttpExchanges certificate. This page lists the CAs that offer this type of certificate.
If you don't have a certificate, then you can configure your webpkgserver to automatically retrieve certificates from your CA. You can follow the directions for what goes in webpkgserver.toml in this page.
Although not a requirement, it is strongly recommended that you run webpkgserver behind an edge server. If you do not use an edge server, you will need to configure the TLS.PEMFile and TLS.KeyFile options in webpkgserver.toml. By default, webpkgserver runs over HTTP. However, SXG certificates must be served over HTTPS to be considered valid by the browser. Configuring TLS.PEMFile and TLS.KeyFile allows webpkgserver to use HTTPS and therefore serve the SXG certificate directly to the browser.

Instructions #

Create a PEM file by concatenating your site's SXG certificate followed by your site's CA certificate. More instructions on this can be found here.

PEM is a file format that is commonly used as a "container" for storing multiple certificates.
Create a fresh webpkgsever.toml file by copying the example.
```
cp ./webpkgserver.example.toml ./webpkgserver.toml
```
Open webpkgserver.toml with the editor of your choice and make the following changes:
- Change the line PEMFile = cert.pem to reflect the location of the PEM file containing your full certificate chain.
- Change the line KeyFile = 'priv.key' to reflect the location of the private key corresponding to your PEM File.
- Change the line Domain = 'example.org' to reflect your site.
- (Optional) To have webpkgserver auto-renew the SXG certificate every 90 days (45 days for Google), configure the options in the [SXG.ACME] section of webpkgserver.toml. This option only applies to sites with a DigiCert or Google ACME account setup.
Configure your edge server to forward traffic to the webpkgserver instance.

There are two primary types of requests handled by webpkgserver: requests for SXGs (which are served by the /priv/doc/ endpoint) and requests for the SXG certificate (which are served by the /webpkg/cert/ endpoint). The URL rewriting rules for each of these request types varies slightly. For more information, see Running behind front end edge server.

Note:

By default, webpkgserver serves the SXG certificate at /webpkg/cert/$CERT_HASH—for example, /webpkg/cert/-0QmE0gvoedn92gtwI3s7On9zPevJGm5pn2RYhpZxgY. To generate $CERT_HASH, run the following command:
```
openssl base64 -in cert.pem -d | openssl dgst -sha256 -binary | base64 | tr /+ _- | tr -d =
```

Optimize images with Thumbor

2019-09-23T00:00:00Z

Thumbor is a free, open source image CDN that makes it easy to compress, resize, and transform images. This post lets you try out Thumbor firsthand without needing to install anything. We've set up a sandbox Thumbor server for you to try out at http://34.67.235.246:8888. The image that you're going to experiment with is available at http://34.67.235.246:8888/unsafe/https://web.dev/backdrop-filter/hero.jpg.

Prequisites #

This post assumes that you understand how image CDNs can improve your load performance. If not, check out Use image CDNs to optimize images. It also assumes that you've built basic websites before.

Thumbor URL Format #

As mentioned in Use Image CDNs to Optimize Images, each image CDN uses a slightly different URL format for images. Figure 1 represents Thumbor's format.

Thumbor's URL format

Origin #

Like all origins, the origin of a Thumbor URL is composed of three parts: a scheme (which is almost always http or https), a host, and a port. In this example, the host is identified using an IP address, but if you're using a DNS server it might look like thumbor-server.my-site.com. By default, Thumbor uses port 8888 to serve images.

Security Key #

The unsafe part of the URL indicates that you're using Thumbor without a security key. A security key prevents a user from making unauthorized changes to your image URLs. By changing the image URL, a user could use your server (and your hosting bill) to resize their images, or, more maliciously, to overload your server. This guide won't cover setting up Thumbor's security key feature.

Size #

This part of the URL specifies the desired size of the output image. This can be omitted if you don't want to change the size of the image. Thumbor will use different approaches like cropping or scaling to achieve the desired size depending on the other URL parameters. The next section of this post explains how to resize images in more detail.

Try it now:

Click the following URL to view the image served at its original size in a new tab: http://34.67.235.246:8888/unsafe/https://web.dev/backdrop-filter/hero.jpg

Original image
Resize the image to 100x100 pixels: http://34.67.235.246:8888/unsafe/100x100/https://web.dev/backdrop-filter/hero.jpg

Image resized to 100x100 pixels

Filters #

Filters transform an image. The filters part of the URL segment starts with filters: followed by a colon-separated list of filters; this can be omitted if you are not using any filters. The syntax for individual filters resembles a function call (for example grayscale()) containing zero or more arguments.

Try it now:

Apply a single filter: a Gaussian blur effect with a radius of 25 pixels: http://34.67.235.246:8888/unsafe/filters:blur(25)/https://web.dev/backdrop-filter/hero.jpg

Blurred image
Apply multiple filter. Convert to grayscale and rotate the image 90 degrees: http://34.67.235.246:8888/unsafe/filters:grayscale():blur(90)/https://web.dev/backdrop-filter/hero.jpg

Grayscale, rotated image

Transforming Images #

This section focuses on the Thumbor functionalities most relevant to performance: compression, resizing, and conversion between file formats.

Compression #

The quality filter compresses JPEG images to the desired image quality level (1-100). If no quality level is provided, Thumbor compresses the image to a quality level of 80. This is a good default: quality levels 80-85 typically have little noticeable effect on image quality, but usually decrease image size by 30-40%.

Try it now:

Compress the image to a quality of 1 (very bad): http://34.67.235.246:8888/unsafe/filters:quality(1)/https://web.dev/backdrop-filter/hero.jpg

Low-quality image
Compress the image using Thumbor's default compression settings: http://34.67.235.246:8888/unsafe/filters:quality()/https://web.dev/backdrop-filter/hero.jpg

Compressed image

Resizing #

To resize an image while maintaining its original proportions use the format $WIDTHx0 or 0x$HEIGHT within the size portion of the URL string.

Try it now:

Resize the image to a width of 200 pixels while maintaining original proportions: http://34.67.235.246:8888/unsafe/200x0/https://web.dev/backdrop-filter/hero.jpg

Image resized to a width of 200 pixels
Resize the image to a height of 500 pixels while maintaining original proportion: http://34.67.235.246:8888/unsafe/0x500/https://web.dev/backdrop-filter/hero.jpg

Image resized to a height of 500 pixels

You can also resize images to a percentage of the original by using the proportion filter. If size is specified in conjunction with the proportion filter, the image will be resized, and then the proportion filter will be applied.

Try it now:

Resize the image to 50% of the original: http://34.67.235.246:8888/unsafe/filters:proportion(.5)/https://web.dev/backdrop-filter/hero.jpg

Image resized to 50% the size of the original
Resize the image to a width of 1000 pixels, then resize the image to 10% of its current size: http://34.67.235.246:8888/unsafe/1000x/filters:proportion(.1)/https://web.dev/backdrop-filter/hero.jpg

Image resized to a width of 100 pixels

These methods are just a few of Thumbor's many cropping and resizing options. To read about other options, check out Usage.

File Formats #

The format filter converts images to jpeg, webp, gif, or png. Keep in mind that if you're optimizing for performance you should use either JPEG or WebP as PNG and GIF files tend to be significantly larger and do not compress as well.

Try it now:

Convert the image to WebP. If you open the Network panel of DevTools the document's Content-Type response header shows that the server returned a WebP image: http://34.67.235.246:8888/unsafe/filters:format(webp)/https://web.dev/backdrop-filter/hero.jpg

The content-type response header shown in DevTools

Next Steps #

Try out other filters and transformations on the hero.jpg image.

If you're following along using your own Thumbor installation, check out the appendix below that explains how and why to use the thumbor.conf file.

Appendix: `thumbor.conf` #

Many of the configuration options discussed in this post, plus many others, can be established as defaults by setting up and using a thumbor.conf configuration file. Settings in the thumbor.conf file will be applied to all images unless overridden by the URL string parameters.

Run the thumbor-config command to create a new thumbor.conf file.
```
thumbor-config > ./thumbor.conf
```
Open your new thumbor.conf file. The thumbor-config command generated a file that lists and explains all Thumbor configuration options.
Configure settings by uncommenting lines and changing the default values. You may find it useful to set the following settings:
- QUALITY
- AUTO_WEBP
- MAX_WIDTH and MAX_HEIGHT
- ALLOW_ANIMATED_GIFS
Run Thumbor with the --conf flag to use your thumbor.conf settings.
```
thumbor --conf /path/to/thumbor.conf
```

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.

How to install the Thumbor image CDN

2019-08-14T00:00:00Z

Image CDNs make it easy to dynamically optimize the aesthetics and performance of your images. Unlike most image CDNs, Thumbor is open-source and can be used for free to resize, compress, and transform images. It's suitable for production use; Wikipedia and Square both use Thumbor.

This guide explains how to install Thumbor on your own server. Once installed, you'll be able to use Thumbor as an API for transforming your images.

Intro #

You'll be installing Thumbor on a VM running Ubuntu 16.04. Ubuntu 16.04 is a very common image and these instructions are intended to work on any cloud provider. Creating a VM might sound like more work than installing Thumbor on your local machine, but the minutes that you take to create a VM will probably save you hours or days of frustration trying to get Thumbor to properly install on your local machine. Although easy to use, Thumbor is notoriously difficult to install but these instructions simplify the process. If dependencies download quickly, the installation can be completed in 5 to 10 minutes.

Prerequisites #

This post assumes that you know how to create a Ubuntu 16.04 LTS VM on a cloud platform like Google Cloud, AWS, or Azure and how to use command line tools to set up the VM.

Install Thumbor Dependencies #

Update and upgrade Ubuntu's already-installed packages:

sudo apt-get update -y && sudo apt-get upgrade -y

Install pip, the package manager for Python. Later you'll install Thumbor with pip.

sudo apt-get install -y python-pip

Install Thumbor's dependencies. Thumbor's documentation does not explicitly mention these dependencies, but Thumbor will not install successfully without them.

# ssl packages
sudo apt-get install -y libcurl4-openssl-dev libssl-dev

# computer vision packages
sudo apt-get install -y python-opencv libopencv-dev

# image format packages
sudo apt-get install -y libjpeg-dev libpng-dev libwebp-dev webp

Install Thumbor #

Install Thumbor using pip.

sudo pip install thumbor

Note: Many Python developers use virtualenv to manage their packages. For the sake of simplicity, these instructions do not use virtualenv. If you are installing Thumbor in a standalone environment, virtualenv is not necessary. If you choose to use virtualenv, note that Thumbor requires Python 2.7 and will not work with newer versions of pip (e.g., these instructions use pip 8.1.1).

If you've successfully installed Thumbor, this should work:

thumbor --help

Run Thumbor #

Run Thumbor. Debug logging is optional but can be helpful when you're getting started.

thumbor --log-level debug

Thumbor is now running.

Open Firewall Port #

By default, Thumbor runs on port 8888. If your VM's IP address is 12.123.12.122, then you would access Thumbor from the web browser at http://12.123.12.123:8888/.../$IMAGE.

However, this probably won't work for you (yet) because cloud providers usually require that you explicitly open firewall ports before they will accept incoming traffic.

Update the firewall to expose port 8888. Here's more information on how to do this for: Google Cloud, AWS, and Azure. Note that for Google Cloud you need to first assign a static IP address to your VM and then allow an external HTTP connection.

Try It Out #

Thumbor is now accessible and ready for use. Try it out by visiting the following URL:

http://YOUR_VIRTUAL_MACHINE:8888/unsafe/100x100/https://web.dev/install-thumbor/hero.jpg

Note that this URL uses HTTP. Thumbor uses HTTP by default but can be configured to use HTTPS.

You should see an image that is 100 pixels wide by 100 pixels tall. Thumbor has taken the image hero.jpg and size specified in the URL string and served the result. You can replace the image in the URL string (i.e., https://web.dev/install-thumbor/hero.jpg) with any other image (e.g., https://your-site.com/cat.jpg) and Thumbor will resize that image too.

The Optimize images with Thumbor article has more information on using the Thumbor API. In particular, you may be interested in setting up a Thumbor configuration file.

Appendix: Configuring Systemd #

This step explains how to make sure that the Thumbor process keeps running, even after the VM has been restarted. This step is important for production sites, but optional if you're just playing around with Thumbor.

Systemd is the "system and service manager" for Linux operating systems. systemd makes it easy to configure when services (processes) run.

You will be configuring systemd to automatically start Thumbor on VM boot. If the VM is restarted, the Thumbor process will automatically restart as well. This is much more reliable than relying on user intervention to start Thumbor.

Navigate to the /lib/systemd/system directory. This directory contains the service files for systemd.

cd /lib/systemd/system

As superuser, create a thumbor.service file.

sudo touch thumbor.service

Using your favorite text editor (vim and nano come pre-installed on Ubuntu or you can install another editor), add the following configuration to thumbor.service. This configuration will run /usr/local/bin/thumbor (i.e. the Thumbor binary) once networking is available and will restart Thumbor on failure.

[Unit]

Description=Service for Thumbor image CDN

Documentation=https://thumbor.readthedocs.io/en/latest/

After=network.target

[Service]

ExecStart=/usr/local/bin/thumbor

Restart=on-failure

[Install]

WantedBy=multi-user.target

systemctl is the utility used to manage systemd. Use the start command to start Thumbor.

sudo systemctl start thumbor.service

Note: If Thumbor is currently running, you should stop it before attempting to start Thumbor using systemctl.

Next, "enable" Thumbor. This means that Thumbor will automatically start on boot.

sudo systemctl enable thumbor.service

Verify that you've successfully configured systemd by running the status command.

systemctl status thumbor.service

If you've successfully set up thumbor.service to use systemd, the status should show that it is enabled and active.

Third-party contributors

2019-07-28T00:00:00Z

First, thanks for contributing to web.dev! We really appreciate your help in making this community better.

If you're not a Googler, we ask that you provide a point of contact who can respond to GitHub issues related to your content. Ideally, your point of contact will be able to respond within a week of when the issue is submitted. The web.dev team will tag the point of contact in relevant issues so that they can respond.

Tooling and libraries

2019-07-21T00:00:00Z

Choosing tooling and libraries can be one of the most overwhelming and time consuming aspects of web development. To help readers feel confident in their choices, provide instructions for well-known, well-established tools rather than an exhaustive list of options. Strike a balance between what's most commonly used and what's best practice, in terms of compatibility, accessibility, and functionality.

When appropriate, provide multiple paths, frameworks, or tools to achieve a goal. Including a codelab for each path is often a good way to achieve that goal. To see an example, check out the codelab callout at the end of the Use Imagemin to compress images post.

Use open-source software #

This keeps web.dev accessible to as many developers as possible.

Ensure tooling is well-established #

When you're planning to include tooling in a post or codelab, make sure it meets at least one of these criteria:

HTTP Archive data: Tooling is used by ≥ 10K domains.
npm weekly download statistics: Tooling consistently has ≥ 50K weekly downloads.

Include a link to the relevant data source in your content proposal.

Sometimes it's impossible to use these data sources to verify the popularity of a given tool. (For example, if you're writing an article about servers, neither data source can be used to verify the usage of NGINX.) In such cases you can demonstrate the popularity of a tool in your content proposal by listing 5–10 well-known sites that have self-identified as users.

Use Lighthouse for performance budgets

2019-06-14T00:00:00Z

Lighthouse now supports performance budgets. This feature, known as LightWallet, can be set up in under five minutes and provides feedback on performance metrics and the size and quantity of page resources.

Install Lighthouse #

LightWallet is available in the command line version of Lighthouse v5+.

To get started, install Lighthouse:

npm install -g lighthouse

Create a Budget #

Create a file named budget.json. In this file add the following JSON:

[
  {
    "path": "/*",
    "timings": [
      {
        "metric": "interactive",
        "budget": 3000
      },
      {
        "metric": "first-meaningful-paint",
        "budget": 1000
      }
    ],
    "resourceSizes": [
      {
        "resourceType": "script",
        "budget": 125
      },
      {
        "resourceType": "total",
        "budget": 300
      }
    ],
    "resourceCounts": [
      {
        "resourceType": "third-party",
        "budget": 10
      }
    ]
  }
]

This example budget.json file sets five separate budgets:

A budget of 3000ms for Time to Interactive.
A budget of 1000ms for First Meaningful Paint
A budget of 125 KB for the total amount of JavaScript on the page.
A budget of 300 KB for the overall size of the page.
A budget of 10 requests for the number of requests made to third-party origins.

For a complete list of supported performance metrics and resource types, refer to the Performance Budgets section of the Lighthouse docs.

Run Lighthouse #

Run Lighthouse using the --budget-path flag. This flag tells Lighthouse the location of your budget file.

lighthouse https://example.com --budget-path=./budget.json

View the Results #

If LightWallet has been configured correctly, the Lighthouse report will contain a Budgets section within the Performance category.

In the JSON version of the Lighthouse report, Lightwallet results can be found within the audit findings for the performance-budget audit.

Speed at scale: what's new in web performance?

2019-05-24T00:00:00Z

During the "Speed at Scale" talk at Google I/O 2019, we announced three things that we hope will improve web performance over the coming year.

Lighthouse now supports Performance Budgeting #

LightWallet is a new feature in Lighthouse that adds support for performance budgets. Performance budgets establish standards for the performance of your site. More importantly, they make it is easy to identify and fix performance regressions before they ship.

LightWallet is available in the newest version of the Lighthouse CLI and only takes a couple minutes to set up. These instructions provide more information.

Unsure what your budgets should be? Try our experimental Performance Budget Calculator which can generate a LightWallet compatible budget configuration.

Browser-level image and iframe lazy loading comes to the web #

Web pages often contain a large number of images, which contribute to data-usage, page-bloat and slower page loads. Many of these images are offscreen, requiring a user to scroll in order to view them.

Until now, you've needed to solve lazy loading images using a JavaScript library but that may soon change. This summer, Chrome will be launching support for the loading attribute which brings standardized <img> and <iframe> lazy loading to the web.

The loading attribute allows a browser to defer loading offscreen images and iframes until users scroll near them. loading supports three values:

lazy: is a good candidate for lazy loading.
eager: is not a good candidate for lazy loading. Load right away.
auto: browser will determine whether or not to lazily load.

<img src="io2019.jpg" loading="lazy" alt="..." />
<iframe src="video-player.html" loading="lazy"></iframe>

The exact heuristics for "when the user scrolls near" is left up to the browser. In general, our hope is that browsers will start fetching deferred images and iframe content a little before it comes into the viewport.

The loading attribute is implemented behind flags in Chrome Canary. You can try out this demo in Chrome 75+ with the about://flags/#enable-lazy-image-loading and about://flags/#enable-lazy-frame-loading flags turned on.

A write-up on the lazy loading feature is available with more details.

Google Fonts now supports font-display as a query parameter #

We announced support for font-display is now available in production for all Google Fonts via the display query-string parameter:

https://fonts.googleapis.com/css?family=Lobster&display=swap

The font-display descriptor lets you decide how your web fonts will render or fallback, depending on how long it takes for them to load. It supports a number of values including auto, block, swap, fallback and optional.

Previously, the only way to specify font-display for web fonts from Google Fonts was to self-host them but this change removes the need to do so.

The Google Fonts documentation has been updated to include font-display in the default code embeds (as seem below). We hope this will encourage more developers to try out this exciting addition.

Here's a demo on Glitch of using display with multiple font families. Try it out with DevTools network emulation to see the impact of font-display: swap.

Watch for more #

Our talk also covered several production case studies of using advanced performance patterns to improve user-experience. These included sites leveraging image CDNs, Brotli compression, smart JavaScript serving and prefetching to speed up their pages. Watch the talk to learn more :)

Serve responsive images

2018-11-05T00:00:00Z

Serving desktop-sized images to mobile devices can use 2–4x more data than needed. Instead of a "one-size-fits-all" approach to images, serve different image sizes to different devices.

Responsive images and Core Web Vitals #

When you serve responsive images, you're evaluating the display capabilities of the user's device and choosing one of a set of image candidates that are optimal for display based on those criteria. The result—as stated previously—is rather than delivering too much image data to devices that won't benefit from it, you're serving an appropriately sized image for the device. For smaller devices such as phones and tablets, this equates to reduced data usage as compared to devices with larger screens, such as laptops.

The effects of faster image loading can also extend to your page's Largest Contentful Paint (LCP). For example, if your page's LCP element is an image, you're reducing that LCP candidate's resource load time.

Lower resource load times will lower the load time for an LCP image, which will improve the page's LCP score. A lower LCP means users will perceive that your site is loading faster, particularly the largest piece of content visible in the viewport during page load. Serving responsive images can also reduce bandwidth contention for other resources on the page, which can improve how fast your page loads in general.

Resize images #

Two of the most popular image resizing tools are the sharp npm package and the ImageMagick CLI tool.

The sharp package is a good choice for automating image resizing (for example, generating multiple sizes of thumbnails for all the videos on your website). It is fast and easily integrated with build scripts and tools. On the other hand, ImageMagick is convenient for one-off image resizing because it is used entirely from the command line.

sharp #

To use sharp as a Node script, save this code as a separate script in your project, and then run it to convert your images:

const sharp = require('sharp');
const fs = require('fs');
const directory = './images';

fs.readdirSync(directory).forEach(file => {
  sharp(`${directory}/${file}`)
    .resize(200, 100) // width, height
    .toFile(`${directory}/${file}-small.jpg`);
  });

ImageMagick #

To resize an image to 33% of its original size, run the following command in your terminal:

convert -resize 33% flower.jpg flower-small.jpg

To resize an image to fit within 300px wide by 200px high, run the following command:

# macOS/Linux
convert flower.jpg -resize 300x200 flower-small.jpg

# Windows
magick convert flower.jpg -resize 300x200 flower-small.jpg

How many image versions should you create? #

There is no single "correct" answer to this question. However, it's common to serve 3-5 different sizes of an image. Serving more image sizes is better for performance, but will take up more space on your servers and require writing a tiny bit more HTML.

Other options #

Image services like Thumbor (open-source) and Cloudinary are also worth checking out. Image services provide responsive images (and image manipulation) on-demand. Thumbor is setup by installing it on a server; Cloudinary takes care of these details for you and requires no server setup. Both are easy ways to create responsive images.

Serve multiple image versions #

Specify multiple image versions and the browser will choose the best one to use:

Before	After
<img src="flower-large.jpg">	<img src="flower-large.jpg" srcset="flower-small.jpg 480w, flower-large.jpg 1080w" sizes="50vw">

The <img> tag's src, srcset, and sizes attributes all interact to achieve this end result.

The "src" attribute #

The src attribute makes this code work for browsers that don't support the srcset and sizes attributes. If a browser does not support these attributes, it will fall back to loading the resource specified by the src attribute.

The "srcset" attribute #

The srcset attribute is a comma-separated list of image filenames and their width or density descriptors.

This example uses width descriptors. 480w is a width descriptor tells the browser that flower-small.jpg is 480px wide; 1080w is a width descriptor tells the browser that flower-large.jpg is 1080px wide.

"Width descriptor" sounds fancy but is just a way to tell the browser the width of an image. This saves the browser from needing to download the image to determine its size.

Extra Credit: You don't need to know about density descriptors to serve different image sizes. However, if you're curious about how density descriptors work, check out the Resolution Switching code lab. Density descriptors are used to serve different images based on the device's pixel density.

The "sizes" attribute #

The sizes attribute tells the browser how wide the image will be when it is displayed. However, the sizes attribute has no effect on display size; you still need CSS for that.

The browser uses this information, along with what it knows about the user's device (i.e. its dimensions and pixel density), to determine which image to load.

If a browser does not recognize the "sizes" attribute, it will fallback to loading the image specified by the "src" attribute. (Browsers shipped support for the "sizes" and "srcset" attributes at the same time, so a browser will either support both attributes or neither.)

Extra Credit: If you want to be fancy, you can also use the sizes attribute to specify multiple slot sizes. This accommodates websites that use different layouts for different viewport sizes. Check out this multiple slot code sample to learn how to do this.

(Even more) Extra Credit #

In addition to all the extra credit already listed (images are complex!), you can also use these same concepts for art direction. Art direction is the practice of serving completely different looking images (rather than different versions of the same image) to different viewports. You can learn more in the Art Direction code lab.

Verify #

Once you've implemented responsive images, you can use Lighthouse to make sure that you didn't miss any images. Run the Lighthouse Performance Audit (Lighthouse > Options > Performance) and look for the results of the Properly size images audit. These results will list the images that need to be resized.

Serve images with correct dimensions

2018-11-05T00:00:00Z

We've all been there: you forgot to scale down an image before adding it to the page. The image looks fine, but it is wasting users' data and hurting page performance.

Identify incorrectly sized images #

Lighthouse makes it easy to identify incorrectly-sized images. Run the Performance Audit (Lighthouse > Options > Performance) and look for the results of the Properly size images audit. The audit lists any images that need to be resized.

Determine the correct image size #

Image sizing can be deceptively complicated. For this reason, we've provided two approaches: the "good" and the "better." Both will improve performance, but the "better" approach may take a bit longer to understand and implement. However, it will also reward you with bigger performance improvements. The best choice for you is the one that you feel comfortable implementing.

A quick note on CSS units #

There are two types of CSS units for specifying the size of HTML elements, including images:

Absolute units: Elements styled using absolute units will always be displayed at the same size, regardless of device. Examples of valid, absolute CSS units: px, cm, mm, in.
Relative units: Elements styled using relative units will be displayed at varying sizes, depending on the relative length specified. Examples of valid, relative CSS units: %, vw (1vw = 1% of the width of the viewport), em (1.5 em = 1.5 times font size).

The "Good" Approach #

For images with sizing based on…

Relative units: Resize the image to a size that will work across all devices.

You may find it helpful to check your analytics data (e.g. Google Analytics) to see which display sizes are commonly used by your users. Alternatively, screensiz.es provides information about the displays of many common devices.

Absolute units: Resize the image to match the size that it is displayed at.

The DevTools Elements panel can be used to determine what size an image is displayed at.

The "Better" approach #

For images with both absolute and relative sizing, use srcset and sizes attributes to serve different images to different display densities. Read the guide on responsive images.

"Display density" refers to the fact that different displays have different densities of pixels. All other things being equal, a high pixel density display will look sharper than a low pixel density display.

As a result, multiple image versions are necessary if you want users to experience the crispest possible images, regardless of the pixel density of their device.

Responsive image techniques make this possible by allowing you to list multiple image versions and for the device to choose the image that works best for it.

An image that works across all devices will be unnecessarily large for smaller devices. Responsive image techniques, specifically srcset and sizes, allow you to specify multiple image versions and for the device to choose the size that works best for it.

Resize images #

Regardless of the approach that you choose, you may find it helpful to use ImageMagick to resize your images. ImageMagick is the most popular command line tool for creating and editing images. Most people can resize images far more quickly when using the CLI than a GUI-based image editor.

Resize image to 25% the size of the original:

convert flower.jpg -resize 25% flower_small.jpg

Scale image to fit within "200px wide by 100px tall":

# macOS/Linux
convert flower.jpg -resize 200x100 flower_small.jpg

# Windows
magick convert flower.jpg -resize 200x100 flower_small.jpg

If you'll be resizing many images, you may find it more convenient to use a script or service to automate the process. You can learn more about this in the Responsive Images guide.

Avoid layout shifts by specifying dimensions #

While this guide discusses image dimensions in the context of reducing the amount of unnecessary bytes downloaded, it's important to note that reserving the correct space for images in the layout is another crucial component of minimizing a page's Cumulative Layout Shift metric. When serving images in HTML, be sure to use proper width and height attributes so that the browser knows how much space to allocate in the layout for the image:

<img src="flower.jpg" width="640" height="480" alt="A picture of a siberian iris.">

Without these attributes, or the equivalent CSS sizing, the browser has no idea how much space the image will take up until it has loaded. This will cause layout shifts in the document, which can be frustrating to users when content moves after they have started consuming it. This can result in users losing their place when reading, or to "miss" their intended hit target and end up clicking on something else they didn't intend to during page load.

An alternative to providing the width and height explicitly, is to use the CSS aspect-ratio property on the image. This has a similar effect on an element's size that width and height attributes do in the sense that the container will maintain a consistent aspect ratio. However, the difference is that this may result in a different aspect-ratio being used than the image is provided in, so you will likely want to use an object-fit setting to ensure the image is not distorted in this explicit 16/9 view:

img {
  aspect-ratio: 16 / 9;
  width: 100%;
  object-fit: cover;
}

Verify #

Once you've resized all your images, re-run Lighthouse to verify that you didn't miss anything.

Use WebP images

2018-11-05T00:00:00Z

Why should you care? #

WebP images are smaller than their JPEG and PNG counterparts—usually on the magnitude of a 25–35% reduction in filesize. This decreases page sizes and improves performance.

YouTube found that switching to WebP thumbnails resulted in 10% faster page loads.
Facebook experienced a 25-35% filesize savings for JPEGs and an 80% filesize savings for PNGs when they switched to using WebP.

WebP is an excellent replacement for JPEG, PNG, and GIF images. In addition, WebP offers both lossless and lossy compression. In lossless compression no data is lost. Lossy compression reduces file size, but at the expense of possibly reducing image quality.

Convert images to WebP #

People generally use one of the following approaches for converting their images to WebP: the cwebp command-line tool or the Imagemin WebP plugin (npm package). The Imagemin WebP plugin is generally the best choice if your project uses build scripts or build tools (e.g. Webpack or Gulp), whereas the CLI is a good choice for simple projects or if you'll only need to convert images once.

When you convert images to WebP, you have the option to set a wide variety of compression settings—but for most people the only thing you'll ever need to care about is the quality setting. You can specify a quality level from 0 (worst) to 100 (best). It's worth playing around with this, find which level is the right tradeoff between image quality and filesize for your needs.

Use cwebp #

Convert a single file, using cwebp's default compression settings:

cwebp images/flower.jpg -o images/flower.webp

Convert a single file, using a quality level of 50:

cwebp -q 50 images/flower.jpg -o images/flower.webp

Convert all files in a directory:

for file in images/*; do cwebp "$file" -o "${file%.*}.webp"; done

Use Imagemin #

The Imagemin WebP plugin can be used by itself or with your favorite build tool (Webpack/Gulp/Grunt/etc.). This usually involves adding ~10 lines of code to a build script or the configuration file for your build tool. Here are examples of how to do that for Webpack, Gulp, and Grunt.

If you are not using one of those build tools, you can use Imagemin by itself as a Node script. This script will convert the files in the images directory and save them in the compressed_images directory.

const imagemin = require('imagemin');
const imageminWebp = require('imagemin-webp');

imagemin(['images/*'], {
  destination: 'compressed_images',
  plugins: [imageminWebp({quality: 50})]
}).then(() => {
  console.log('Done!');
});

Serve WebP images #

If your site only supports WebP compatible browsers, you can stop reading. Otherwise, serve WebP to newer browsers and a fallback image to older browsers:

Before:

<img src="flower.jpg" alt="">

After:

<picture>
  <source type="image/webp" srcset="flower.webp">
  <source type="image/jpeg" srcset="flower.jpg">
  <img src="flower.jpg" alt="">
</picture>

The <picture>, <source>, and <img> tags, including how they are ordered relative to each other, all interact to achieve this end result.

`<picture>` #

The <picture> tag provides a wrapper for zero or more <source> tags and one <img> tag.

`<source>` #

The <source> tag specifies a media resource.

The browser uses the first listed source that's in a format it supports. If the browser does not support any of the formats listed in the <source> tags, it falls back to loading the image specified by the <img> tag.

`<img>` #

The <img> tag is what makes this code work on browsers that don't support the <picture> tag. If a browser does not support the <picture> tag, it will ignore the tags it doesn't support. Thus, it only "sees" the <img src="flower.jpg" alt=""> tag and loads that image.

Reading the HTTP `Accept` header #

If you have an application back end or web server that allows you to rewrite requests, you can read the value of the HTTP Accept header, which will advertise what alternative image formats are supported:

Accept: image/webp,image/svg+xml,image/*,*/*;q=0.8

Reading this request header and rewriting the response based on its contents has the benefit of simplifying your image markup. <picture> markup can get rather long with many sources. Below is an Apache mod_rewrite rule that can serve WebP alternates:

RewriteEngine On
RewriteCond %{HTTP:Accept} image/webp [NC]
RewriteCond %{HTTP:Content-Disposition} !attachment [NC]
RewriteCond %{DOCUMENT_ROOT}/$1.webp -f [NC]
RewriteRule (.+)\.(png|jpe?g)$ $1.webp [T=image/webp,L]

If you go this route, you'll need to set the HTTP Vary response header to ensure caches will understand that the image may be served with varying content types:

<FilesMatch ".(jpe?g|png)$">
  <IfModule mod_headers.c>
    Header set Vary "Content-Type"
  </IfModule>
</FilesMatch>

The rewrite rule above will look for a WebP version of any requested JPEG or PNG image. If a WebP alternate is found, it will be served with the proper Content-Type header. This will allow you to use image markup similar to the following with automatic WebP support:

<img src="flower-320w.jpg" srcset="flower-320w.jpg 320w, flower-640w.jpg 640w, flower-960w.jpg 960w">

Verify WebP usage #

Lighthouse can be used to verify that all images on your site are being served using WebP. Run the Lighthouse Performance Audit (Lighthouse > Options > Performance) and look for the results of the Serve images in next-gen formats audit. Lighthouse will list any images that are not being served in WebP.

Use Imagemin to compress images

2018-11-05T00:00:00Z

Why should you care? #

Uncompressed images bloat your pages with unnecessary bytes. Because images can be candidates for Largest Contentful Paint (LCP), those unnecessary bytes can add unnecessary resource load time, which can result in longer LCP times.

The photo on the right is 40% smaller than the one on the left, yet would probably look identical to the average user.

20 KB	12 KB

Measure #

Run Lighthouse to check for opportunities to improve page load by compressing images. These opportunities are listed under "Efficiently encode images":

Imagemin #

Imagemin is an excellent choice for image compression because it supports a wide variety of image formats and is easily integrated with build scripts and build tools. Imagemin is available as both a CLI and an npm module. Generally, the npm module is the best choice because it offers more configuration options, but the CLI can be a decent alternative if you want to try Imagemin without touching any code.

Plugins #

Imagemin is built around "plugins." A plugin is an npm package that compresses a particular image format (e.g. "mozjpeg" compresses JPEGs). Popular image formats may have multiple plugins to pick from.

The most important thing to consider when choosing a plugin is whether it is "lossy" or "lossless." In lossless compression, no data is lost. Lossy compression reduces file size, but at the expense of possibly reducing image quality. If a plugin doesn't mention whether it is "lossy" or "lossless," you can tell by its API: if you can specify the image quality of the output, then it is "lossy."

For most people, lossy plugins are the best choice. They offer significantly greater filesize savings, and you can customize the compression levels to meet your needs. The table below lists popular Imagemin plugins. These aren't the only plugins available, but they'd all be good choices for your project.

Image Format	Lossy Plugin(s)	Lossless Plugin(s)
JPEG	imagemin-mozjpeg	imagemin-jpegtran
PNG	imagemin-pngquant	imagemin-optipng
GIF	imagemin-giflossy	imagemin-gifsicle
SVG	imagemin-svgo
WebP	imagemin-webp	imagemin-webp

Imagemin CLI #

The Imagemin CLI works with 5 different plugins: imagemin-gifsicle, imagemin-jpegtran, imagemin-optipng, imagemin-pngquant, and imagemin-svgo. Imagemin uses the appropriate plugin based on the image format of the input.

To compress the images in the "images/" directory and save them to the same directory, run the following command (overwrites the original files):

$ imagemin images/* --out-dir=images

Imagemin npm module #

If you use one of these build tools, checkout the codelabs for Imagemin with webpack, gulp, or grunt.

You can also use Imagemin by itself as a Node script. This code uses the "imagemin-mozjpeg" plugin to compress JPEG files to a quality of 50 ('0' being the worst; '100' being the best):

const imagemin = require('imagemin');
const imageminMozjpeg = require('imagemin-mozjpeg');

(async() => {
  const files = await imagemin(
      ['source_dir/*.jpg', 'another_dir/*.jpg'],
      {
        destination: 'destination_dir',
        plugins: [imageminMozjpeg({quality: 50})]
      }
  );
  console.log(files);
})();

Avoid invisible text during font loading

2018-11-05T00:00:00Z

Why should you care? #

Fonts are often large files that take awhile to load. To deal with this, some browsers hide text until the font loads (the "flash of invisible text"). If you're optimizing for performance, you'll want to avoid the "flash of invisible text" and show content to users immediately using a system font (the "flash of unstyled text").

Display text immediately #

This guide outlines two ways to achieve this: the first approach is very simple but does not have universal browser support; the second approach is more work but has full browser support. The best choice for you is the one that you'll actually implement and maintain.

Option #1: Use font-display #

Before	After
`@font-face { font-family: Helvetica; }`	`@font-face { font-family: Helvetica; font-display: swap; }`

font-display is an API for specifying font display strategy. swap tells the browser that text using this font should be displayed immediately using a system font. Once the custom font is ready, the system font is swapped out.

Browser support

Chrome 60, Supported 60
Firefox 58, Supported 58
Edge 79, Supported 79
Safari 11.1, Supported 11.1

Source

If a browser does not support font-display, the browser continues to follow its default behavior for loading fonts.

These are the default font-loading behaviors for common browsers:

Browser	Default behavior if font is not ready…
Edge	Uses a system font until font is ready. Swaps out font.
Chrome	Will hide text for up to 3 seconds. If text is still not ready, uses a system font until font is ready. Swaps out font.
Firefox	Will hide text for up to 3 seconds. If text is still not ready, uses a system font until font is ready. Swaps out font.
Safari	Hides text until font is ready.

Option #2: Wait to use custom fonts until they are loaded #

With a bit more work, the same behavior can be implemented to work across all browsers.

There are three parts to this approach:

Don't use a custom font on initial page load. This ensures that the browser displays text immediately using a system font.
Detect when your custom font is loaded. This can be accomplished with a couple lines of JavaScript code, thanks to the FontFaceObserver library.
Update page styling to use the custom font.

Here are the changes you can expect to make to implement this:

Refactor your CSS to not use a custom font on initial page load.
Add a script to your page. This script detects when the custom font is loaded and then will update the page styling.

Verify #

Run Lighthouse to verify the site is using font-display: swap to display text:

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Lighthouse tab.
Make sure the Performance checkbox is selected in the Categories list.
Click the Generate report button.

Confirm that the Ensure text remains visible during webfont load audit is passing.

Art direction

2018-11-05T00:00:00Z

Try out this demo #

To preview the site, press View App. Then press Fullscreen .
Reload the app using different browser sizes. Notice how different the images are: they're not only different sizes but also different croppings and aspect ratios.

What's going on here? #

Art direction shows different images on different display sizes.

A responsive image loads different sizes of the same image. Art direction takes this a step further and loads completely different images depending on the display.

Use art direction to improve visual presentation. For example, the different image croppings in this demo ensure that the point of interest (the flower) is always shown in detail, regardless of the display. Art direction's benefits are purely aesthetic; it provides no performance benefit over responsive images.

View the code #

View index.html to see the art direction code for this demo.

How the code works #

Art direction uses the <picture>, <source>, and <img> tags.

picture

The <picture> tag provides a wrapper for zero or more <source> tags and one <image> tag.

source

The <source> tag specifies a media resource.

The browser uses the first <source> tag with a media query that returns true. If none of the media queries match, the browser falls back to loading the image specified by the <img>. tag.

img

The <img> tag makes this code work on browsers that don't support the <picture> tag.

If a browser does not support the <picture> tag, it loads the image specified by the <img> tag.

Avoid flash of invisible text

2018-11-05T00:00:00Z

This code lab shows you how to display text immediately using Font Face Observer.

Add Font Face Observer #

Font Face Observer is a script that detects when a font loads. The fontfaceobserver.js file has already been saved to the project directory, so you don't need to add it separately. However, you do need to add a script tag for it.

Click Remix to Edit to make the project editable.
Add a script tag for fontfaceobserver.js to index.html:

  <div class="text">Some text.</div>
  <script src="fontfaceobserver.js" type="text/javascript"></script>
</body>

Use Font Face Observer #

Create Observers #

Create an observer for each font family that it is used on the page.

Add the following script after the fontfaceobserver.js script. This creates observers for the "Pacifico" and "Roboto" font families:

  <script src="fontfaceobserver.js" type="text/javascript"></script>
  <script type="text/javascript">
    const pacificoObserver = new FontFaceObserver('Pacifico');
    const robotoObserver = new FontFaceObserver('Roboto');
  </script>
<body>

If you're ever unsure what font face observers you need to create, just look for the font-family declarations in your CSS. Pass the font-family name of these declarations to FontFaceObserver(). There is no need to create a font observer for fallback fonts.

For example, if your CSS was:

font-family: "Times New Roman", Times, serif;

you would add FontFaceObserver('Times New Roman'). Times and serif are fallback fonts, so you would not need to declare FontFaceObservers for them.

Detect font load #

The code for detecting a font load looks like this:

robotoObserver.load().then(function(){
  console.log("Hooray! Font loaded.");
});

robotoObserver.load() is a promise that resolves when the font loads.

The demo site uses two different fonts, so you need to use Promise.all() to wait until both fonts have loaded.

Add this promise to your script, right below the FontFaceObservers that you just declared:

Promise.all([
  pacificoObserver.load(),
  robotoObserver.load()
]).then(function(){
  /* Do things */
});

✔️Check-in #

Your script should now look like this:

<script type="text/javascript">
const pacificoObserver = new FontFaceObserver('Pacifico');
const robotoObserver = new FontFaceObserver('Roboto');

Promise.all([
  pacificoObserver.load(),
  robotoObserver.load()
]).then(function(){
  /* Do things */
});
</script>

Apply `fonts-loaded` class #

Replace the /* Do things */ comment in the script with this line:

document.documentElement.classList.add("fonts-loaded");

This adds the fonts-loaded class to the document's root element (the <html> tag) once both fonts have loaded.

✔️Check-in #

Your completed script should look like this:

<script type="text/javascript">
  const pacificoObserver = new FontFaceObserver('Pacifico');
  const robotoObserver = new FontFaceObserver('Roboto');

  Promise.all([
    pacificoObserver.load(),
    robotoObserver.load()
  ]).then(function(){
    document.documentElement.className += " fonts-loaded";
  });
</script>

Update CSS #

Your page should be styled to use a system font initially and custom fonts once the fonts-loaded class has been applied.

Update the CSS:

.header {
html.fonts-loaded .header {
  font-family: 'Pacifico', cursive;
}

.text
html.fonts-loaded .text {
  font-family: 'Roboto', sans-serif;
}

Verify #

To preview the site, press View App. Then press Fullscreen .

If the page looks like this, then you've successfully implemented Font Face Observer and gotten rid of the "Flash of Invisible Text."

Use density descriptors

2018-11-05T00:00:00Z

Explore This Demo #

To preview the site, press View App. Then press Fullscreen .
Reload the page using different devices to see the browser load different images.

You can use the device emulator for this. If you're looking for specific display densities, here are some devices to try:

1x density	Blackberry Playbook, many external monitors
2x density	iPad or IPhone 5/6
3x density	Galaxy S5 or iPhone X

Checkout index.html for the code that makes this work.

How does it work? #

The concept of density descriptors may be unfamiliar to most folks. To better understand them, it helps to have a bit of background on how the browser works with pixels.

What are pixels #

Let's start at the very beginning by defining what a pixel is. This sounds simple, but "pixel" can actually have many meanings:

Device pixel (a.k.a. "physical pixel"): The smallest dot of color that can be displayed on a device.
Logical pixel: Information that specifies the color at a particular location on a grid. This type of pixel has no inherent physical size.
CSS pixel: The CSS spec defines a pixel as a unit of physical measurement. 1 pixel = 1/96th of an inch.

Pixel Density #

Pixel density (also referred to as "screen density" or "display density") measures the density of device pixels in a given physical area. This is commonly measured using pixels per inch (ppi).

For many years, 96 ppi was a very common display density (hence CSS defining a pixel as 1/96th of an inch). Starting in the 1980s it was the default resolution of Windows. In addition, it was the resolution of CRT monitors.

This began to change as LED monitors became common in the 2000s. In particular, Apple made a big splash in 2010 when it introduced Retina displays. These displays had a minimum resolution of 192 ppi, which was twice the resolution of "regular" displays (192 ppi/96 ppi = 2).

window.devicePixelRatio #

With the introduction of newer display technology, "device pixels" began to vary in physical size and shape and were no longer the same size as "CSS pixels". The need to define the relationship between the size of "device pixels" and "CSS pixels" is what led to the introduction of the devicePixelRatio (sometimes called the "CSS Pixel Ratio").

devicePixelRatio defines the relationship between device pixels and CSS pixels for a particular device. A 192 ppi device has a devicePixelRatio of 2 (192 ppi/96 ppi = 2) because "2 of its display pixels are the size of 1 CSS pixel".

These days most devices have a device-pixel-ratio between 1.0 and 4.0.

Determine the pixel density of a device by typing window.devicePixelRatio in the console.
View this table to see the pixel ratios of common devices. Most are between 1.0 and 4.0.

So how do you actually apply this information?

Size images based on device-pixel-ratios #

In order for images to look their very best on high resolution screens, it's necessary to provide different image versions for different devicePixelRatios.

Device Pixel Ratio	Indicates that:	On this device, an <img> tag with a CSS width of 250 pixels, will look best when the source image is...
1	1 device pixel = 1 CSS pixel	250 pixels wide
2	2 device pixels = 1 CSS pixel	500 pixels wide
3	3 device pixels = 1 CSS pixel	750 pixels wide

Things to note:

The pixel dimensions listed in image editors, file directories, and other places are a measurement of logical pixels.
For higher resolution screens and larger displays you'll need images with larger dimensions. Merely enlarging smaller images defeats the purpose of serving multiple image versions. The browser would have done this anyway if a high resolution image was not provided.

Use Density Descriptors to serve multiple
images #

Density descriptors, in conjunction with the "srcset " attribute, can be used to serve different images to different devicePixelRatios.

Take a look at the index.html file and note the <img> element.

<img src="flower.jpg"
  srcset="flower-1x.jpg 1x,
          flower-2x.jpg 2x,
          flower-3x.jpg 3x">

This example put into words:

1x, 2x, and 3x are all density descriptors that tell the browser the pixel density that an image is intended for. This saves the browser from needing to download an image to determine this information.
The browser can choose between three images: flower-1x.jpg (intended for browsers with a 1.0 pixel density), flower-2x.jpg (intended for browsers with a 2.0 pixel density), and flower-3x.jpg (intended for browsers with a 3.0 pixel density).
flower.jpg is the fallback image for browsers that do not support srcset.

How to use this:

Use a devicePixelRatio and the x unit to write density descriptors. For example, the density descriptor for many Retina screens (window.devicePixelRatio = 2) would be written as 2x.
If a density descriptor isn't provided, it is assumed to be 1x.
Including density descriptors in filenames is a common convention (and will help you keep track of files) but is not necessary. Images can have any filename.
There is no need to include a sizes attribute. The sizes attribute is only used with width descriptors.

Using Imagemin with Grunt

2018-11-05T00:00:00Z

Setup the Imagemin Grunt plugin #

This Glitch already contains grunt, grunt-cli, and the grunt-contrib-imagemin plugin. To add the configuration for Imagemin, you'll need to edit your gruntfile.js file.

Click Remix to Edit to make the project editable.
In gruntfile.js, replace the //Add configuration here comment with this code block:

imagemin: {
  dynamic: {
    files: [{
      cwd: 'images/',
      expand: true,
      src: ['**/*.{png,jpg}'],
    }]
  }
}

This code block tells Grunt which files should be compressed with Imagemin.

dynamic indicates that the list of files to compress will be dynamically generated by matching the filenames against the specified file pattern.
The file pattern {cwd: 'images/', expand: true, src: ['**/*.{png,jpg}']} will match all the JPEG and PNG images in the images/ directory.

Load the Imagemin task by adding this line immediately before grunt.registerTask(...):

grunt.loadNpmTasks('grunt-contrib-imagemin');
grunt.registerTask('default', [/* list plugins here */]);

Lastly, add Imagemin as the default Grunt task by replacing the /* list plugins here */ comment with 'imagemin'. That line should now look like this:

grunt.registerTask('default', ['imagemin']);

✔︎ Check-in #

The complete gruntfile.js file should now look like this:

const grunt = require('grunt')
grunt.initConfig({
  imagemin: {
    dynamic: {
      files: [{
        cwd: 'images/'
        expand: true,
        src: ['**/*.{png,jpg}'],
      }]
    }
  }
});
grunt.loadNpmTasks('grunt-contrib-imagemin');
grunt.registerTask('default', ['imagemin']);

Customize your Imagemin Configuration #

imagemin-pngquant is a plugin for specifying compression quality levels. We've already added imagemin-pngquant to this project in the package.json file so that you can use it to compress your PNGs. To use it, declare the plugin and specify a compression quality level in your Gruntfile.

Declare the imagemin-pngquant plugin by adding this line to the top of your gruntfile.js:

const pngquant = require('imagemin-pngquant');
const grunt = require('grunt')
grunt.initConfig({
  ...

Add settings for compressing PNG images by adding an options property to the imagemin object. That options property should look like this:

grunt.initConfig({
  imagemin: {
    options: {
      use: [
        pngquant({quality: [0.5, 0.5]}),
      ]
    },
    dynamic: {
  ...

This code tells Imagemin to compress PNGs using the Pngquant plugin. The quality field uses a min and max range of values to determine the compression level—0 is the lowest and 1 is the highest. To force all images to be compressed at 50% quality, pass 0.5 as both the min and max value.

✔︎ Check-in #

Your gruntfile.js file should now look like this:

const pngquant = require('imagemin-pngquant');
const grunt = require('grunt')
grunt.initConfig({
  imagemin: {
    options: {
      use: [
        pngquant({quality: [0.5, 0.5]}),
      ]
    },
    dynamic: {
      files: [{
        cwd: 'images/',
        expand: true,
        src: ['**/*.{png,jpg}'],
      }]
    }
  }
});
grunt.loadNpmTasks('grunt-contrib-imagemin');
grunt.registerTask('default', ['imagemin']);

But what about JPEGs? The project also has JPEG images, so you should specify how they are compressed as well.

Customize your Imagemin configuration (continued) #

Use the imagemin-mozjpeg plugin, which has already been installed for you, to compress JPEG images.

Declare the imagemin-mozjpeg plugin by putting this line at the top your gruntfile.js.

const mozjpeg = require('imagemin-mozjpeg');
const pngquant = require('imagemin-pngquant');
const grunt = require('grunt');

Next, add mozjpeg({quality: 50}) to the array in the options object. That array should now look like this:

grunt.initConfig({
  imagemin: {
    options: {
      use: [
        pngquant({quality: [0.5, 0.5]}),
        mozjpeg({quality: 50})
      ]
    },
    dynamic: {

✔︎ Check-in #

Your gruntfile.js file should now look like this:

const mozjpeg = require('imagemin-mozjpeg');
const pngquant = require('imagemin-pngquant');
const grunt = require('grunt');
grunt.initConfig({
  imagemin: {
    options: {
      use: [
        pngquant({quality: [0.5, 0.5]}),
        mozjpeg({quality: 50})
      ]
    },
    dynamic: {
      files: [{
        cwd: 'images/',
        expand: true,
        src: ['**/*.{png,jpg}'],
      }]
    }
  }
});
grunt.loadNpmTasks('grunt-contrib-imagemin');
grunt.registerTask('default', ['imagemin']);

Run Grunt & verify results with Lighthouse #

Click the Tools button.
Then click the Console button.
Run Grunt by typing the following command into the console:

grunt

When Grunt completes you should see a message like this in console:

Minified 6 images (saved 667 kB - 66.5%)

Hooray! These results are much better.

Lastly, it's a good idea to use Lighthouse to verify the changes that you just made. Lighthouse's "Efficiently encode images" performance audit will let you know if the JPEG images on your page are optimally compressed.

To preview the site, press View App. Then press Fullscreen .
Run the Lighthouse performance audit (Lighthouse > Options > Performance) on the live version of your Glitch and verify that the "Efficiently encode images" audit was passed.

Success! You have used Imagemin to optimally compress the images on your page.

Using Imagemin with Gulp

2018-11-05T00:00:00Z

Setup the Imagemin Gulp plugin #

This Glitch already contains gulp, gulp-cli, and the gulp-imagemin plugin. To add the configuration for Imagemin, you'll need to edit your gulpfile.js file.

Click Remix to Edit to make the project editable.
First, initialize the gulp-imagemin plugin by adding this code at the top of gulpfile.js:

const imagemin = require('gulp-imagemin');

Next, replace the //Add tasks here comment in gulpfile.js with this code block:

gulp.src('images/*')
  .pipe(imagemin())
  .pipe(gulp.dest('images/'))

This code adds a Gulp task that uses Imagemin to compress the images in the images/ directory. The original images are overwritten and saved in the same images/ directory.

✔︎ Check-in #

Your gulpfile.js file should now look like this:

const imagemin = require('gulp-imagemin');
const gulp = require('gulp');

gulp.task('default', () => {
  gulp.src('images/*')
    .pipe(imagemin())
    .pipe(gulp.dest('images/'))
});

You now have a gulpfile.js that can be used to compress images.

Run Gulp #

Click the Tools button.
Then click the Console button.
Run Gulp to compress your images by typing the following command into the console:

gulp

When Gulp completes, you should see a message like this in the terminal:

gulp-imagemin: Minified 6 images (saved 50 kB—14.8%)

A 15% improvement in file size is a good start; however, more improvements can be made by using different compression settings.

Customize your Imagemin Configuration #

Declare the imagemin-pngquant plugin by adding this line to the top of your gulpfile.js:

const pngquant = require('imagemin-pngquant');

Add the imagemin-pngquant plugin (and its settings) by passing the following array to ImageminPlugin():

[pngquant({quality: [0.5, 0.5]})]

✔︎ Check-in #

Your gulpfile.js file should now look like this:

const pngquant = require('imagemin-pngquant');
const imagemin = require('gulp-imagemin');
const gulp = require('gulp');

gulp.task('default', () => {
  gulp.src('images/*')
    .pipe(imagemin([
      pngquant({quality: [0.5, 0.5]})
    ]))
    .pipe(gulp.dest('images/'))
});

But what about JPGs? The project also has JPG images; these need to be compressed too.

Customize your Imagemin Configuration (continued) #

Use the imagemin-mozjpeg plugin, which has already been installed for you, to compress JPG images.

Declare the imagemin-mozjpeg plugin by putting this line at the top your gulpfile.js.

const mozjpeg = require('imagemin-mozjpeg');

Next, add mozjpeg({quality: 50}) to the array that's passed to ImageminPlugin():

[
  pngquant({quality: [0.5, 0.5]}),
  mozjpeg({quality: 50})
]

✔︎ Check-in #

Your gulpfile.js file should now look like this:

const mozjpeg = require('imagemin-mozjpeg')
const pngquant = require('imagemin-pngquant');
const imagemin = require('gulp-imagemin');
const gulp = require('gulp');

gulp.task('default', () => {
  gulp.src('images/*')
    .pipe(imagemin([
      pngquant({quality: [0.5, 0.5]}),
      mozjpeg({quality: 50})
    ]))
    .pipe(gulp.dest('images/'))
});

Re-run Gulp & verify results with Lighthouse #

Re-run Gulp:

gulp

When Gulp completes, you should see a message like this in terminal:

gulp-imagemin: Minified 6 images (saved 667 kB—66.5%)

Hooray! These results are much better.

Lastly, it's a good idea to use Lighthouse to verify the changes that you just made.

Lighthouse's "Efficiently encode images" performance audit can let you know if the JPEG images on your page are optimally compressed.

To preview the site, press View App. Then press Fullscreen .
Run the Lighthouse performance audit (Lighthouse > Options > Performance) on the live version of your Glitch and verify that the "Efficiently encode images" audit was passed.

Success! You have used Imagemin to optimally compress the images on your page.

Using Imagemin with webpack

2018-11-05T00:00:00Z

Set up the Imagemin webpack plugin #

This Glitch already contains webpack, webpack-cli, and imagemin-webpack-plugin. To add the configuration for Imagemin, you'll need to edit your webpack.config.js file.

The existing webpack.config.js for this project has been copying images from the images/ directory to the dist/ directory but it hasn't been compressing them.

Click Remix to Edit to make the project editable.

First, declare the Imagemin plugin by adding this code at the top of webpack.config.js:

const ImageminPlugin = require('imagemin-webpack-plugin').default;

Next, add the following code as the last item in the plugins[] array. This adds Imagemin to the list of plugins that webpack uses:

new ImageminPlugin()

✔︎ Check-in #

Your complete webpack.config.js file should now look like this:

const ImageminPlugin = require('imagemin-webpack-plugin').default;
const CopyWebpackPlugin = require('copy-webpack-plugin');
const path = require('path');

module.exports = {
  entry: './index.js',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
     new CopyWebpackPlugin([{
       from: 'img/**/**',
       to: path.resolve(__dirname, 'dist')
     }]),
     new ImageminPlugin()
  ]
}

You now have a webpack config that compresses images using Imagemin.

Run webpack #

Click Terminal (note: if the Terminal button does not show you may need to use the Fullscreen option).

To compress your images, run webpack by typing the following command into the console:

webpack --config webpack.config.js --mode development

But what happens if you run webpack in production mode?

Re-run webpack, but this time in production mode:

webpack --config webpack.config.js --mode production

This time around, webpack displays a warning letting you know that your PNG files, in spite of some compression, still exceed the recommended size limit. (webpack's development & production modes prioritize different things, which is why you only see this warning while running webpack in production mode.)

Customize our Imagemin configuration to fix this warning.

Customize your Imagemin Configuration #

Add settings for compressing PNG images by passing the following object to ImageminPlugin():

{pngquant: ({quality: [0.5, 0.5]})}

✔︎ Check-in #

Your webpack.config.js file should now look like this:

const ImageminPlugin = require('imagemin-webpack-plugin').default;
const CopyWebpackPlugin = require('copy-webpack-plugin');
const path = require('path');

module.exports = {
  entry: './index.js',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CopyWebpackPlugin([{
		from: 'img/**/**',
    	to: path.resolve(__dirname, 'dist')
    }]),
    new ImageminPlugin({
      pngquant: ({quality: [0.5, 0.5]}),
	  })
  ]
}

But what about JPEGs? The project also has JPEG images, so you should specify how they are compressed as well.

Customize your Imagemin Configuration (continued) #

Instead of using imagemin-webpack-plugin's default plugin for JPG compression (imagemin-jpegtran), use the imagemin-mozjpeg plugin. Unlike Jpegtran, Mozjpeg let's you specify a compression quality for your JPG compression. We've already installed the Mozjpeg plugin for you in this Glitch, but you'll need to edit your webpack.config.js file:

Initialize the imagemin-mozjpeg plugin by adding the following line at the top of your webpack.config.js file:

const imageminMozjpeg = require('imagemin-mozjpeg');

Add a plugins property to the object passed to ImageminPlugin(), such that the object now looks like this:

new ImageminPlugin({
  pngquant: ({quality: [0.5, 0.5]}),
  plugins: [imageminMozjpeg({quality: 50})]
})

This code tells webpack to compress JPGs to a quality of 50 (0 is the worst; 100 is the best) using the Mozjpeg plugin.

If you're adding settings for a plugin that is a default plugin of imagemin-webpack-plugin, they can be added as a key-object pair on the object passed to ImageminPlugin(). The settings for Pnquant are a good example of this.

However, if you're adding settings for non-default plugins (for example, Mozjpeg), they should be added by including them in the array corresponding to the plugins property.

✔︎ Check-in #

Your code should now look like this:

const imageminMozjpeg = require('imagemin-mozjpeg');
const ImageminPlugin = require('imagemin-webpack-plugin').default;
const CopyWebpackPlugin = require('copy-webpack-plugin');
const path = require('path');

module.exports = {
  entry: './index.js',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist')
  },
  plugins: [
    new CopyWebpackPlugin([{
      from: 'img/**/**',
      to: path.resolve(__dirname, 'dist')
    }]),
    new ImageminPlugin({
      pngquant: ({quality: [0.5, 0.5]}),
      plugins: [imageminMozjpeg({quality: 50})]
    })
  ]
}

Re-run webpack and verify results with Lighthouse #

In the console, re-run webpack:

webpack --config webpack.config.js --mode production

Hooray! Your changes should have fixed the webpack warnings.

webpack warns you about large images, but it can't tell you if images are uncompressed or undercompressed. This is why it's always a good idea to use Lighthouse to verify your changes.

Lighthouse's "Efficiently encode images" performance audit can let you know if the JPEG images on your page are optimally compressed.

To preview the site, press View App. Then press Fullscreen .
Run the Lighthouse performance audit (Lighthouse > Options > Performance) on the live version of your Glitch and verify that the Efficiently encode images audit was passed.

Success! You have used Imagemin to optimally compress the images on your page.

Serve images with correct dimensions

2018-11-05T00:00:00Z

Run Lighthouse #

This Glitch is small enough that its images could be inspected by hand. However for most websites, using a tool like Lighthouse to automate this is essential.

To preview the site, press View App. Then press Fullscreen .
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Lighthouse tab.
Make sure the Performance checkbox is selected in the Categories list.
Click the Generate report button.
Look for the results of the Properly Size Images audit.

The Lighthouse audit shows that both of this page's images need to be resized.

Fix `flower_logo.png` #

Start at the top of the page and fix the logo image.

Inspect flower_logo.png in the DevTools Elements panel.

This is the CSS for flower_logo.png:

.logo {
  width: 50px;
  height: 50px;
}

The CSS width of this image is 50 pixels, so flower_logo.png should be resized to match. You can use ImageMagick to resize the image to fit. ImageMagick is a CLI tool for image editing that comes pre-installed in the codelab environment.

Click Remix to Edit to make the project editable.
Click Terminal (note: if the Terminal button does not show you may need to use the Fullscreen option).
In the console, type:

convert flower_logo.png -resize 50x50 flower_logo.png

Fix flower_photo.jpg #

Next, fix the photo of the purple flowers.

Inspect flower_photo.jpg in the DevTools elements panel.

This is the CSS for flower_photo.jpg:

.photo {
  width: 50vw;
  margin: 30px auto;
  border: 1px solid black;
}

50vw sets the CSS width of flower_photo.jpg to "half the width of the browser." (1vw is equal to 1% the width of the browser).

The ideal size for this image would depend on the device it is being viewed on, so you should resize it to a size that works well for most of your users. You can check your analytics data to learn which screen resolutions are common amongst your users:

This data indicates that 95%+ of the visitors to this site use screen resolutions 1920 pixels wide or less.

Using this information we can calculate how wide the image should be: (1920 pixels wide) * (50% of browser width) = 960 pixels

On resolutions greater than 1920 pixels wide, the image will be stretched to cover the area. The resized image is still fairly large, so the effects of this should not be very noticeable.

Use ImageMagick to resize the image to 960 pixels wide. In the terminal type:

# macOS/Linux
convert flower_photo.jpg -resize 960x flower_photo.jpg

# Windows
magick convert flower_photo.jpg -resize 960x flower_photo.jpg

Re-Run Lighthouse #

Re-run the Lighthouse Performance audit to verify that you have successfully re-sized the images.

… And it fails! Why is that?

Lighthouse runs its tests on a Nexus 5x. The Nexus 5x has a 1080 x 1920 screen. For the Nexus 5x, the optimal size of flower_photo.jpg would be 540 pixels wide (1080 pixels * . 5). This is much smaller than our resized image.

Should you resize the image to be even smaller? Probably. However, the answer to this isn't always clear-cut.

The trade-off here is between image quality on high-resolution devices and performance. It's easy to overestimate how closely users will be inspecting images—so you should probably make them smaller—but there are certainly use cases where image quality is more important.

The good news is that you can bypass this tradeoff altogether by using responsive images to serve multiple images sizes. You can learn more about this in the Responsive Images guide.

Creating WebP Images with the Command Line

2018-11-05T00:00:00Z

The webp command line tool has already been installed for you, so you're all set to get started. This tool converts JPG, PNG, and TIFF images to WebP.

Convert images to WebP #

Click Remix to Edit to make the project editable.
Click Terminal (note: if the Terminal button does not show you may need to use the Fullscreen option).
Type the following command:

cwebp -q 50 images/flower1.jpg -o images/flower1.webp

This command converts, at a quality of 50 (0 is the worst; 100 is the best), the images/flower1.jpg file and saves it as images/flower1.webp.

After doing this, you should see something like this in the console:

Saving file 'images/flower1.webp'
File:      images/flower1.jpg
Dimension: 504 x 378
Output:    29538 bytes Y-U-V-All-PSNR 34.57 36.57 36.12   35.09 dB
           (1.24 bpp)
block count:  intra4:        750  (97.66%)
              intra16:        18  (2.34%)
              skipped:         0  (0.00%)
bytes used:  header:            116  (0.4%)
             mode-partition:   4014  (13.6%)
 Residuals bytes  |segment 1|segment 2|segment 3|segment 4|  total
    macroblocks:  |      22%|      26%|      36%|      17%|     768
      quantizer:  |      52 |      42 |      33 |      24 |
   filter level:  |      16 |       9 |       6 |      26 |

You've just successfully converted the image to WebP.

However, running the cwebp command one image at a time like this would take a long time to convert many images. If you need to do this, you can use a script instead.

Run this script in the console (don't forget the backticks):

`for file in images/*; do cwebp -q 50 "$file" -o "${file%.*}.webp"; done`

This script converts, at a quality of 50, all the files in the images/ directory, and saves them as a new file (same filename, but with a .webp file extension) in the same directory.

✔︎ Check-in #

You should now have 6 files in your images/ directory:

flower1.jpg
flower1.webp
flower2.jpg
flower2.webp
flower3.png
flower3.webp

Next, update this Glitch to serve WebP images to browsers that support it.

Add WebP images using the `<picture>` tag #

The <picture> tag allows you to serve WebP to newer browsers while maintaining support for older browsers.

In index.html replace <img src="images/flower1.jpg"/> with the following HTML:

<picture>
  <source type="image/webp" srcset="images/flower1.webp">
  <source type="image/jpeg" srcset="images/flower1.jpg">
  <img src="images/flower1.jpg">
</picture>

Next, replace the <img> tags for flower2.jpg and flower3.png with <picture> tags.

✔︎ Check-in #

Once completed, the <picture> tags in index.html should look like this:

<picture>
  <source type="image/webp" srcset="images/flower1.webp">
  <source type="image/jpeg" srcset="images/flower1.jpg">
  <img src="images/flower1.jpg">
</picture>
<picture>
  <source type="image/webp" srcset="images/flower2.webp">
  <source type="image/jpeg" srcset="images/flower2.jpg">
  <img src="images/flower2.jpg">
</picture>
<picture>
  <source type="image/webp" srcset="images/flower3.webp">
  <source type="image/png" srcset="images/flower3.png">
  <img src="images/flower3.png">
</picture>

Next, use Lighthouse to verify you've correctly implemented WebP images on the site.

Verify WebP usage with Lighthouse #

Lighthouse's Serve images in next-gen formats performance audit can let you know if all the images on your site are using next-gen formats like WebP.

To preview the site, press View App. Then press Fullscreen .
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Lighthouse tab.
Make sure the Performance checkbox is selected in the Categories list.
Click the Generate report button.
Verify the Serve images in next-gen formats audit is passed.

Success! You are now serving WebP images on your site.

Specifying multiple slot widths

2018-11-05T00:00:00Z

Try out this demo #

To preview the site, press View App. Then press Fullscreen .
Reload the app in differently sized browser windows to see the browser load different images and use different layouts at different browser sizes.

View the code #

Checkout index.html for the code that makes this work:

<img src="flower.jpg"
  srcset="flower-small.jpg 480w, flower-large.jpg 800w"
  sizes="(max-width: 480px) 100vw, (max-width: 1024px) 50vw, 800px">

What's going on here? #

The value of the sizes attribute dictates that image display width will be: "100% of the viewport width" on viewports up to 480px wide, "50% of the viewport width" on screens 481–1024px wide, and 800px on screens wider than 1024px. These widths match the widths specified in the CSS.

The ability to specify multiple slot widths accommodates page layouts that use different styling (that is, image widths) for different viewport sizes.

How to specify multiple slot widths #

Use a comma-separated list to specify multiple slot widths. Each list item, except for the last item, consists of a media condition (e.g. max-width or min-width) and a slot width.
The last item in this list is the default slot width. It is the default, so you do not need to specify a media condition.
You can list as many slot widths as you want - the number of images listed in srcset does not matter.
Slot width can be specified using a variety of units. The following are all valid widths:
100px
33vw
20em
calc(50vw-10px)

The following is not a valid width:

25% (percentages cannot be used with the sizes attribute)

Lazy load offscreen images with lazysizes

2018-11-05T00:00:00Z

Lazy loading is the approach of waiting to load resources until they are needed, rather than loading them in advance. This can improve performance by reducing the amount of resources that need to be loaded and parsed on initial page load.

Images that are offscreen during the initial pageload are ideal candidates for this technique. Best of all, lazysizes makes this a very simple strategy to implement.

Add the lazysizes script to the page #

Click Remix to Edit to make the project editable.

lazysizes.min.js has already been downloaded and added to this Glitch. To include it in the page:

Add the following <script> tag to index.html:

  <script src="lazysizes.min.js" async></script>
  <!-- Images End -->
</body>

lazysizes will intelligently load images as the user scrolls through the page and prioritize the images that the user is going to encounter soon.

Indicate the images to lazy load #

Add the class lazyload to images that should be lazy loaded. In addition, change the src attribute to data-src.

For example, the changes for flower3.png would look like this:

<img src="images/flower3.png" alt="">
<img data-src="images/flower3.png" class="lazyload" alt="">

For this example, try lazy loading flower3.png, flower4.jpg, and flower5.jpg.

See it in action #

That's it! To see these changes in action, follow these steps:

To preview the site, press View App. Then press Fullscreen .
Open the console and find the images that were just added. Their classes should change from lazyload to lazyloaded as you scroll down the page.

Watch the network panel to see the image files load individually as you scroll down the page.

Verify using Lighthouse #

Lastly, it's a good idea to use Lighthouse to verify these changes. Lighthouse's "Defer offscreen images" performance audit will indicate if you've forgotten to add lazy loading to any offscreen images.

To preview the site, press View App. Then press Fullscreen .
Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Lighthouse tab.
Make sure the Performance checkbox is selected in the Categories list.
Click the Generate report button.
Verify the Defer offscreen images audit was passed.

Success! You have used lazysizes to lazy load the images on your page.

Katie Hempenius on web.dev

Best practices for using third-party embeds

What is an embed #

Performance impact of third-party embeds #

Loading best practices #

Script ordering #

Lazy-loading #

Native lazy-loading for <iframe> #

lazysizes library #

Using data-lazy in Facebook #

Lazy-loading Instagram feeds #

Replace embeds with facades #

Use static images as facades #

Use dynamic images as facades #

Use click-to-load to enhance facades #

Remove or replace embeds with links #

Layout stability #

Layout Shift Terminator #

Conclusion #

Best practices for tags and tag managers

Impact on Core Web Vitals #

Tag types #

Not all scripts should be loaded using a tag manager #

Be careful with Custom HTML tags #

Consider using Custom Templates #

Inject scripts correctly #

Use pixels #

Alternatives to pixels #

sendBeacon() #

fetch() keepalive #

Get clarification #

Triggers #

Choose an appropriate trigger event #

Use custom events #

Use specific trigger conditions #

Load your tag manager at an appropriate time #

Variables #

Tag management #

Use the data layer #

Remove duplicate and unused tags #

Use allow and deny lists #

Consider using server-side tagging #

Containers #

Use only one container per page #

Use separate containers if needed #

Keep an eye on container size #

Name your container versions #

Tagging workflows #

Test tags before deploying #

Preview mode #

Standalone testing #

Monitor tag performance #

Require approval for container changes #

Periodically audit tag usage #

Best practices for fonts

Font loading #

Understanding @font-face #

Inline font declarations #

Preconnect to critical third-party origins #

Be cautious when using preload to load fonts #

Font delivery #

Using self-hosted fonts #

Use WOFF2 #

Subset fonts #

Use fewer web fonts #

Font rendering #

Choose an appropriate font-display strategy #

Reduce the shift between your fallback font and your webfont #

Conclusion #

CSS for Web Vitals

Layout #

Inserting content into the DOM #

Identify #

Fix #

Images #

Images and Largest Contentful Paint (LCP) #

Fix #

Images and layout shifts #

Identify #

Fix #

Native lazy-loading for `<iframe>` #

`sendBeacon()` #

`fetch() keepalive` #

Understanding `@font-face` #

Be cautious when using `preload` to load fonts #

Choose an appropriate `font-display` strategy #