Jeremy Wagner on web.dev

Client-side rendering of HTML and interactivity

2023-05-09T00:00:00Z

Parsing and rendering of HTML is something that browsers do very well by default for websites that use the browser's built-in navigation logic—sometimes called "traditional page loads" or "hard navigations". Such websites are sometimes called multi-page applications (MPAs).

However, developers may work around browser defaults to suit their application needs. This is certainly the case for websites using the single page application (SPA) pattern, which dynamically creates large parts of the HTML/DOM on the client with JavaScript. Client-side rendering is the name for this design pattern, and it can have effects on your website's Interaction to Next Paint (INP) if the work involved is excessive.

This guide will help you weigh the difference between using HTML sent by the server to the browser versus creating it on the client with JavaScript, and how the latter can result in high interaction latency at crucial moments.

How the browser renders HTML provided by the server #

The navigation pattern used in traditional page loads involves receiving HTML from the server on every navigation. If you enter a URL in the address bar of your browser or click on a link in an MPA, the following series of events occurs:

The browser sends a navigation request for the URL provided.
The server responds with HTML in chunks.

The last step of these is key. It's also one of the most fundamental performance optimizations in the server/browser exchange, and is known as streaming. If the server can begin sending HTML as soon as possible, and the browser doesn't wait for the entire response to arrive, the browser can process HTML in chunks as it arrives.

Parsing and rendering of HTML provided by the server as visualized in the performance panel of Chrome DevTools. The tasks involved in parsing HTML and rendering it are split into chunks.

Like most things that happen in the browser, parsing HTML occurs within tasks. When HTML is streamed from the server to the browser, the browser optimizes parsing of that HTML by doing so a bit at a time as bits of that stream arrive in chunks. The consequence is that the browser yields to the main thread periodically after processing each chunk, which avoids long tasks. This means that other work can occur while HTML is being parsed, including the incremental rendering work necessary to present a page to the user, as well as processing user interactions that may occur during the page's crucial startup period. This approach translates to a better Interaction to Next Paint (INP) score for the page.

The takeaway? When you stream HTML from the server, you get incremental parsing and rendering of HTML and automatic yielding to the main thread for free. You don't get that with client-side rendering.

How the browser renders HTML provided by JavaScript #

While every navigation request to a page requires some amount of HTML to be provided by the server, some websites will use the SPA pattern. This approach often involves a minimal initial payload of HTML is provided by the server, but then the client will populate the main content area of a page with HTML assembled from data fetched from the server. Subsequent navigations—sometimes referred to as "soft navigations" in this case—are handled entirely by JavaScript to populate the page with new HTML.

Client-side rendering may also occur in non-SPAs in more limited cases where HTML is dynamically added to the DOM through JavaScript.

There are a few common ways of creating HTML or adding to the DOM through JavaScript:

The innerHTML property allows you to set the content on an existing element via a string, which the browser parses into DOM.
The document.createElement method allows you to create new elements to be added to the DOM without using any browser HTML parsing.
The document.write method allows you to write HTML to the document (and the browser parses it, just like in approach #1). Due to a number of reasons, however, usage of document.write is strongly discouraged.

Parsing and rendering of HTML through JavaScript on the client as visualized in the performance panel of Chrome DevTools. The tasks involved in parsing and rendering it are not chunked up, resulting in a long task that blocks the main thread.

The consequences of creating HTML/DOM through client-side JavaScript can be significant:

Unlike HTML streamed by the server in response to a navigation request, JavaScript tasks on the client are not automatically chunked up, which may result in long tasks that block the main thread. This means that your page's INP can be negatively affected if you're creating too much HTML/DOM at a time on the client.
If HTML is created on the client during startup, resources referenced within it will not be discovered by the browser preload scanner. This will certainly have a negative effect on a page's Largest Contentful Paint (LCP). While this is not a runtime performance issue (instead it's an issue of network delay in fetching important resources), you don't want your website's LCP to be affected by sidestepping this fundamental browser performance optimization.

What you can do about the performance impact of client-side rendering #

If your website depends heavily on client-side rendering and you've observed poor INP values in your field data, you might be wondering if client-side rendering has anything to do with the problem. For example, if your website is an SPA, your field data may reveal interactions responsible for considerable rendering work.

Whatever the cause, here are some potential causes you can explore to help get things back on track.

Provide as much HTML from the server as possible #

As mentioned earlier, the browser handles HTML from the server in a very performant way by default. It will break up parsing and rendering of HTML in a way that avoids long tasks, and optimizes the amount of total main thread time. This leads to a lower Total Blocking Time (TBT), and TBT is strongly correlated with INP.

You may be relying on a frontend framework to build your website. If so, you'll want to make sure you're rendering component HTML on the server. This will limit the amount of initial client-side rendering your website will require, and should result in a better experience.

For React, you'll want to make use of the Server DOM API to render HTML on the server. But be aware: the traditional method of server-side rendering uses a synchronous approach, which can lead to a longer Time to First Byte (TTFB), as well as subsequent metrics such as First Contentful Paint (FCP) and LCP. Where possible, make sure you're using the streaming APIs for Node.js or other JavaScript runtimes so that the server can begin streaming HTML to the browser as soon as possible. Next.js—a React-based framework—provides many best practices by default. In addition to automatically rendering HTML on the server, it can also statically generate HTML for pages that don't change based on user context (such as authentication).
Vue also performs client-side rendering by default. However, like React, Vue can also render your component HTML on the server. Either take advantage of these server-side APIs where possible, or consider a higher-level abstraction for your Vue project to make the best practices easier to implement.
Svelte renders HTML on the server by default—although if your component code needs access to browser-exclusive namespaces (window, for example), you may not be able to render that component's HTML on the server. Explore alternative approaches wherever possible so that you're not causing unnecessary client-side rendering. SvelteKit—which is to Svelte as Next.js is to React—embeds many best practices into your Svelte projects as possible, so you can avoid potential pitfalls in projects that use Svelte alone.

Limit the amount of DOM nodes created on the client #

When DOMs are large, the amount of processing time required to render them tends to increase. Whether your website is a full-fledged SPA, or is injecting new nodes into an existing DOM as the result of an interaction for an MPA, consider keeping those DOMs as small as possible. This will help reduce the work required during client-side rendering to display that HTML, hopefully helping to keep your website's INP lower.

Consider a streaming service worker architecture #

This is an advanced technique—one that may not work easily with every use case—but it's one that can turn your MPA into a website that feels like it's loading instantly when users navigate from one page to the next. You can use a service worker to precache the static parts of your website in CacheStorage while using the ReadableStream API to fetch the rest of a page's HTML from the server.

When you use this technique successfully, you aren't creating HTML on the client, but the instant loading of content partials from the cache will give the impression that your site is loading quickly. Websites using this approach can feel almost like an SPA, but without the downfalls of client-side rendering. It also reduces the amount of HTML you're requesting from the server.

In short, a streaming service worker architecture doesn't replace the browser's built-in navigation logic—it adds to it. For more information on how to achieve this with Workbox, read Faster multipage applications with streams.

Conclusion #

How your website receives and renders HTML has an impact on performance. When you rely on the server to send all (or the bulk of) the HTML required for your website to function, you're getting a lot for free: incremental parsing and rendering, and automatic yielding to the main thread to avoid long tasks.

Client-side HTML rendering introduces a number of potential performance issues that can be avoidable in many cases. Due to each individual website's requirements, however, it's not entirely avoidable 100% of the time. To mitigate the potential long tasks that can result from excessive client-site rendering, make sure you're sending as much of your website's HTML from the server whenever possible, keep your DOM sizes as small as possible for HTML that must be rendered on the client, and consider alternative architectures to speed the delivery of HTML to the client while also taking advantage of the incremental parsing and rendering the browser provides for HTML loaded from the server.

If you can get your website's client-side rendering to be as minimal as possible, you'll improve not just your website's INP, but other metrics such as LCP, TBT, and possibly even your TTFB in some cases.

Hero image from Unsplash, by Maik Jonietz.

Diagnose slow interactions in the lab

2023-05-09T00:00:00Z

One challenging aspect of optimizing Interaction to Next Paint (INP) is figuring out what's causing poor INP. There's a large variety of potential causes: third-party scripts that schedule many tasks on the main thread, large DOM sizes, expensive event callbacks, and so on.

Finding ways to fix poor INP can be difficult. To start, you have to know which interactions tend to be responsible for a page's INP. If you don't know this already, start by reading Find slow interactions in the field. Once you have that field data and know what interactions to test, you can do so in lab tools to work out why those interactions are slow.

What if you don't have field data? #

Ideally, you'll want field data, as it saves you a lot of time trying to figure out which interactions need to be optimized. You might be in a position where you don't have field data, though. If that's your situation, you can still find interactions to improve: you'll just have to take a different approach.

Total Blocking Time (TBT) is a metric that assesses page responsiveness during load. It correlates very well with INP, and can give you an idea if there might be interactions you can profile while the page is loading.

You can use either Lighthouse or PageSpeed Insights to measure your page's TBT. If your TBT is either poor or needs improvement, there's a good chance there are interactions that might be slow during page load.

To find slow interactions after the page has loaded, you might need to rely on other types of data, such as common user flows that you may already have in your website's analytics. If you work on an ecommerce website, for example, a common user flow would be the actions users take when they're adding items to an online shopping cart or going through an online checkout.

Whether or not you have field data, the next step involves reproducing that interaction—because it's only when you're able to conclusively identify a slow interaction that you'll be able to fix it.

Reproducing slow interactions in the lab #

Once you've identified a slow interaction, the next step is to test it in the lab to see if it's reliably slow.

Don't reach for the performance profiler right away #

Chrome performance profiler—while invaluable—doesn't provide a live view while interacting with the page. It's more efficient to test interaction latency in a much faster way first, so you can quickly assess whether a given interaction is reliably slow, and then reach for the performance profiler when you need more information.

Use the Web Vitals Chrome Extension #

The Web Vitals Chrome Extension involves the lowest amount of effort in testing interaction latency. Once installed, the extension will display interaction data in the console if you do the following:

In Chrome, click the extensions icon to the right of the address bar.
Locate the Web Vitals extension in the drop-down menu.
Click the icon at the right to open the extension's settings.
Click Options.
Enable the Console logging checkbox in the resulting screen, and then click Save.

Once this has been done, open the console in Chrome DevTools, and begin testing the desired interactions on your website. As you interact with the page, you'll receive useful console logs giving you detailed diagnostic information for the interaction.

A console entry from the Web Vitals extension when console logging is turned on. Each qualifying interaction will log interaction data to the console.

Use a JavaScript snippet #

Using the Web Vitals extension may not be a viable option for a number of reasons. Extensions can be blocked in some cases, and they also can't be installed on mobile devices. The latter is problematic if you want to test on a physical Android device with remote debugging.

An alternate method involves copying and pasting some JavaScript into the console of Chrome DevTools. The following code yields the same console output as the Web Vitals extension for every interaction:

let worstInp = 0;

const observer = new PerformanceObserver((list, obs, options) => {
  for (let entry of list.getEntries()) {
    if (!entry.interactionId) continue;

    entry.renderTime = entry.startTime + entry.duration;
    worstInp = Math.max(entry.duration, worstInp);
      
    console.log('[Interaction]', entry.duration, `type: ${entry.name} interactionCount: ${performance.interactionCount}, worstInp: ${worstInp}`, entry, options);
  }
});

observer.observe({
  type: 'event',
  durationThreshold: 0, // 16 minimum by spec
  buffered: true
});

Once you have determined that the interaction is reliably slow, you can then profile the interaction to get more detailed information on why that interaction is slow.

What if you can't reproduce a slow interaction? #

What if you've managed to find something in your field data that suggests a particular interaction is slow, but you can't reproduce it in the lab?

For one, this is a common challenge in troubleshooting performance issues of any kind. Your point of view when testing is entirely relative and dependent on the hardware you're using. After all, you may be on a fast device with a fast internet connection—but that doesn't mean your users are too. For this situation you can do one of three things:

If you have a physical Android device, use remote debugging to open a Chrome DevTools instance on your host machine and try to reproduce slow interactions there.
If you don't have a physical device, enable the CPU throttling feature in Chrome DevTools.
Follow both steps 1 and 2, as you can also enable CPU throttling on the DevTools instance for a physical Android device.

Another cause could be that you're waiting for a page to load before you interact with it, but your users are not. If you're on a fast network, enable network throttling and interact with the page as soon as it paints. You should do this because the main thread is often busiest during startup, and testing at that time might help reveal what your users are actually experiencing.

Record a trace #

To get more information on why an interaction is slow, you'll need to take things to the next level by using the performance profiler in Chrome DevTools. To profile an interaction in Chrome's performance profiler, do the following:

With the page you need to profile loaded and ready for interactions, open Chrome DevTools and go to the Performance panel.
Click the Record button at the upper left of the panel to start tracing.
Perform the desired interaction.
Click the Record button again to stop tracing.

When the profile populates, the first place to look should be the activity summary at the top of the profiler. The activity summary will show red bars at the top where long tasks occurred in the recording. This allows you to quickly zoom in on problem areas.

The activity summary at the top of Chrome's performance profiler. Long tasks are highlighted in red above the activity flame chart. In this case, significant scripting work was responsible for most of the work in the long task.

You can quickly focus on the problem area by dragging and selecting a region in the activity summary. Once you've focused to where the interaction occurred, the Interactions track will help you line up the interaction and the activity that occurred in the main thread track below it:

An interaction profiled in the performance profiler in Chrome's DevTools. The Interactions track shows a series of events that amount to a click interaction. The Interactions track entries span across the tasks responsible for driving the interaction.

From here, it's a matter of observing what the problem with the interaction might be. There are many things that can contribute to high interaction latency, so let's go through what some of the culprits could be.

Use Lighthouse timespans as an alternative to tracing #

Chrome's performance profiler—while rich with diagnostic information—can be a bit intimidating to the uninitiated. One alternative to the performance profiler is Lighthouse's timespan mode. To use this mode, do the following:

With DevTools open, go to the Lighthouse tab in DevTools.
Under the section labeled Mode, select the Timespan option.
Select the desired device type under the section labeled Device.
Ensure at least the checkbox labeled Performance is selected under the Categories label.
Click the Start timespan button.
Test the desired interaction(s) on the page.
Click the End timespan button and wait for the audit to appear
Once the audit populates in the Lighthouse tab, you can filter the audits by INP by clicking the INP link next to the label which reads Show audits relevant to.

At this point, you'll see a drop-down list for audits that have failed or passed. When you expand that drop-down, you'll probably see a breakdown of time spent during the interaction.

An interaction profiled in Lighthouse's timespan mode. When interactions are made with the page, Lighthouse provides an audit detailing where the time during an interaction was spent, and breaks it down by input delay, processing delay, and presentation delay.

How to identify long input delays #

One thing that could be contributing to high interaction latency is input delay. The input delay is the first phase of an interaction. This is the period of time from when the user action is first received by the operating system until the browser is able to start processing the first event triggered by that input. The input delay ends right as the event callbacks for the interaction begin to run.

Identifying input delay in Chrome's performance profiler can be done by finding the start of an interaction in the interactions panel, and then finding the beginning of when the event callbacks for that interaction start to run.

You'll always incur at least some input delay, as it takes some time for the operating system to pass the input event to the browser—but you do have some control over how long the input delay is. The key is to figure out if there is work running on the main thread that's preventing your callbacks from running.

Input delay caused by a task fired by a timer from a third-party script.

In the previous figure, a task from a third-party script is running as the user attempts to interact with the page, and therefore extends the input delay. The extended input delay affects the interaction's latency, and could therefore affect the page's INP.

For more information on how you can resolve long input delays, read about how you can identify and reduce input delay.

How to identify expensive event callbacks #

Event callbacks occur immediately after the input delay. If an event callback runs too long, it delays the browser from presenting the next frame, and can add significantly to an interaction's total latency. Event callbacks can often run for too long, whether they run as the result of first-party or third-party JavaScript—and in some cases, both.

The event callbacks that run in response to a click interaction, as shown in the performance profiler in Chrome DevTools. Note the red triangle in the upper right corner of both the Event: pointerdown and Event: click entries, which identifies expensive event callbacks.

Finding expensive event callbacks can be done by observing the following in a trace for a specific interaction:

Determine whether the task associated with the event callbacks is a long task. To reveal long tasks in a lab setting more reliably, you may need to enable CPU throttling in the performance panel, or connect a low to mid-tier Android device and use remote debugging.
If the task that runs the event callbacks is a long task, look for event handler entries (entries with names such as Event: click, for example) in the call stack that have a red triangle at the upper right corner of the entry. These are expensive event callbacks.

To address expensive event callbacks, try one of the following strategies:

Do as little work as possible. Is everything that happens in an expensive event callback strictly necessary? If not, consider removing that code altogether if you can, or deferring its execution to a later point in time if you can't. You can also take advantage of framework features to help. For example, React's PureComponent class and memoization feature can skip unnecessary rendering work when props and state haven't changed for a component.
Defer non-rendering work in the event callback to a later point in time. Long tasks can be broken up by yielding to the main thread. Whenever you yield to the main thread, you're ending execution of the current task and breaking up the remainder of the work into a separate task. This gives the renderer a chance to process updates to the user interface that were processed earlier in the event callback. If you happen to be developing in React, its transitions feature will do this for you.

By employing these strategies, you should be able to get your event callbacks in a place where they're responding more quickly to user input.

How to identify presentation delays #

Long input delays and expensive event callbacks aren't the only possible culprits of poor INP. Sometimes the rendering updates that occur in response to even small amounts of event callback code can be expensive. The time it takes for the browser to render visual updates to the user interface to reflect the result of an interaction is known as presentation delay.

Rendering tasks as shown in Chrome's performance profiler. The rendering work is shown in purple, with paint work in green.

Of all the possible causes of high interaction latency, rendering work can be the most difficult to troubleshoot and fix, but the result is worth the effort. Excessive rendering work could be caused by any of the following:

Large DOM sizes. Rendering work often increases along with the size of the page's DOM. For more information, read How large DOM sizes affect interactivity—and what you can do about it.
Forced reflows. This happens when you apply style changes to elements in JavaScript, and then query the results of that work. The result is that the browser has to perform the layout work before doing anything else, so that the browser can return the updated styles. For more information and tips on avoiding forced reflows, read Avoid large, complex layouts and layout thrashing.
Excessive or unnecessary work in requestAnimationFrame callbacks. requestAnimationFrame() callbacks are run during the rendering phase of the event loop, and must complete before the next frame can be presented. If you're using requestAnimationFrame() to do work that doesn't involve changes to the user interface, understand that you could be delaying the next frame.
ResizeObserver callbacks. Such callbacks run prior to rendering, and may delay presentation of the next frame if the work in them is expensive. As with event callbacks, defer any logic not needed for the next frame.

Troubleshooting INP is an iterative process #

Finding out what's causing high interaction latency that contributes to poor INP takes a lot of work—but if you can pin down the causes, you're halfway there. By following a methodical approach to troubleshooting poor INP, you can reliably pin down what's causing a problem, and arrive more quickly to the right fix. To review:

Rely on field data to find slow interactions.
Test problematic field interactions in the lab to see if they're reproducible.
Identify whether the cause is due to long input delay, expensive event callbacks, or expensive rendering work.
Repeat.

The last of these is the most important. Like most other work you must do to improve page performance, troubleshooting and improving INP is a cyclical process. When you fix one slow interaction, you'll need to move onto the next, and continue to do so until you start to see results. Stay vigilant!

Hero image from Unsplash, by Louis Reed.

How large DOM sizes affect interactivity, and what you can do about it

2023-05-09T00:00:00Z

There's no way around it: when you build a web page, that page is going to have a Document Object Model (DOM). The DOM represents the structure of your page's HTML, and gives JavaScript and CSS access to a page's structure and contents.

The problem, however, is that the size of the DOM affects a browser's ability to render a page quickly and efficiently. Generally speaking, the larger a DOM is, the more expensive it is to initially render that page and update its rendering later on in the page lifecycle.

This becomes problematic in pages with very large DOMs when interactions that modify or update the DOM trigger expensive layout work that affects the ability of the page to respond quickly. Expensive layout work can affect a page's Interaction to Next Paint (INP); If you want a page to respond quickly to user interactions, it's important to ensure your DOM sizes are only as large as necessary.

When is a page's DOM too large? #

According to Lighthouse, a page's DOM size is excessive when it exceeds 1,400 nodes. Lighthouse will begin to throw warnings when a page's DOM exceeds 800 nodes. Take the following HTML for example:

<ul>
  <li>List item one.</li>
  <li>List item two.</li>
  <li>List item three.</li>
</ul>

In the above code, there are four DOM elements: the <ul> element, and its three <li> child elements. Your web page will almost certainly have many more nodes than this, so it's important to understand what you can do to keep DOM sizes in check—as well as other strategies to optimize the rendering work once you've gotten a page's DOM as small as it can be.

How do large DOMs affect page performance? #

Large DOMs affect page performance in a few ways:

During the page's initial render. When CSS is applied to a page, a structure similar to the DOM known as the CSS Object Model (CSSOM) is created. As CSS selectors increase in specificity, the CSSOM becomes more complex, and more time is needed to run the necessary layout, styling, compositing, and paint work necessary to draw the web page to the screen. This added work increases interaction latency for interactions that occur early on during page load.
When interactions modify the DOM, either through element insertion or deletion, or by modifying DOM contents and styles, the work necessary to render that update can result in very costly layout, styling, compositing, and paint work. As is the case with the page's initial render, an increase in CSS selector specificity can add to rendering work when HTML elements are inserted into the DOM as the result of an interaction.
When JavaScript queries the DOM, references to DOM elements are stored in memory. For example, if you call document.querySelectorAll to select all <div> elements on a page, the memory cost could be considerable if the result returns a large number of DOM elements.

A long task as shown in the performance profiler in Chrome DevTools. The long task shown is caused by inserting DOM elements into a large DOM via JavaScript.

All of these can affect interactivity, but the second item in the list above is of particular importance. If an interaction results in a change to the DOM, it can kick off a lot of work that can contribute to a poor INP on a page.

How do I measure DOM size? #

You can measure DOM size in a couple of ways. The first method uses Lighthouse. When you run an audit, statistics on the current page's DOM will be in the "Avoid an excessive DOM size" audit under the "Diagnostics" heading. In this section, you can see the total number of DOM elements, the DOM element containing the most child elements, as well as the deepest DOM element.

A simpler method involves using the JavaScript console in the developer tools in any major browser. To get the total number of HTML elements in the DOM, you can use the following code in the console after the page has loaded:

document.querySelectorAll('*').length;

If you want to see the DOM size update in realtime, you can also use the performance monitor tool. Using this tool, you can correlate layout and styling operations (and other performance aspects) along with the current DOM size.

The performance monitor in Chrome DevTools. In this view, the page's current number of DOM nodes is charted along with layout operations and style recalculations performed per second.

If the DOM's size is approaching Lighthouse DOM size's warning threshold—or fails altogether—the next step is to figure out how to reduce the DOM's size to improve your page's ability to respond to user interactions so that your website's INP can improve.

How can I measure the number of DOM elements affected by an interaction? #

If you're profiling a slow interaction in the lab that you suspect might have something to do with the size of the page's DOM, you can figure out how many DOM elements were affected by selecting any piece of activity in the profiler labeled "Recalculate Style" and observe the contextual data in the bottom panel.

Observing the number of affected elements in the DOM as the result of style recalculation work. Note that the shaded portion of the interaction in the interactions track represents the portion of the interaction duration that was over 200 milliseconds, which is the designated "good" threshold for INP.

In the above screenshot, observe that the style recalculation of the work—when selected—shows the number of affected elements. While the above screenshot shows an extreme case of the effect of DOM size on rendering work on a page with many DOM elements, this diagnostic info is useful in any case to determine if the size of the DOM is a limiting factor in how long it takes for the next frame to paint in response to an interaction.

How can I reduce DOM size? #

Beyond auditing your website's HTML for unnecessary markup, the principal way to reduce DOM size is to reduce DOM depth. One signal that your DOM might be unnecessarily deep is if you're seeing markup that looks something like this in the Elements tab of your browser's developer tools:

<div>
  <div>
    <div>
      <div>
        <!-- Contents -->
      </div>
    </div>
  </div>
</div>

When you see patterns like this, you can probably simplify them by flattening your DOM structure. Doing so will reduce the number of DOM elements, and likely give you an opportunity to simplify page styles.

DOM depth may also be a symptom of the frameworks you use. In particular, component-based frameworks—such as those that rely on JSX—require you to nest multiple components in a parent container.

However, many frameworks allow you to avoid nesting components by using what are known as fragments. Component-based frameworks that offer fragments as a feature include (but are not limited to) the following:

By using fragments in your framework of choice, you can reduce DOM depth. If you're concerned about the impact flattening DOM structure has on styling, you might benefit from using more modern (and faster) layout modes such as flexbox or grid.

Other strategies to consider #

Even if you take pains to flatten your DOM tree and remove unnecessary HTML elements to keep your DOM as small as possible, it can still be quite large and kick off a lot of rendering work as it changes in response to user interactions. If you find yourself in this position, there are some other strategies you can consider to limit rendering work.

Consider an additive approach #

You might be in a position where large parts of your page aren't initially visible to the user when it first renders. This could be an opportunity to lazy load HTML by omitting those parts of the DOM on startup, but add them in when the user interacts with the parts of the page that require the initially hidden aspects of the page.

This approach is useful both during the initial load and perhaps even afterwards. For the initial page load, you're taking on less rendering work up front, meaning that your initial HTML payload will be lighter, and will render more quickly. This will give interactions during that crucial period more opportunities to run with less competition for the main thread's attention.

If you have many parts of the page that are initially hidden on load, it could also speed up other interactions that trigger re-rendering work. However, as other interactions add more to the DOM, rendering work will increase as the DOM grows throughout the page lifecycle.

Adding to the DOM over time can be tricky, and it has its own tradeoffs. If you're going this route, you're likely making network requests to get data to populate the HTML you intend to add to the page in response to a user interaction. While in-flight network requests are not counted towards INP, it can increase perceived latency. If possible, show a loading spinner or other indicator that data is being fetched so that users understand that something is happening.

Limit CSS selector complexity #

When the browser parses selectors in your CSS, it has to traverse the DOM tree to understand how—and if—those selectors apply to the current layout. The more complex these selectors are, the more work the browser has to do in order to perform both the initial rendering of the page, as well as increased style recalculations and layout work if the page changes as the result of an interaction.

Use the `content-visibility` property #

CSS offers the content-visibility property, which is effectively a way to lazily render off-screen DOM elements. As the elements approach the viewport, they're rendered on demand. The benefits of content-visibility don't just cut out a significant amount of rendering work on the initial page render, but also skip rendering work for offscreen elements when the page DOM is changed as the result of a user interaction.

Conclusion #

Reducing your DOM size to only what is strictly necessary is a good way to optimize your website's INP. By doing so, you can reduce the amount of time it takes for the browser to perform layout and rendering work when the DOM is updated. Even if you can't meaningfully reduce DOM size, there are some techniques you can use to isolate rendering work to a DOM subtree, such as CSS containment and the content-visibility CSS property.

However you go about it, creating an environment where rendering work is minimized—as well as reducing the amount of rendering work your page does in response to interactions—the result will be that your website will feel more responsive to users when they interact with them. That means you'll have a lower INP for your website, and that translates to a better user experience.

Hero image from Unsplash, by Louis Reed.

Find slow interactions in the field

2023-05-09T00:00:00Z

Field data is the authoritative source when it comes to how actual users are experiencing your website. It teases out issues you may not see in lab data alone. While interactions can be simulated in lab-based tools, you're not going to be able to reproduce every single interaction in the lab in the way that users in the field experience them. Gathering field data for Interaction to Next Paint (INP) is critical to understanding how responsive your page is to real users, and it contains the clues to make their experience even better.

What you should collect in the field and why #

When collecting INP data in the field, you'll want to capture the following to give context to why interactions were slow:

The INP value. This is the key piece of data you'll need to collect. The distribution of these values will determine whether the page meets the INP thresholds.
The element selector string responsible for the page's INP. Knowing a page's INP is good, but not good enough by itself. Without knowing what element was responsible for it, you'll be in the dark. By logging element selector strings, you’ll know exactly what elements are responsible for interactions.
The loading state of the page for the interaction that is the page's INP. When a page is loading, it's reasonable to assume that there's more main thread activity occurring that could result in higher interaction latency. During page load, there's HTML parsing, stylesheet parsing, and JavaScript evaluation and execution going on. Knowing whether an interaction has taken place during page load or afterwards helps you to figure out if you need to optimize for faster startup so interactions have more room on the main thread to run quickly, or if the interaction responsible for the page's INP in itself is slow regardless.
The interaction's startTime. Logging the interaction's startTime lets you know exactly when the interaction occurred on the performance timeline.
The event type. The event type is good to know, as it will tell you whether the interaction was the result of a click, keypress, or other eligible event type. A user interaction may contain multiple callbacks, and can help you to pinpoint exactly which event callback in the interaction took the longest to run.

While this all seems like a lot to take into account, you don't have to reinvent the wheel to get there. Thankfully, this data is exposed in the web-vitals JavaScript library, and you'll learn how to gather it in the next section.

Measure interactions in the field with the `web-vitals` JavaScript library #

The web-vitals JavaScript library is a great way to find slow interactions in the field, thanks in large part to its ability to provide attribution for what's causing them. INP can be collected in browsers that support the Event Timing API and its interactionId property.

Browser support

Chrome 96, Supported 96
Firefox, Not supported
Edge 96, Supported 96
Safari, Not supported

Source

Using a Real User Monitoring (RUM) provider to get INP is most convenient, but not always an option. If that's your case, for example, you can use the web-vitals JavaScript library to collect and transmit INP data to Google Analytics for later evaluation:

// Be sure to import from the attribution build:
import {onINP} from 'web-vitals/attribution';

function sendToGoogleAnalytics ({name, value, id, attribution}) {
  // Destructure the attribution object:
  const {eventEntry, eventTarget, eventType, loadState} = attribution;

  // Get timings from the event timing entry:
  const {startTime, processingStart, processingEnd, duration, interactionId} = eventEntry;

  const eventParams = {
    // The page's INP value:
    metric_inp_value: value,
    // A unique ID for the page session, which is useful
    // for computing totals when you group by the ID.
    metric_id: id,
    // The event target (a CSS selector string pointing
    // to the element responsible for the interaction):
    metric_inp_event_target: eventTarget,
    // The type of event that triggered the interaction:
    metric_inp_event_type: eventType,
    // Whether the page was loaded when the interaction
    // took place. Useful for identifying startup versus
    // post-load interactions:
    metric_inp_load_state: loadState,
    // The time (in milliseconds) after page load when
    // the interaction took place:
    metric_inp_start_time: startTime,
    // When processing of the event callbacks in the
    // interaction started to run:
    metric_inp_processing_start: processingStart,
    // When processing of the event callbacks in the
    // interaction finished:
    metric_inp_processing_end: processingEnd,
    // The total duration of the interaction. Note: this
    // value is rounded to 8 milliseconds of granularity:
    metric_inp_duration: duration,
    // The interaction ID assigned to the interaction by
    // the Event Timing API. This could be useful in cases
    // where you might want to aggregate related events:
    metric_inp_interaction_id: interactionId
  };

  // Send to Google Analytics
  gtag('event', name, eventParams);
}

// Pass the reporting function to the web-vitals INP reporter:
onINP(sendToGoogleAnalytics);

If you have Google Analytics and run the preceding code on your website, you'll get a detailed reporting of not just the page's INP, but also useful contextual information that can give you a better sense of where to begin optimizing slow interactions.

Monitor full session duration, not just up to `onload` #

Using the web-vitals JavaScript library, as previously mentioned, may result in multiple analytics events being sent to Google Analytics. This is fine, as the ID web-vitals generates for the current page will stay the same, and Google Analytics will allow you to overwrite previous data.

However, not all RUM providers operate this way, so if you're building your own RUM collection solution, you'll need to take this into account. If your current analytics provider won't allow overwrites of existing records, you'll need to record all the delta values—that is, the difference between a metric's past and current states— for a metric and transmit them using the same ID provided by the web-vitals library; then you can sum those changes by grouping on the ID. For more more information, consult the web-vitals documentation's section on handling deltas.

Get field data quickly with CrUX #

The Chrome UX Report (CrUX) is the official dataset of the Web Vitals program. While data from CrUX alone doesn't give you all the information you need to troubleshoot specific INP issues, it does let you know whether you have a problem in the first place. Even if you're already collecting field data through a RUM provider, consider contrasting it with CrUX data for your website (if available), as there are differences in the methodologies they use.

You can evaluate your website's INP and view its CrUX data using PageSpeed Insights (PSI). PageSpeed Insights may provide page-level field data for websites that are included in the CrUX dataset. To audit a URL with PageSpeed Insights, go to https://pagespeed.web.dev/, enter a URL to test, and click the Analyze button.

Once the assessment begins, CrUX data will be available instantly as Lighthouse (a lab tool) runs.

The distribution of INP experiences as seen in PageSpeed Insights.

When Lighthouse has finished running its assessment, PSI will populate the assessment with Lighthouse audits.

Audits for Total Blocking Time

What if I don't have field data? #

You might be in a situation where you don't have or can’t even collect field data. If this describes your situation, then you'll be entirely dependent on lab tools in order to find slow interactions. For more information on lab testing, read How to diagnose what's causing poor INP in the lab.

Conclusion #

Field data is the best source of information you can draw on when it comes to understanding which interactions are problematic for actual users in the field. By drawing on information available in PageSpeed Insights, or relying on field data collection tools such as the web-vitals JavaScript library (or your RUM provider), you can be more confident about which interactions are most problematic, and then move on to reproducing problematic interactions in the lab and then go about fixing them.

Hero image from Unsplash, by Federico Respini.

Optimize input delay

2023-05-09T00:00:00Z

Interactions on the web are complicated things, with all sorts of activity occurring in the browser to drive them. What they all have in common, though, is that they incur some input delay before their event callbacks begin to run. In this guide, you'll learn what input delay is, and what you can do to minimize it so your website's interactions run faster.

What is input delay? #

Input delay is the period of time beginning from when the user first interacts with a page—such as tapping on a screen, clicking with a mouse, or pressing a key—up to when the event callbacks for the interaction begin to run. Every interaction begins with some amount of input delay.

The mechanics behind input delay. When an input is received by the operating system, it must be passed to the browser before the interaction starts. This takes a certain amount of time, and can be increased by existing main thread work.

Some portion of the input delay is unavoidable: it always takes some amount of time for the operating system to recognize an input event and pass it to the browser. However, that portion of the input delay is often not even noticeable, and there are other things that happen on the page itself that can make input delays long enough to cause problems.

How to think about input delay #

Generally speaking, you want to keep every part of an interaction as short as possible so that your website has the best chance of meeting the Interaction to Next Paint (INP) metric's "good" threshold, regardless of the user's device. Keeping input delay in check is just one part of meeting that threshold.

You might be tempted to look to the First Input Delay (FID) thresholds to determine an allowance for input delays—but the "good" threshold for FID is 100 milliseconds or less. If you go by this threshold, you'd be allotting half of your budget for INP to input delay alone. This is inadvisable when you consider that an interaction also requires time to run event callbacks and for the browser to paint the next frame.

To meet INP's "good" threshold, you'll want to aim for the shortest input delay possible, but you shouldn't expect to eliminate it entirely, as that is impossible. As long as you're avoiding excessive main thread work while users are attempting to interact with your page, your input delay should be low enough to avoid problems.

How to minimize input delay #

As said previously, some input delay is unavoidable, but on the other hand, some input delay is avoidable. Here are some things to consider if you're struggling with long input delays.

Avoid recurring timers that kick off excessive main thread work #

There are two commonly used timer functions in JavaScript that can contribute to input delay: setTimeout and setInterval. The difference between the two is that setTimeout schedules a callback to run after a specified time. setInterval, on the other hand, schedules a callback to run every n milliseconds in perpetuity, or until the timer is stopped with clearInterval.

setTimeout is not problematic in itself—in fact, it can be helpful in avoiding long tasks. However, it depends on when the timeout occurs, and whether the user attempts to interact with the page when the timeout callback runs.

Additionally, setTimeout can be run in a loop or recursively, where it acts more like setInterval, though preferably not scheduling the next iteration until the previous one is completed. While this means the loop will yield to the main thread every time setTimeout is called, you should take care to ensure its callback doesn't end up doing excessive work.

setInterval runs a callback on an interval, and is therefore much more likely to get in the way of interactions. This is because—unlike a single instance of a setTimeout call, which is a one-off callback that may get in the way of a user interaction—setInterval's recurring nature makes it much more likely that it will get in the way of an interaction, thus increasing the interaction's input delay.

A timer registered by a previous setInterval call contributing to input delay as depicted in the performance panel of Chrome DevTools. The added input delay causes the event callbacks for the interaction to run later than they otherwise could.

If timers are occurring in first-party code, then you have control over them. Evaluate whether you need them, or do your best to reduce the work in them as much as possible. However, timers in third-party scripts are a different story. You often don't have control over what a third-party script does, and fixing performance issues in third-party code often involves working with stakeholders to determine whether a given third-party script is necessary, and if so, establish contact with a third-party script vendor to determine what can done to fix performance issues they may cause on your website.

Avoid long tasks #

One way to mitigate long input delays is to avoid long tasks. When you have excessive main thread work that blocks the main thread during interactions, that will add to the input delay for them before the long tasks have had a chance to finish.

A visualization of what happens to interactions when tasks are too long and the browser can't respond quickly enough to interactions, versus when longer tasks are broken up into smaller tasks.

Besides minimizing the amount of work you do in a task—and you should always strive to do as little work as possible on the main thread—you can improve responsiveness to user input by breaking up long tasks.

Be mindful of interaction overlap #

A particularly challenging part of optimizing INP can be if you have interactions that overlap. Interaction overlap means that after you've interacted with one element, you make another interaction with the page before the initial interaction has had a chance to render the next frame.

A visualization of two concurrent interactions in the performance profiler in Chrome's DevTools. The rendering work in the initial click interaction causes an input delay for the subsequent keyboard interaction.

Sources of interaction overlap may be as simple as users making many interactions in a short period of time. This can occur when users type in form fields, where many keyboard interactions can occur in a very short period of time. If the work on a key event is especially expensive—such as in the common case of autocomplete fields where network requests are made to a back end—you have a couple of options:

Consider debouncing inputs to limit the amount of times an event callback executes in a given period of time.
Use AbortController to cancel outgoing fetch requests so the main thread doesn't become congested handling fetch callbacks. Note: an AbortController instance's signal property can also be used to abort events.

Another source of increased input delay due to overlapping interactions can be expensive animations. In particular, animations in JavaScript may fire many requestAnimationFrame calls, which may get in the way of user interactions. To get around this, use CSS animations whenever possible to avoid queueing potentially expensive animation frames—but if you do this, make sure you avoid non-composited animations so that animations run mainly on the GPU and compositor threads, and not on the main thread.

Conclusion #

While input delays may not represent the majority of the time your interactions take to run, it's important to understand that every part of an interaction takes up an amount of time that you can reduce. If you're observing long input delay, then you have opportunities to reduce it. Avoiding recurring timer callbacks, breaking up long tasks, and being aware of potential interaction overlap can all help you to reduce input delay, leading to faster interactivity for your website's users.

Hero image from Unsplash, by Erik Mclean.

Script evaluation and long tasks

2023-05-09T00:00:00Z

When it comes to optimizing Interaction to Next Paint (INP), most of the advice you'll encounter is to optimize interactions themselves. For example, in the optimize long tasks guide, techniques such as yielding with setTimeout, isInputPending, and so forth are discussed. These techniques are beneficial, as they allow the main thread some breathing room by avoiding long tasks, which can allow more opportunities for interactions and other activity to run sooner, rather than if they had to wait for a single long task.

However, what about the long tasks that come from loading scripts themselves? These tasks can interfere with user interactions and affect a page's INP during load. This guide will explore how browsers handle tasks kicked off by script evaluation, and look into what you may be able to do to break up script evaluation work so that your main thread can be more responsive to user input while the page is loading.

What is script evaluation? #

If you've profiled an application that ships a lot of JavaScript, you may have seen long tasks where the culprit is labeled Evaluate Script.

Script evaluation work as shown in the performance profiler in Chrome DevTools. In this case, the work is enough to cause a long task that blocks the main thread from taking on other work—including tasks that drive user interactions.

Script evaluation is a necessary part of executing JavaScript in the browser, as JavaScript is compiled just-in-time before execution. When a script is evaluated, it is first parsed for errors. If the parser doesn't find errors, the script is then compiled into bytecode, and then can continue onto execution.

Though necessary, script evaluation can be problematic, as users may try to interact with a page shortly after it initially renders. However, just because a page has rendered doesn't mean that the page has finished loading. Interactions that take place during load can be delayed because the page is busy evaluating scripts. While there's no guarantee that the desired interaction can take place at this point in time—as a script responsible for it may not have loaded yet—there could be interactions dependent on JavaScript that are ready, or the interactivity doesn't depend on JavaScript at all.

The relationship between scripts and the tasks that evaluate them #

How tasks responsible for script evaluation are kicked off depends on whether the script you're loading is loaded via a regular <script> element, or if a script is a module loaded with the type=module. Since browsers have the tendency to handle things differently, how the major browser engines handle script evaluation will be touched upon where script evaluation behaviors across them vary.

Loading scripts with the `<script>` element #

The number of tasks dispatched to evaluate scripts generally has a direct relationship with the number of <script> elements on a page. Each <script> element kicks off a task to evaluate the requested script so it can be parsed, compiled, and executed. This is the case for Chromium-based browsers, Safari, and Firefox.

Why does this matter? Let's say you're using a bundler to manage your production scripts, and you've configured it to bundle everything your page needs to run into a single script. If this is the case for your website, you can expect that there will be a single task dispatched to evaluate that script. Is this a bad thing? Not necessarily—unless that script is huge.

You can break up script evaluation work by avoiding loading large chunks of JavaScript, and load more individual, smaller scripts using additional <script> elements.

While you should always strive to load as little JavaScript as possible during page load, splitting up your scripts ensures that, instead of one large task that may block the main thread, you have a greater number of smaller tasks that won't block the main thread at all—or at least less than what you started with.

Multiple tasks spawned to evaluate scripts as a result of multiple <script> elements present in the page's HTML. This is preferable to sending one large script bundle to users, which is more likely to block the main thread.

You can think of breaking up tasks for script evaluation as being somewhat similar to yielding during event callbacks that run during an interaction. However, with script evaluation, the yielding mechanism breaks up the JavaScript you load into multiple smaller scripts, rather than a smaller number of larger scripts than are more likely to block the main thread.

Loading scripts with the `<script>` element and the `type=module` attribute #

It's now possible to load ES modules natively in the browser with the type=module attribute on the <script> element. This approach to script loading carries some developer experience benefits, such as not having to transform code for production use—especially when used in combination with import maps. However, loading scripts in this way schedules tasks that differ from browser to browser.

Chromium-based browsers #

In browsers such as Chrome—or those derived from it—loading ES modules using the type=module attribute produces different sorts of tasks than you'd normally see when not using type=module. For example, a task for each module script will run that involves activity labeled as Compile module.

Module loading behavior in Chromium-based browsers. Each module script will spawn a Compile module call to compile their contents prior to evaluation.

Once the modules have compiled, any code that subsequently runs in them will kick off activity labeled as Evaluate module.

When code in a module runs, that module will be evaluated just-in-time.

The effect here—in Chrome and related browsers, at least—is that the compilation steps are broken up when using ES modules. This is a clear win in terms of managing long tasks; however, the resulting module evaluation work that results still means you're incurring some unavoidable cost. While you should strive to ship as little JavaScript as possible, using ES modules—regardless of the browser—provides the following benefits:

All module code is automatically run in strict mode, which allows potential optimizations by JavaScript engines that couldn't otherwise be made in a non-strict context.
Scripts loaded using type=module are treated as if they were deferred by default. It's possible to use the async attribute on scripts loaded with type=module to change this behavior.

Safari and Firefox #

When modules are loaded in Safari and Firefox, each of them is evaluated in a separate task. This means you could theoretically load a single top-level module consisting of only static import statements to other modules, and every module loaded will incur a separate network request and task to evaluate it.

Loading scripts with dynamic `import()` #

Dynamic import() is another method for loading scripts. Unlike static import statements that are required to be at the top of an ES module, a dynamic import() call can appear anywhere in a script to load a chunk of JavaScript on demand. This technique is called code splitting.

Dynamic import() has two advantages when it comes to improving INP:

Modules which are deferred to load later reduce main thread contention during startup by reducing the amount of JavaScript loaded at that time. This frees up the main thread so it can be more responsive to user interactions.
When dynamic import() calls are made, each call will effectively separate the compilation and evaluation of each module to its own task. Of course, a dynamic import() that loads a very large module will kick off a rather large script evaluation task, and that can interfere with the ability of the main thread to respond to user input if the interaction occurs at the same time as the dynamic import() call. Therefore, it's still very important that you load as little JavaScript as possible.

Dynamic import() calls behave similarly in all major browser engines: the script evaluation tasks that result will be the same as the amount of modules that are dynamically imported.

Loading scripts in a web worker #

Web workers are a special JavaScript use case. Web workers are registered on the main thread, and the code within the worker then runs on its own thread. This is hugely beneficial in the sense that—while the code that registers the web worker runs on the main thread—the code within the web worker doesn't. This reduces main thread congestion, and can help keep the main thread more responsive to user interactions.

In addition to reducing main thread work, web workers themselves can load external scripts to be used in the worker context, either through importScripts or static import statements in browsers that support module workers. The result is that any script requested by a web worker is evaluated off the main thread.

Trade-offs and considerations #

While breaking up your scripts into separate, smaller files helps limit long tasks as opposed to loading fewer, much larger files, it's important to take some things into account when deciding how to break scripts up.

Compression efficiency #

Compression is a factor when it comes to breaking up scripts. When scripts are smaller, compression becomes somewhat less efficient. Larger scripts will benefit much more from compression. While increasing compression efficiency helps to keep load times for scripts as low as possible, it's a bit of a balancing act to ensure that you're breaking up scripts into enough smaller chunks to facilitate better interactivity during startup.

Bundlers are ideal tools for managing the output size for the scripts your website depends on:

Where webpack is concerned, its SplitChunksPlugin plugin can help. Consult the SplitChunksPlugin documentation for options you can set to help manage asset sizes.
For other bundlers such as Rollup and esbuild, you can manage script file sizes by using dynamic import() calls in your code. These bundlers—as well as webpack—will automatically break off the dynamically imported asset into its own file, thus avoiding larger initial bundle sizes.

Cache invalidation #

Cache invalidation plays a big role in how fast a page loads on repeat visits. When you ship large, monolithic script bundles, you're at a disadvantage when it comes to browser caching. This is because when you update your first-party code—either through updating packages or shipping bug fixes—the entire bundle becomes invalidated and must be downloaded again.

By breaking up your scripts, you're not just breaking up script evaluation work across smaller tasks, you're also increasing the likelihood that return visitors will grab more scripts from the browser cache instead of from the network. This translates into an overall faster page load.

Nested modules and loading performance #

If you're shipping ES modules in production and loading them with the type=module attribute, you need to be aware of how module nesting can impact startup time. Module nesting refers to when an ES module statically imports another ES module that statically imports another ES module:

// a.js
import {b} from './b.js';

// b.js
import {c} from './c.js';

If your ES modules are not bundled together, the preceding code results in a network request chain: when a.js is requested from a <script> element, another network request is dispatched for b.js, which then involves another request for c.js. One way to avoid this is to use a bundler—but be sure you're configuring your bundler to break up scripts to spread out script evaluation work.

If you don't want to use a bundler, then another way to get around nested module calls is to use the modulepreload resource hint, which will preload ES modules ahead of time to avoid network request chains. Beware, however: this hint is currently only supported in Chromium-based browsers.

Conclusion #

Optimizing evaluation of scripts in the browser is no doubt a tricky feat. The approach depends on your website's requirements and constraints. However, by splitting up scripts, you're spreading the work of script evaluation over numerous smaller tasks, and therefore giving the main thread the ability to handle user interactions more efficiently, rather than blocking the main thread.

To recap, here are some things you can to do to break up large script evaluation tasks:

When loading scripts using the <script> element without the type=module attribute, avoid loading scripts that are very large, as these will kick off resource-intensive script evaluation tasks that block the main thread. Spread out your scripts over more <script> elements to break up this work.
Using the type=module attribute to load ES modules natively in the browser will kick off individual tasks for evaluation for each separate module script.
Reduce the size of your initial bundles by using dynamic import() calls. This also works in bundlers, as bundlers will treat each dynamically imported module as a "split point," resulting in a separate script being generated for each dynamically imported module.
Be sure to weigh trade-offs such as compression efficiency and cache invalidation. Larger scripts will compress better, but are more likely to involve more expensive script evaluation work in fewer tasks, and result in browser cache invalidation, leading to overall lower caching efficiency.
If using ES modules natively without bundling, use the modulepreload resource hint to optimize the loading of them during startup.
As always, ship as little JavaScript as possible.

It's a balancing act for sure—but by breaking up scripts and reducing initial payloads via dynamic import(), you can achieve better startup performance and better accommodate user interactions during that crucial startup period. This should help you score better on the INP metric, thus delivering a better user experience.

Hero image from Unsplash, by Markus Spiske.

Optimize Time to First Byte

2023-01-19T00:00:00Z

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

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

Important

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

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

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

How to Measure TTFB #

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

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

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

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

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

Understanding high TTFB with `Server-Timing` #

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ways to optimize TTFB #

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

Platform-specific guidance #

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

Hosting, hosting, hosting #

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

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

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

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

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

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

Use a Content Delivery Network (CDN) #

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

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

CDN providers may also offer benefits beyond edge servers:

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

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

Used cached content where possible #

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

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

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

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

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

Avoid multiple page redirects #

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

There are two types of redirects:

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

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

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

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

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

Stream markup to the browser #

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

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

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

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

Use a service worker #

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

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

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

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

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

Conclusion #

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

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

Hero image by Taylor Vick, sourced from Unsplash.

Our top Core Web Vitals recommendations for 2023

2023-01-10T00:00:00Z

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

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

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

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

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

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

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

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

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

Largest Contentful Paint (LCP) #

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

Ensure the LCP resource is discoverable from the HTML source #

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

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

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

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

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

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

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

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

Ensure the LCP resource is prioritized #

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

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

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

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

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

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

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

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

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

Use a CDN to optimize document and resource TTFB #

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

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

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

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

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

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

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

Some tips for configuring your CDNs are:

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

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

Cumulative Layout Shift (CLS) #

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

Set explicit sizes on any content loaded from the page #

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

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

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

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

Ensure pages are eligible for bfcache #

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

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

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

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

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

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

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

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

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

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

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

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

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

First Input Delay (FID) #

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

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

Avoid or break up long tasks #

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

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

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

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

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

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

Avoid unnecessary JavaScript #

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

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

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

Avoid large rendering updates #

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

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

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

Conclusion #

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

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

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

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

Photo by Devin Avery

Optimize Interaction to Next Paint

2022-12-08T00:00:00Z

Interaction to Next Paint (INP) is a pending Core Web Vital metric that assesses a page's overall responsiveness to user interactions by observing the latency of all qualifying interactions that occur throughout the lifespan of a user's visit to a page. The final INP value is the longest interaction observed (sometimes ignoring outliers).

To provide a good user experience, websites should strive to have an Interaction to Next Paint of 200 milliseconds or less. To ensure you're hitting this target for most of your users, a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.

Depending on the website, there may be few to no interactions—such as pages of mostly text and images with few to no interactive elements. Or, in the case of websites such as text editors or games, there could be hundreds—even thousands—of interactions. In either case, where there's a high INP, the user experience is at risk.

It takes time and effort to improve INP, but the reward is a better user experience. In this guide, a path to improving INP will be explored.

Figure out what's causing poor INP #

Before you can fix slow interactions, you'll need data to tell you if your website's INP is poor or needs improvement. Once you have that information, you can move into the lab to begin diagnosing slow interactions, and work your way toward a solution.

Find slow interactions in the field #

Ideally, your journey in optimizing INP will start with field data. At its best, field data from a Real User Monitoring (RUM) provider will give you not only a page's INP value, but also contextual data that highlights what specific interaction was responsible for the INP value itself, whether the interaction occurred during or after page load, the type of interaction (click, keypress, or tap), and other valuable information.

If you're not relying on a RUM provider to get field data, the INP field data guide advises using the Chrome User Experience Report (CrUX) via PageSpeed Insights to help fill in the gaps. CrUX is the official dataset of the Core Web Vitals program and provides a high-level summary of metrics for millions of websites, including INP. However, CrUX often does not provide the contextual data you'd get from a RUM provider to help you to analyze issues. Because of this, we still recommend that sites use a RUM provider when possible, or implement their own RUM solution to supplement what is available in CrUX.

Diagnose slow interactions in the lab #

Ideally, you'll want to start testing in the lab once you have field data that suggests you have slow interactions. In the absence of field data, there are some strategies for identifying slow interactions in the lab. Such strategies include following common user flows and testing interactions along the way, as well as interacting with the page during load—when the main thread is often busiest—in order to surface slow interactions during that crucial part of the user experience.

Optimize interactions #

Once you've identified a slow interaction and can reproduce it in the lab, the next step is to optimize it. Interactions can be broken down into three phases:

The input delay, which starts when the user initiates an interaction with the page, and ends when the event callbacks for the interaction begin to run.
The processing time, which consists of the time it takes for event callbacks to run to completion.
The presentation delay, which is the time it takes for the browser to present the next frame which contains the visual result of the interaction.

The sum of these three phases is the total interaction latency. Every single phase of an interaction contributes some amount of time to total interaction latency, so it's important to know how you can optimize each part of the interaction so it runs for as little time as possible.

Identify and reduce input delay #

When a user interacts with a page, the first part of that interaction is the input delay. Depending on other activity on the page, input delays can be considerable in length. This could be due to activity occurring on the main thread (perhaps due to scripts loading, parsing and compiling), fetch handling, timer functions, or even from other interactions that occur in quick succession and overlap with one another.

Whatever the source of an interaction's input delay, you'll want to reduce input delay to a minimum so that interactions can begin running event callbacks as soon as possible.

The relationship between script evaluation and long tasks during startup #

A critical aspect of interactivity in the page lifecycle is during startup. As a page loads, it will initially render, but it's important to remember that just because a page has rendered, doesn't mean that the page is finished loading. Depending on how many resources a page requires to become fully functional, it's possible that users may attempt to interact with the page while it's still loading.

One thing that can extend an interaction's input delay while a page loads is script evaluation. After a JavaScript file has been fetched from the network, the browser still has work to do before that JavaScript can run; that work includes parsing a script to ensure its syntax is valid, compiling it into bytecode, and then finally executing it.

Depending on the size of a script, this work can introduce long tasks on the main thread, which will delay the browser from responding to other user interactions. To keep your page responsive to user input during page load, it's important to understand what you can do to reduce the likelihood of long tasks during page load so the page stays snappy.

Optimize event callbacks #

The input delay is only the first part of what INP measures. You'll also need to make sure that the event callbacks that run in response to a user interaction can complete as quickly as possible.

Yield to the main thread often #

The best general advice in optimizing event callbacks is to do as little work as possible in them. However, your interaction logic may be complex, and you may only be able to marginally reduce the work they do.

If you find this is the case for your website, the next thing you can try is to break up the work in event callbacks into separate tasks. This prevents the collective work from becoming a long task that blocks the main thread, which allows other interactions that otherwise would be waiting on the main thread to run sooner.

setTimeout is one way to break up tasks, because the callback passed to it runs in a new task. You can use setTimeout by itself or abstract its use into a separate function for more ergonomic yielding.

Yielding indiscriminately is better than not yielding at all—however, there is a more nuanced way of yielding to the main thread, and that involves only yielding immediately after an event callback that updates the user interface so rendering logic can run sooner.

Yield to allow rendering work to occur sooner #

A more advanced yielding technique involves structuring the code in your event callbacks to limit what gets run to just the logic required to apply visual updates for the next frame. Everything else can be deferred to a subsequent task. This not only keeps callbacks light and nimble, but it also improves rendering time for interactions by not allowing visual updates to block on event callback code.

For example, imagine a rich text editor that formats text as you type, but also updates other aspects of the UI in response to what you've written (such as word count, highlighting spelling mistakes, and other important visual feedback). In addition, the application may also need to save what you've written so that if you leave and return, you haven't lost any work.

In this example, the following four things need to happen in response to characters typed by the user. However, only the first item needs to be done before the next frame is presented.

Update the text box with what the user typed and apply any required formatting.
Update the part of the UI that displays the current word count.
Run logic to check for spelling mistakes.
Save the most recent changes (either locally or to a remote database).

The code to do this might look something like the following:

textBox.addEventListener('input', (inputEvent) => {
  // Update the UI immediately, so the changes the user made
  // are visible as soon as the next frame is presented.
  updateTextBox(inputEvent);

  // Use `setTimeout` to defer all other work until at least the next
  // frame by queuing a task in a `requestAnimationFrame()` callback.
  requestAnimationFrame(() => {
    setTimeout(() => {
      const text = textBox.textContent;
      updateWordCount(text);
      checkSpelling(text);
      saveChanges(text);
    }, 0);
  });
});

The following visualization shows how deferring any non-critical updates until after the next frame can reduce the processing time and thus the overall interaction latency.

Click the above figure to see a high-resolution version.

While the use of setTimeout() inside a requestAnimationFrame() call in the previous code example is admittedly a bit esoteric, it is an effective method that works in all browsers to ensure that the non-critical code does not block the next frame.

Avoid layout thrashing #

Layout thrashing—sometimes called forced synchronous layout—is a rendering performance problem where layout occurs synchronously. It occurs when you update styles in JavaScript, and then read them in the same task—and there are many properties in JavaScript that can cause layout thrashing.

An example of layout thrashing, as shown in the performance panel of Chrome DevTools. Rendering tasks that involve layout thrashing will be noted with a red triangle at the upper right corner of the portion of the call stack, often labeled Recalculate Style or Layout.

Layout thrashing is a performance bottleneck because by updating styles and then immediately requesting the values of those styles in JavaScript, the browser is forced to do synchronous layout work it otherwise could have waited to perform asynchronously later on after event callbacks have finished running.

Minimize presentation delay #

The presentation delay of an interaction marks spans from when an interaction's event callbacks have finished running, up to the point at which the browser is able to paint the next frame that shows the resulting visual changes.

Minimize DOM size #

When a page's DOM is small, rendering work usually finishes quickly. However, when DOMs get very large, rendering work tends to scale with increasing DOM size. The relationship between rendering work and DOM size isn't a linear one, but large DOMs do require more work to render than small DOMs. A large DOM is problematic in two cases:

During the initial page render, where a large DOM requires a lot of work to render the page's initial state.
In response to a user interaction, where a large DOM can cause rendering updates to be very expensive, and therefore increase the time it takes for the browser to present the next frame.

Bear in mind that there are instances in which large DOMs can't be significantly reduced. While there are approaches you can take to reduce DOM size, such as flattening your DOM or add to the DOM during user interactions to keep your initial DOM size small, those techniques may only go so far.

Use `content-visibility` to lazily render off-screen elements #

One way you can limit the amount of both rendering work during page load and rendering work in response to user interactions is to lean on the CSS content-visibility property, which effectively amounts to lazily rendering elements as they approach the viewport. While content-visibility can take some practice to use effectively, it's worth investigating if the result is lower rendering time that can improve your page's INP.

Be aware of performance costs when rendering HTML using JavaScript #

Where there's HTML, there's HTML parsing, and after the browser has finished parsing HTML into a DOM, it must apply styles to it, perform layout calculations, and subsequently render that layout. This is an unavoidable cost, but how you go about rendering HTML matters.

When the server sends HTML, it arrives in the browser as a stream. Streaming means that the HTML response from the server is arriving in chunks. The browser optimizes how it handles a stream by incrementally parsing chunks of that stream as they arrive, and rendering them bit by bit. This is a performance optimization in that the browser implicitly yields periodically and automatically during page load, and you get that for free.

While the first visit to any website will always involve some amount of HTML, a common approach starts with a minimal initial bit of HTML, and then JavaScript is used to populate the content area. Subsequent updates to that content area also occur as the result of user interactions. This is usually called the single-page application (SPA) model. One drawback of this pattern is that, by rendering HTML with JavaScript on the client, you not only get the cost of the JavaScript processing to create that HTML, but also the browser will not yield until it has finished parsing that HTML, and rendering it.

It's vital to remember though, that even websites that aren't SPAs will probably involve some amount of HTML rendering through JavaScript as the result of interactions. This is generally fine, so long as you're not rendering large amounts of HTML on the client, which can delay presentation of the next frame. However, it's important to understand the performance implications of this approach to rendering HTML in the browser, and how it can impact the responsiveness of your website to user input if you are rendering a lot of HTML via JavaScript.

Conclusion #

Improving your site's INP is an iterative process. When you fix a slow interaction in the field, the chances are good that—especially if your website provides lots of interactivity—you'll start to find other slow interactions, and you'll need to optimize them too.

The key to improving INP is persistence. In time, you can get your page's responsiveness to a place where users are happy with the experience you're providing them. The chances are also good that as you develop new features for your users, you may need to go through the same process in optimizing interactions specific to them. It will take time and effort, but it's time and effort well spent.

Hero image from Unsplash, by David Pisnoy and modified in accordance with the Unsplash license.

Optimize long tasks

2022-09-30T00:00:00Z

If you read lots of stuff about web performance, the advice for keeping your JavaScript apps fast tends to involve some of these tidbits:

"Don't block the main thread."
"Break up your long tasks."

What does any of that mean? Shipping less JavaScript is good, but does that automatically equate to snappier user interfaces throughout the page lifecycle? Maybe, but maybe not.

To get your head around why it's important to optimize tasks in JavaScript, you need to understand the role of tasks and how the browser handles them—and that starts with understanding what a task is.

What is a task? #

A task is any discrete piece of work that the browser does. Tasks involve work such as rendering, parsing HTML and CSS, running the JavaScript code you write, and other things you may not have direct control over. Of all of this, the JavaScript you write and deploy to the web is a major source of tasks.

A depiction of a task kicked off by a click event handler in the performance profiler in Chrome DevTools.

Tasks impact performance in a couple of ways. For example, when a browser downloads a JavaScript file during startup, it queues tasks to parse and compile that JavaScript so it can be executed. Later on in the page lifecycle, tasks are kicked off when your JavaScript does work such as driving interactions through event handlers, JavaScript-driven animations, and background activity such as analytics collection. All of this stuff—with the exception of web workers and similar APIs—happens on the main thread.

What is the main thread? #

The main thread is where most tasks are run in the browser. It's called the main thread for a reason: it's the one thread where nearly all the JavaScript you write does its work.

The main thread can only process one task at a time. When tasks stretch beyond a certain point—50 milliseconds to be exact—they're classified as long tasks. If the user is attempting to interact with the page while a long task runs—or if an important rendering update needs to happen—the browser will be delayed in handling that work. This results in interaction or rendering latency.

A long task as depicted in Chrome's performance profiler. Long tasks are indicated by a red triangle in the corner of the task, with the blocking portion of the task filled in with a pattern of diagonal red stripes.

You need to break up tasks. This means taking a single long task and dividing it into smaller tasks that take less time to run individually.

A visualization of a single long task versus that same task broken up into five shorter tasks.

This matters because when tasks are broken up, the browser has more opportunities to respond to higher-priority work—and that includes user interactions.

A visualization of what happens to interactions when tasks are too long and the browser can't respond quickly enough to interactions, versus when longer tasks are broken up into smaller tasks.

At the top of the preceding figure, an event handler queued up by a user interaction had to wait for a single long task before it could run, This delays the interaction from taking place. At the bottom, the event handler has a chance to run sooner. Because the event handler had an opportunity to run in between smaller tasks, it runs sooner than if it had to wait for a long task to finish. In the top example, the user might have noticed lag; in the bottom, the interaction might have felt instant.

The problem, though, is that the advice of "break up your long tasks" and "don't block the main thread" isn't specific enough unless you already know how to do those things. That's what this guide will explain.

Task management strategies #

A common bit of advice in software architecture is to break up your work into smaller functions. This gives you the benefits of better code readability, and project maintainability. This also makes tests easier to write.

function saveSettings () {
  validateForm();
  showSpinner();
  saveToDatabase();
  updateUI();
  sendAnalytics();
}

In this example, there's a function named saveSettings() that calls five functions within it to do the work, such as validating a form, showing a spinner, sending data, and so on. Conceptually, this is well architected. If you need to debug one of these functions, you can traverse the project tree to figure out what each function does.

The problem, however, is that JavaScript doesn't run each of these functions as separate tasks because they are being executed within the saveSettings() function. This means that all five functions run as a single task.

A single function saveSettings() that calls five functions. The work is run as part of one long monolithic task.

In the best case scenario, even just one of those functions can contribute 50 milliseconds or more to the total length of the task. In the worst case, more of those tasks can run quite a bit longer—especially on resource-constrained devices. What follows is a set of strategies you can use to break up and prioritize tasks.

Manually defer code execution #

One method developers have used to break up tasks into smaller ones involves setTimeout(). With this technique, you pass the function to setTimeout(). This postpones execution of the callback into a separate task, even if you specify a timeout of 0.

function saveSettings () {
  // Do critical work that is user-visible:
  validateForm();
  showSpinner();
  updateUI();

  // Defer work that isn't user-visible to a separate task:
  setTimeout(() => {
    saveToDatabase();
    sendAnalytics();
  }, 0);
}

This works well if you have a series of functions that need to run sequentially, but your code may not always be organized this way. For example, you could have a large amount of data that needs to be processed in a loop, and that task could take a very long time if you have millions of items.

function processData () {
  for (const item of largeDataArray) {
    // Process the individual item here.
  }
}

Using setTimeout() here is problematic, because the ergonomics of it make it difficult to implement, and the entire array of data could take a very long time to process, even if each item can be processed very quickly. It all adds up, and setTimeout() isn't the right tool for the job—at least not when used this way.

In addition to setTimeout(), there are a few other APIs that allow you to defer code execution to a subsequent task. One involves using postMessage() for faster timeouts. You can also break up work using requestIdleCallback()—but beware!—requestIdleCallback() schedules tasks at the lowest possible priority, and only during browser idle time. When the main thread is congested, tasks scheduled with requestIdleCallback() may never get to run.

Use `async`/`await` to create yield points #

A phrase you'll see throughout the rest of this guide is "yield to the main thread"—but what does that mean? Why should you do it? When should you do it?

When tasks are broken up, other tasks can be prioritized better by the browser's internal prioritization scheme. One way to yield to the main thread involves using a combination of a Promise that resolves with a call to setTimeout():

function yieldToMain () {
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

In the saveSettings() function, you can yield to the main thread after each bit of work if you await the yieldToMain() function after each function call:

async function saveSettings () {
  // Create an array of functions to run:
  const tasks = [
    validateForm,
    showSpinner,
    saveToDatabase,
    updateUI,
    sendAnalytics
  ]

  // Loop over the tasks:
  while (tasks.length > 0) {
    // Shift the first task off the tasks array:
    const task = tasks.shift();

    // Run the task:
    task();

    // Yield to the main thread:
    await yieldToMain();
  }
}

The result is that the once-monolithic task is now broken up into separate tasks.

The saveSettings() function now executes its child functions as separate tasks.

The benefit of using a promise-based approach to yielding rather than manual use of setTimeout() is better ergonomics. Yield points become declarative, and therefore easier to write, read, and understand.

Yield only when necessary #

What if you have a bunch of tasks, but you only want to yield if the user attempts to interact with the page? That's the kind of thing that isInputPending() was made for.

isInputPending() is a function you can run at any time to determine if the user is attempting to interact with a page element: a call to isInputPending() will return true. It returns false otherwise.

Say you have a queue of tasks you need to run, but you don't want to get in the way of any inputs. This code—which uses both isInputPending() and our custom yieldToMain() function—ensures that an input won't be delayed while the user is trying to interact with the page:

async function saveSettings () {
  // A task queue of functions
  const tasks = [
    validateForm,
    showSpinner,
    saveToDatabase,
    updateUI,
    sendAnalytics
  ];
  
  while (tasks.length > 0) {
    // Yield to a pending user input:
    if (navigator.scheduling.isInputPending()) {
      // There's a pending user input. Yield here:
      await yieldToMain();
    } else {
      // Shift the task out of the queue:
      const task = tasks.shift();

      // Run the task:
      task();
    }
  }
}

While saveSettings() runs, it will loop over the tasks in the queue. If isInputPending() returns true during the loop, saveSettings() will call yieldToMain() so the user input can be handled. Otherwise, it will shift the next task off the front of the queue and run it continuously. It will do this until no more tasks are left.

saveSettings() runs a task queue for five tasks, but the user has clicked to open a menu while the second work item was running. isInputPending() yields to the main thread to handle the interaction, and resume running the rest of the tasks.

Using isInputPending() in combination with a yielding mechanism is a great way to get the browser to stop whatever tasks it's processing so that it can respond to critical user-facing interactions. That can help improve your page's ability to respond to the user in many situations when a lot of tasks are in flight.

Another way to use isInputPending()—particularly if you're concerned about providing a fallback for browsers that don't support it—is to use a time-based approach in conjunction with the optional chaining operator:

async function saveSettings () {
  // A task queue of functions
  const tasks = [
    validateForm,
    showSpinner,
    saveToDatabase,
    updateUI,
    sendAnalytics
  ];
  
  let deadline = performance.now() + 50;

  while (tasks.length > 0) {
    // Optional chaining operator used here helps to avoid
    // errors in browsers that don't support `isInputPending`:
    if (navigator.scheduling?.isInputPending() || performance.now() >= deadline) {
      // There's a pending user input, or the
      // deadline has been reached. Yield here:
      await yieldToMain();

      // Extend the deadline:
      deadline = performance.now() + 50;

      // Stop the execution of the current loop and
      // move onto the next iteration:
      continue;
    }

    // Shift the task out of the queue:
    const task = tasks.shift();

    // Run the task:
    task();
  }
}

With this approach, you get a fallback for browsers that don't support isInputPending() by using a time-based approach that uses (and adjusts) a deadline so that work will be broken up where necessary, whether by yielding to user input, or by a certain point in time.

Gaps in current APIs #

The APIs mentioned so far can help you break up tasks, but they have a significant downside: when you yield to the main thread by deferring code to run in a subsequent task, that code gets added to the very end of the task queue.

If you control all the code on your page, it's possible to create your own scheduler with the ability to prioritize tasks, but third-party scripts won't use your scheduler. In effect, you're not really able to prioritize work in such environments. You can only chunk it up, or explicitly yield to user interactions.

Fortunately, there is a dedicated scheduler API that is currently in development that addresses these problems.

A dedicated scheduler API #

The scheduler API currently offers the postTask() function which, at the time of writing, is available in Chromium browsers, and in Firefox behind a flag. postTask() allows for finer-grained scheduling of tasks, and is one way to help the browser prioritize work so that low priority tasks yield to the main thread. postTask() uses promises, and accepts a priority setting.

The postTask() API has three priorities you can use:

'background' for the lowest priority tasks.
'user-visible' for medium priority tasks. This is the default if no priority is set.
'user-blocking' for critical tasks that need to run at high priority.

Take the following code as an example, where the postTask() API is used to run three tasks at the highest possible priority, and the remaining two tasks at the lowest possible priority.

function saveSettings () {
  // Validate the form at high priority
  scheduler.postTask(validateForm, {priority: 'user-blocking'});

  // Show the spinner at high priority:
  scheduler.postTask(showSpinner, {priority: 'user-blocking'});

  // Update the database in the background:
  scheduler.postTask(saveToDatabase, {priority: 'background'});

  // Update the user interface at high priority:
  scheduler.postTask(updateUI, {priority: 'user-blocking'});

  // Send analytics data in the background:
  scheduler.postTask(sendAnalytics, {priority: 'background'});
};

Here, the priority of tasks is scheduled in such a way that browser-prioritized tasks—such as user interactions—can work their way in.

When saveSettings() is run, the function schedules the individual functions using postTask(). The critical user-facing work is scheduled at high priority, while work the user doesn't know about is scheduled to run in the background. This allows for user interactions to execute more quickly, as the work is both broken up and prioritized appropriately.

This is a simplistic example of how postTask() can be used. It's possible to instantiate different TaskController objects that can share priorities between tasks, including the ability to change priorities for different TaskController instances as needed.

Built-in yield with continuation via `scheduler.yield` #

One proposed part of the scheduler API is scheduler.yield, an API specifically designed for yielding to the main thread in the browser which is currently available to try as an origin trial. Its use resembles the yieldToMain() function demonstrated earlier in this article:

async function saveSettings () {
  // Create an array of functions to run:
  const tasks = [
    validateForm,
    showSpinner,
    saveToDatabase,
    updateUI,
    sendAnalytics
  ]

  // Loop over the tasks:
  while (tasks.length > 0) {
    // Shift the first task off the tasks array:
    const task = tasks.shift();

    // Run the task:
    task();

    // Yield to the main thread with the scheduler
    // API's own yielding mechanism:
    await scheduler.yield();
  }
}

You'll note that the code above is largely familiar, but instead of using yieldToMain(), you call and await scheduler.yield() instead.

A visualization of task execution without yielding, with yielding, and with yielding and continuation. When scheduler.yield() is used, task execution picks up where it left off even after the yield point.

The benefit of scheduler.yield() is continuation, which means that if you yield in the middle of a set of tasks, the other scheduled tasks will continue in the same order after the yield point. This avoids code from third-party scripts from usurping the order of your code's execution.

Conclusion #

Managing tasks is challenging, but doing so helps your page respond more quickly to user interactions. There's no one single piece of advice for managing and prioritizing tasks. Rather, it's a number of different techniques. To reiterate, these are the main things you'll want to consider when managing tasks:

Yield to the main thread for critical, user-facing tasks.
Use isInputPending() to yield to the main thread when the user is trying to interact with the page.
Prioritize tasks with postTask().
Finally, do as little work as possible in your functions.

With one or more of these tools, you should be able to structure the work in your application so that it prioritizes the user's needs, while ensuring that less critical work still gets done. That's going to create a better user experience which is more responsive and more enjoyable to use.

Special thanks to Philip Walton for his technical vetting of this article.

Hero image sourced from Unsplash, courtesy of Amirali Mirhashemian.

How the BBC is rolling out HSTS for better security and performance.

2022-07-25T00:00:00Z

HTTPS adoption has been steadily increasing in recent years. Per the HTTP Archive's 2021 Web Almanac, around 91% of all requests for both desktop and mobile were served over HTTPS. HTTPS isn't just here to stay, it's a necessary prerequisite to use features such as Service Worker and modern protocols such as HTTP/2 and HTTP/3.

Recently Neil Craig—a lead technical Architect at the BBC—tweeted that HTTP Strict Transport Security (HSTS) is being slowly rolled out for bbc.com. Let's find out what that means for the BBC, and what it could mean for you.

The problem #

Web servers often listen for requests on both ports 80 and 443. Port 80 is for insecure HTTP requests, whereas 443 is for secure HTTPS. This can create a problem, because when you enter an address into your address bar without the https:// protocol prefix—like most users tend to do—some browsers will direct traffic to the insecure HTTP version of a site, for legacy reasons (though this isn't always the case).

A common way to ensure users don't access an unsecured version of a website is to place an HTTP-to-HTTPS redirect for all requests. This certainly works, but it kicks off the following chain of events:

The server receives a request via HTTP.
The server issues a redirect to go to the HTTPS equivalent of the requested resource.
The server via HTTPS must negotiate a secure connection with the browser.
The content loads as usual.

While redirects work fine, they can be misconfigured in ways that still allow access to the insecure version of a site. Even if everything is configured properly, there is still a security issue in that the user will still connect over insecure HTTP during the redirect phase, which exposes users to the possibility of dangerous man-in-the-middle attacks.

Enter HSTS #

Browser support

Chrome 4, Supported 4
Firefox 4, Supported 4
Edge 12, Supported 12
Safari 7, Supported 7

Source

HSTS is dictated by the Strict-Transport-Security HTTP response header for HTTPS requests. When set, return visits to a website will trigger a special redirect known as a "307 Internal Redirect", which is when the browser handles the redirect logic, rather than the server. This prevents the request being intercepted, since it never leaves the browser, so is more secure. As an added bonus, these types of redirect are extremely fast, so any noticeable latency during an HTTP-to-HTTPS hop is eliminated.

Similar in syntax to Cache-Control's max-age directive, an HSTS header specifies a max-age directive. This directive takes a value in seconds that specifies how long the policy is effective for:

Strict-Transport-Security: max-age=3600

In the above example, the policy should only take effect for an hour.

Deploying HSTS #

The main drawback of deploying HSTS is if you're not ready to treat your origin as strictly secure. Let's say you have a number of subdomains you're serving resources from, but maybe not all of them are secure. In this scenario, an HSTS header could break your website.

The BBC took the right approach to deploying HSTS. As Neil Craig mentioned in his tweet, the initial value that was set for bbc.com was max-age=10.

This approach means that the policy was only initially effective for ten seconds. This doesn't provide much of a benefit, but the idea is to feel out whether there may be issues with applying HSTS at all. As time goes on, you can increase the policy incrementally and see if issues occur. At the time of this writing, bbc.com is specifying an HSTS policy of max-age=86400, and that will almost certainly increase over time.

You certainly don't want to come out of the gate with a long max-age value when deploying HSTS. You could find yourself suddenly scrambling to fix issues while users experience problems. Start small, and increment over time! When you're confident all is well, you can set your max-age directive to a much longer period of time. It is recommended to set max-age to one or two years when it is fully rolled out.

Get safer and faster initial navigations with the HSTS preload list #

An HSTS policy only takes effect after the first visit to a website, so the benefits are not present for the first visit to the site. This will still require the insecure redirect. However, you can preload your HSTS policy by submitting your website to the HSTS preload list, which is a hardcoded list of websites that the browser knows are strictly HTTPS. When your site is on the preload list, the first visit is also protected and HTTP-to-HTTPS redirect latency via HSTS will be instantaneous.

Try it out for yourself #

If the BBC feels comfortable testing out HSTS, there's a good chance that you can do the same for your website. Give it a shot for your website, and—if you're looking to rev things up—add it to the HSTS preload list when you're confident there are no bugs to give your users a safer and faster experience.

GOV.UK drops jQuery from their front end.

2022-05-19T00:00:00Z

jQuery is a roughly 30 KiB dependency that nearly 84% of mobile pages used in 2021—and for good reason. jQuery was an instrumental tool in a time when we really needed a way to script interactivity in a way that smoothed over the differing implementations of stuff like event handling, selecting elements, animating elements, and so on.

The web is better because of jQuery—not just because it has such incredible utility, but because its ubiquity led to making what it provided part of the web platform itself. Nowadays, we can do just about anything jQuery can do in vanilla JavaScript:

We can select elements using a CSS selector syntax with querySelector and querySelectorAll.
We can add, remove, and toggle classes on elements with the classList API.
We can attach event handlers to DOM elements and the window using addEventListener.
And so, so, much more.

It really begs the question: Do we really need jQuery today? That's a question that GOV.UK has answered with a resounding "no". In March of 2022, Matt Hobbs announced that GOV.UK removed their jQuery dependency. This is a big deal when it comes to the user experience, because GOV.UK provides services and information online for The United Kingdom at scale. Not everyone is tapping away on their 2022 MacBook Pro on a rip-roarin' broadband connection. GOV.UK has to be accessible to everyone, and that means keepin' it lean.

Here's a few of the greatest hits from Matt Hobbs on what GOV.UK noticed in removing jQuery:

Less front end processing time overall.
11% less blocking time at the 75th percentile.
10% less blocking time for users at the 95th percentile. These are users who experience seriously adverse network and device conditions, and every performance gain matters especially for them.

For the full story, check out Matt's informative Twitter thread. It's great stuff for web performance geeks, and drives home the point that dependencies matter when it comes to performance. Don't shortchange your users if the web platform can easily do the job a framework can.

This level of commitment to the user experience from a institution that works at the scale GOV.UK does is commendable. I can only hope others follow in their footsteps.

Don't fight the browser preload scanner

2022-05-13T00:00:00Z

One overlooked aspect of optimizing page speed involves knowing a bit about browser internals. Browsers make certain optimizations to improve performance in ways that we as developers can't—but only so long as those optimizations aren't unintentionally thwarted.

One internal browser optimization to understand is the browser preload scanner. This post will cover how the preload scanner works—and more importantly, how you can avoid getting in its way.

What's a preload scanner? #

Every browser has a primary HTML parser that tokenizes raw markup and processes it into an object model. This all merrily goes on until the parser pauses when it finds a blocking resource, such as a stylesheet loaded with a <link> element, or script loaded with a <script> element without an async or defer attribute.

Fig. 1: A diagram of how the browser's primary HTML parser can be blocked. In this case, the parser runs into a <link> element for an external CSS file, which blocks the browser from parsing the rest of the document—or even rendering any of it—until the CSS is downloaded and parsed.

In the case of CSS files, both parsing and rendering are blocked in order to prevent a flash of unstyled content (FOUC), which is when an unstyled version of a page can be seen briefly before styles are applied to it.

Fig. 2: A simulated example of FOUC. At left is the front page of web.dev without styles. At right is the same page with styles applied. The unstyled state can occur in a flash if the browser doesn't block rendering while a stylesheet is being downloaded and processed.

The browser also blocks parsing and rendering of the page when it encounters <script> elements without a defer or async attribute.

The reason for this is that the browser can't know for sure if any given script will modify the DOM while the primary HTML parser is still doing its job. This is why it's been a common practice to load your JavaScript at the end of the document so that the effects of blocked parsing and rendering become marginal.

These are good reasons for why the browser should block both parsing and rendering. Yet, blocking either of these important steps is undesirable, as they can hold up the show by delaying the discovery of other important resources. Thankfully, browsers do their best to mitigate these problems by way of a secondary HTML parser called a preload scanner.

Fig. 3: A diagram depicting how the preload scanner works in parallel with the primary HTML parser to speculatively load assets. Here, the primary HTML parser is blocked as it loads and processes CSS before it can begin processing image markup in the <body> element, but the preload scanner can look ahead in the raw markup to find that image resource and begin loading it before the primary HTML parser is unblocked.

A preload scanner's role is speculative, meaning that it examines raw markup in order to find resources to opportunistically fetch before the primary HTML parser would otherwise discover them.

How to tell when the preload scanner is working #

The preload scanner exists because of blocked rendering and parsing. If these two performance issues never existed, the preload scanner wouldn't be very useful. The key to figuring out whether a web page benefits from the preload scanner depends on these blocking phenomena. To do that, you can introduce an artificial delay for requests to find out where the preload scanner is working.

Take this page of basic text and images with a stylesheet as an example. Because CSS files block both rendering and parsing, you introduce an artificial delay of two seconds for the stylesheet through a proxy service. This delay makes it easier to see in the network waterfall where the preload scanner is working.

Fig. 4: A WebPageTest network waterfall chart of a web page run on Chrome on a mobile device over a simulated 3G connection. Even though the stylesheet is artificially delayed through a proxy by two seconds before it begins to load, the image located later in the markup payload is discovered by the preload scanner.

As you can see in the waterfall, the preload scanner discovers the <img> element even while rendering and document parsing is blocked. Without this optimization, the browser can't fetch things opportunistically during the blocking period, and more resource requests would be consecutive rather than concurrent.

With that toy example out of the way, let's take a look at some real-world patterns where the preload scanner can be defeated—and what can be done to fix them.

Injected `async` scripts #

Let's say you've got HTML in your <head> that includes some inline JavaScript like this:

<script>
  const scriptEl = document.createElement('script');
  scriptEl.src = '/yall.min.js';

  document.head.appendChild(scriptEl);
</script>

Injected scripts are async by default, so when this script is injected, it will behave as if the async attribute was applied to it. That means it will run as soon as possible and not block rendering. Sounds optimal, right? Yet, if you presume that this inline <script> comes after a <link> element that loads an external CSS file, you'll get a suboptimal result:

Fig. 5: A WebPageTest network waterfall chart of a web page run on Chrome on a mobile device over a simulated 3G connection. The page contains a single stylesheet and an injected async script. The preload scanner can't discover the script during the render blocking phase, because it's injected on the client.

Let's break down what happened here:

At 0 seconds, the main document is requested.
At 1.4 seconds, the first byte of the navigation request arrives.
At 2.0 seconds, the CSS and image are requested.
Because the parser is blocked loading the stylesheet and the inline JavaScript that injects the async script comes after that stylesheet at 2.6 seconds, the functionality that script provides isn't available as soon as it could be.

This is suboptimal because the request for the script occurs only after the stylesheet has finished downloading. This delays the script from running as soon as possible. This could have the potential to affect a page's Time to Interactive (TTI). By contrast, because the <img> element is discoverable in the server-provided markup, it's discovered by the preload scanner.

So, what happens if you use a regular <script> tag with the async attribute as opposed to injecting the script into the DOM?

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

This is the result:

Fig. 6: A WebPageTest network waterfall chart of a web page run on Chrome on a mobile device over a simulated 3G connection. The page contains a single stylesheet and a single async <script> element. The preload scanner discovers the script during the render blocking phase, and loads it concurrently with the CSS.

There may be some temptation to suggest that these issues could be remedied by using rel=preload. This would certainly work, but it may carry some side effects. After all, why use rel=preload to fix a problem that can be avoided by not injecting a <script> element into the DOM?

Fig. 7: A WebPageTest network waterfall chart of a web page run on Chrome on a mobile device over a simulated 3G connection. The page contains a single stylesheet and an injected async script, but the async script is preloaded to ensure it is discovered sooner.

Preloading "fixes" the problem here, but it introduces a new problem: the async script in the first two demos—despite being loaded in the <head>—are loaded at "Low" priority, whereas the stylesheet is loaded at "Highest" priority. In the last demo where the async script is preloaded, the stylesheet is still loaded at "Highest" priority, but the script's priority has been promoted to "High".

When a resource's priority is raised, the browser allocates more bandwidth to it. This means that—even though the stylesheet has the highest priority—the script's raised priority may cause bandwidth contention. That could be a factor on slow connections, or in cases where resources are quite large.

The answer here is straightforward: if a script is needed during startup, don't defeat the preload scanner by injecting it into the DOM. Experiment as needed with <script> element placement, as well as with attributes such as defer and async.

Lazy loading with JavaScript #

Lazy loading is a great method of conserving data, one that's often applied to images. However, sometimes lazy loading is incorrectly applied to images that are "above the fold", so to speak.

This introduces potential issues with resource discoverability where the preload scanner is concerned, and can unnecessarily delay how long it takes to discover a reference to an image, download it, decode it, and present it. Let's take this image markup for example:

<img data-src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">

The use of a data- prefix is a common pattern in JavaScript-powered lazy loaders. When the image is scrolled into the viewport, the lazy loader strips the data- prefix, meaning that in the preceding example, data-src becomes src. This update prompts the browser to fetch the resource.

This pattern isn't problematic until it's applied to images that are in the viewport during startup. Because the preload scanner doesn't read the data-src attribute in the same way that it would an src (or srcset) attribute, the image reference isn't discovered earlier. Worse, the image is delayed from loading until after the lazy loader JavaScript downloads, compiles, and executes.

Fig. 8: A WebPageTest network waterfall chart of a web page run on Chrome on a mobile device over a simulated 3G connection. The image resource is unnecessarily lazy-loaded, even though it is visible in the viewport during startup. This defeats the preload scanner and causes an unnecessary delay.

Depending on the size of the image—which may depend on the size of the viewport—it may be a candidate element for Largest Contentful Paint (LCP). When the preload scanner cannot speculatively fetch the image resource ahead of time—possibly during the point at which the page's stylesheet(s) block rendering—LCP suffers.

The solution is to change the image markup:

<img src="/sand-wasp.jpg" alt="Sand Wasp" width="384" height="255">

This is the optimal pattern for images that are in the viewport during startup, as the preload scanner will discover and fetch the image resource more quickly.

Fig. 9: A WebPageTest network waterfall chart of a web page run on Chrome on a mobile device over a simulated 3G connection. The preload scanner discovers the image resource before the CSS and JavaScript begin loading, which gives the browser a head start on loading it.

The result in this simplified example is a 100-millisecond improvement in LCP on a slow connection. This may not seem like a huge improvement, but it is when you consider that the solution is a quick markup fix, and that most web pages are more complex than this set of examples. That means that LCP candidates may have to contend for bandwidth with many other resources, so optimizations like this become increasingly important.

CSS background images #

Remember that the browser preload scanner scans markup. It doesn't scan other resource types, such as CSS which may involve fetches for images referenced by the background-image property.

Like HTML, browsers process CSS into its own object model, known as the CSSOM. If external resources are discovered as the CSSOM is constructed, those resources are requested at the time of discovery, and not by the preload scanner.

Let's say your page's LCP candidate is an element with a CSS background-image property. The following is what happens as resources load:

Fig. 10: A WebPageTest network waterfall chart of a web page run on Chrome on a mobile device over a simulated 3G connection. The page's LCP candidate is an element with a CSS background-image property (row 3). The image it requests doesn't begin fetching until the CSS parser finds it.

In this case, the preload scanner isn't so much defeated as it is uninvolved. Even so, if an LCP candidate on the page is from a background-image CSS property, you're going to want to preload that image:

<!-- Make sure this is in the <head> below any
     stylesheets, so as not to block them from loading -->
<link rel="preload" as="image" href="lcp-image.jpg">

That rel=preload hint is small, but it helps the browser discover the image sooner than it otherwise would:

Fig. 11: A WebPageTest network waterfall chart of a web page run on Chrome on a mobile device over a simulated 3G connection. The page's LCP candidate is an element with a CSS background-image property (row 3). The rel=preload hint helps the browser to discover the image around 250 milliseconds sooner than without the hint.

With the rel=preload hint, the LCP candidate is discovered sooner, lowering the LCP time. While that hint helps fix this issue, the better option may be to assess whether or not your image LCP candidate has to be loaded from CSS. With an <img> tag, you'll have more control over loading an image that's appropriate for the viewport while allowing the preload scanner to discover it.

Inlining too many resources #

Inlining is a practice that places a resource inside of the HTML. You can inline stylesheets in <style> elements, scripts in <script> elements, and virtually any other resource using base64 encoding.

Inlining resources can be faster than downloading them because a separate request isn't issued for the resource. It's right in the document, and loads instantly. However, there are significant drawbacks:

If you're not caching your HTML—and you just can't if the HTML response is dynamic—the inlined resources are never cached. This affects performance because the inlined resources aren't reusable.
Even if you can cache HTML, inlined resources aren't shared between documents. This reduces caching efficiency compared to external files that can be cached and reused across an entire origin.
If you inline too much, you delay the preload scanner from discovering resources later in the document, because downloading that extra, inlined, content takes longer.

Take this page as an example. In certain conditions the LCP candidate is the image at the top of the page, and the CSS is in a separate file loaded by a <link> element. The page also uses four web fonts which are requested as separate files from the CSS resource.

Fig. 12: A WebPageTest network waterfall chart of a web page run on Chrome on a mobile device over a simulated 3G connection. The page's LCP candidate is an image loaded from an <img> element, but is discovered by the preload scanner because the CSS and the fonts required for the page load in separate resources, which doesn't delay the preload scanner from doing its job.

Now what happens if the CSS and all the fonts are inlined as base64 resources?

Fig. 13: A WebPageTest network waterfall chart of a web page run on Chrome on a mobile device over a simulated 3G connection. The page's LCP candidate is an image loaded from an <img> element, but the inlining of the CSS and its four font resources in the `` delays the preload scanner from discovering the image until those resources are fully downloaded.

The impact of inlining yields negative consequences for LCP in this example—and for performance in general. The version of the page that doesn't inline anything paints the LCP image in about 3.5 seconds. The page that inlines everything doesn't paint the LCP image until just over 7 seconds.

There's more at play here than just the preload scanner. Inlining fonts is not a great strategy because base64 is an inefficient format for binary resources. Another factor at play is that external font resources aren't downloaded unless they're determined necessary by the CSSOM. When those fonts are inlined as base64, they're downloaded whether they're needed for the current page or not.

Could a preload improve things here? Sure. You could preload the LCP image and reduce LCP time, but bloating your potentially uncacheable HTML with inlined resources has other negative performance consequences. First Contentful Paint (FCP) is also affected by this pattern. In the version of the page where nothing is inlined, FCP is roughly 2.7 seconds. In the version where everything is inlined, FCP is roughly 5.8 seconds.

Be very careful with inlining stuff into HTML, especially base64-encoded resources. In general it is not recommended, except for very small resources. Inline as little as possible, because inlining too much is playing with fire.

Rendering markup with client-side JavaScript #

There's no doubt about it: JavaScript definitely affects page speed. Not only do developers depend on it to provide interactivity, but there has also been a tendency to rely on it to deliver content itself. This leads to a better developer experience in some ways; but benefits for developers don't always translate into benefits for users.

One pattern that can defeat the preload scanner is rendering markup with client-side JavaScript:

Fig. 14: A WebPageTest network waterfall chart of a client-rendered web page run on Chrome on a mobile device over a simulated 3G connection. Because the content is contained in JavaScript and relies on a framework to render, the image resource in the client-rendered markup is hidden from the preload scanner. The equivalent server-rendered experience is depicted in Fig. 9.

When markup payloads are contained in and rendered entirely by JavaScript in the browser, any resources in that markup are effectively invisible to the preload scanner. This delays the discovery of important resources, which certainly affects LCP. In the case of these examples, the request for the LCP image is significantly delayed when compared to the equivalent server-rendered experience that doesn't require JavaScript to appear.

This veers a bit from the focus of this article, but the effects of rendering markup on the client go far beyond defeating the preload scanner. For one, introducing JavaScript to power an experience that doesn't require it introduces unnecessary processing time that can affect Interaction to Next Paint (INP).

Additionally, rendering extremely large amounts of markup on the client is more likely to generate long tasks compared to the same amount of markup being sent by the server. The reason for this—aside from the extra processing that JavaScript involves—is that browsers stream markup from the server and chunk up rendering in such a way that avoids long tasks. Client-rendered markup, on the other hand, is handled as a single, monolithic task, which may affect page responsiveness metrics such as Total Blocking Time (TBT) or First Input Delay (FID) in addition to INP.

The remedy for this scenario depends on the answer to this question: Is there a reason why your page's markup can't be provided by the server as opposed to being rendered on the client? If the answer to this is "no", server-side rendering (SSR) or statically generated markup should be considered where possible, as it will help the preload scanner to discover and opportunistically fetch important resources ahead of time.

If your page does need JavaScript to attach functionality to some parts of your page markup, you can still do so with SSR, either with vanilla JavaScript, or hydration to get the best of both worlds.

Help the preload scanner help you #

The preload scanner is a highly effective browser optimization that helps pages load faster during startup. By avoiding patterns which defeat its ability to discover important resources ahead of time, you're not just making development simpler for yourself, you're creating better user experiences that will deliver better results in many metrics, including some web vitals.

To recap, here's the following things you'll want to take away from this post:

The browser preload scanner is a secondary HTML parser that scans ahead of the primary one if it's blocked to opportunistically discover resources it can fetch sooner.
Resources that aren't present in markup provided by the server on the initial navigation request can't be discovered by the preload scanner. Ways the preload scanner can be defeated may include (but are not limited to):
- Injecting resources into the DOM with JavaScript, be they scripts, images, stylesheets, or anything else that would be better off in the initial markup payload from the server.
- Lazy loading above-the-fold images or iframes using a JavaScript solution.
- Rendering markup on the client that may contain references to document subresources using JavaScript.
The preload scanner only scans HTML. It does not examine the contents of other resources—particularly CSS—that may include references to important assets, including LCP candidates.

If, for whatever reason, you can't avoid a pattern that negatively affects the preload scanner's ability to speed up loading performance, consider the rel=preload resource hint. If you do use rel=preload, test in lab tools to ensure that it's giving you the desired effect. Finally, don't preload too many resources, because when you prioritize everything, nothing will be.

Resources #

Hero image from Unsplash, by Mohammad Rahmani .

Interaction to Next Paint (INP)

2022-05-06T00:00:00Z

Browser support

Chrome 96, Supported 96
Firefox, Not supported
Edge 96, Supported 96
Safari, Not supported

Source

Chrome usage data shows that 90% of a user's time on a page is spent after it loads, Thus, careful measurement of responsiveness throughout the page lifecycle is important. This is what the INP metric assesses.

Good responsiveness means that a page responds quickly to interactions made with it. When a page responds to an interaction, the result is visual feedback, which is presented by the browser in the next frame the browser presents. Visual feedback tells you if, for example, an item you add to an online shopping cart is indeed being added, whether a mobile navigation menu has opened, if a login form's contents are being authenticated by the server, and so forth.

Some interactions will naturally take longer than others, but for especially complex interactions, it's important to quickly present some initial visual feedback as a cue to the user that something is happening. The time until the next paint is the earliest opportunity to do this. Therefore, the intent of INP is not to measure all the eventual effects of the interaction (such as network fetches and UI updates from other asynchronous operations), but the time in which the next paint is being blocked. By delaying visual feedback, you may be giving users the impression that the page is not responding to their actions.

The goal of INP is to ensure the time from when a user initiates an interaction until the next frame is painted is as short as possible, for all or most interactions the user makes.

In the following video, the example on the right gives immediate visual feedback that an accordion is opening. It also demonstrates how poor responsiveness can cause multiple unintended responses to input because the user thinks the experience is broken.

An example of poor versus good responsiveness. At left, long tasks block the accordion from opening. This causes the user to click multiple times, thinking the experience is broken. When the main thread catches up, it processes the delayed inputs, resulting in the accordion opening and closing unexpectedly.

This article explains how INP works, how to measure it, and points to resources for improving it.

What is INP? #

INP is a metric that assesses a page's overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user's visit to a page. The final INP value is the longest interaction observed, ignoring outliers.

A note on how INP is calculated

As stated above, INP is calculated by observing all the interactions made with a page. For most sites the interaction with the worst latency is reported as INP. However, for pages with large numbers of interactions, random hiccups can result in an unusually high interaction on an otherwise responsive site. The more interactions, the more likely this is to happen. To counter this, and give a better measure of the actual responsiveness for those types of pages, we ignore one highest interaction for every 50 interactions. The vast majority of page experiences do not have over 50 interactions so will report the worst interaction. The 75th percentile of all the page views is then reported as usual, which further removes outliers to give a value that the vast majority of users experience or better.

An interaction is a group of event handlers that fire during the same logical user gesture. For example, "tap" interactions on a touchscreen device include multiple events, such as pointerup, pointerdown, and click. An interaction can be driven by JavaScript, CSS, built-in browser controls (such as form elements), or a combination thereof.

An interaction's latency consists of the single longest duration of a group of event handlers that drives the interaction, from the time the user begins the interaction to the moment the next frame is presented with visual feedback.

What is a good INP score? #

Pinning labels such as "good" or "poor" on a responsiveness metric is difficult. On one hand, you want to encourage development practices that prioritize good responsiveness. On the other hand, you must account for the fact that there's considerable variability in the capabilities of devices people use to set achievable development expectations.

To ensure you're delivering user experiences with good responsiveness, a good threshold to measure is the 75th percentile of page loads recorded in the field, segmented across mobile and desktop devices:

An INP below or at 200 milliseconds means that your page has good responsiveness.
An INP above 200 milliseconds and below or at 500 milliseconds means that your page's responsiveness needs improvement.
An INP above 500 milliseconds means that your page has poor responsiveness.

What's in an interaction? #

The life of an interaction. An input delay occurs until event handlers begin running, which may be caused by factors such as long tasks on the main thread. The interaction's event handlers then run, and a delay occurs before the next frame is presented.

The primary driver of interactivity is often JavaScript, though browsers do provide interactivity through controls not powered by JavaScript, such as checkboxes, radio buttons, and controls powered by CSS.

As far as INP goes, only the following interaction types are observed:

Clicking with a mouse.
Tapping on a device with a touchscreen.
Pressing a key on either a physical or onscreen keyboard.

Interactions happen in the main document or in iframes embedded in the document—for example clicking play on an embedded video. End users will not be aware what is in an iframe or not. Therefore, INP within iframes are needed to measure the user experience for the top level page. Note JavaScript Web APIs will not have access to the iframe contents so may not be able to measure INP within an iframe and this will show as a difference between CrUX and RUM.

Interactions may consist of two parts, each with multiple events. For example, a keystroke consists of the keydown, keypress, and keyup events. Tap interactions contain pointerup and pointerdown events. The event with the longest duration within the interaction is chosen as the interaction's latency.

A depiction of an interaction with multiple event handlers. The first part of the interaction receives an input when the user clicks down on a mouse button. However, before they release the mouse button, a frame is presented. When the user releases the mouse button, another series of event handlers must run before the next frame is presented.

INP is calculated when the user leaves the page, resulting in a single value that is representative of the page's overall responsiveness throughout the entire page's lifecycle. A low INP means that a page is reliably responsive to user input.

How is INP different from First Input Delay (FID)? #

Where INP considers all page interactions, First Input Delay (FID) only accounts for the first interaction. It also only measures the first interaction's input delay, not the time it takes to run event handlers, or the delay in presenting the next frame.

Given that FID is also a load responsiveness metric, the rationale behind it is that if the first interaction made with a page in the loading phase has little to no perceptible input delay, the page has made a good first impression.

INP is more than about first impressions. By sampling all interactions, responsiveness can be assessed comprehensively, making INP a more reliable indicator of overall responsiveness than FID.

What if no INP value is reported? #

It's possible that a page can return no INP value. This can happen for a number of reasons:

The page was loaded, but the user never clicked, tapped, or pressed a key on their keyboard.
The page was loaded, but the user interacted with the page using gestures that did not involve clicking, tapping, or using the keyboard. For example, scrolling or hovering over elements does not factor into how INP is calculated.
The page is being accessed by a bot such as a search crawler or headless browser that has not been scripted to interact with the page.

How to measure INP #

INP can be measured both in the field and in the lab through a variety of tools.

In the field #

Ideally, your journey in optimizing INP will start with field data. At its best, field data from Real User Monitoring (RUM) will give you not only a page's INP value, but also contextual data that highlights what specific interaction was responsible for the INP value itself, whether the interaction occurred during or after page load, the type of interaction (click, keypress, or tap), and other valuable information.

If your website qualifies for inclusion in the Chrome User Experience Report (CrUX), you can quickly get field data for INP via CrUX in PageSpeed Insights (and other Core Web Vitals). At a minimum, you can get an origin-level picture of your website's INP, but in some cases, you can also get page-level data as well.

However, while CrUX is useful to tell you that there is a problem at a high level, it often doesn't provide enough detail to help fully understand what the problem is. A RUM solution can help you drill down into more detail as to the pages, users or user interactions which are experiencing slow interactions. Being able to attribute INP to individual interactions avoids guesswork and wasted effort.

In the lab #

Optimally, you'll want to start testing in the lab once you have field data that suggests you have slow interactions. In the absence of field data, however, there are some strategies for reproducing slow interactions in the lab. Such strategies include following common user flows and testing interactions along the way, as well as interacting with the page during load—when the main thread is often busiest—in order to surface slow interactions during that crucial part of the user experience.

How to improve INP #

A collection of guides on optimizing INP is available to guide you through the process of identifying slow interactions in the field and using lab data to drill down and optimize them in a variety of ways.

CHANGELOG #

Occasionally, bugs are discovered in the APIs used to measure metrics, and sometimes in the definitions of the metrics themselves. As a result, changes must sometimes be made, and these changes can show up as improvements or regressions in your internal reports and dashboards.

To help you manage this, all changes to either the implementation or definition of these metrics will be surfaced in this CHANGELOG.

If you have feedback for these metrics, you can provide it in the web-vitals-feedback Google group.

Time to First Byte (TTFB)

2021-10-26T00:00:00Z

Browser support

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

Source

What is TTFB? #

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

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

TTFB is the sum of the following request phases:

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

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

What is a good TTFB score? #

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

Important

How to measure TTFB #

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

Field tools #

Lab tools #

In the network panel of Chrome's DevTools
WebPageTest

Measure TTFB in JavaScript #

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

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

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

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

import {onTTFB} from 'web-vitals';

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

Measuring resource requests #

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

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

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

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

How to improve TTFB #

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

Assessing loading performance in the field with Navigation Timing and Resource Timing

2021-10-08T00:00:00Z

If you've used connection throttling in the network panel in a browser's developer tools (or Lighthouse in Chrome) to assess loading performance, you know how convenient those tools are for performance tuning. You can quickly measure the impact of performance optimizations with a consistent and stable baseline connection speed. The only problem is that this is synthetic testing, which yields lab data, not field data.

Synthetic testing isn't inherently bad, but it's not representative of how fast your website is loading for real users. That requires field data, which you can collect from the Navigation Timing and Resource Timing APIs.

APIs to help you assess loading performance in the field #

Navigation Timing and Resource Timing are two similar APIs with significant overlap that measure two distinct things:

Navigation Timing measures the speed of requests for HTML documents (that is, navigation requests).
Resource Timing measures the speed of requests for document-dependent resources such as CSS, JavaScript, images, and so on.

These APIs expose their data in a performance entry buffer, which can be accessed in the browser with JavaScript. There are multiple ways to query a performance buffer, but a common way is by using performance.getEntriesByType:

// Get Navigation Timing entries:
performance.getEntriesByType('navigation');

// Get Resource Timing entries:
performance.getEntriesByType('resource');

performance.getEntriesByType accepts a string describing the type of entries you want to retrieve from the performance entry buffer. 'navigation' and 'resource' retrieve timings for the Navigation Timing and Resource Timing APIs, respectively.

The amount of information these APIs provide can be overwhelming, but they're your key to measuring loading performance in the field, as you can gather these timings from users as they visit your website.

The life and timings of a network request #

Gathering and analyzing navigation and resource timings is sort of like archeology in that you're reconstructing the fleeting life of a network request after the fact. Sometimes it helps to visualize concepts, and where network requests are concerned, your browser's developer tools can help.

A visualization of a network request in the network panel of Chrome's DevTools

The life of a network request has distinct phases, such as DNS lookup, connection establishment, TLS negotiation, and so on. These timings are represented as a DOMHighResTimestamp. Depending on your browser, the granularity of timings may be down to the microsecond, or be rounded up to milliseconds. Let's examine these phases in detail, and how they relate to Navigation Timing and Resource Timing.

DNS lookup #

When a user goes to a URL, the Domain Name System (DNS) is queried to translate a domain to an IP address. This process may take significant time—time you'll want to measure in the field, even. Navigation Timing and Resource Timing expose two DNS-related timings:

domainLookupStart is when DNS lookup begins.
domainLookupEnd is when DNS lookup ends.

Calculating total DNS lookup time can be done by subtracting the start metric from the end metric:

// Measuring DNS lookup time
const [pageNav] = performance.getEntriesByType('navigation');
const totalLookupTime = pageNav.domainLookupEnd - pageNav.domainLookupStart;

Connection negotiation #

Another contributing factor to loading performance is connection negotiation, which is latency incurred when connecting to a web server. If HTTPS is involved, this process will also include TLS negotiation time. The connection phase consists of three timings:

connectStart is when the browser starts to open a connection to a web server.
secureConnectionStart marks when the client begins TLS negotiation.
connectEnd is when the connection to the web server has been established.

Measuring total connection time is similar to measuring total DNS lookup time: you subtract the start timing from the end timing. However, there's an additional secureConnectionStart property that may be 0 if HTTPS isn't used or if the connection is persistent. If you want to measure TLS negotiation time, you'll need to keep that in mind:

// Quantifying total connection time
const [pageNav] = performance.getEntriesByType('navigation');
const connectionTime = pageNav.connectEnd - pageNav.connectStart;
let tlsTime = 0; // <-- Assume 0 to start with

// Was there TLS negotiation?
if (pageNav.secureConnectionStart > 0) {
  // Awesome! Calculate it!
  tlsTime = pageNav.connectEnd - pageNav.secureConnectionStart;
}

Once DNS lookup and connection negotiation ends, timings related to fetching documents and their dependent resources come into play.

Requests and responses #

Loading performance is affected by two types of factors:

Extrinsic factors: These are things like latency and bandwidth. Beyond choosing a hosting company and a CDN, they're (mostly) out of our control, as users can access the web from anywhere.
Intrinsic factors: These are things like server and client-side architectures, as well as resource size and our ability to optimize for those things, which are within our control.

Both types of factors affect loading performance. Timings related to these factors are vital, as they describe how long resources take to download. Both Navigation Timing and Resource Timing describe loading performance with the following metrics:

fetchStart marks when the browser begins to fetch a resource (Resource Timing) or a document for a navigation request (Navigation Timing). This precedes the actual request, and is the point at which the browser is checking caches (for example, HTTP and Cache instances).
workerStart marks when a request starts being handled within a service worker's fetch event handler. This will be 0 when no service worker is controlling the current page.
requestStart is when the browser makes the request.
responseStart is when the first byte of the response arrives.
responseEnd is when the last byte of the response arrives.

These timings allow you to measure multiple aspects of loading performance, such as cache lookup within a service worker and download time:

// Cache seek plus response time of the current document
const [pageNav] = performance.getEntriesByType('navigation');
const fetchTime = pageNav.responseEnd - pageNav.fetchStart;

// Service worker time plus response time
let workerTime = 0;

if (pageNav.workerStart > 0) {
  workerTime = pageNav.responseEnd - pageNav.workerStart;
}

You can also measure other aspects of request/response latency:

const [pageNav] = performance.getEntriesByType('navigation');

// Request time only (excluding redirects, DNS, and connection/TLS time)
const requestTime = pageNav.responseStart - pageNav.requestStart;

// Response time only (download)
const responseTime = pageNav.responseEnd - pageNav.responseStart;

// Request + response time
const requestResponseTime = pageNav.responseEnd - pageNav.requestStart;

Other measurements you can make #

Navigation Timing and Resource Timing is useful for more than what the examples above outline. Here are some other situations with relevant timings that may be worth exploring:

Page redirects: Redirects are an overlooked source of added latency, especially redirect chains. Latency gets added in a number of ways, such as HTTP-to-HTTPs hops, as well as 302/uncached 301 redirects. The redirectStart, redirectEnd, and redirectCount timings are helpful in assessing redirect latency.
Document unloading: In pages that run code in an unload event handler, the browser must execute that code before it can navigate to the next page. unloadEventStart and unloadEventEnd measure document unloading.
Document processing: Document processing time may not be consequential unless your website sends very large HTML payloads. If this describes your situation, the domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd, and domComplete timings may be of interest.

Acquiring timings in application code #

All of the examples shown so far use performance.getEntriesByType, but there are other ways to query the performance entry buffer, such as performance.getEntriesByName and performance.getEntries. These methods are fine when only light analysis is needed. In other situations, though, they can introduce excessive main thread work by iterating over a large number of entries, or even repeatedly polling the performance buffer to find new entries.

The recommended approach for collecting entries from the performance entry buffer is to use a PerformanceObserver. PerformanceObserver listens for performance entries, and provides them as they're added to the buffer:

// Create the performance observer:
const perfObserver = new PerformanceObserver((observedEntries) => {
  // Get all resource entries collected so far:
  const entries = observedEntries.getEntries();

  // Iterate over entries:
  for (let i = 0; i < entries.length; i++) {
    // Do the work!
  }
});

// Run the observer for Navigation Timing entries:
perfObserver.observe({
  type: 'navigation',
  buffered: true
});

// Run the observer for Resource Timing entries:
perfObserver.observe({
  type: 'resource',
  buffered: true
});

This method of collecting timings may feel awkward when compared to directly accessing the performance entry buffer, but it's preferable to tying up the main thread with work that doesn't serve a critical and user-facing purpose.

Phoning home #

Once you've collected all the timings you need, you can send them to an endpoint for further analysis. Two ways to do this are with either navigator.sendBeacon or a fetch with the keepalive option set. Both methods will send a request to a specified endpoint in a non-blocking way, and the request will be queued in a way that outlives the current page session if need be:

// Caution: If you have lots of performance entries, don't
// do this. This is an example for illustrative purposes.
const data = JSON.stringify(performance.getEntries()));

// The endpoint to transmit the encoded data to
const endpoint = '/analytics';

// Check for fetch keepalive support
if ('keepalive' in Request.prototype) {
  fetch(endpoint, {
    method: 'POST',
    body: data,
    keepalive: true,
    headers: {
      'Content-Type': 'application/json'
    }
  });
} else if ('sendBeacon' in navigator) {
  // Use sendBeacon as a fallback
  navigator.sendBeacon(endpoint, data);
}

In this example, the JSON string will arrive in a POST payload that you can decode and process/store in an application backend as needed.

Wrapping up #

Once you have metrics collected, it's up to you to figure out how to analyze that field data. When analyzing field data, there are a few general rules to follow to ensure you're drawing meaningful conclusions:

Avoid averages, as they're not representative of any one user's experience, and may be skewed by outliers.
Rely on percentiles. In datasets of time-based performance metrics, lower is better. This means that when you prioritize low percentiles, you're only paying attention to the fastest experiences.
Prioritize the long tail of values. When you prioritize experiences at the 75th percentile or higher, you're putting your focus where it belongs: on the slowest experiences.

This guide isn't meant to be an exhaustive resource on Navigation or Resource Timing, but a starting point. Below are some additional resources you may find helpful:

With these APIs and the data they provide, you'll be better equipped to understand how loading performance is experienced by real users, which will give you more confidence in diagnosing and addressing loading performance problems in the field.

Using AVIF to compress images on your site

2021-06-07T00:00:00Z

We frequently write about the bloat on websites from images, and tools like Lighthouse highlight when image loading is having a negative impact on user experience, such as increasing load time, or taking bandwidth away from more important resources. One way to fix this is to use modern compression to reduce the file size of images, and a new option for web developers is the AVIF image format. This blog post talks about recent updates to open source tooling for AVIF, introduces the libaom and libavif encoding libraries, and includes a tutorial for using these libraries to encode AVIF images efficiently.

AVIF is an image format based on the AV1 video codec, and standardized by the Alliance for Open Media. AVIF offers significant compression gains over other image formats like JPEG and WebP. While the exact savings will depend on the content, encoding settings, and quality target, we and others have seen greater than 50% savings vs. JPEG.

1120 by 840 AVIF at 18,769 bytes (click to enlarge)

1120 by 840 JPEG at 20,036 bytes (click to enlarge)

Additionally, AVIF adds codec and container support for new image features such as High Dynamic Range and Wide Color Gamut, film grain synthesis, and progressive decoding.

What's New #

Since landing AVIF support in Chrome M85, AVIF support in the open source ecosystem has improved on a number of fronts.

Libaom #

Libaom is an open source AV1 encoder and decoder maintained by the companies in the Alliance for Open Media, and used in many production services at Google and other member companies. Between the libaom 2.0.0 release—around the same time Chrome added AVIF support—and the recent 3.1.0 release, there have been significant still image encoding optimizations added to the codebase. These include:

Optimizations for multi-threading and tiled encoding.
5x reduction in memory usage.
6.5x reduction in CPU usage, as shown in the chart below.

Using speed=6, cq-level=18, for 8.1 MP images

These changes massively reduce the cost of encoding AVIF— particularly the most frequently loaded, or highest priority images on your site. As hardware-accelerated encoding of AV1 becomes more available on servers and cloud services, the cost to create AVIF images will continue to drop.

Libavif #

Libavif, the reference implementation of AVIF, is an open source AVIF muxer and parser which is used in Chrome for decoding AVIF images. It can also be used with libaom for creating AVIF images from your existing uncompressed images, or transcoding from existing web images (JPEG, PNG, etc).

Libavif recently added support for a wider range of encoder settings, including integration with more advanced libaom encoder settings. Optimizations in the processing pipeline like fast YUV-to-RGB conversion using libyuv and premultiplied alpha support further speed up the decoding process. And finally, support for the all-intra encoding mode newly added in libaom 3.1.0 brings all the libaom improvements mentioned in the above.

Note: libheif is another popular open source AVIF muxer and parser, used in ImageMagick, libvips, and the sharp Node.js module.

Encoding AVIF images with avifenc #

A quick way to experiment with AVIF is Squoosh.app. Squoosh runs a WebAssembly version of libavif, and exposes many of the same features as the command line tools. It's an easy way to compare AVIF to other formats old and new. There's also a CLI version of Squoosh aimed at Node apps.

However, WebAssembly doesn't yet have access to all the performance primitives of CPUs, so if you want to run libavif at its fastest, we recommend the command line encoder, avifenc.

To understand how to encode AVIF images, we will present a tutorial using the same source image used in our example above. To start, you will need:

Chrome version 85 or later
cmake
git
ninja

You will also need to install the development packages for zlib, libpng, and libjpeg. The commands for the Debian and Ubuntu Linux distributions are:

sudo apt-get install zlib1g-dev
sudo apt-get install libpng-dev
sudo apt-get install libjpeg-dev

Building command line encoder avifenc #

1. Get the code #

Check out a release tag of libavif.

git clone -b v0.9.1 https://github.com/AOMediaCodec/libavif.git

2. Change directory to libavif #

cd libavif

There are many different ways you can configure avifenc and libavif to build. You can find more information at libavif. We are going to build avifenc so that it is statically linked to the AV1 encoder and decoder library, libaom.

3. Get and build libaom #

Change to the libavif external dependencies directory.

cd ext

The next command will pull the libaom source code and build libaom statically.

./aom.cmd

Change directory to libavif.

cd ..

4. Build the command line encoding tool, avifenc #

It is a good idea to create a build directory for avifenc.

mkdir build

Change to the build directory.

cd build

Create the build files for avifenc.

cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=0 -DAVIF_CODEC_AOM=1 -DAVIF_LOCAL_AOM=1 -DAVIF_BUILD_APPS=1 ..

Build avifenc.

make

You have successfully built avifenc!

Understanding the avifenc command line parameters #

avifenc uses the command-line structure:

./avifenc [options] input.file output.avif

The basic parameters for avifenc used in this tutorial are:

avifenc
--min 0	Set min quantizer for color to 0
--max 63	Set max quantizer for color to 63
--minalpha 0	Set min quantizer for alpha to 0
--maxalpha 63	Set max quantizer for alpha to 63
-a end-usage=q	Set the rate control mode to Constant Quality (Q) mode
-a cq-level=Q	Set quantize level for both color and alpha to Q
-a color:cq-level=Q	Set quantize level for color to Q
-a alpha:cq-level=Q	Set quantize level for alpha to Q
-a tune=ssim	Tune for SSIM (default is to tune for PSNR)
--jobs J	Use J worker threads (default: 1)
--speed S	Set encoder speed from 0-10 (slowest-fastest. default: 6)

The cq-level option sets the quantize level (0-63) to control the quality for color or alpha.

Create an AVIF image with default settings #

The most basic parameters for avifenc to run, are setting the input and output files.

./avifenc happy_dog.jpg happy_dog.avif

We recommend the following command line to encode an image, say at quantize level 18:

./avifenc --min 0 --max 63 -a end-usage=q -a cq-level=18 -a tune=ssim happy_dog.jpg happy_dog.avif

Avifenc has a lot of options that will affect both quality and speed. If you want to see the options and learn more about them just run ./avifenc

You now have your very own AVIF image!

Speeding up the encoder #

One parameter that may be good to change depending on how many cores you have on your machine is the --jobs parameter. This parameter sets how many threads avifenc will use to create AVIF images. Try running this at the command line.

./avifenc --min 0 --max 63 -a end-usage=q -a cq-level=18 -a tune=ssim --jobs 8 happy_dog.jpg happy_dog.avif

This tells avifenc to use 8 threads when creating the AVIF image, which speeds up AVIF encoding by roughly 5x.

Effects on Largest Contentful Paint (LCP) #

Images are a common candidate for the Largest Contentful Paint (LCP) metric. One common recommendation for improving the loading speed of LCP images is to ensure that an image is optimized. By reducing a resource's transfer size, you're improving its resource load time, which is one of the four key phases to target when dealing with LCP candidates that are images.

Using an image CDN is strongly recommended when optimizing images, as it requires much less effort than setting up image optimization pipelines in your website's build process or manually using encoder binaries to optimize images by hand. However, image CDNs may be cost-prohibitive for some projects. If this is the case for you, consider the following when optimizing with the avifenc encoder:

Familiarize yourself with the options the encoder offers. You may find additional savings while still retaining sufficient image quality by experimenting with some of AVIF's available encoding features.
AVIF provides both lossy and lossless encoding. Depending on an image's contents, one type of encoding may perform better than another. For example, photographs which are normally served as JPEGs will probably do best with lossy encoding, whereas lossless encoding is likely best for images containing simple details or line art normally served as PNG.
If using a bundler with community support for imagemin, consider using the imagemin-avif package to enable your bundler to output AVIF image variants.

By experimenting with AVIF, you may be able to realize an improvement for your website's LCP times in cases where the LCP candidate is an image. For more information on optimizing LCP, read the guide on optimizing LCP.

Conclusion #

Using libaom, libavif and other open source tooling, you can get the best image quality and performance for your website using AVIF. The format is still relatively new, and optimizations and tooling integrations are actively being developed. If you have questions, comments, or feature requests, reach out on the av1-discuss mailing list, AOM GitHub community, and AVIF wiki.

`content-visibility`: the new CSS property that boosts your rendering performance

2020-08-05T00:00:00Z

The content-visibility property, launching in Chromium 85, might be one of the most impactful new CSS properties for improving page load performance. content-visibility enables the user agent to skip an element's rendering work, including layout and painting, until it is needed. Because rendering is skipped, if a large portion of your content is off-screen, leveraging the content-visibility property makes the initial user load much faster. It also allows for faster interactions with the on-screen content. Pretty neat.

In our article demo, applying content-visibility: auto to chunked content areas gives a 7x rendering performance boost on initial load. Read on to learn more.

Browser support #

Browser support

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

Source

content-visibility relies on primitives within the the CSS Containment Spec. While content-visibility is only supported in Chromium 85 for now (and deemed "worth prototyping" for Firefox), the Containment Spec is supported in most modern browsers.

CSS Containment #

The key and overarching goal of CSS containment is to enable rendering performance improvements of web content by providing predictable isolation of a DOM subtree from the rest of the page.

Basically a developer can tell a browser what parts of the page are encapsulated as a set of content, allowing the browsers to reason about the content without needing to consider state outside of the subtree. Knowing which bits of content (subtrees) contain isolated content means the browser can make optimization decisions for page rendering.

There are four types of CSS containment, each a potential value for the contain CSS property, which can be combined in a space-separated list of values:

size: Size containment on an element ensures that the element's box can be laid out without needing to examine its descendants. This means we can potentially skip layout of the descendants if all we need is the size of the element.
layout: Layout containment means that the descendants do not affect the external layout of other boxes on the page. This allows us to potentially skip layout of the descendants if all we want to do is lay out other boxes.
style: Style containment ensures that properties which can have effects on more than just its descendants don't escape the element (e.g. counters). This allows us to potentially skip style computation for the descendants if all we want is to compute styles on other elements.
paint: Paint containment ensures that the descendants of the containing box don't display outside its bounds. Nothing can visibly overflow the element, and if an element is off-screen or otherwise not visible, its descendants will also not be visible. This allows us to potentially skip painting the descendants if the element is offscreen.

Skipping rendering work with `content-visibility` #

It may be hard to figure out which containment values to use, since browser optimizations may only kick in when an appropriate set is specified. You can play around with the values to see what works best, or you can use another CSS property called content-visibility to apply the needed containment automatically. content-visibility ensures that you get the largest performance gains the browser can provide with minimal effort from you as a developer.

The content-visibility property accepts several values, but auto is the one that provides immediate performance improvements. An element that has content-visibility: auto gains layout, style and paint containment. If the element is off-screen (and not otherwise relevant to the user—relevant elements would be the ones that have focus or selection in their subtree), it also gains size containment (and it stops painting and hit-testing its contents).

What does this mean? In short, if the element is off-screen its descendants are not rendered. The browser determines the size of the element without considering any of its contents, and it stops there. Most of the rendering, such as styling and layout of the element's subtree are skipped.

As the element approaches the viewport, the browser no longer adds the size containment and starts painting and hit-testing the element's content. This enables the rendering work to be done just in time to be seen by the user.

A note on accessibility #

One of the features of content-visibility: auto is that the off-screen content remains available in the document object model and therefore, the accessibility tree (unlike with visibility: hidden). This means, that content can be searched for on the page, and navigated to, without waiting for it to load or sacrificing rendering performance.

The flip-side of this, however, is that landmark elements with style features such as display: none or visibility: hidden will also appear in the accessibility tree when off-screen, since the browser will not render these styles until they enter the viewport. To prevent these from being visible in the accessibility tree, potentially causing clutter, be sure to also add aria-hidden="true".

Example: a travel blog #

In this example, we baseline our travel blog on the right, and apply content-visibility: auto to chunked areas on the left. The results show rendering times going from 232ms to 30ms on initial page load.

A travel blog typically contains a set of stories with a few pictures, and some descriptive text. Here is what happens in a typical browser when it navigates to a travel blog:

A part of the page is downloaded from the network, along with any needed resources.
The browser styles and lays out all of the contents of the page, without considering if the content is visible to the user.
The browser goes back to step 1 until all of the page and resources are downloaded.

In step 2, the browser processes all of the contents looking for things that may have changed. It updates the style and layout of any new elements, along with the elements that may have shifted as a result of new updates. This is rendering work. This takes time.

An example of a travel blog. See Demo on Codepen

Now consider what happens if you put content-visibility: auto on each of the individual stories in the blog. The general loop is the same: the browser downloads and renders chunks of the page. However, the difference is in the amount of work that it does in step 2.

With content-visibility, it will style and layout all of the contents that are currently visible to the user (they are on-screen). However, when processing the story that is fully off-screen, the browser will skip the rendering work and only style and layout the element box itself.

The performance of loading this page would be as if it contained full on-screen stories and empty boxes for each of the off-screen stories. This performs much better, with expected reduction of 50% or more from the rendering cost of loading. In our example, we see a boost from a 232ms rendering time to a 30ms rendering time. That's a 7x performance boost.

What is the work that you need to do in order to reap these benefits? First, we chunk the content into sections:

Example of chunking content into sections with the story class applied, to receive content-visibility: auto. See Demo on Codepen

Then, we apply the following style rule to the sections:

.story {
  content-visibility: auto;
  contain-intrinsic-size: 1000px; /* Explained in the next section. */
}

Specifying the natural size of an element with `contain-intrinsic-size` #

In order to realize the potential benefits of content-visibility, the browser needs to apply size containment to ensure that the rendering results of contents do not affect the size of the element in any way. This means that the element will lay out as if it was empty. If the element does not have a height specified in a regular block layout, then it will be of 0 height.

This might not be ideal, since the size of the scrollbar will shift, being reliant on each story having a non-zero height.

Thankfully, CSS provides another property, contain-intrinsic-size, which effectively specifies the natural size of the element if the element is affected by size containment. In our example, we are setting it to 1000px as an estimate for the height and width of the sections.

This means it will lay out as if it had a single child of "intrinsic-size" dimensions, ensuring that your unsized divs still occupy space. contain-intrinsic-size acts as a placeholder size in lieu of rendered content.

In Chromium 98 and onward, there is a new auto keyword for contain-intrinsic-size. When specified, the browser will remember the last-rendered size, if any, and use that instead of the developer-provided placeholder size. For example, if you specified contain-intrinsic-size: auto 300px, the element will start out with a 300px intrinsic sizing in each dimension, but once the element's contents are rendered, it will retain the rendered intrinsic size. Any subsequent rendering size changes will also be remembered. In practice, this means that if you scroll an element with content-visibility: auto applied, and then scroll it back offscreen, it will automatically retain its ideal width and height, and not revert to the placeholder sizing. This feature is especially useful for infinite scrollers, which can now automatically improve sizing estimation over time as the user explores the page.

Hiding content with `content-visibility: hidden` #

What if you want to keep the content unrendered regardless of whether or not it is on-screen, while leveraging the benefits of cached rendering state? Enter: content-visibility: hidden.

The content-visibility: hidden property gives you all of the same benefits of unrendered content and cached rendering state as content-visibility: auto does off-screen. However, unlike with auto, it does not automatically start to render on-screen.

This gives you more control, allowing you to hide an element's contents and later unhide them quickly.

Compare it to other common ways of hiding element's contents:

display: none: hides the element and destroys its rendering state. This means unhiding the element is as expensive as rendering a new element with the same contents.
visibility: hidden: hides the element and keeps its rendering state. This doesn't truly remove the element from the document, as it (and it's subtree) still takes up geometric space on the page and can still be clicked on. It also updates the rendering state any time it is needed even when hidden.

content-visibility: hidden, on the other hand, hides the element while preserving its rendering state, so, if there are any changes that need to happen, they only happen when the element is shown again (i.e. the content-visibility: hidden property is removed).

Some great use cases for content-visibility: hidden are when implementing advanced virtual scrollers, and measuring layout. They're also great for single-page applications (SPA's). Inactive app views can be left in the DOM with content-visibility: hidden applied to prevent their display but maintain their cached state. This makes the view quick to render when it becomes active again.

Effects on Interaction to Next Paint (INP) #

INP is a metric that evaluates a page's ability to be reliably responsive to user input. Responsiveness can be affected by any excessive amount of work that occurs on the main thread, including rendering work.

Whenever you can reduce rendering work on any given page, you're giving the main thread an opportunity to respond to user inputs more quickly. This includes rendering work, and using the content-visiblity CSS property where appropriate can reduce rendering work—especially during startup, when most rendering and layout work is done.

Reducing rendering work has a direct effect on INP. When users attempt to interact with a page that uses the content-visibility property properly to defer layout and rendering of offscreen elements, you're giving the main thread a chance to respond to critical user-visible work. This can improve your page's INP in some situations.

Conclusion #

content-visibility and the CSS Containment Spec mean some exciting performance boosts are coming right to your CSS file. For more information on these properties, check out:

Prefetch resources to speed up future navigations

2019-09-12T00:00:00Z

Research shows that faster load times result in higher conversion rates and better user experiences. If you have insight into how users move through your website and which pages they will likely visit next, you can improve load times of future navigations by downloading the resources for those pages ahead of time.

This guide explains how to achieve that with <link rel=prefetch>, a resource hint that enables you to implement prefetching in an easy and efficient way.

Improve navigations with `rel=prefetch` #

Adding <link rel=prefetch> to a web page tells the browser to download entire pages, or some of the resources (like scripts or CSS files), that the user might need in the future:

<link rel="prefetch" href="/articles/" as="document">

The prefetch hint consumes extra bytes for resources that are not immediately needed, so this technique needs to be applied thoughtfully; only prefetch resources when you are confident that users will need them. Consider not prefetching when users are on slow connections. You can detect that with the Network Information API.

There are different ways to determine which links to prefetch. The simplest one is to prefetch the first link or the first few links on the current page. There are also libraries that use more sophisticated approaches, explained later in this post.

Use cases #

Prefetching subsequent pages #

Prefetch HTML documents when subsequent pages are predictable, so that when a link is clicked, the page is loaded instantly.

For example, in a product listing page, you can prefetch the page for the most popular product in the list. In some cases, the next navigation is even easier to anticipate—on a shopping cart page, the likelihood of a user visiting the checkout page is usually high which makes it a good candidate for prefetching.

While prefetching resources does use additional bandwidth, it can improve most performance metrics. Time to First Byte (TTFB) will often be much lower, as the document request results in a cache hit. Because TTFB will be lower, subsequent time-based metrics will often be lower as well, including Largest Contentful Paint (LCP) and First Contentful Paint (FCP).

Prefetching static assets #

Prefetch static assets, like scripts or stylesheets, when subsequent sections the user might visit can be predicted. This is especially useful when those assets are shared across many pages.

For example, Netflix takes advantage of the time users spend on logged-out pages, to prefetch React, which will be used once users log in. Thanks to this, they reduced Time to Interactive by 30% for future navigations.

The effect of prefetching static assets on performance metrics depends on the resource being prefetched:

Prefetching images can significantly lower LCP times for LCP image elements.
Prefetching stylesheets can improve both FCP and LCP, as the network time to download the stylesheet will be eliminated. Since stylesheets are render blocking, they can reduce LCP when prefetched. In cases where the subsequent page's LCP element is a CSS background image requested via the background-image property, the image will also be prefetched as a dependent resource of the prefetched stylesheet.
Prefetching JavaScript will allow the processing of the prefetched script to occur much sooner than if it were required to be fetched by the network first during navigation. This can have an effect on responsiveness metrics such as First Input Delay (FID) and Interaction to Next Paint (INP). In cases where markup is rendered on the client via JavaScript, LCP can be improved through reduced resource load delays, and client-side rendering of markup containing a page's LCP element can occur sooner.
Prefetching web fonts that are not already used by the current page, can eliminate layout shifts. In cases where font-display: swap; is used, the swap period for the font is eliminated, resulting in faster rendering of the text and eliminating layout shifts. If a future page uses the prefetched font and the page's LCP element is a block of text using a web font, LCP for that element will also be faster.

Prefetching on-demand JavaScript chunks #

Code-splitting your JavaScript bundles allows you to initially load only parts of an app and lazy-load the rest. If you're using this technique, you can apply prefetch to routes or components that are not immediately necessary but will likely be requested soon.

For example, if you have a page that contains a button that opens a dialog box which contains an emoji picker, you can divide it into three JavaScript chunks—home, dialog and picker. Home and dialog could be initially loaded, while the picker could be loaded on-demand. Tools like webpack allow you to instruct the browser to prefetch these on-demand chunks.

How to implement `rel=prefetch` #

The simplest way to implement prefetch is adding a <link> tag to the <head> of the document:

<head>
  ...
  <link rel="prefetch" href="/articles/" as="document">
  ...
</head>

The as attribute helps the browser set the right headers, and determine whether the resource is already in the cache. Example values for this attribute include: document, script, style, font, image, and others.

You can also initiate prefetching via the Link HTTP header:

Link: </css/style.css>; rel=prefetch

A benefit of specifying a prefetch hint in the HTTP Header is that the browser doesn't need to parse the document to find the resource hint, which can offer small improvements in some cases.

Prefetching JavaScript modules with webpack magic comments #

webpack enables you to prefetch scripts for routes or functionality you're reasonably certain users will visit or use soon.

The following code snippet lazy-loads a sorting functionality from the lodash library to sort a group of numbers that will be submitted by a form:

form.addEventListener("submit", e => {
  e.preventDefault()
  import('lodash.sortby')
    .then(module => module.default)
    .then(sortInput())
    .catch(err => { alert(err) });
});

Instead of waiting for the 'submit' event to take place to load this functionality, you can prefetch this resource to increase the chances of having it available in the cache by the time the user submits the form. webpack allows that using the magic comments inside import():

form.addEventListener("submit", e => {
   e.preventDefault()
   import(/* webpackPrefetch: true */ 'lodash.sortby')
         .then(module => module.default)
         .then(sortInput())
         .catch(err => { alert(err) });
});

This tells webpack to inject the <link rel="prefetch"> tag into the HTML document:

<link rel="prefetch" as="script" href="1.bundle.js">

The performance benefits of prefetching on-demand chunks is a bit nuanced, but generally speaking, you could expect to see faster responses to interactions which depend on those on-demand chunks, as they will be immediately available. Depending on the nature of the interaction, this could impart a benefit to a page's INP.

Prefetching in general also factors into overall resource prioritization. When a resource is prefetched, it is done so at the lowest possible priority. Thus, any prefetched resources will not contend for bandwidth for resources needed by the current page.

Smart prefetching with quicklink and Guess.js #

You can also implement smarter prefetching with libraries that use prefetch under the hood:

quicklink uses Intersection Observer API to detect when links come into the viewport and prefetches linked resources during idle time. Bonus: quicklink weighs less than 1 KB!
Guess.js uses analytics reports to build a predictive model that is used to smartly prefetch only what the user is likely to need.

Both quicklink and Guess.js use the Network Information API to avoid prefetching if a user is on a slow network or has Save-Data turned on.

Prefetching under the hood #

Resource hints are not mandatory instructions and it's up to the browser to decide if, and when, they get executed.

You can use prefetch multiple times in the same page. The browser queues up all hints and requests each resource when it's idle. In Chrome, if a prefetch has not finished loading and the user navigates to the destined prefetch resource, the in-flight load is picked up as the navigation by the browser (other browser vendors might implement this differently).

Prefetching takes place at the 'Lowest' priority, so prefetched resources do not compete for bandwidth with the resources required in the current page.

Prefetched files are stored in the HTTP Cache, or the memory cache (depending on whether the resource is cacheable or not), for an amount of time that varies by browsers. For example, in Chrome resources are kept around for five minutes, after which the normal Cache-Control rules for the resource apply.

Conclusion #

Using prefetch can greatly improve load times of future navigations and even make pages appear to load instantly. prefetch is widely supported in modern browsers, which makes it an attractive technique to improve the navigation experience for many users. This technique requires loading extra bytes that might not be used, so be mindful when you use it; only do it when necessary, and ideally, only on fast networks.

Reduce web font size

2019-08-16T00:00:00Z

Typography is fundamental to good design, branding, readability, and accessibility. Web fonts enable all of the above and more: the text is selectable, searchable, zoomable, and high-DPI friendly, providing consistent and sharp text rendering regardless of the screen size and resolution. WebFonts are critical to good design, UX, and performance.

Web font optimization is a critical piece of the overall performance strategy. Each font is an additional resource, and some fonts may block rendering of the text, but just because the page is using WebFonts doesn't mean that it has to render slower. On the contrary, optimized fonts, combined with a judicious strategy for how they are loaded and applied on the page, can help reduce the total page size and improve page rendering times.

Anatomy of a web font #

A web font is a collection of glyphs, and each glyph is a vector shape that describes a letter or symbol. As a result, two simple variables determine the size of a particular font file: the complexity of the vector paths of each glyph and the number of glyphs in a particular font. For example, Open Sans, which is one of the most popular WebFonts, contains 897 glyphs, which include Latin, Greek, and Cyrillic characters.

When picking a font, it's important to consider which character sets are supported. If you need to localize your page content to multiple languages, you should use a font that can deliver a consistent look and experience to your users. For example, Google's Noto font family aims to support all the world's languages. Note, however, that the total size of Noto, with all languages included, results in a 1.1GB+ ZIP download.

In this post you will find out how to reduce the delivered filesize of your web fonts.

Web font formats #

Today there are two recommeded font container formats in use on the web:

WOFF and WOFF 2.0 enjoy wide support and are supported by all modern browsers.

Serve WOFF 2.0 variant to modern browsers.
If absolutely necessary—such as if you still need to support Internet Explorer 11, for example—serve the WOFF as a fallback.
Alternatively, consider not using web fonts for legacy browsers and falling back to the system fonts. This may be more performant for older, more constrained, devices as well.
Since WOFF and WOFF 2.0 cover all bases for modern and legacy browsers still in use, use of EOT and TTF are no longer necessary and can result in longer web font download times.

Web fonts and compression #

Both WOFF and WOFF 2.0 have built-in compression. WOFF 2.0's internal compression uses Brotli, and offers up to 30% better compression than WOFF. For more information, see the WOFF 2.0 evaluation report.

Finally, it's worth noting that some font formats contain additional metadata, such as font hinting and kerning information that may not be necessary on some platforms, which allows for further file-size optimization. For example, Google Fonts maintains 30+ optimized variants for each font and automatically detects and delivers the optimal variant for each platform and browser.

Define a font family with `@font-face` #

The @font-face CSS at-rule allows you to define the location of a particular font resource, its style characteristics, and the Unicode codepoints for which it should be used. A combination of such @font-face declarations can be used to construct a "font family," which the browser will use to evaluate which font resources need to be downloaded and applied to the current page.

Consider a variable font #

Variable fonts can significantly reduce the filesize of your fonts in cases where you need multiple variants of a font. Instead of needing to load the regular and bold styles plus their italic versions, you can load a single file that contains all of the information. However, variable font file sizes will be larger than an individual font variant—though smaller than the combination of many variants. Rather than one large variable font, it may be better to serve critical font variants first, with other variants downloaded later.

Variable fonts are now supported by all modern browsers, find out more in the Introduction to variable fonts on the web.

Select the right format #

Each @font-face declaration provides the name of the font family, which acts as a logical group of multiple declarations, font properties such as style, weight, and stretch, and the src descriptor, which specifies a prioritized list of locations for the font resource.

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 400;
  src: local('Awesome Font'),
       url('/fonts/awesome.woff2') format('woff2'),
       /* Only serve WOFF if necessary. Otherwise,
          WOFF 2.0 is fine by itself. */
       url('/fonts/awesome.woff') format('woff');
}

@font-face {
  font-family: 'Awesome Font';
  font-style: italic;
  font-weight: 400;
  src: local('Awesome Font Italic'),
       url('/fonts/awesome-i.woff2') format('woff2'),
       url('/fonts/awesome-i.woff') format('woff');
}

First, note that the above examples define a single Awesome Font family with two styles (normal and italic), each of which points to a different set of font resources. In turn, each src descriptor contains a prioritized, comma-separated list of resource variants:

The local() directive allows you to reference, load, and use locally installed fonts. If the user already has the font installed on their system, this bypasses the network entirely, and is the fastest.
The url() directive allows you to load external fonts, and are allowed to contain an optional format() hint indicating the format of the font referenced by the provided URL.

When the browser determines that the font is needed, it iterates through the provided resource list in the specified order and tries to load the appropriate resource. For example, following the example above:

The browser performs page layout and determines which font variants are required to render the specified text on the page. Fonts that aren't part of the page's CSS Object Model (CSSOM) are not downloaded by the browser, as they are not required.
For each required font, the browser checks if the font is available locally.
If the font is not available locally, the browser iterates over external definitions:

If a format hint is present, the browser checks if it supports the hint before initiating the download. If the browser doesn't support the hint, the browser advances to the next one.
If no format hint is present, the browser downloads the resource.

The combination of local and external directives with appropriate format hints allows you to specify all of the available font formats and let the browser handle the rest. The browser determines which resources are required and selects the optimal format.

Unicode-range subsetting #

In addition to font properties such as style, weight, and stretch, the @font-face rule allows you to define a set of Unicode codepoints supported by each resource. This enables you to split a large Unicode font into smaller subsets (for example, Latin, Cyrillic, and Greek subsets) and only download the glyphs required to render the text on a particular page.

The unicode-range descriptor allows you to specify a comma-delimited list of range values, each of which can be in one of three different forms:

Single codepoint (for example, U+416)
Interval range (for example, U+400-4ff): indicates the start and end codepoints of a range
Wildcard range (for example, U+4??): ? characters indicate any hexadecimal digit

For example, you can split your Awesome Font family into Latin and Japanese subsets, each of which the browser downloads on an as-needed basis:

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 400;
  src: local('Awesome Font'),
       url('/fonts/awesome-l.woff2') format('woff2');
  /* Latin glyphs */
  unicode-range: U+000-5FF;
}

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 400;
  src: local('Awesome Font'),
       url('/fonts/awesome-jp.woff2') format('woff2');
  /* Japanese glyphs */
  unicode-range: U+3000-9FFF, U+ff??;
}

The use of Unicode range subsets and separate files for each stylistic variant of the font allows you to define a composite font family that is both faster and more efficient to download. Visitors only download the variants and subsets they need, and they aren't forced to download subsets that they may never see or use on the page.

Nearly all browsers support unicode-range. For compatibility with older browsers you may need to fall back to "manual subsetting". In this case you have to fall back to providing a single font resource that contains all the necessary subsets and hide the rest from the browser. For example, if the page is only using Latin characters, then you can strip other glyphs and serve that particular subset as a standalone resource.

Determine which subsets are needed:
- If the browser supports unicode-range subsetting, then it will automatically select the right subset. The page just needs to provide the subset files and specify appropriate unicode-ranges in the @font-face rules.
- If the browser doesn't support unicode-range subsetting, then the page needs to hide all unnecessary subsets; that is, the developer must specify the required subsets.
Generate font subsets:
- Use the open-source pyftsubset tool to subset and optimize your fonts.
- Some font servers—such as Google Font—will automatically subset by default.
- Some font services allow manual subsetting via custom query parameters, which you can use to manually specify the required subset for your page. Consult the documentation from your font provider.

Font selection and synthesis #

Each font family may be composed of multiple stylistic variants (regular, bold, italic) and multiple weights for each style. Each of which, in turn, may contain very different glyph shapes—for example, different spacing, sizing, or a different shape altogether.

The above diagram illustrates a font family that offers three different bold weights:

400 (regular).
700 (bold).
900 (extra bold).

All other in-between variants (indicated in gray) are automatically mapped to the closest variant by the browser.

When a weight is specified for which no face exists, a face with a nearby weight is used. In general, bold weights map to faces with heavier weights and light weights map to faces with lighter weights.
CSS font matching algorithm

Similar logic applies to italic variants. The font designer controls which variants they will produce, and you control which variants you'll use on the page. Because each variant is a separate download, it's a good idea to keep the number of variants small. For example, you can define two bold variants for the Awesome Font family:

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 400;
  src: local('Awesome Font'),
       url('/fonts/awesome-l.woff2') format('woff2');
  /* Latin glyphs */
  unicode-range: U+000-5FF;
}

@font-face {
  font-family: 'Awesome Font';
  font-style: normal;
  font-weight: 700;
  src: local('Awesome Font'),
       url('/fonts/awesome-l-700.woff2') format('woff2');
  /* Latin glyphs */
  unicode-range: U+000-5FF;
}

The above example declares the Awesome Font family that is composed of two resources that cover the same set of Latin glyphs (U+000-5FF) but offer two different "weights": normal (400) and bold (700). However, what happens if one of your CSS rules specifies a different font weight, or sets the font-style property to italic?

If an exact font match isn't available, the browser substitutes the closest match.
If no stylistic match is found (for example, no italic variants were declared in the example above), then the browser synthesizes its own font variant.

The example above illustrates the difference between the actual vs. synthesized font results for Open Sans. All synthesized variants are generated from a single 400-weight font. As you can see, there's a noticeable difference in the results. The details of how to generate the bold and oblique variants are not specified. Therefore, the results vary from browser to browser, and are highly dependent on the font.

Web font size optimization checklist #

Audit and monitor your font use: don't use too many fonts on your pages, and, for each font, minimize the number of used variants. This helps produce a more consistent and a faster experience for your users.
Avoid legacy formats if possible: EOT, TTF, and WOFF formats are larger than WOFF 2.0. EOT and TTF are strictly unnecessary formats, where as WOFF may be acceptable if you need to support Internet Explorer 11. If you're only target modern browsers, using WOFF 2.0 only is the simplest and most performant option.
Subset your font resources: many fonts can be subset, or split into multiple unicode-ranges to deliver just the glyphs that a particular page requires. This reduces the file size and improves the download speed of the resource. However, when defining the subsets, be careful to optimize for font re-use. For example, don't download a different but overlapping set of characters on each page. A good practice is to subset based on script: for example, Latin, and Cyrillic.
Give precedence to local() in your src list: listing local('Font Name') first in your src list ensures that HTTP requests aren't made for fonts that are already installed.
Use Lighthouse to test for text compression.

Effects on Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS) #

Depending on your page's content, text nodes can be considered candidates for Largest Contentful Paint (LCP). It's therefore vital to ensure your web fonts are as small as possible by following the advice in this article so that your users will see the text on your page as soon as they possibly can.

If you're concerned that, despite your optimization efforts, page text might take too long to appear because of large web font resource, the font-display property has a number of settings that can help you to avoid invisible text while a font is downloading. However, using the swap value may cause significant layout shifts that affect your site's Cumulative Layout Shift (CLS). Consider using the optional or fallback values if possible.

If your web fonts are crucial to your branding—and by extension, the user experience— consider preloading your fonts so that the browser has a head start on requesting them. This can reduce both the swap period if you use font-display: swap, or the blocking period if you're not using font-display.

Use lazy loading to improve loading speed

2019-08-16T00:00:00Z

The portion of images and video in the typical payload of a website can be significant. Unfortunately, project stakeholders may be unwilling to cut any media resources from their existing applications. Such impasses are frustrating, especially when all parties involved want to improve site performance, but can't agree on how to get there. Fortunately, lazy loading is a solution that lowers initial page payload and load time, but doesn't skimp on content.

What is lazy loading? #

Lazy loading is a technique that defers loading of non-critical resources at page load time. Instead, these non-critical resources are loaded at the moment of need. Where images are concerned, "non-critical" is often synonymous with "off-screen". If you've used Lighthouse and examined some opportunities for improvement, you may have seen some guidance in this realm in the form of the Defer offscreen images audit:

One of Lighthouse's performance audits is to identify off screen images, which are candidates for lazy loading.

You've probably already seen lazy loading in action, and it goes something like this:

You arrive at a page, and begin to scroll as you read content.
At some point, you scroll a placeholder image into the viewport.
The placeholder image is suddenly replaced by the final image.

An example of image lazy loading can be found on the popular publishing platform Medium, which loads lightweight placeholder images at page load, and replaces them with lazily-loaded images as they're scrolled into the viewport.

An example of image lazy loading in action. A placeholder image is loaded at page load (left), and when scrolled into the viewport, the final image loads at the time of need.

If you're unfamiliar with lazy loading, you might be wondering just how useful the technique is, and what its benefits are. Read on to find out!

Why lazy-load images or video instead of just loading them? #

Because it's possible you're loading stuff the user may never see. This is problematic for a couple reasons:

It wastes data. On unmetered connections, this isn't the worst thing that could happen (although you could be using that precious bandwidth for downloading other resources that are indeed going to be seen by the user). On limited data plans, however, loading stuff the user never sees could effectively be a waste of their money.
It wastes processing time, battery, and other system resources. After a media resource is downloaded, the browser must decode it and render its content in the viewport.

Lazy loading images and video reduces initial page load time, initial page weight, and system resource usage, all of which have positive impacts on performance.

Implementing lazy loading #

There are a number of ways to implement lazy loading. Your choice of solution must take into account the browsers you support, and also what you are trying to lazy-load.

Modern browsers implement browser-level lazy loading, which can be enabled using the loading attribute on images and iframes. To provide compatibility with older browsers or to perform lazy loading on elements without built-in lazy loading you can implement a solution with your own JavaScript. There are also a number of existing libraries to help you to do this. See the posts on this site for full details of all of these approaches:

Also, we have compiled a list of potential issues with lazy loading, and things to watch out for in your implementation.

Conclusion #

Used with care, lazy loading images and video can seriously lower the initial load time and page payloads on your site, including Core Web Vitals. Users won't incur unnecessary network activity—including network contention on slower connections—and processing costs of media resources they may never see, but they can still view those resources if they want.

As far as performance improvement techniques go, lazy loading is reasonably uncontroversial. If you have a lot of inline imagery in your site, it's a perfectly fine way to cut down on unnecessary downloads. Your site's users and project stakeholders will appreciate it!

Lazy loading video

2019-08-16T00:00:00Z

As with image elements, you can also lazy-load video. Videos are commonly loaded with the <video> element (although an alternate method using <img> has emerged with limited implementation). How to lazy-load <video> depends on the use case, though. Let's discuss a couple of scenarios that each require a different solution.

For video that doesn't autoplay #

For videos where playback is initiated by the user (that is, videos that don't autoplay), specifying the preload attribute on the <video> element may be desirable:

<video controls preload="none" poster="one-does-not-simply-placeholder.jpg">
  <source src="one-does-not-simply.webm" type="video/webm">
  <source src="one-does-not-simply.mp4" type="video/mp4">
</video>

The example above uses a preload attribute with a value of none to prevent browsers from preloading any video data. The poster attribute gives the <video> element a placeholder that will occupy the space while the video loads. The reason for this is that default behaviors for loading video can vary from browser to browser:

In Chrome, the default for preload used to be auto, but as of Chrome 64, it now defaults to metadata. Even so, on the desktop version of Chrome, a portion of the video may be preloaded using the Content-Range header. Other Chromium-based browsers and Firefox behave similarly.
As with Chrome on desktop, 11.0 desktop versions of Safari will preload a range of the video. From version 11.2, only the video metadata is preloaded. In Safari on iOS, videos are never preloaded.
When Data Saver mode is enabled, preload defaults to none.

Because browser default behaviors with regard to preload are not set in stone, being explicit is probably your best bet. In this cases where the user initiates playback, using preload="none" is the easiest way to defer loading of video on all platforms. The preload attribute isn't the only way to defer the loading of video content. Fast Playback with Video Preload may give you some ideas and insight into working with video playback in JavaScript.

Unfortunately, it doesn't prove useful when you want to use video in place of animated GIFs, which is covered next.

For video acting as an animated GIF replacement #

While animated GIFs enjoy wide use, they're subpar to video equivalents in a number of ways, particularly in file size. Animated GIFs can stretch into the range of several megabytes of data. Videos of similar visual quality tend to be far smaller.

Using the <video> element as a replacement for animated GIF is not as straightforward as the <img> element. Animated GIFs have three characteristics:

They play automatically when loaded.
They loop continuously (though that's not always the case).
They don't have an audio track.

Achieving this with the <video> element looks something like this:

<video autoplay muted loop playsinline>
  <source src="one-does-not-simply.webm" type="video/webm">
  <source src="one-does-not-simply.mp4" type="video/mp4">
</video>

The autoplay, muted, and loop attributes are self-explanatory. playsinline is necessary for autoplaying to occur in iOS. Now you have a serviceable video-as-GIF replacement that works across platforms. But how to go about lazy loading it? To start, modify your <video> markup accordingly:

<video class="lazy" autoplay muted loop playsinline width="610" height="254" poster="one-does-not-simply.jpg">
  <source data-src="one-does-not-simply.webm" type="video/webm">
  <source data-src="one-does-not-simply.mp4" type="video/mp4">
</video>

You'll notice the addition of the poster attribute, which lets you specify a placeholder to occupy the <video> element's space until the video is lazy-loaded. As with the <img> lazy-loading examples, stash the video URL in the data-src attribute on each <source> element. From there, use JavaScript code similar to the Intersection Observer-based image lazy loading examples:

document.addEventListener("DOMContentLoaded", function() {
  var lazyVideos = [].slice.call(document.querySelectorAll("video.lazy"));

  if ("IntersectionObserver" in window) {
    var lazyVideoObserver = new IntersectionObserver(function(entries, observer) {
      entries.forEach(function(video) {
        if (video.isIntersecting) {
          for (var source in video.target.children) {
            var videoSource = video.target.children[source];
            if (typeof videoSource.tagName === "string" && videoSource.tagName === "SOURCE") {
              videoSource.src = videoSource.dataset.src;
            }
          }

          video.target.load();
          video.target.classList.remove("lazy");
          lazyVideoObserver.unobserve(video.target);
        }
      });
    });

    lazyVideos.forEach(function(lazyVideo) {
      lazyVideoObserver.observe(lazyVideo);
    });
  }
});

When you lazy-load a <video> element, you need to iterate through all of the child <source> elements and flip their data-src attributes to src attributes. Once you've done that, you need to trigger loading of the video by calling the element's load method, after which the media will begin playing automatically per the autoplay attribute.

Using this method, you have a video solution that emulates animated GIF behavior, but doesn't incur the same intensive data usage as animated GIFs do, and you can lazy-load that content.

Lazy loading libraries #

The following libraries can help you to lazy-load video:

vanilla-lazyload and lozad.js are super lightweight options that use Intersection Observer only. As such, they are highly performant, but will need to be polyfilled before you can use them on older browsers.
yall.js is a library that uses Intersection Observer and falls back to event handlers. It can also lazy load video poster images using a data-poster attribute.
If you need a React-specific lazy loading library, you might consider react-lazyload. While it doesn't use Intersection Observer, it does provide a familiar method of lazy loading images for those accustomed to developing applications with React.

Each of these lazy loading libraries is well documented, with plenty of markup patterns for your various lazy loading endeavors.

Lazy loading images

2019-08-16T00:00:00Z

Images can appear on a webpage due to being inline in the HTML as <img> elements or as CSS background images. In this post you will find out how to lazy-load both types of image.

Inline images #

The most common lazy loading candidates are images as used in <img> elements. With inline images we have three options for lazy loading, which may be used in combination for the best compatibility across browsers:

Using browser-level lazy loading #

Chrome and Firefox both support lazy loading with the loading attribute. This attribute can be added to <img> elements, and also to <iframe> elements. A value of lazy tells the browser to load the image immediately if it is in the viewport, and to fetch other images when the user scrolls near them.

See the loading field of MDN's browser compatibility table for details of browser support. If the browser does not support lazy loading then the attribute will be ignored and images will load immediately, as normal.

For most websites, adding this attribute to inline images will be a performance boost and save users loading images that they may not ever scroll to. If you have large numbers of images and want to be sure that users of browsers without support for lazy loading benefit you will need to combine this with one of the methods explained next.

To learn more, check out Browser-level lazy loading for the web.

Using Intersection Observer #

To polyfill lazy loading of <img> elements, we use JavaScript to check if they're in the viewport. If they are, their src (and sometimes srcset) attributes are populated with URLs to the desired image content.

If you've written lazy loading code before, you may have accomplished your task by using event handlers such as scroll or resize. While this approach is the most compatible across browsers, modern browsers offer a more performant and efficient way to do the work of checking element visibility via the Intersection Observer API.

Intersection Observer is easier to use and read than code relying on various event handlers, because you only need to register an observer to watch elements rather than writing tedious element visibility detection code. All that's left to do is to decide what to do when an element is visible. Let's assume this basic markup pattern for your lazily loaded <img> elements:

<img class="lazy" src="placeholder-image.jpg" data-src="image-to-lazy-load-1x.jpg" data-srcset="image-to-lazy-load-2x.jpg 2x, image-to-lazy-load-1x.jpg 1x" alt="I'm an image!">

There are three relevant pieces of this markup that you should focus on:

The class attribute, which is what you'll select the element with in JavaScript.
The src attribute, which references a placeholder image that will appear when the page first loads.
The data-src and data-srcset attributes, which are placeholder attributes containing the URL for the image you'll load once the element is in the viewport.

Now let's see how to use Intersection Observer in JavaScript to lazy-load images using this markup pattern:

document.addEventListener("DOMContentLoaded", function() {
  var lazyImages = [].slice.call(document.querySelectorAll("img.lazy"));

  if ("IntersectionObserver" in window) {
    let lazyImageObserver = new IntersectionObserver(function(entries, observer) {
      entries.forEach(function(entry) {
        if (entry.isIntersecting) {
          let lazyImage = entry.target;
          lazyImage.src = lazyImage.dataset.src;
          lazyImage.srcset = lazyImage.dataset.srcset;
          lazyImage.classList.remove("lazy");
          lazyImageObserver.unobserve(lazyImage);
        }
      });
    });

    lazyImages.forEach(function(lazyImage) {
      lazyImageObserver.observe(lazyImage);
    });
  } else {
    // Possibly fall back to event handlers here
  }
});

On the document's DOMContentLoaded event, this script queries the DOM for all <img> elements with a class of lazy. If Intersection Observer is available, create a new observer that runs a callback when img.lazy elements enter the viewport.

Intersection Observer is available in all modern browsers. Therefore using it as a polyfill for loading="lazy" will ensure that lazy loading is available for most visitors.

Images in CSS #

While <img> tags are the most common way of using images on web pages, images can also be invoked via the CSS background-image property (and other properties). Browser-level lazy loading does not apply to CSS background images, so you need to consider other methods if you have background images to lazy-load.

Unlike <img> elements which load regardless of their visibility, image loading behavior in CSS is done with more speculation. When the document and CSS object models and render tree are built, the browser examines how CSS is applied to a document before requesting external resources. If the browser has determined a CSS rule involving an external resource doesn't apply to the document as it's currently constructed, the browser doesn't request it.

This speculative behavior can be used to defer the loading of images in CSS by using JavaScript to determine when an element is within the viewport, and subsequently applying a class to that element that applies styling invoking a background image. This causes the image to be downloaded at the time of need instead of at initial load. For example, let's take an element that contains a large hero background image:

<div class="lazy-background">
  <h1>Here's a hero heading to get your attention!</h1>
  <p>Here's hero copy to convince you to buy a thing!</p>
  <a href="/buy-a-thing">Buy a thing!</a>
</div>

The div.lazy-background element would normally contain the hero background image invoked by some CSS. In this lazy loading example, however, you can isolate the div.lazy-background element's background-image property via a visible class added to the element when it's in the viewport:

.lazy-background {
  background-image: url("hero-placeholder.jpg"); /* Placeholder image */
}

.lazy-background.visible {
  background-image: url("hero.jpg"); /* The final image */
}

From here, use JavaScript to check if the element is in the viewport (with Intersection Observer!), and add the visible class to the div.lazy-background element at that time, which loads the image:

document.addEventListener("DOMContentLoaded", function() {
  var lazyBackgrounds = [].slice.call(document.querySelectorAll(".lazy-background"));

  if ("IntersectionObserver" in window) {
    let lazyBackgroundObserver = new IntersectionObserver(function(entries, observer) {
      entries.forEach(function(entry) {
        if (entry.isIntersecting) {
          entry.target.classList.add("visible");
          lazyBackgroundObserver.unobserve(entry.target);
        }
      });
    });

    lazyBackgrounds.forEach(function(lazyBackground) {
      lazyBackgroundObserver.observe(lazyBackground);
    });
  }
});

Effects on Largest Contentful Paint (LCP) #

Lazy loading is a great optimization that reduces both overall data usage and network contention during startup by deferring the loading of images to when they're actually needed. This can improve startup time, and reduce processing on the main thread by reducing time needed for image decodes.

However, lazy loading is a technique that can affect your website's Largest Contentful Paint LCP in a negative way if you're too eager with the technique. One thing you will want to avoid is lazy loading images that are in the viewport during startup.

When using JavaScript-based lazy loaders, you will want to avoid lazy loading in-viewport images because these solutions often use a data-src or data-srcset attribute as a placeholder for src and srcset attributes. The problem here is that the loading of these images will be delayed because the browser preload scanner can't find them during startup.

Even using browser-level lazy loading to lazy load an in-viewport image can backfire. When loading="lazy" is applied to an in-viewport image, that image will be delayed until the browser knows for sure it's in the viewport, which can affect a page's LCP.

Never lazy load images that are visible in the viewport during startup. It's a pattern that will affect your site's LCP negatively, and therefore the user experience. If you need an image at startup, load it at startup as quickly as possible by not lazy loading it!

Lazy loading libraries #

You should use browser-level lazy loading whenever possible, but if you find yourself in a situation where that isn't an option—such as a significant group of users still reliant on older browsers—the following libraries can be used to lazy-load images:

lazysizes is a full-featured lazy loading library that lazy-loads images and iframes. The pattern it uses is quite similar to the code examples shown here in that it automatically binds to a lazyload class on <img> elements, and requires you to specify image URLs in data-src and/or data-srcset attributes, the contents of which are swapped into src and/or srcset attributes, respectively. It uses Intersection Observer (which you can polyfill), and can be extended with a number of plugins to do things like lazy-load video. Find out more about using lazysizes.
vanilla-lazyload is a lightweight option for lazy loading images, background images, videos, iframes, and scripts. It leverages Intersection Observer, supports responsive images, and enables browser-level lazy loading.
lozad.js is a another lightweight option that uses Intersection Observer only. As such, it's highly performant, but will need to be polyfilled before you can use it on older browsers.
If you need a React-specific lazy loading library, consider react-lazyload. While it doesn't use Intersection Observer, it does provide a familiar method of lazy loading images for those accustomed to developing applications with React.

Lazy loading best practices

2019-08-16T00:00:00Z

While lazy loading images and video have positive and measurable performance benefits, it's not a task to be taken lightly. If you get it wrong, there could be unintended consequences. As such, it's important to keep the following concerns in mind.

Mind the fold #

It may be tempting to lazy-load every single media resource on the page with JavaScript, but you need to resist this temptation. Anything resting above the fold shouldn't be lazy-loaded. Such resources should be considered critical assets, and thus should be loaded normally.

Lazy loading delays the loading of resources until after the DOM is interactive when scripts have finished loading and begin execution. For images below the fold, this is fine, but critical resources above the fold should be loaded with the standard <img> element so they're displayed as soon as possible.

Of course, where the fold lies is not so clear these days when websites are viewed on so many screens of varying sizes. What lies above the fold on a laptop may well lie below it on mobile devices. There's no bulletproof advice for addressing this optimally in every situation. You'll need to conduct an inventory of your page's critical assets, and load those images in typical fashion.

Additionally, you may not want to be so strict about the fold line as the threshold for triggering lazy loading. It may be more ideal for your purposes to establish a buffer zone some distance below the fold so that images begin loading well before the user scrolls them into the viewport. For example, the Intersection Observer API allows you to specify a rootMargin property in an options object when you create a new IntersectionObserver instance. This effectively gives elements a buffer, which triggers lazy loading behavior before the element is in the viewport:

let lazyImageObserver = new IntersectionObserver(function(entries, observer) {
  // lazy-loading image code goes here
}, {
  rootMargin: "0px 0px 256px 0px"
});

If the value for rootMargin looks similar to values you'd specify for a CSS margin property, that's because it is! In this case, the bottom margin of the observed element (the browser viewport by default, but this can be changed to a specific element using the root property) is broadened by 256 pixels. That means the callback function will execute when an image element is within 256 pixels of the viewport and the image will begin to load before the user actually sees it.

To achieve this same effect in browsers that don't support Intersection Observe, use scroll event handling code and adjust your getBoundingClientRect check to include a buffer.

Layout shifting and placeholders #

Lazy loading media can cause shifting in the layout if placeholders aren't used. These changes can be disorienting for users and trigger expensive DOM layout operations that consume system resources and contribute to jank. At a minimum, consider using a solid color placeholder occupying the same dimensions as the target image, or techniques such as LQIP or SQIP that hint at the content of a media item before it loads.

For <img> tags, src should initially point to a placeholder until that attribute is updated with the final image URL. Use the poster attribute in a <video> element to point to a placeholder image. Additionally, use width and height attributes on both <img> and <video> tags. This ensures that transitioning from placeholders to final images won't change the rendered size of the element as media loads.

Image decoding delays #

Loading large images in JavaScript and dropping them into the DOM can tie up the main thread, causing the user interface to be unresponsive for a short period of time while decoding occurs. Asynchronously decoding images using the decode method prior to inserting them into the DOM can cut down on this sort of jank, but beware: It's not available everywhere yet, and it adds complexity to lazy loading logic. If you want to use it, you'll need to check for it. Below shows how you might use Image.decode() with a fallback:

var newImage = new Image();
newImage.src = "my-awesome-image.jpg";

if ("decode" in newImage) {
  // Fancy decoding logic
  newImage.decode().then(function() {
    imageContainer.appendChild(newImage);
  });
} else {
  // Regular image load
  imageContainer.appendChild(newImage);
}

Check out this CodePen link to see code similar to this example in action. If most of your images are fairly small, this may not do much for you, but it can certainly help cut down on jank when lazy loading large images and inserting them into the DOM.

When stuff doesn't load #

Sometimes media resources fail to load for one reason or another and errors occur. When might this happen? It depends, but here's one hypothetical scenario for you: You have an HTML caching policy for a short period of time (e.g., five minutes), and the user visits the site or a user has a left a stale tab open for a long period of time (e.g., several hours) and comes back to read your content. At some point in this process, a redeployment occurs. During this deployment, an image resource's name changes due to hash-based versioning, or is removed altogether. By the time the user lazy-loads the image, the resource is unavailable, and thus fails.

While these are relatively rare occurrences, it may behoove you to have a backup plan if lazy loading fails. For images, such a solution may look something like this:

var newImage = new Image();
newImage.src = "my-awesome-image.jpg";

newImage.onerror = function(){
  // Decide what to do on error
};
newImage.onload = function(){
  // Load the image
};

What you decide to do in the event of an error depends on your application. For example, you could replace the image placeholder area with a button that allows the user to attempt to load the image again, or simply display an error message in the image placeholder area.

Other scenarios could arise as well. Whatever you do, it's never a bad idea to signal to the user when an error has occurred, and possibly give them an action to take if something goes awry.

JavaScript availability #

It shouldn't be assumed that JavaScript is always available. If you're going to lazy-load images, consider offering <noscript> markup that will show images in case JavaScript is unavailable. The simplest possible fallback example involves using <noscript> elements to serve images if JavaScript is turned off:

If JavaScript is turned off, users will see both the placeholder image and the image contained with the <noscript> elements. To get around this, place a class of no-js on the <html> tag like so:

<html class="no-js">

Then place one line of inline script in the <head> before any style sheets are requested via <link> tags that removes the no-js class from the <html> element if JavaScript is on:

<script>document.documentElement.classList.remove("no-js");</script>

Finally, use some CSS to hide elements with a class of lazy when JavaScript is unavailable:

.no-js .lazy {
  display: none;
}

This doesn't prevent placeholder images from loading, but the outcome is more desirable. People with JavaScript turned off get something more than placeholder images, which is better than placeholders and no meaningful image content at all.

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.

Establish network connections early to improve perceived page speed

2019-07-30T00:00:00Z

Before the browser can request a resource from a server, it must establish a connection. Establishing a secure connection involves three steps:

Look up the domain name and resolve it to an IP address.
Set up a connection to the server.
Encrypt the connection for security.

In each of these steps the browser sends a piece of data to a server, and the server sends back a response. That journey, from origin to destination and back, is called a round trip.

Depending on network conditions, a single round trip might take a significant amount of time. The connection setup process might involve up to three round trips—and more in unoptimized cases.

Taking care of all that ahead of time makes applications feel much faster. This post explains how to achieve that with two resource hints: <link rel=preconnect> and <link rel=dns-prefetch>.

Establish early connections with `rel=preconnect` #

Modern browsers try their best to anticipate what connections a page will need, but they cannot reliably predict them all. The good news is that you can give them a (resource 😉) hint.

Adding rel=preconnect to a <link> informs the browser that your page intends to establish a connection to another domain, and that you'd like the process to start as soon as possible. Resources will load more quickly because the setup process has already been completed by the time the browser requests them.

Resource hints get their name because they are not mandatory instructions. They provide the information about what you'd like to happen, but it's ultimately up to the browser to decide whether to execute them. Setting up and keeping a connection open is a lot of work, so the browser might choose to ignore resource hints or execute them partially depending on the situation.

Informing the browser of your intention is as simple as adding a <link> tag to your page:

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

You can speed up the load time by 100–500 ms by establishing early connections to important third-party origins. These numbers might seem small, but they make a difference in how users perceive web page performance.

Use-cases for `rel=preconnect` #

Knowing where from, but not what you're fetching #

Due to versioned dependencies, you sometimes end up in a situation where you know you'll be requesting a resource from a particular CDN, but not the exact path for it.

An example of a versioned URL.

The other common case is loading images from an image CDN, where the exact path for an image depends on media queries or runtime feature checks on the user's browser.

An example of an image CDN URL.

In these situations, if the resource you'll be fetching is important, you want to save as much time as possible by pre-connecting to the server. The browser won't download the file until your page requests it, but at least it can handle the connection aspects ahead of time, saving the user from waiting for several round trips.

Streaming media #

Another example where you may want to save some time in the connection phase, but not necessarily start retrieving content right away, is when streaming media from a different origin.

Depending on how your page handles the streamed content, you may want to wait until your scripts have loaded and are ready to process the stream. Pre-connecting helps you cut the waiting time to a single round trip once you're ready to start fetching.

How to implement `rel=preconnect` #

One way of initiating a preconnect is adding a <link> tag to the <head> of the document.

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

Preconnecting is only effective for domains other than the origin domain, so you shouldn't use it for your site.

You can also initiate a preconnect via the Link HTTP header:

Link: <https://example.com/>; rel=preconnect

Some types of resources, such as fonts, are loaded in anonymous mode. For those you must set the crossorigin attribute with the preconnect hint:

<link rel="preconnect" href="https://example.com/ComicSans" crossorigin>

If you omit the crossorigin attribute, the browser only performs the DNS lookup.

Resolve domain name early with `rel=dns-prefetch` #

You remember sites by their names, but servers remember them by IP addresses. This is why the domain name system (DNS) exists. The browser uses DNS to convert the site name to an IP address. This process—domain name resolution— is the first step in establishing a connection.

If a page needs to make connections to many third-party domains, preconnecting all of them is counterproductive. The preconnect hint is best used for only the most critical connections. For all the rest, use <link rel=dns-prefetch> to save time on the first step, the DNS lookup, which usually takes around 20–120 ms.

DNS resolution is initiated similarly to preconnect: by adding a <link> tag to the <head> of the document.

<link rel="dns-prefetch" href="http://example.com">

Browser support for dns-prefetch is slightly different from preconnect support, so dns-prefetch can serve as a fallback for browsers that don't support preconnect.

<link rel="preconnect" href="http://example.com">
<link rel="dns-prefetch" href="http://example.com">

To safely implement the fallback technique, use separate link tags.

Don't

<link rel="preconnect dns-prefetch" href="http://example.com">

Implementing dns-prefetch fallback in the same <link> tag causes a bug in Safari where preconnect gets cancelled.

Effect on Largest Contentful Paint (LCP) #

Using dns-prefetch and preconnect allows sites to reduce the amount of time it takes to connect to another origin. The ultimate aim is that the time to load a resource from another origin should be minimized as much as possible.

Where Largest Contentful Paint (LCP) is concerned, it is better that resources are immediately discoverable, since LCP candidates are crucial parts of the user experience. A fetchpriority value of "high" on LCP resources can further improve this by signaling the importance of this asset to the browser so it can fetch it early.

Where it is not possible to make LCP assets immediately discoverable, a preload link—also with the fetchpriority value of "high"—still allows the browser to load the resource as soon as possible.

If neither of these options are available—because the exact resource will not be known until later in the page load—you can use preconnect on cross-origin resources to reduce the impact of the late discovery of the resource as much as possible.

Additionally, preconnect is less expensive than preload in terms of bandwidth usage, but still not without its risks. As is the case with excessive preload hints, excessive preconnect hints still consume bandwidth where TLS certificates are concerned. Be careful not to preconnect to too many origins, as this may cause bandwidth contention.

Conclusion #

These two resource hints are helpful for improving page speed when you know you'll download something from a third-party domain soon, but you don't know the exact URL for the resource. Examples include CDNs that distribute JavaScript libraries, images or fonts. Be mindful of constraints, use preconnect only for the most important resources, rely on dns-prefetch for the rest, and always measure the impact in the real-world.

Why does speed matter?

2019-05-01T00:00:00Z

Consumers increasingly rely on mobile to access digital content and services, and if you look at your site analytics, you'll probably see this story playing out in your own data. Consumers are also more demanding than they've ever been, and when they weigh the experience on your site, they aren't just comparing you with your competitors, they're rating you against the best-in-class services they use every day.

This post rounds up some of the research that has been done on the relationship between performance and business success.

Performance is about retaining users #

Performance has directly impacted the company's bottom line.
Pinterest

Performance plays a major role in the success of any online venture. High-performing sites engage and retain users better than low-performing ones.

Pinterest reduced perceived wait times by 40% and this increased search engine traffic and sign-ups by 15%.

COOK reduced average page load time by 850 milliseconds which increased conversions by 7%, decreased bounce rates by 7%, and increased pages per session by 10%.

Studies have also shown the negative impact poor performance can have on business goals. For example, the BBC found they lost an additional 10% of users for every additional second their site took to load.

Performance is about improving conversions #

Retaining users is crucial to improving conversions. Slow sites have a negative impact on revenue, and fast sites are shown to increase conversion rates.

For Mobify, every 100ms decrease in homepage load speed worked out to a 1.11% increase in session-based conversion, yielding an average annual revenue increase of nearly $380,000. Additionally, a 100ms decrease in checkout page load speed amounted to a 1.55% increase in session-based conversion, which in turn yielded an average annual revenue increase of nearly $530,000.

When AutoAnything reduced page load time by half, they saw a boost of 12% to 13% in sales.

Retailer Furniture Village audited their site speed and developed a plan to address the problems they found, leading to a 20% reduction in page load time and a 10% increase in conversion rate.

Performance is about user experience #

When it comes to user experience, speed matters. A consumer study shows that the stress response to delays in mobile speed are similar to that of watching a horror movie or solving a mathematical problem, and greater than waiting in a checkout line at a retail store.

As a site begins to load, there's a period of time where users wait for content to appear. Until this happens, there's no user experience to speak of. This lack of an experience is fleeting on fast connections. On slower connections, however, users are forced to wait. Users may experience more problems as page resources slowly trickle in.

A comparison of page load on a very slow connection (top) versus a faster connection (bottom).

Performance is a foundational aspect of good user experiences. When sites ship a lot of code, browsers must use megabytes of the user's data plan to download it. Mobile devices have limited CPU power and memory. They often get overwhelmed with what we might consider a small amount of unoptimized code. This creates poor performance which leads to unresponsiveness. Knowing what we know about human behavior, users will only tolerate low performing applications for so long before abandoning them.

Performance is about people #

Poorly performing sites and applications can also pose real costs for the people who use them.

As mobile users continue to make up a larger portion of internet users worldwide, it's important to bear in mind that many of these users access the web through mobile LTE, 4G, 3G, and even 2G networks. As Ben Schwarz of Calibre points out in this study of real world performance, the cost of prepaid data plans is decreasing, which in turn is making access to the internet more affordable in places where it once wasn't. Mobile devices and internet access are no longer luxuries. They are common tools necessary to navigate and function in an increasingly interconnected world.

Total page size has been steadily increasing since at least 2011, and the trend appears to be continuing. As the typical page sends more data, users must replenish their metered data plans more often, which costs them money.

In addition to saving your users money, fast and lightweight user experiences can also prove crucial for users in crisis. Public resources such as hospitals, clinics, and crisis centers have online resources that give users important and specific information that they need during a crisis. While design is pivotal in presenting important information efficiently in stressful moments, the importance of delivering this information fast can't be understated. It's part of our job.

Get started with improving your website speed #

Read up on the Core Web Vitals to learn about the metrics that Google believes all websites should focus on.

Today, we’re building on this work and providing an early look at an upcoming Search ranking change that incorporates these page experience metrics. We will introduce a new signal that combines Core Web Vitals with our existing signals for page experience to provide a holistic picture of the quality of a user’s experience on a web page.
Evaluating page experience for a better web , Official Google Webmaster Central Blog

Then check out Fast load times for lots of tips and tricks related to getting fast and staying fast.

Adapting to Users with Client Hints

2018-11-22T00:00:00Z

Developing sites that are fast everywhere can be a tricky prospect. The plethora of device capabilities—and the quality of the networks they connect to—can make it seem like an insurmountable task. While we can take advantage of browser features to improve loading performance, how do we know what the user’s device is capable of, or the quality of their network connection? The solution is client hints!

Client hints are a set of opt-in HTTP request headers that give us insight into these aspects of the user’s device and the network they’re connected to. By tapping into this information server side, we can change how we deliver content based on device and/or network conditions. This can help us to create more inclusive user experiences.

It’s All About Content Negotiation #

Client hints are another method of content negotiation, which means changing content responses based on browser request headers.

One example of content negotiation involves the Accept request header. It describes what content types the browser understands, which the server can use to negotiate the response. For image requests, the content of Chrome’s Accept header is:

Accept: image/webp,image/apng,image/*,*/*;q=0.8

While all browsers support image formats like JPEG, PNG, and GIF, Accept tells in this case that the browser also supports WebP and APNG. Using this information, we can negotiate the best image types for each browser:

<?php
// Check Accept for an "image/webp" substring.
$webp = stristr($_SERVER["HTTP_ACCEPT"], "image/webp") !== false ? true : false;

// Set the image URL based on the browser's WebP support status.
$imageFile = $webp ? "whats-up.webp" : "whats-up.jpg";
?>
<img src="<?php echo($imageFile); ?>" alt="I'm an image!">

Like Accept, client hints are another avenue for negotiating content, but in the context of device capabilities and network conditions. With client hints, we can make server side performance decisions based on a user's individual experience, such as deciding whether non-critical resources should be served to users with poor network conditions. In this guide, we’ll describe all the available hints and some ways you can use them to make content delivery more accommodating to users.

Opting in #

Unlike the Accept header, client hints don’t just magically appear (with the exception of Save-Data, which we’ll discuss later). In the interest of keeping request headers at a minimum, you’ll need to opt into which client hints you’ll want to receive by sending an Accept-CH header when a user requests a resource:

Accept-CH: Viewport-Width, Downlink

The value for Accept-CH is a comma-separated list of requested hints the site will use in determining the results for subsequent resource request. When the client reads this header, it’s being told “this site wants the Viewport-Width and Downlink client hints.” Don’t worry about the specific hints themselves. We’ll get to those in a moment.

You can set these opt-in headers in any back-end language. For example, PHP’s header function could be used. You could even set these opt-in headers with the http-equiv attribute on a <meta> tag:

<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />

All the client hints! #

Client hints describe one of two things: the device your users, well, use, and the network they’re using to access your site. Let’s briefly cover all of the hints that are available.

Device hints #

Some client hints describe characteristics of the user’s device, usually screen characteristics. Some of them can help you choose the optimal media resource for a given user’s screen, but not all of them are necessarily media-centric.

Before we get into this list, it might be helpful to learn a few key terms used to describe screens and media resolution:

Intrinsic size: the actual dimensions of a media resource. For example, if you open an image in Photoshop, the dimensions shown in the image size dialogue describe its intrinsic size.

Density-corrected intrinsic size: the dimensions of a media resource after it has been corrected for pixel density. It’s the image’s intrinsic size divided by a device pixel ratio. For example, let’s take this markup:

<img
  src="whats-up-1x.png"
  srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
  alt="I'm that image you wanted."
/>

Let’s say the intrinsic size of the 1x image in this case is 320x240, and the 2x image’s intrinsic size is 640x480. If this markup is parsed by a client installed on a device with a screen device pixel ratio of 2 (e.g., a Retina screen), the 2x image is requested. The density-corrected intrinsic size of the 2x image is 320x240, since 640x480 divided by 2 is 320x240.

Extrinsic size: the size of a media resource after CSS and other layout factors (such as width and height attributes) have been applied to it. Let’s say you have an <img> element that loads an image with a density-corrected intrinsic size of 320x240, but it also has CSS width and height properties with values of 256px and 192px applied to it, respectively. In this example, the extrinsic size of that <img> element becomes 256x192.

Figure 1. An illustration of intrinsic versus extrinsic size. An image gains its extrinsic size after layout factors have been applied to it. In this case, applying CSS rules of width: 256px; and height: 192px; transforms a 320x240 intrinsically sized image to a 256x192 extrinsically sized one.

With some terminology under our belt, let’s get into the list of device-specific client hints available to you.

Viewport-Width #

Viewport-Width is the width of the user’s viewport in CSS pixels:

Viewport-Width: 320

This hint can used with other screen-specific hints to deliver different treatments (i.e., crops) of an image which are optimal for specific screen sizes (i.e., art direction), or to omit resources that are unnecessary for the current screen width.

DPR #

DPR, short for device pixel ratio, reports the ratio of physical pixels to CSS pixels of the user’s screen:

DPR: 2

This hint is useful when selecting image sources which correspond to a screen's pixel density (like x descriptors do in the srcset attribute).

Width #

The Width hint appears on requests for image resources fired off by <img> or <source> tags using the sizes attribute. sizes tells the browser what the extrinsic size of the resource will be; Width uses that extrinsic size to request an image with an intrinsic size that is optimal for the current layout.

For example, let’s say a user requests a page with a 320 CSS pixel wide screen with a DPR of 2. The device loads a document with an <img> element containing a sizes attribute value of 85vw (i.e., 85% of the viewport width for all screen sizes). If the Width hint has been opted-into, the client will send this Width hint to the server with the request for the <img>’s src:

Width: 544

In this case, the client is hinting to the server that an optimal intrinsic width for the requested image would be 85% of the viewport width (272 pixels) multiplied by the screen’s DPR (2), which equals 544 pixels.

This hint is especially powerful because it not only takes into account the density-corrected width of the screen, but also reconciles this critical piece of information with the image’s extrinsic size within the layout. This gives servers the opportunity to negotiate image responses that are optimal for both the screen and the layout.

Content-DPR #

While you already know that screens have a device pixel ratio, resources also have their own pixel ratios. In the simplest resource selection use cases, pixel ratios between devices and resources can be the same. But! In cases where both the DPR and Width headers are in play, the extrinsic size of a resource can produce scenarios where the two differ. This is where the Content-DPR hint comes into play.

Unlike other client hints, Content-DPR is not a request header to be used by servers, but rather a response header servers must send whenever DPR and Width hints are used to select a resource. The value of Content-DPR should be the result of this equation:

Content-DPR = [Selected image resource size] / ([Width] / [DPR])

When a Content-DPR request header is sent, the browser will know how to scale the given image for the screen’s device pixel ratio and the layout. Without it, images may not scale properly.

Device-Memory #

Technically a part of the Device Memory API, Device-Memory reveals the approximate amount of memory the current device has in GiB:

Device-Memory: 2

A possible use case for this hint would be to reduce the amount of JavaScript sent to browsers on devices with limited memory, as JavaScript is the most resource-intensive content type browsers typically load. Or you could send lower DPR images as they use less memory to decode.

Network hints #

The Network Information API provides another category of client hints that describe the performance of the user’s network connection. In my opinion, these are the most useful set of hints. With them, we have the ability to tailor experiences to users by changing how we deliver resources to clients on slow connections.

RTT #

The RTT hint provides the approximate Round Trip Time, in milliseconds, on the application layer. The RTT hint, unlike transport layer RTT, includes server processing time.

RTT: 125

This hint is useful because of the role latency plays in loading performance. Using the RTT hint, we can make decisions based on network responsiveness, which can help speed the delivery of an entire experience (e.g., through omitting some requests).

Downlink #

While latency is important in loading performance, bandwidth is influential, too. The Downlink hint, expressed in megabits per second (Mbps), reveals the approximate downstream speed of the user’s connection:

Downlink: 2.5

In conjunction with RTT, Downlink can be useful in changing how content is delivered to users based on the quality of a network connection.

ECT #

The ECT hint stands for Effective Connection Type. Its value is one of an enumerated list of connection types, each of which describes a connection within specified ranges of both RTT and Downlink values.

This header doesn’t explain what the actual connection type is—for example, it doesn’t report whether your gateway is a cell tower or a wifi access point. Rather, it analyzes the current connection’s latency and bandwidth and determines what network profile it resembles most. For example, if you connect through wifi to a slow network, ECT may be populated with a value of 2g, which is the closest approximation of the effective connection:

ECT: 2g

Valid values for ECT are 4g, 3g, 2g, and slow-2g. This hint can be used as a starting point for assessing connection quality, and subsequently refined using the RTT and Downlink hints.

Save-Data #

Save-Data isn’t so much a hint describing network conditions as it is a user preference stating that pages should send less data.

I prefer to classify Save-Data as a network hint because many of the things you would do with it are similar to other network hints. Users may also be likely to enable it in high latency/low bandwidth environments. This hint, when present, always looks like this:

Save-Data: on

Here at Google, we’ve talked about what you can do with Save-Data. The impact it can have on performance can be profound. It’s a signal where users are literally asking you to send them less stuff! If you listen and act on that signal, users will appreciate it.

Tying it all together #

What you do with client hints depends on you. Because they offer so much information, you have many options. To get some ideas flowing, let’s see what client hints can do for Sconnie Timber, a fictional timber company located in the rural Upper Midwest. As is often the case in remote areas, network connections can be fragile. This is where a technology like client hints can really make a difference for users.

Responsive Images #

All but the simplest responsive image use cases can get complicated. What if you have multiple treatments and variants of the same images for different screen sizes—and different formats? That markup gets very complicated very quickly. It’s easy to get it wrong, and easy to forget or misunderstand important concepts (such as sizes).

While <picture> and srcset are undeniably awesome tools, they can be time-consuming to develop and maintain for complex use cases. We can automate markup generation, but doing so is also difficult because the functionality <picture> and srcset provides is complex enough that their automation needs to be done in a way that maintains the flexibility they provide.

Client hints are can simplify this. Negotiating image responses with client hints could look something like this:

If applicable to your workflow, first select an image treatment (i.e., art-directed imagery) by checking the Viewport-Width hint.
Select an image resolution by checking the Width hint and the DPR hint, and choosing a source that fits the image’s layout size and screen density (similar to how x and w descriptors work in srcset).
Select the most optimal file format the browser supports (something Accept helps us do in most browsers).

Where my fictitious timber company client was concerned, I developed a naïve responsive image selection routine in PHP that uses client hints. This meant instead of sending this markup to all users:

<picture>
  <source
    srcset="
      company-photo-256w.webp   256w,
      company-photo-512w.webp   512w,
      company-photo-768w.webp   768w,
      company-photo-1024w.webp 1024w,
      company-photo-1280w.webp 1280w
    "
    type="image/webp"
  />
  <img
    srcset="
      company-photo-256w.jpg   256w,
      company-photo-512w.jpg   512w,
      company-photo-768w.jpg   768w,
      company-photo-1024w.jpg 1024w,
      company-photo-1280w.jpg 1280w
    "
    src="company-photo-256w.jpg"
    sizes="(min-width: 560px) 251px, 88.43vw"
    alt="The Sconnie Timber Staff!"
  />
</picture>

I was able to reduce it to the following based on individual browser support:

<img
  src="/image/sizes:true/company-photo.jpg"
  sizes="(min-width: 560px) 251px, 88.43vw"
  alt="SAY CHEESY PICKLES."
/>

In this example, the /image URL is a PHP script followed by parameters rewritten by mod_rewrite. It takes an image filename and additional parameters to help a back-end script choose the best image in the given conditions.

I sense “But isn’t this just reimplementing <picture> and srcset on the back-end?” is your first question.

In a way, yes—but with an important distinction: when an application uses client hints to craft media responses, most (if not all) of the work is much easier to automate, which can include a service (such as a CDN) that can do this on your behalf. Whereas with HTML solutions, new markup needs to be written to provide for every use case. Sure, you can automate markup generation. If your design or requirements change, though, there’s a good chance you’ll need to revisit your automation strategy in the future.

Client hints make it possible to start with a lossless, high-resolution image that can then be dynamically resized to be optimal for any combination of screen and layout. Unlike srcset, which requires you to enumerate a fixed list of possible image candidates for the browser to choose from, this approach can be more flexible. While srcset forces you to offer browsers a coarse set of variants—say, 256w, 512w, 768w, and 1024w—a client-hints powered solution can serve all widths, without a giant pile of markup.

Of course, you don’t have to write image selection logic yourself. Cloudinary uses client hints to craft image responses when you use the w_auto parameter, and observed that median users downloaded 42% less bytes when using browsers supporting client hints.

But beware! Changes in the desktop version of Chrome 67 have removed support for cross-origin client hints. Fortunately, these restrictions don’t affect mobile versions of Chrome, and they'll be lifted altogether for all platforms when work on Feature Policy is complete.

Helping users on slow networks #

Adaptive performance is the idea that we can adjust how we deliver resources based on the information client hints makes available to us; specifically information surrounding the current state of the user’s network connection.

Where Sconnie Timber’s site is concerned, we take steps to lighten the load when networks are slow, with Save-Data, ECT, RTT, and Downlink headers being examined in our back-end code. When this is done, we generate a network quality score we can use to determine if we should intervene for a better user experience. This network score is between 0 and 1, where 0 is the worst network possible network quality, and 1 is the best.

Initially, we check if Save-Data is present. If it is, the score is set to 0, as we’re assuming the user wants us to do whatever is necessary to make the experience lighter and faster.

If Save-Data is absent, however, we move on and weigh the values of the ECT, RTT, and Downlink hints to calculate a score that describes network connection quality. The network score generation source code is available on Github. The takeaway is, if we use the network-related hints in some fashion, we can make experiences better for those who are on slow networks.

Figure 2. An “about us” page for a local business site. The baseline experience includes web fonts, JavaScript to drive a carousel and accordion behavior, as well as content images. These are all things we can omit when network conditions are too slow to load them quickly.

When sites adapt to the information client hints provide, we don’t have to adopt an “all or nothing” approach. We can intelligently decide which resources to send. We can modify our responsive image selection logic to send lower quality images for a given display to speed up loading performance when network quality is poor.

In this example, we can see the impact client hints have when it comes to improving the performance of sites on slower networks. Below is a WebPagetest waterfall of a site on a slow network that doesn’t adapt to client hints:

Figure 3. A resource heavy site loading images, scripts, and fonts on a slow connection.

And now a waterfall for the same site on the same slow connection, except this time, the site uses client hints to eliminate non-critical page resources:

Figure 4. The same site on the same connection, only the “nice to have” resources are excluded in favor of faster loading.

Client hints reduced the page load time from over 45 seconds to less than a tenth of that time. The benefits of client hints in this scenario can’t be emphasized enough and can be a serious boon to users seeking critical information over slow networks.

Furthermore, it’s possible to use client hints without breaking the experience for browsers that don’t support them. For example, if we want adjust resource delivery suing the value of the ECT hint while still delivering the full experience for non-supporting browsers, we can set fall back to a default value like so:

// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";

Here, "4g" represents the highest quality network connection the ECT header describes. If we initialize $ect to "4g", browsers that don’t support client hints won’t be affected. Opt-in FTW!

Mind those caches! #

Whenever you change a response based on an HTTP header, you need to be aware of how caches will handle future fetches for that resource. The Vary header is indispensable here, as it keys cache entries to the value of the request headers supplied to it. Simply put, if you modify any response based on a given HTTP request header, you should almost always include request that header in Vary like so:

Vary: DPR, Width

There’s a big caveat to this, though: You never want to Vary cacheable responses on a frequently changing header (like Cookie) because those resources become effectively uncacheable. Knowing this, you might want to avoid Varying on client hint headers such as RTT or Downlink, because those are connection factors that could change quite often. If you want to modify responses on those headers, consider keying only the ECT header, which will minimize cache misses.

Of course, this only applies if you’re caching a response in the first place. For example, you won’t cache HTML assets if their content is dynamic, because that can break the user experience on repeat visits. In cases like these, feel free to modify such responses on whatever basis you feel is necessary and not concern yourself with Vary.

Client hints in service workers #

Content negotiation isn’t just for servers anymore! Because service workers act as proxies between clients and the servers, you have control over how resources are delivered via JavaScript. This includes client hints. In the service worker fetch event, you can use the event object’s request.headers.get method to read a resource’s request headers like so:

self.addEventListener('fetch', (event) => {
  let dpr = event.request.headers.get('DPR');
  let viewportWidth = event.request.headers.get('Viewport-Width');
  let width = event.request.headers.get('Width');

  event.respondWith(
    (async function () {
      // Do what you will with these hints!
    })(),
  );
});

Any client hint header you opt into can be read in this fashion. Though that’s not the only way you can get some of this information. Network-specific hints can be read in these equivalent JavaScript properties in the navigator object:

Imagemin plugins for filetypes.
Client hint	JS equivalent
`ECT`	`navigator.connection.effectiveType`
`RTT`	`navigator.connection.rtt`
`Save-Data`	`navigator.connection.saveData`
`Downlink`	`navigator.connection.downlink`
`Device-Memory`	`navigator.deviceMemory`

Because these APIs aren’t available everywhere you need feature check with the in operator:

if ('connection' in navigator) {
  // Work with netinfo API properties in JavaScript!
}

From here, you can use logic similar to what you would use on the server, except you don’t need a server to negotiate content with client hints. Service workers alone have the power to make experiences faster and more resilient due to the added ability they have to serve content when the user is offline.

Wrapping up #

With client hints, we have the power to make experiences faster for users in a fully progressive way. We can serve media based on the user’s device capabilities in a way that makes serving responsive images easier than relying on <picture> and srcset, especially for complex use cases. This enables us to not only reduce time and effort on the development side, but also to optimize resources—particularly images—in a way that targets user’s screens more finely than and srcset can.

Perhaps more importantly, we can sniff out poor network connections and bridge the gap for users by modifying what we send—and how we send it. This can go a long way in making sites easier to access for users on fragile networks. Combined with service workers, we can create incredibly fast sites that are available offline.

While client hints are only available in Chrome—and Chromium-based browsers—it’s possible to use them in such a way that doesn’t encumber browsers that don’t support them. Consider using client hints to create truly inclusive and adaptable experiences that are aware of every user’s device capabilities, and the networks they connect to. Hopefully, other browser vendors will see the value of them and show intent to implement.

Resources #

Thank you to Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss, and Estelle Weyl for their valuable feedback and edits on this article.

Reduce JavaScript payloads with code splitting

2018-11-05T00:00:00Z

Nobody likes waiting. Over 50% of users abandon a website if it takes longer than 3 seconds to load.

Sending large JavaScript payloads impacts the speed of your site significantly. Instead of shipping all the JavaScript to your user as soon as the first page of your application is loaded, split your bundle into multiple pieces and only send what's necessary at the very beginning.

Why is code splitting beneficial? #

Code splitting is a technique that seeks to minimize startup time. When we ship less JavaScript at startup, we can get applications to be interactive faster by minimizing main thread work during this critical period.

When it comes to Core Web Vitals, reducing JavaScript payloads downloaded at startup will contribute to better First Input Delay (FID) and Interaction to Next Paint (INP) times. The reasoning behind this is that, by freeing up the main thread, the application is able to respond to user inputs more quickly by reducing JavaScript parse, compile, and execution-related startup costs.

Depending on your website's architecture—particularly if your website relies heavily on client-side rendering—reducing the size of JavaScript payloads responsible for rendering markup may lead to improved Largest Contentful Paint (LCP) times. This can occur when the LCP resource is delayed in being discovered by the browser until after client-side markup is completed, or when the main thread is too busy to render that LCP element. Both scenarios can delay the LCP time for the page.

Measure #

Lighthouse displays a failed audit when a significant amount of time is taken to execute all the JavaScript on a page.

Split the JavaScript bundle to only send the code needed for the initial route when the user loads an application. This minimizes the amount of script that needs to be parsed and compiled, which results in faster page load times.

Popular module bundlers like webpack, Parcel, and Rollup allow you to split your bundles using dynamic imports. For example, consider the following code snippet that shows an example of a someFunction method that gets fired when a form is submitted.

import moduleA from "library";

form.addEventListener("submit", e => {
  e.preventDefault();
  someFunction();
});

const someFunction = () => {
  // uses moduleA
}

In here, someFunction uses a module imported from a particular library. If this module is not being used elsewhere, the code block can be modified to use a dynamic import to fetch it only when the form is submitted by the user.

form.addEventListener("submit", e => {
  e.preventDefault();
  import('library.moduleA')
    .then(module => module.default) // using the default export
    .then(() => someFunction())
    .catch(handleError());
});

const someFunction = () => {
    // uses moduleA
}

The code that makes up the module does not get included into the initial bundle and is now lazy loaded, or provided to the user only when it is needed after the form submission. To further improve page performance, preload critical chunks to prioritize and fetch them sooner.

Although the previous code snippet is a simple example, lazy loading third party dependencies is not a common pattern in larger applications. Usually, third party dependencies are split into a separate vendor bundle that can be cached since they don't update as often. You can read more about how the SplitChunksPlugin can help you do this.

Splitting on the route or component level when using a client-side framework is a simpler approach to lazy loading different parts of your application. Many popular frameworks that use webpack provide abstractions to make lazy loading easier than diving into the configurations yourself.

Replace animated GIFs with video for faster page loads

2018-11-05T00:00:00Z

Have you ever seen an animated GIF on a service like Imgur or Gfycat, inspected it in your dev tools, only to find out that GIF was really a video? There's a good reason for that. Animated GIFs can be downright huge.

Thankfully, this is one of those areas of loading performance where you can do relatively little work to realize huge gains! By converting large GIFs to videos, you can save big on users' bandwidth.

Measure first #

Use Lighthouse to check your site for GIFs that can be converted to videos. In DevTools, click on the Audits tab and check the Performance checkbox. Then run Lighthouse and check the report. If you have any GIFs that can be converted, you should see a suggestion to "Use video formats for animated content":

Create MPEG videos #

There are a number of ways to convert GIFs to video, FFmpeg is the tool used in this guide. To use FFmpeg to convert the GIF, my-animation.gif to an MP4 video, run the following command in your console:

ffmpeg -i my-animation.gif -b:v 0 -crf 25 -f mp4 -vcodec libx264 -pix_fmt yuv420p my-animation.mp4

This tells FFmpeg to take my-animation.gif as the input, signified by the -i flag, and to convert it to a video called my-animation.mp4.

The libx264 encoder only works with files that have even dimensions, like 320px by 240px. If the input GIF has odd dimensions you can include a crop filter to avoid FFmpeg throwing a 'height/width not divisible by 2' error:

ffmpeg -i my-animation.gif -vf "crop=trunc(iw/2)*2:trunc(ih/2)*2" -b:v 0 -crf 25 -f mp4 -vcodec libx264 -pix_fmt yuv420p my-animation.mp4

Create WebM videos #

While MP4 has been around since 1999, WebM is a relatively new file format initially released in 2010. WebM videos are much smaller than MP4 videos, but not all browsers support WebM so it makes sense to generate both.

To use FFmpeg to convert my-animation.gif to a WebM video, run the following command in your console:

ffmpeg -i my-animation.gif -c vp9 -b:v 0 -crf 41 my-animation.webm

Compare the difference #

The cost savings between a GIF and a video can be pretty significant.

In this example, the initial GIF is 3.7 MB, compared to the MP4 version, which is 551 KB, and the WebM version, which is only 341 KB!

Replace the GIF img with a video #

Animated GIFs have three key traits that a video needs to replicate:

They play automatically.
They loop continuously (usually, but it is possible to prevent looping).
They're silent.

Luckily, you can recreate these behaviors using the <video> element.

<video autoplay loop muted playsinline></video>

A <video> element with these attributes plays automatically, loops endlessly, plays no audio, and plays inline (that is, not full screen), all the hallmark behaviors expected of animated GIFs! 🎉

Finally, the <video> element requires one or more <source> child elements pointing to different video files that the browser can choose from, depending on the browser's format support. Provide both WebM and MP4, so that if a browser doesn't support WebM, it can fall back to MP4.

<video autoplay loop muted playsinline>
  <source src="my-animation.webm" type="video/webm">
  <source src="my-animation.mp4" type="video/mp4">
</video>

Effect on Largest Contentful Paint (LCP) #

It should be noted that while <img> elements are candidates for LCP, <video> elements without a poster image are not LCP candidates. The solution in the case of emulating animated GIFs is not to add poster attribute to your <video> elements, because that image will go unused.

What does this mean for your website? The recommendation is to stick with using a <video> instead of an animated GIF, but with the understanding that such media will not be a candidate for LCP, and the next largest candidate will be used instead. As GIFs and <video>s are typically larger and so slower to download, moving to a different LCP candidate will likely even improve the site's LCP.

Preload critical assets to improve loading speed

2018-11-05T00:00:00Z

When you open a web page, the browser requests the HTML document from a server, parses its contents, and submits separate requests for any referenced resources. As a developer, you already know about all the resources your page needs and which of them are the most important. You can use that knowledge to request the critical resources ahead of time and speed up the loading process. This post explains how to achieve that with <link rel="preload">.

How preloading works #

Preloading is best suited for resources typically discovered late by the browser.

In this example, Pacifico font is defined in the stylesheet with a @font-face rule. The browser loads the font file only after it has finished downloading and parsing the stylesheet.

By preloading a certain resource, you are telling the browser that you would like to fetch it sooner than the browser would otherwise discover it because you are certain that it is important for the current page.

In this example, Pacifico font is preloaded, so the download happens in parallel with the stylesheet.

The critical request chain represents the order of resources that are prioritized and fetched by the browser. Lighthouse identifies assets that are on the third level of this chain as late-discovered. You can use the Preload key requests audit to identify which resources to preload.

You can preload resources by adding a <link> tag with rel="preload" to the head of your HTML document:

<link rel="preload" as="script" href="critical.js">

The browser caches preloaded resources so they are available immediately when needed. (It doesn't execute the scripts or apply the stylesheets.)

Resource hints, for example, preconnectand prefetch, are executed as the browser sees fit. The preload, on the other hand, is mandatory for the browser. Modern browsers are already pretty good at prioritizing resources, that's why it's important to use preload sparingly and only preload the most critical resources.

Unused preloads trigger a Console warning in Chrome, approximately 3 seconds after the load event.

Use cases #

Preloading resources defined in CSS #

Fonts defined with @font-face rules or background images defined in CSS files aren't discovered until the browser downloads and parses those CSS files. Preloading these resources ensures they are fetched before the CSS files have downloaded.

Preloading CSS files #

If you are using the critical CSS approach, you split your CSS into two parts. The critical CSS required for rendering the above-the-fold content is inlined in the <head> of the document and non-critical CSS is usually lazy-loaded with JavaScript. Waiting for JavaScript to execute before loading non-critical CSS can cause delays in rendering when users scroll, so it's a good idea to use <link rel="preload"> to initiate the download sooner.

Preloading JavaScript files #

Because browsers don't execute preloaded files, preloading is useful to separate fetching from execution which can improve metrics such as Time to Interactive. Preloading works best if you split your JavaScript bundles and only preload critical chunks.

How to implement rel=preload #

The simplest way to implement preload is to add a <link> tag to the <head> of the document:

<head>
  <link rel="preload" as="script" href="critical.js">
</head>

Supplying the as attribute helps the browser set the priority of the prefetched resource according to its type, set the right headers, and determine whether the resource already exists in the cache. Accepted values for this attribute include: script, style, font, image, and others.

Some types of resources, such as fonts, are loaded in anonymous mode. For those you must set the crossorigin attribute with preload:

<link rel="preload" href="ComicSans.woff2" as="font" type="font/woff2" crossorigin>

<link> elements also accept a type attribute, which contains the MIME type of the linked resource. The browsers use the value of the type attribute to make sure that resources get preloaded only if their file type is supported. If a browser doesn't support the specified resource type, it will ignore the <link rel="preload">.

You can also preload any type of resource via the Link HTTP header:

Link: </css/style.css>; rel="preload"; as="style"

A benefit of specifying preload in the HTTP Header is that the browser doesn't need to parse the document to discover it, which can offer small improvements in some cases.

Preloading JavaScript modules with webpack #

If you are using a module bundler that creates build files of your application, you need to check if it supports the injection of preload tags. With webpack version 4.6.0 or later, preloading is supported through the use of magic comments inside import():

import(_/* webpackPreload: true */_ "CriticalChunk")

If you are using an older version of webpack, use a third-party plugin such as preload-webpack-plugin.

Effects of preloading on Core Web Vitals #

Preloading is a powerful performance optimization that has an effect on loading speed. Such optimizations can lead to changes in your site's Core Web Vitals, and it's important to be aware them.

Largest Contentful Paint (LCP) #

Preloading has a powerful effect on Largest Contentful Paint (LCP) when it comes to fonts and images, as both images and text nodes can be LCP candidates. Hero images and large runs of text that are rendered using web fonts can benefit significantly from a well-placed preload hint, and should be used when there are opportunities to deliver these important bits of content to the user faster.

However, you want to be careful when it comes to preloading—and other optimizations! In particular, avoid preloading too many resources. If too many resources are prioritized, effectively none of them are. The effects of excessive preload hints will be especially detrimental to those on slower networks where bandwidth contention will be more evident.

Instead, focus on a few high-value resources that you know will benefit from a well-placed preload. When preloading fonts, ensure that you're serving fonts in WOFF 2.0 format to reduce resource load time as much as possible. Since WOFF 2.0 has excellent browser support, using older formats such as WOFF 1.0 or TrueType (TTF) will delay your LCP if the LCP candidate is a text node.

When it comes to LCP and JavaScript, you'll want to ensure that you're sending complete markup from the server in order for the browser's preload scanner to work properly. If you're serving up an experience that relies entirely on JavaScript to render markup and can't send server-rendered HTML, it would be advantageous to step in where the browser preload scanner can't and preload resources that would only otherwise be discoverable when the JavaScript finishes loading and executing.

Cumulative Layout Shift (CLS) #

Cumulative Layout Shift (CLS) is an especially important metric where web fonts are concerned, and CLS has significant interplay with web fonts that use the font-display CSS property to manage how fonts are loaded. To minimize web font-related layout shifts, consider the following strategies:

Preload fonts while using the default block value for font-display. This is a delicate balance. Blocking the display of fonts without a fallback can be considered a user experience problem. On one hand, loading fonts with font-display: block; eliminates web font-related layout shifts. On the other hand, you still want to get those web fonts loaded as soon as possible if they're crucial to the user experience. Combining a preload with font-display: block; may be an acceptable compromise.
Preload fonts while using the fallback value for font-display. fallback is a compromise between swap and block, in that it has an extremely short blocking period.
Use the optional value for font-display without a preload. If a web font isn't crucial to the user experience, but it is still used to render a significant amount of page text, consider using the optional value. In adverse conditions, optional will display page text in a fallback font while it loads the font in the background for the next navigation. The net result in these conditions is improved CLS, as system fonts will render immediately, while subsequent page loads will load the font immediately without layout shifts.

CLS is a difficult metric to optimize for when it comes to web fonts. As always, experiment in the lab, but trust your field data to determine if your font loading strategies are improving CLS or making it worse.

Responsiveness metrics #

First Input Delay (FID) and Interaction to Next Paint are two metrics that gauge responsiveness to user input. Since the lion's share of interactivity on the web is driven by JavaScript, preloading JavaScript that powers important interactions may help to keep your FID and INP metrics as low as they can possibly be. However, be aware that FID is a load responsiveness metric and INP observes interactions throughout the entire page lifecycle—including during startup. Preloading too much JavaScript during startup can carry unintended negative consequences if too many resources are contending for bandwidth.

You'll also want to be careful about how you go about code splitting. Code splitting is an excellent optimization for reducing the amount of JavaScript loaded during startup, but interactions can be delayed if they rely on JavaScript loaded right at the start of the interaction. To compensate for this, you'll need to examine the user's intent, and inject a preload for the necessary chunk(s) of JavaScript before the interaction takes place. One example could be preloading JavaScript required for validating a form's contents when any of the fields in the form are focused.

Conclusion #

To improve page speed, preload important resources that are discovered late by the browser. Preloading everything would be counterproductive so use preload sparingly and measure the impact in the real-world.

Choose the right image format

2018-08-30T00:00:00Z

The very first question you should ask yourself is whether an image is, in fact, required to achieve the effect you are after. Good design is simple and will also always yield the best performance. If you can eliminate an image resource, which often requires a large number of bytes relative to HTML, CSS, JavaScript and other assets on the page, then that is always the best optimization strategy. That said, a well-placed image can also communicate more information than a thousand words, so it is up to you to find that balance.

Next, you should consider if there is an alternative technology that could deliver the desired results, but in a more efficient manner:

CSS effects (such as shadows or gradients) and CSS animations can be used to produce resolution-independent assets that always look sharp at every resolution and zoom level, often at a fraction of the bytes required by an image file.
Web fonts enable use of beautiful typefaces while preserving the ability to select, search, and resize text—a significant improvement in usability.

If you ever find yourself encoding text in an image asset, stop and reconsider. Great typography is critical to good design, branding, and readability, but text-in-images delivers a poor user experience: the text is not selectable, not searchable, not zoomable, not accessible, and not friendly for high-DPI devices. The use of web fonts requires its own set of optimizations, but it addresses all of these concerns and is always a better choice for displaying text.

Choose the right image format #

If you are sure an image is the correct option, you should carefully select the right kind of image for the job.

Zoomed-in vector image (L) raster image (R)

Vector graphics use lines, points, and polygons to represent an image.
Raster graphics represent an image by encoding the individual values of each pixel within a rectangular grid.

Each format has its own set of pros and cons. Vector formats are ideally suited for images that consist of simple geometric shapes such as logos, text, or icons. They deliver sharp results at every resolution and zoom setting, which makes them an ideal format for high-resolution screens and assets that need to be displayed at varying sizes.

However, vector formats fall short when the scene is complicated (for example, a photo): the amount of SVG markup to describe all the shapes can be prohibitively high and the output may still not look "photorealistic". When that's the case, that's when you should be using a raster image format such as PNG, JPEG, WebP, or AVIF.

Raster images do not have the same nice properties of being resolution or zoom independent —when you scale up a raster image you'll see jagged and blurry graphics. As a result, you may need to save multiple versions of a raster image at various resolutions to deliver the optimal experience to your users.

Implications of high-resolution screens #

There are two different kinds of pixels: CSS pixels and device pixels. A single CSS pixel may correspond directly to a single device pixel, or may be backed by multiple device pixels. What's the point? Well, the more device pixels there are, the finer the detail of the displayed content on the screen.

The difference between CSS pixels and device pixels.

High DPI (HiDPI) screens produce beautiful results, but there is one obvious tradeoff: image assets require more detail to take advantage of the higher device pixel counts. The good news is, vector images are ideally suited for this task, as they can be rendered at any resolution with sharp results— you might incur a higher processing cost to render the finer detail, but the underlying asset is the same and is resolution independent.

On the other hand, raster images pose a much larger challenge because they encode image data on a per-pixel basis. Hence, the larger the number of pixels, the larger the filesize of a raster image. As an example, let's consider the difference between a photo asset displayed at 100x100 (CSS) pixels:

Screen resolution	Total pixels	Uncompressed filesize (4 bytes per pixel)
1x	100 x 100 = 10,000	40,000 bytes
2x	100 x 100 x 4 = 40,000	160,000 bytes
3x	100 x 100 x 9 = 90,000	360,000 bytes

When we double the resolution of the physical screen, the total number of pixels increases by a factor of four: double the number of horizontal pixels, times double the number of vertical pixels. Hence, a "2x" screen not just doubles, but quadruples the number of required pixels!

So, what does this mean in practice? High-resolution screens enable you to deliver beautiful images, which can be a great product feature. However, high-resolution screens also require high-resolution images, therefore:

Prefer vector images whenever possible as they are resolution-independent and always deliver sharp results.
If a raster image is required, serve responsive images.

Features of different raster image formats #

In addition to different lossy and lossless compression algorithms, different image formats support different features such as animation and transparency (alpha) channels. As a result, the choice of the "right format" for a particular image is a combination of desired visual results and functional requirements.

Format	Transparency	Animation	Browser
PNG	Yes	No	All
JPEG	No	No	All
WebP	Yes	Yes	All modern browsers. See Can I use?
AVIF	Yes	Yes	No. See Can I use?

There are two universally supported raster image formats: PNG and JPEG. In addition to these formats, modern browsers support the newer format WebP, while only some support the newer AVIF format. Both of the newer formats offer better overall compression and more features. So, which format should you use?

WebP and AVIF will generally provide better compression than older formats, and should be used where possible. You can use WebP or AVIF images along with a JPEG or PNG image as a fallback. See Use WebP images for more details.

In terms of older image formats, consider the following:

Do you need animation? Use <video> elements.
- What about GIF? GIF limits the color palette to at most 256 colors, and creates significantly larger file sizes than <video> elements. See Replace animated GIFs with video.
Do you need to preserve fine detail with highest resolution? Use PNG or lossless WebP.
- PNG does not apply any lossy compression algorithms beyond the choice of the size of the color palette. As a result, it will produce the highest quality image, but at a cost of significantly higher filesize than other formats. Use judiciously.
- WebP has a lossless encoding mode that may be more efficient than PNG.
- If the image asset contains imagery composed of geometric shapes, consider converting it to a vector (SVG) format!
- If the image asset contains text, stop and reconsider. Text in images is not selectable, searchable, or "zoomable". If you need to convey a custom look (for branding or other reasons), use a web font instead.
Are you optimizing a photo, screenshot, or a similar image asset? Use JPEG, lossy WebP, or lossy AVIF.
- JPEG uses a combination of lossy and lossless optimization to reduce filesize of the image asset. Try several JPEG quality levels to find the best quality versus filesize tradeoff for your asset.
- Lossy WebP or lossy AVIF may be acceptable JPEG alternatives, but be aware that WebP's lossy mode in particular discards some chroma information to achieve smaller images. This means that select colors may not be the same as an equivalent JPEG.

Finally, note that if you are using a WebView to render content in your platform-specific application, then you have full control of the client and can use WebP exclusively! Facebook and many others use WebP to deliver all of their images within their applications— the savings are definitely worth it.

Impact on Largest Contentful Paint (LCP) #

Images may be LCP candidates. That means the size of an image affects its load time. When an image is an LCP candidate, efficiently encoding that image is crucial to improving LCP.

You should strive to apply the advice given in this article so that the perceptual performance of a page is as fast as it can possibly be for all users. LCP is part of perceptual performance, as it measures how fast the largest (and therefore most perceivable) element on the page displays.

Choose the correct level of compression

2018-08-30T00:00:00Z

Images often account for most of the downloaded bytes on a web page and also often occupy a significant amount of visual space. As a result, optimizing images can often yield some of the largest byte savings and performance improvements for your website: the fewer bytes the browser has to download, the less competition there is for the client's bandwidth and the faster the browser can download and render useful content on the screen.

Image optimization is both an art and science: an art because there is no one definitive answer for how best to compress an individual image, and a science because there are many well developed techniques and algorithms that can significantly reduce the size of an image. Finding the optimal settings for your image requires careful analysis along many dimensions: format capabilities, content of encoded data, quality, pixel dimensions, and more.

Optimizing vector images #

All modern browsers support Scalable Vector Graphics (SVG), which is an XML-based image format for two-dimensional graphics. You can embed the SVG markup directly on the page or as an external resource. Most vector-based drawing software can create SVG files or you can write them by hand directly in your favorite text editor.

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 17.1.0, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
<svg version="1.2" baseProfile="tiny" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
    x="0px" y="0px" viewBox="0 0 612 792" xml:space="preserve">
<g id="XMLID_1_">
  <g>
    <circle fill="red" stroke="black" stroke-width="2" stroke-miterlimit="10" cx="50" cy="50" r="40"/>
  </g>
</g>
</svg>

The above example renders the below simple circle shape with a black outline and red background and was exported from Adobe Illustrator.

As you can tell, it contains a lot of metadata, such as layer information, comments, and XML namespaces that are often unnecessary to render the asset in the browser. As a result, it is always a good idea to minify your SVG files by running through a tool like SVGO.

Case in point, SVGO reduces the size of the above SVG file generated by Illustrator by 58%, taking it from 470 to 199 bytes.

<svg version="1.2" baseProfile="tiny" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 612 792"><circle fill="red" stroke="#000" stroke-width="2" stroke-miterlimit="10" cx="50" cy="50" r="40"/></svg>

Because SVG is an XML-based format, you can also apply GZIP compression to reduce its transfer size—make sure your server is configured to compress SVG assets!

A raster image is simply a two-dimensional grid of individual "pixels"—for example, a 100x100 pixel image is a sequence of 10,000 pixels. In turn, each pixel stores the "RGBA" values: (R) red channel, (G) green channel, (B) blue channel, and (A) alpha (transparency) channel.

Internally, the browser allocates 256 values (shades) for each channel, which translates to 8 bits per channel (2 ^ 8 = 256), and 4 bytes per pixel (4 channels x 8 bits = 32 bits = 4 bytes). As a result, if we know the dimensions of the grid we can easily calculate the filesize:

100x100 pixel image is composed of 10,000 pixels
10,000 pixels x 4 bytes = 40,000 bytes
40,000 bytes / 1024 = 39 KB

Dimensions	Pixels	File size
100 x 100	10,000	39 KB
200 x 200	40,000	156 KB
300 x 300	90,000	351 KB
500 x 500	250,000	977 KB
800 x 800	640,000	2500 KB

39 KB for a 100x100 pixel image may not seem like a big deal, but the filesize quickly explodes for larger images and makes image assets both slow and expensive to download. This post has so far only focused on the "uncompressed" image format. Thankfully, a lot can be done to reduce the image file size.

One simple strategy is to reduce the "bit-depth" of the image from 8 bits per channel to a smaller color palette: 8 bits per channel gives us 256 values per channel and 16,777,216 (256 ^ 3) colors in total. What if you reduce the palette to 256 colors? Then you would only need 8 bits in total for the RGB channels and immediately save two bytes per pixel—that's 50% compression savings over the original 4 bytes per pixel format!

Left to right (PNG): 32-bit (16M colors), 7-bit (128 colors), 5-bit (32 colors).

Complex scenes with gradual color transitions (for example, gradients or sky) require larger color palettes to avoid visual artifacts such as the pixelated sky in the 5-bit asset. On the other hand, if the image only uses a few colors, then a large palette is simply wasting precious bits!

Next, once you've optimized the data stored in individual pixels you could get more clever and look at nearby pixels as well: turns out, many images, and especially photos, have many nearby pixels with similar colors— for example, the sky, repeating textures, and so on. Using this information to your advantage the compressor can apply delta encoding where instead of storing the individual values for each pixel, you can store the difference between nearby pixels: if the adjacent pixels are the same, then the delta is "zero" and you only need to store a single bit! But why stop there…

The human eye has different level of sensitivity to different colors: you can optimize your color encoding to account for this by reducing or increasing the palette for those colors. "Nearby" pixels form a two-dimensional grid. This means that each pixel has multiple neighbors: you can use this fact to further improve delta encoding. Instead of looking at just the immediate neighbors for each pixel, you can look at larger blocks of nearby pixels and encode different blocks with different settings.

As you can tell, image optimization gets complicated quickly (or fun, depending on your perspective), and is an active area of academic and commercial research. Images occupy a lot of bytes and there is a lot of value in developing better image compression techniques! If you're curious to learn more, head to the Wikipedia page, or check out the WebP compression techniques whitepaper for a hands-on example.

So, once again, this is all great, but also very academic: how does it help you to optimize images on your site? Well, it's important to understand the shape of the problem: RGBA pixels, bit-depth, and various optimization techniques. All of these concepts are critical to understand and keep in mind before you dive into the discussions of various raster image formats.

Lossless versus lossy image compression #

For certain types of data, such as source code for a page, or an executable file, it is critical that a compressor does not alter or lose any of the original information: a single missing or wrong bit of data could completely change the meaning of the contents of the file, or worse, break it entirely. For some other types of data, such as images, audio, and video, it may be perfectly acceptable to deliver an "approximate" representation of the original data.

In fact, due to how the eye works, we can often get away with discarding some information about each pixel in order to reduce the filesize of an image— for example, our eyes have different sensitivity to different colors, which means that we can use fewer bits to encode some colors. As a result, a typical image optimization pipeline consists of two high level steps:

Image is processed with a lossy filter that eliminates some pixel data.
Image is processed with a lossless filter that compresses the pixel data.

The first step is optional, and the exact algorithm will depend on the particular image format, but it is important to understand that any image can undergo a lossy compression step to reduce its size. In fact, the difference between various image formats, such as GIF, PNG, JPEG, and others, is in the combination of the specific algorithms they use (or omit) when applying the lossy and lossless steps.

So, what is the "optimal" configuration of lossy and lossless optimization? The answer depends on the image contents and your own criteria such as the tradeoff between filesize and artifacts introduced by lossy compression: In some cases, you may want to skip lossy optimization to communicate intricate detail in its full fidelity. In other cases, you may be able to apply aggressive lossy optimization to reduce the filesize of the image asset. This is where your own judgment and context need to come into play—there is no one universal setting.

As a hands-on example, when using a lossy format such as JPEG, the compressor will typically expose a customizable "quality" setting (for example, the quality slider provided by the "Save for Web" functionality in Adobe Photoshop), which is typically a number between 1 and 100 that controls the inner workings of the specific collection of lossy and lossless algorithms. For best results, experiment with various quality settings for your images, and don't be afraid to dial down the quality—the visual results are often very good and the filesize savings can be quite large.

Effects of image compression on Core Web Vitals #

Because images are often candidates for Largest Contentful Paint, reducing the resource load time of an image can translate into better LCP in both the lab and in the field.

When playing with compression settings on raster image formats, be sure to experiment with WebP and AVIF formats to see if you can deliver the same image in a small footprint as compared to older formats.

You want to be careful not to overcompress raster images, though. A good solution is to use an image optimization CDN to find the best compression settings for you, but an alternative may be to use tools like Butteraugli to estimate visual differences so that you don't encode images too aggressively and lose too much quality.

Image optimization checklist #

Some tips and techniques to keep in mind as you work on optimizing your images:

Prefer vector formats: vector images are resolution and scale independent, which makes them a perfect fit for the multi-device and high-resolution world.
Minify and compress SVG assets: XML markup produced by most drawing applications often contains unnecessary metadata which can be removed; Ensure that your servers are configured to apply GZIP compression for SVG assets.
Prefer WebP or AVIF over older raster formats: WebP and AVIF images will usually be far smaller than older image formats.
Pick best raster image format: determine your functional requirements and select the one that suits each particular asset.
Experiment with optimal quality settings for raster formats: don't be afraid to dial down the "quality" settings, the results are often very good and byte savings are significant.
Remove unnecessary image metadata: many raster images contain unnecessary metadata about the asset: geo information, camera information, and so on. Use appropriate tools to strip this data.
Serve scaled images: resize images and ensure that the "display" size is as close as possible to the "natural" size of the image. Pay close attention to large images in particular, as they account for largest overhead when resized!
Automate, automate, automate: invest into automated tools and infrastructure that will ensure that all of your image assets are always optimized.

Reduce JavaScript payloads with tree shaking

2018-06-14T00:00:00Z

Today's web applications can get pretty big, especially the JavaScript part of them. As of mid-2018, HTTP Archive puts the median transfer size of JavaScript on mobile devices at approximately 350 KB. And this is just transfer size! JavaScript is often compressed when sent over the network, meaning that the actual amount of JavaScript is quite a bit more after the browser decompresses it. That's important to point out, because as far as resource processing is concerned, compression is irrelevant. 900 KB of decompressed JavaScript is still 900 KB to the parser and compiler, even though it may be roughly 300 KB when compressed.

The process of downloading and running JavaScript. Note that even though the transfer size of the script is 300 KB compressed, it is still 900 KB worth of JavaScript that must be parsed, compiled, and executed.

JavaScript is an expensive resource to process. Unlike images which only incur relatively trivial decode time once downloaded, JavaScript must be parsed, compiled, and then finally executed. Byte for byte, this makes JavaScript more expensive than other types of resources.

The processing cost of parsing/compiling 170 KB of JavaScript vs decode time of an equivalently sized JPEG. (source).

While improvements are continually being made to improve the efficiency of JavaScript engines, improving JavaScript performance is—as always—a task for developers.

To that end, there are techniques to improve JavaScript performance. Code splitting, is one such technique that improves performance by partitioning application JavaScript into chunks, and serving those chunks to only the routes of an application that need them.

While this technique works, it doesn't address a common problem of JavaScript-heavy applications, which is the inclusion of code that's never used. Tree shaking attempts to solve this problem.

What is tree shaking? #

Tree shaking is a form of dead code elimination. The term was popularized by Rollup, but the concept of dead code elimination has existed for some time. The concept has also found purchase in webpack, which is demonstrated in this article by way of a sample app.

The term "tree shaking" comes from the mental model of your application and its dependencies as a tree-like structure. Each node in the tree represents a dependency that provides distinct functionality for your app. In modern apps, these dependencies are brought in via static import statements like so:

// Import all the array utilities!
import arrayUtils from "array-utils";

When an app is young—a sapling, if you will—it may have few dependencies. It's also using most—if not all—the dependencies you add. As your app matures, however, more dependencies can get added. To compound matters, older dependencies fall out of use, but may not get pruned from your codebase. The end result is that an app ends up shipping with a lot of unused JavaScript. Tree shaking addresses this by taking advantage of how static import statements pull in specific parts of ES6 modules:

// Import only some of the utilities!
import { unique, implode, explode } from "array-utils";

The difference between this import example and the previous one is that rather than importing everything from the "array-utils" module—which could be a lot of code)—this example imports only specific parts of it. In dev builds, this doesn't change anything, as the entire module gets imported regardless. In production builds, webpack can be configured to "shake" off exports from ES6 modules that weren't explicitly imported, making those production builds smaller. In this guide, you'll learn how to do just that!

Finding opportunities to shake a tree #

For illustrative purposes, a sample one-page app is available that demonstrates how tree shaking works. You can clone it and follow along if you like, but we'll cover every step of the way together in this guide, so cloning isn't necessary (unless hands-on learning is your thing).

The sample app is a searchable database of guitar effect pedals. You enter a query and a list of effect pedals will appear.

A screenshot of the sample app.

The behavior that drives this app is separated into vendor (i.e., Preact and Emotion) and app-specific code bundles (or "chunks", as webpack calls them):

The app's two JavaScript bundles. These are uncompressed sizes.

The JavaScript bundles shown in the figure above are production builds, meaning they're optimized through uglification. 21.1 KB for an app-specific bundle isn't bad, but it should be noted that no tree shaking is occurring whatsoever. Let's look at the app code and see what can be done to fix that.

In any application, finding tree shaking opportunities are going to involve looking for static import statements. Near the top of the main component file, you'll see a line like this:

import * as utils from "../../utils/utils";

You can import ES6 modules in a variety of ways, but ones like this should get your attention. This specific line says "import everything from the utils module, and put it in a namespace called utils." The big question to ask here is, "just how much stuff is in that module?"

If you look at the utils module source code, you'll find there's about 1,300 lines of code.

Do you need all that stuff? Let's double check by searching the main component file that imports the utils module to see how many instances of that namespace come up.

The utils namespace we've imported tons of modules from is only invoked three times within the main component file.

As it turns out, the utils namespace appears in only three spots in our application—but for what functions? If you take a look at the main component file again, it appears to be only one function, which is utils.simpleSort, which is used to sort the search results list by a number of criteria when the sorting dropdowns are changed:

if (this.state.sortBy === "model") {
  // `simpleSort` gets used here...
  json = utils.simpleSort(json, "model", this.state.sortOrder);
} else if (this.state.sortBy === "type") {
  // ..and here...
  json = utils.simpleSort(json, "type", this.state.sortOrder);
} else {
  // ..and here.
  json = utils.simpleSort(json, "manufacturer", this.state.sortOrder);
}

Out of a 1,300 line file with a bunch of exports, only one of them is used. This results in shipping a lot of unused JavaScript.

While this example app is admittedly a bit contrived, it doesn't change the fact that this synthetic sort of scenario resembles actual optimization opportunities you may encounter in a production web app. Now that you've identified an opportunity for tree shaking to be useful, how is it actually done?

Keeping Babel from transpiling ES6 modules to CommonJS modules #

Babel is an indispensable tool, but it may make the effects of tree shaking a bit more difficult to observe. If you're using @babel/preset-env, Babel may transform ES6 modules into more widely compatible CommonJS modules—that is, modules you require instead of import.

Because tree shaking is more difficult to do for CommonJS modules, webpack won't know what to prune from bundles if you decide to use them. The solution is to configure @babel/preset-env to explicitly leave ES6 modules alone. Wherever you configure Babel—be it in babel.config.js or package.json—this involves adding a little something extra:

// babel.config.js
export default {
  presets: [
    [
      "@babel/preset-env", {
        modules: false
      }
    ]
  ]
}

Specifying modules: false in your @babel/preset-env config gets Babel to behave as desired, which allows webpack to analyze your dependency tree and shake off unused dependencies.

Keeping side effects in mind #

Another aspect to consider when shaking dependencies from your app is whether your project's modules have side effects. An example of a side effect is when a function modifies something outside of its own scope, which is a side effect of its execution:

let fruits = ["apple", "orange", "pear"];

console.log(fruits); // (3) ["apple", "orange", "pear"]

const addFruit = function(fruit) {
  fruits.push(fruit);
};

addFruit("kiwi");

console.log(fruits); // (4) ["apple", "orange", "pear", "kiwi"]

In this example, addFruit produces a side effect when it modifies the fruits array, which is outside its scope.

Side effects also apply to ES6 modules, and that matters in the context of tree shaking. Modules that take predictable inputs and produce equally predictable outputs without modifying anything outside of their own scope are dependencies that can be safely dropped if we're not using them. They're self-contained, modular pieces of code. Hence, "modules".

Where webpack is concerned, a hint can be used to specify that a package and its dependencies are free of side effects by specifying "sideEffects": false in a project's package.json file:

{
  "name": "webpack-tree-shaking-example",
  "version": "1.0.0",
  "sideEffects": false
}

Alternatively, you can tell webpack which specific files are not side effect-free:

{
  "name": "webpack-tree-shaking-example",
  "version": "1.0.0",
  "sideEffects": [
    "./src/utils/utils.js"
  ]
}

In the latter example, any file that isn't specified will be assumed to be free of side effects. If you don't want to add this to your package.json file, you can also specify this flag in your webpack config via module.rules.

Importing only what's needed #

After instructing Babel to leave ES6 modules alone, a slight adjustment to our import syntax is required to bring in only the functions needed from the utils module. In this guide's example, all that's needed is the simpleSort function:

import { simpleSort } from "../../utils/utils";

Because only simpleSort is being imported instead of the entire utils module, every instance of utils.simpleSort will need to changed to simpleSort:

if (this.state.sortBy === "model") {
  json = simpleSort(json, "model", this.state.sortOrder);
} else if (this.state.sortBy === "type") {
  json = simpleSort(json, "type", this.state.sortOrder);
} else {
  json = simpleSort(json, "manufacturer", this.state.sortOrder);
}

This should be all that's needed for tree shaking to work in this example. This is the webpack output before shaking the dependency tree:

                 Asset      Size  Chunks             Chunk Names
js/vendors.16262743.js  37.1 KiB       0  [emitted]  vendors
   js/main.797ebb8b.js  20.8 KiB       1  [emitted]  main

This is the output after tree shaking is successful:

                 Asset      Size  Chunks             Chunk Names
js/vendors.45ce9b64.js  36.9 KiB       0  [emitted]  vendors
   js/main.559652be.js  8.46 KiB       1  [emitted]  main

While both bundles shrank, it's really the main bundle that benefits most. By shaking off the unused parts of the utils module, the main bundle shrinks by about 60%. This not only lowers the amount of time the script takes to the download, but processing time as well.

Go shake some trees! #

Whatever mileage you get out of tree shaking depends on your app and its dependencies and architecture. Try it! If you know for a fact you haven't set up your module bundler to perform this optimization, there's no harm trying and seeing how it benefits your application.

You may realize a significant performance gain from tree shaking, or not much at all. But by configuring your build system to take advantage of this optimization in production builds and selectively importing only what your application needs, you'll be proactively keeping your application bundles as small as possible.

Special thanks to Kristofer Baxter, Jason Miller, Addy Osmani, Jeff Posnick, Sam Saccone, and Philip Walton for their valuable feedback, which significantly improved the quality of this article.

Delivering Fast and Light Applications with Save-Data

2016-02-18T00:00:00Z

The Save-Data client hint request header available in Chrome, Opera, and Yandex browsers lets developers deliver lighter, faster applications to users who opt-in to data saving mode in their browser.

The need for lightweight pages #

Everyone agrees that faster and lighter web pages provide a more satisfying user experience, allow better content comprehension and retention, and deliver increased conversions and revenue. Google research has shown that "…optimized pages load four times faster than the original page and use 80% fewer bytes. Because these pages load so much faster, we also saw a 50% increase in traffic to these pages."

And, although the number of 2G connections is finally on the decline, 2G was still the dominant network technology in 2015. The penetration and availability of 3G and 4G networks is growing rapidly, but the associated ownership costs and network constraints are still a significant factor for hundreds of millions of users.

These are strong arguments for page optimization.

There are alternative methods for improving site speed without direct developer involvement, such as proxy browsers and transcoding services. Although such services are quite popular, they come with substantial drawbacks — simple (and sometimes unacceptable) image and text compression, inability to process secure (HTTPS) pages, only optimizing pages visited via a search result, and more. The very popularity of these services is itself an indicator that web developers are not properly addressing the high user demand for fast and light applications and pages. But reaching that goal is a complex and sometimes difficult path.

The `Save-Data` request header #

One fairly straightforward technique is to let the browser help, using the Save-Data request header. By identifying this header, a web page can customize and deliver an optimized user experience to cost- and performance-constrained users.

Supported browsers (below) allow the user to enable a *data saving- mode that gives the browser permission to apply a set of optimizations to reduce the amount of data required to render the page. When this feature is exposed, or advertised, the browser may request lower resolution images, defer loading of some resources, or route requests through a service that applies other content-specific optimizations such as image and text resource compression.

Browser support #

Chrome 49+ advertises Save-Data when the user enables the "Data Saver" option on mobile, or the "Data Saver" extension on desktop browsers.
Opera 35+ advertises Save-Data when the user enables "Opera Turbo" mode on desktop, or the "Data savings" option on Android browsers.
Yandex 16.2+ advertises Save-Data when Turbo mode is enabled on desktop or mobile browsers.

Detecting the `Save-Data` setting #

To determine when to deliver the "light" experience to your users, your application can check for the Save-Data client hint request header. This request header indicates the client's preference for reduced data usage due to high transfer costs, slow connection speeds, or other reasons.

When the user enables the data saving mode in their browser, the browser appends the Save-Data request header to all outgoing requests (both HTTP and HTTPS). As of this writing, the browser only advertises one *on- token in the header (Save-Data: on), but this may be extended in the future to indicate other user preferences.

Additionally, it's possible to detect if Save-Data is turned on in JavaScript:

if ('connection' in navigator) {
  if (navigator.connection.saveData === true) {
    // Implement data saving operations here.
  }
}

Checking for the presence of the connection object within the navigator object is vital, as it represents the Network Information API, which is only implemented in Chrome, Chrome for Android, and Samsung Internet browsers. From there, you only need to check if navigator.connection.saveData is equal to true, and you can implement any data saving operations in that condition.

Enabling the Data Saver extension in Chrome desktop.

If your application uses a service worker, it can inspect the request headers and apply relevant logic to optimize the experience. Alternatively, the server can look for the advertised preferences in the Save-Data request header and return an alternate response — different markup, smaller images and video, and so on.

Tip: If you use PageSpeed for Apache or Nginx to optimize your pages, see this discussion to learn how to enable Save-Data savings for your users._

Implementation tips and best practices #

When using Save-Data, provide some UI devices that support it and allow users to easily toggle between experiences. For example:
- Notify users that Save-Data is supported and encourage them to use it.
- Allow users to identify and choose the mode with appropriate prompts and intuitive on/off buttons or checkboxes.
- When data saving mode is selected, announce and provide an easy and obvious way to disable it and revert back to the full experience if desired.
Remember that lightweight applications are not lesser applications. They don't omit important functionality or data, they're just more cognizant of the involved costs and the user experience. For example:
- A photo gallery application may deliver lower resolution previews, or use a less code-heavy carousel mechanism.
- A search application may return fewer results at a time, limit the number of media-heavy results, or reduce the number of dependencies required to render the page.
- A news-oriented site may show fewer stories, omit less popular categories, or provide smaller media previews.
Provide server logic to check for the Save-Data request header and consider providing an alternate, lighter page response when it is enabled — e.g., reduce the number of required resources and dependencies, apply more aggressive resource compression, etc.
- If you're serving an alternate response based on the Save-Data header, remember to add it to the Vary list — Vary: Save-Data — to tell upstream caches that they should cache and serve this version only if the Save-Data request header is present. For more details, see the best practices for interaction with caches.
If you use a service worker, your application can detect when the data saving option is enabled by checking for the presence of the Save-Data request header, or by checking the value of the navigator.connection.saveData property. If enabled, consider whether you can rewrite the request to fetch fewer bytes, or use an already fetched response.
Consider augmenting Save-Data with other signals, such as information about the user's connection type and technology (see NetInfo API). For example, you might want to serve the lightweight experience to any user on a 2G connection even if Save-Data is not enabled. Conversely, just because the user is on a "fast" 4G connection doesn't mean they aren't interested in saving data — for example, when roaming. Additionally, you could augment the presence of Save-Data with the Device-Memory client hint to further adapt to users on devices with limited memory. User device memory is also advertised in the navigator.deviceMemory client hint.

Recipes #

What you can achieve via Save-Data is limited only to what you can come up with. To give you an idea of what's possible, let's run through a couple of use cases. You may come up with other use cases of your own as you read this, so feel free to experiment and see what's possible!

Checking for `Save-Data` in server side code #

While the Save-Data state is something you can detect in JavaScript via the navigator.connection.saveData property, detecting it on the server side is sometimes preferable. JavaScript can fail to execute in some cases. Plus, server side detection is the only way to modify markup before it's sent to the client, which is involved in some of Save-Datas most beneficial use cases.

The specific syntax for detecting the Save-Data header in server side code depends on the language used, but the basic idea should be the same for any application back end. In PHP, for example, request headers are stored in the $_SERVER superglobal array at indexes starting with HTTP_. This means you can detect the Save-Data header by checking the existence and value of the $_SERVER["HTTP_SAVE_DATA"] variable like so:

// false by default.
$saveData = false;

// Check if the `Save-Data` header exists and is set to a value of "on".
if (isset($_SERVER["HTTP_SAVE_DATA"]) && strtolower($_SERVER["HTTP_SAVE_DATA"]) === "on") {
  // `Save-Data` detected!
  $saveData = true;
}

If you place this check before any markup is sent to the client, the $saveData variable will contain the Save-Data state, and will be available anywhere for use on the page. With this mechanism illustrated, let's look a few examples of how we can use it to limit how much data we send to the user.

Serve low resolution images for high resolution screens #

A common use case for images on the web involves serving images in sets of two: One image for "standard" screens (1x), and another image that's twice as large (2x) for high resolution screens (e.g., Retina Display). This class of high resolution screens is not necessarily limited to high end devices, and is becoming increasingly common. In cases where a lighter application experience is preferred, it might be prudent to send lower resolution (1x) images to these screens, rather than larger (2x) variants. To achieve this when the Save-Data header is present, we simply modify the markup we send to the client:

if ($saveData === true) {
  // Send a low-resolution version of the image for clients specifying `Save-Data`.
  ?><img src="butterfly-1x.jpg" alt="A butterfly perched on a flower."><?php
}
else {
  // Send the usual assets for everyone else.
  ?><img src="butterfly-1x.jpg" srcset="butterfly-2x.jpg 2x, butterfly-1x.jpg 1x" alt="A butterfly perched on a flower."><?php
}

This use case is a perfect example of how little effort it takes to accommodate someone who is specifically asking you to send them less data. If you don't like modifying markup on the back end, you could also achieve the same result by using a URL rewrite module such as Apache's mod_rewrite. There are examples of how to achieve this with relatively little configuration.

You could also extend this concept to CSS background-image properties by simply adding a class to the <html> element:

<html class="<?php if ($saveData === true): ?>save-data<?php endif; ?>">

From here, you can target the save-data class on the <html> element in your CSS to change how images are delivered. You could send low resolution background images to high resolution screens as shown in the above HTML example, or omit certain resources altogether.

Omit non-essential imagery #

Some image content on the web is simply non-essential. While such imagery can make for nice asides to content, they may not be desirable by those trying to squeeze all they can out of metered data plans. In what is perhaps the simplest use case of Save-Data, we can use the PHP detection code from earlier and omit non-essential image markup altogether:

<p>This paragraph is essential content. The image below may be humorous, but it's not critical to the content.</p>
<?php
if ($saveData === false) {
  // Only send this image if `Save-Data` hasn't been detected.
  ?><img src="meme.jpg" alt="One does not simply consume data."><?php
}

This technique can certainly have a pronounced effect, as you can see in the figure below:

A comparison of non-critical imagery being loaded when Save-Data is absent, versus that same imagery being omitted when Save-Data is present.

Of course, omitting images isn't the only possibility. You can also act on Save-Data to forego sending other non-critical resources, such as certain typefaces.

Omit non-essential web fonts #

While web fonts don't usually make up nearly as much of a given page's total payload as images often do, they're still quite popular. They don't consume an insignificant amount of data, either. Furthermore, the way browsers fetch and render fonts is more complicated than you might think, with concepts such as FOIT, FOUT, and browser heuristics making rendering a nuanced operation.

It might stand to reason then that you might want to leave out non-essential web fonts for users who want leaner user experiences. Save-Data makes this a reasonably painless thing to do.

For example, let's say you've included Fira Sans from Google Fonts on your site. Fira Sans is an excellent body copy font, but maybe it isn't so crucial to users trying to save data. By adding a class of save-data to the <html> element when the Save-Data header is present, we can write styles that invoke the non-essential typeface at first, but then opts out of it when the Save-Data header is present:

/* Opt into web fonts by default. */
p,
li {
  font-family: 'Fira Sans', 'Arial', sans-serif;
}

/* Opt out of web fonts if the `save-Data` class is present. */
.save-data p,
.save-data li {
  font-family: 'Arial', sans-serif;
}

Using this approach, you can leave the <link> snippet from Google Fonts in place, because the browser speculatively loads CSS resources (including web fonts) by first applying styles to the DOM, and then checking if any HTML elements invoke any of the resources in the style sheet. If someone happens by with Save-Data on, Fira Sans will never load because the styled DOM never invokes it. Arial will kick in, instead. It's not as nice as as Fira Sans, but it may be preferable to those users trying to stretch their data plans.

Opting out of server pushes #

HTTP/2 server push is often the most touted feature of HTTP/2. While it can boost performance, it can potentially be problematic due to caching "gotchas".

If you're comfortable using server push and understand its current, quirky way of interacting with the browser cache, then great. But you may want to consider disabling it altogether if the Save-Data header is present.

Many HTTP/2 implementations kick off a server push for a resource when a Link response header invoking rel=preload is set. This leads to some confusion as to whether rel=preload and server push are one and the same, but they're two distinct things. rel=preload is a resource hint, and server push is part of HTTP/2. It just so happens the Link header kicks off a server push in a number of HTTP/2 implementations.

The specification for rel=preload addresses this potential pain point by offering a nopush keyword to be used in Link HTTP response headers. Using the back end detection logic outlined earlier, you could append nopush if Save-Data is present:

// `preload` like usual…
$preload = "</css/styles.css>; rel=preload; as=style";

if($saveData === true) {
  // …but don't push anything if `Save-Data` is detected!
  $preload .= "; nopush";
}

header("Link: " . $preload);

There are other ways to achieve this, some more more nuanced than others, but the idea is the same: HTTP/2 server push is turned off when Save-Data is present.

As you can see, there's a lot that can be accomplished with Save-Data. These are just a couple simple use cases to get you going, so feel free to experiment and see what novel use cases you can come up with!

Summary #

The Save-Data header does not have much nuance; it is either on or off, and the application bears the burden of providing appropriate experiences based on its setting, regardless of the reason.

For example, some users might not allow data saving mode if they suspect there will be a loss of app content or function, even in a poor connectivity situation. Conversely, some users might enable it as a matter of course to keep pages as small and simple as possible, even in a good connectivity situation. It's best for your app to assume that the user wants the full and unlimited experience until you have a clear indication otherwise via an explicit user action.

As site owners and web developers, let's take on the responsibility of managing our content to improve the user experience for data- and cost-constrained users.

For more detail on Save-Data and excellent practical examples, see Help Your Users Save Data.

Avoid large, complex layouts and layout thrashing

2015-03-20T00:00:00Z

Layout is where the browser figures out the geometric information for elements: their size and location in the page. Each element will have explicit or implicit sizing information based on the CSS that was used, the contents of the element, or a parent element. The process is called Layout in Chrome (and derived browsers such as Edge), and Safari. In Firefox it's called Reflow, but the process is effectively the same.

Similarly to style calculations, the immediate concerns for layout cost are:

The number of elements that require layout, which is a byproduct of the page's DOM size.
The complexity of those layouts.

Summary #

Layout has a direct effect on interaction latency
Layout is normally scoped to the whole document.
The number of DOM elements will affect performance; you should avoid triggering layout wherever possible.
Avoid forced synchronous layouts and layout thrashing; read style values then make style changes.

The effects of layout on interaction latency #

When a user interacts with the page, those interactions should be as fast as possible. The amount of time it takes for an interaction to complete—ending when the browser presents the next frame to show the results of the interaction—is known as interaction latency. This is an aspect of page performance that the Interaction to Next Paint metric measures.

The amount of time it takes for the browser to present the next frame in response to a user interaction is known as the interaction's presentation delay. The goal of an interaction is to provide visual feedback in order to signal to the user that something has occurred, and visual updates can involve some amount of layout work in order to achieve that goal.

In order to keep your website's INP as low as possible, it's important to avoid layout when possible. If it's not possible to avoid layout entirely, it's important to limit that layout work so that the browser can present the next frame quickly.

Avoid layout wherever possible #

When you change styles the browser checks to see if any of the changes require layout to be calculated, and for that render tree to be updated. Changes to "geometric properties", such as widths, heights, left, or top all require layout.

.box {
  width: 20px;
  height: 20px;
}

/**
  * Changing width and height
  * triggers layout.
  */

.box--expanded {
  width: 200px;
  height: 350px;
}

Layout is almost always scoped to the entire document. If you have a lot of elements, it's going to take a long time to figure out the locations and dimensions of them all.

If it's not possible to avoid layout then the key is to once again use Chrome DevTools to see how long it's taking, and determine if layout is the cause of a bottleneck. Firstly, open DevTools, go to the Timeline tab, hit record and interact with your site. When you stop recording you'll see a breakdown of how your site performed:

When digging into the trace in the above example, we see that over 28 milliseconds is spent inside layout for each frame, which, when we have 16 milliseconds to get a frame on screen in an animation, is far too high. You can also see that DevTools will tell you the tree size (1,618 elements in this case), and how many nodes were in need of layout (5 in this case).

Keep in mind that the general advice here is to avoid layout whenever possible—but it isn't always possible to avoid layout. In cases where you can't avoid layout, know that the cost of layout has a relationship with the size of the DOM. Although the relationship between the two isn't tightly coupled, larger DOMs will generally incur higher layout costs.

Avoid forced synchronous layouts #

Shipping a frame to screen has this order:

First the JavaScript runs, then style calculations, then layout. It is, however, possible to force a browser to perform layout earlier with JavaScript. This is called forced synchronous layout.

The first thing to keep in mind is that as the JavaScript runs all the old layout values from the previous frame are known and available for you to query. So if, for example, you want to write out the height of an element (let's call it "box") at the start of the frame you may write some code like this:

// Schedule our function to run at the start of the frame:
requestAnimationFrame(logBoxHeight);

function logBoxHeight () {
  // Gets the height of the box in pixels and logs it out:
  console.log(box.offsetHeight);
}

Things get problematic if you've changed the styles of the box before you ask for its height:

function logBoxHeight () {
  box.classList.add('super-big');

  // Gets the height of the box in pixels and logs it out:
  console.log(box.offsetHeight);
}

Now, in order to answer the height question, the browser must first apply the style change (because of adding the super-big class), and then run layout. Only then will it be able to return the correct height. This is unnecessary and potentially expensive work.

Because of this, you should always batch your style reads and do them first (where the browser can use the previous frame's layout values) and then do any writes:

Done correctly the above function would be:

function logBoxHeight () {
  // Gets the height of the box in pixels and logs it out:
  console.log(box.offsetHeight);

  box.classList.add('super-big');
}

For the most part you shouldn't need to apply styles and then query values; using the last frame's values should be sufficient. Running the style calculations and layout synchronously and earlier than the browser would like are potential bottlenecks, and not something you will typically want to do.

Avoid layout thrashing #

There's a way to make forced synchronous layouts even worse: do lots of them in quick succession. Take a look at this code:

function resizeAllParagraphsToMatchBlockWidth () {
  // Puts the browser into a read-write-read-write cycle.
  for (let i = 0; i < paragraphs.length; i++) {
    paragraphs[i].style.width = `${box.offsetWidth}px`;
  }
}

This code loops over a group of paragraphs and sets each paragraph's width to match the width of an element called "box". It looks harmless enough, but the problem is that each iteration of the loop reads a style value (box.offsetWidth) and then immediately uses it to update the width of a paragraph (paragraphs[i].style.width). On the next iteration of the loop, the browser has to account for the fact that styles have changed since offsetWidth was last requested (in the previous iteration), and so it must apply the style changes, and run layout. This will happen on every single iteration!.

The fix for this sample is to once again read and then write values:

// Read.
const width = box.offsetWidth;

function resizeAllParagraphsToMatchBlockWidth () {
  for (let i = 0; i < paragraphs.length; i++) {
    // Now write.
    paragraphs[i].style.width = `${width}px`;
  }
}

If you want to guarantee safety, consider using FastDOM, which automatically batches your reads and writes for you, and should prevent you from triggering forced synchronous layouts or layout thrashing accidentally.

Hero image from Unsplash, by Hal Gatewood.

Reduce the scope and complexity of style calculations

2015-03-20T00:00:00Z

Changing the DOM, through adding and removing elements, changing attributes, classes, or through animation, will all cause the browser to recalculate element styles and, in many cases, layout (or reflow) the page, or parts of it. This process is called computed style calculation.

The first part of computing styles is to create a set of matching selectors, which is essentially the browser figuring out which classes, pseudo-selectors, and IDs apply to any given element.

The second part of the process involves taking all the style rules from the matching selectors and figuring out what final styles the element has.

Summary #

How reducing style calculation costs can lower interaction latency.
Reduce the complexity of your selectors; use a class-centric methodology (BEM, for example).
Reduce the number of elements on which style calculation must be calculated.

Style recalculation time and interaction latency #

The Interaction to Next Paint (INP) is a user-centric runtime performance metric that assesses a page's overall responsiveness to user input. When interaction latency is assessed by this metric, it measures the time starting from when the user interacts with the page, up until the browser paints the next frame showing the corresponding visual updates made to the user interface.

A significant component of an interaction is the time it takes to paint the next frame. Rendering work done to present the next frame is made up of many parts, including calculation of page styles that occur just prior to layout, paint, and compositing work. While this article focuses solely on style calculation costs, it's important to emphasize that reducing any part of the rendering phase inherent to interaction will reduce its total latency—style calculation included.

Reduce the complexity of your selectors #

In the simplest case, you can reference an element in your CSS with just a class:

.title {
  /* styles */
}

But, as any project grows, it will likely result in more complex CSS, such that you may end up with selectors that look like this:

.box:nth-last-child(-n+1) .title {
  /* styles */
}

In order to know how these styles apply to the page, the browser has to effectively ask "is this an element with a class of title which has a parent who happens to be the minus nth child plus 1 element with a class of box?" Figuring this out can take a lot of time, depending on the selector used as well as the browser in question. The intended behavior of the selector could instead be changed to a class:

.final-box-title {
  /* styles */
}

You can take issue with the name of the class, but the job just got a lot simpler for the browser. In the previous version, in order to know, for example, that the element is the last of its type, the browser must first know everything about all the other elements and whether the are any elements that come after it that would be the nth-last-child, which is potentially more expensive than simply matching up the selector to the element because its class matches.

Reduce the number of elements being styled #

Another performance consideration—which is typically the more important factor for many style updates—is the sheer volume of work that needs to be carried out when an element changes.

In general terms, the worst case cost of calculating the computed style of elements is the number of elements multiplied by the selector count, because each element needs to be at least checked once against every style to see if it matches.

Style calculations can often be targeted to a few elements directly rather than invalidating the page as a whole. In modern browsers, this tends to be less of an issue because the browser doesn't necessarily need to check all the elements potentially affected by a change. Older browsers, on the other hand, aren't necessarily as optimized for such tasks. Where you can, you should reduce the number of invalidated elements.

Measure your style recalculation cost #

One way to measure the cost of style recalculations is to use the performance panel in Chrome DevTools. To begin, open DevTools, go to the tab labeled Performance, hit record, and interact with the page. When you stop recording, you'll see something like the image below:

The strip at the top is a miniature flame chart that also plots frames per second. The closer the activity is to the bottom of the strip, the faster frames are being painted by the browser. If you see the flame chart leveling out at the top with red strips above it, then you have work that's causing long running frames.

If you have a long running frame during an interaction like scrolling, then it bears further scrutiny. If you have a large purple block, zoom in on the activity and select any work labeled Recalculate Style to get more information on potentially expensive style recalculation work.

In this grab there is long-running style recalculation work that is taking just over 25ms.

If you click the event itself, you are given a call stack. If the rendering work was due to a user interaction, the place in your JavaScript that is responsible for triggering the style change will be called out. In addition to that, you also get the number of elements that have been affected by the change—just over 900 elements in this case—and how long it took to do the style calculation work. You can use this information to start trying to find a fix in your code.

Use Block, Element, Modifier #

Approaches to coding like BEM (Block, Element, Modifier) actually bake in the selector matching performance benefits above, because it recommends that everything has a single class, and, where you need hierarchy, that gets baked into the name of the class as well:

.list {
  /* Styles */
}

.list__list-item {
  /* Styles */
}

If you need some modifier, like in the above where we want to do something special for the last child, you can add that like so:

.list__list-item--last-child {
  /* Styles */
}

If you're looking for a good way to organize your CSS, BEM is a good starting point, both from a structure point-of-view, and also because of the simplifications of style lookup the methodology promotes.

If you don't like BEM, there are other ways to approach your CSS, but the performance considerations should be assessed alongside the ergonomics of the approach.

Resources #

Hero image from Unsplash, by Markus Spiske.

Eliminate unnecessary downloads

2014-03-31T00:00:00Z

The fastest and best-optimized resource is a resource not sent. You should eliminate unnecessary resources from your application. It's a good practice to question—and periodically revisit—the implicit and explicit assumptions with your team. Here are a few examples:

You've always included resource X on your pages, but does the cost of downloading and displaying it offset the value it delivers to the user? Can you measure and prove its value?
Does the resource (especially if it's a third-party resource) deliver consistent performance? Is this resource in the critical path, or need to be? If the resource is in the critical path, could it be a single point of failure for the site? That is, if the resource is unavailable, does it affect performance and the user experience of your pages?
Does this resource need or have an SLA? Does this resource follow performance best practices: compression, caching, and so on?

Too often, pages contain resources that are unnecessary, or worse, that hinder page performance without delivering much value to the visitor or to the site they're hosted on. This applies equally to first-party and third-party resources and widgets:

Site A has decided to display a photo carousel on its homepage to allow the visitor to preview multiple photos with a quick click. All of the photos are loaded when the page is loaded, and the user advances through the photos.
- Question: Have you measured how many users view multiple photos in the carousel? You might be incurring high overhead by downloading resources that most visitors never view.
Site B has decided to install a third-party widget to display related content, improve social engagement, or provide some other service.
- Question: Have you tracked how many visitors use the widget or click-through on the content that the widget provides? Is the engagement that this widget generates enough to justify its overhead? Furthermore, is it feasible for you to use a loading strategy to ensure the script isn't loaded until it's needed?

Determining whether to eliminate unnecessary downloads often requires a lot of careful thinking and measurement. For best results, periodically inventory and revisit these questions for every asset on your pages.

Effects on Core Web Vitals #

The Core Web Vitals initative was introduced by Google to provide a set of metrics that reflect what users are experiencing as they use the web. While there are many optimization strategies for Core Web Vitals, questioning whether to load a particular resource on a page may light a path for you to improve these metrics on your website. Below are a few examples—grouped by each Core Web Vital—that are worth your consideration. Though this isn't an exhaustive list of examples (and there are many!), reading them over may give you food for thought.

Largest Contentful Paint (LCP) #

Largest Contentful Paint (LCP) measures when the largest content (for example a hero image, or a headline) is loaded. It's considered an important perceptual metric that gives the user the impression that a site is loading quickly.

In general, downloading less resources means that the bandwidth the user does have will be allocated across less resources, and may translate to an improvement in LCP. A classic example is that of lazy loading, where images outside of the viewport during page load will not be downloaded until the browser has determined the user is more likely to see them. If you have a large thumbnail gallery of, say, 50 images, lazy loading all but the top ten of them means that the browser can make more efficient use of the bandwidth available to it, and the first images the user will see will load more quickly.

However, it's not just about loading less images, necessarily. The browser has an internal prioritization scheme that determines how much bandwidth each resource should receive. However, even with this all resources—particularly those downloaded at high priority—have the potential to deprive a potential LCP element's dependent resource. This is especially true on slow network connections. That dependent resource may be an image file that represents the page's LCP element, but it could also very well be a web font resource that the browser needs to render a text node that may be determined as the page's LCP element.

If your website is heavy on text, it may be the case that a page's LCP element is a text node. While there are many good font optimization and loading strategies, it may be worth considering whether a system font is sufficient for your website's needs, so that LCP elements which are text nodes can load without a dependency on a web font resource and paint almost immediately as the CSS and HTML arrives from the server.

Cumulative Layout Shift (CLS) #

Every resource you load has the potential to contribute to a page's Cumulative Layout Shift (CLS), particularly if has not finished downloading by the time of the initial paint. For images, avoid CLS involves practices such as setting explicit dimensions. For fonts, managing font loading and potentially fallback font matching can minimize shifts during a web font's swap period. For JavaScript, it could be managing how that script manipulates the DOM so that layout shifts are reduced to an acceptable amount.

Every resource that contributes to a page's CLS requires some amount of work to ensure page layout is sufficiently stable. By questioning whether or not you need a specific resource, you're not just speeding up page loads, you're also reducing the cognitive effort necessary to preserve layout stability. That leads to not only a much less frustrating user experience, but a less frustrating developer experience, as you'll have more time to pursue other goals in your projects.

Interaction to Next Paint (INP) and First Input Delay (FID) #

Interaction to Next Paint (INP) and First Input Delay (FID) are metrics that measure responsiveness to user inputs. While INP is slated to replace FID as a Core Web Vital in March of 2024, optimization strategies for FID tend to also apply to INP. Furthermore, INP is generally more difficult to optimize for than FID, as it tracks the full interaction latency for all page interactions, not just the input delay of the first interaction as FID measures.

INP and FID tend to be most affected by JavaScript, as JavaScript is what drives most of the interactivity one experiences across the web. For both INP and FID, the amount of script resources downloaded during page load will kick off potentially expensive work involved in script evaluation and compilation. The less JavaScript you load during startup, the less work the browser has to do at that critical point in the page experience.

While there are strategies for reducing the size of JavaScript resources downloaded during startup—such as code splitting and tree shaking—it's worth auditing the packages you use in your projects to see if they're necessary at all. For example, lodash has many methods that are still useful today, but ships with methods that the browser provides out of the box, such as Array-specific functions for mapping, reducing, and filtering, and many others.

Progressive enhancement is also a useful approach to JavaScript, as it enables you to serve a baseline (but still functional) experience for users that you can add to for users with more powerful devices and faster network connections. Whether you adhere to the principle of progressive enhancement or not, the point remains: Every JavaScript resource you can avoid downloading can result in an experience that responds faster to user interactions, which is a vital aspect of web performance.

Conclusion #

Auditing your website for unnecessary downloads may be just one aspect of delivering fast user experiences, but it's one that has the potential for high impact. To recap:

Inventory your own assets and third-party assets on your pages.
Measure the performance of each asset: its value and its technical performance.
Determine if the resources are providing sufficient value.
Understand the effect of unnecessary downloads on Core Web Vitals and supporting metrics.

By optimizing content efficiency in this way, you're not only improving performance overall, you're also taking care not to waste users' bandwidth, as well as potentially improving user-centric metrics and delivering a better user experience.

Jeremy Wagner on web.dev

Client-side rendering of HTML and interactivity

How the browser renders HTML provided by the server #

How the browser renders HTML provided by JavaScript #

What you can do about the performance impact of client-side rendering #

Provide as much HTML from the server as possible #

Limit the amount of DOM nodes created on the client #

Consider a streaming service worker architecture #

Conclusion #

Diagnose slow interactions in the lab

What if you don't have field data? #

Reproducing slow interactions in the lab #

Don't reach for the performance profiler right away #

Use the Web Vitals Chrome Extension #

Use a JavaScript snippet #

What if you can't reproduce a slow interaction? #

Record a trace #

Use Lighthouse timespans as an alternative to tracing #

How to identify long input delays #

How to identify expensive event callbacks #

How to identify presentation delays #

Troubleshooting INP is an iterative process #

How large DOM sizes affect interactivity, and what you can do about it

When is a page's DOM too large? #

How do large DOMs affect page performance? #

How do I measure DOM size? #

How can I measure the number of DOM elements affected by an interaction? #

How can I reduce DOM size? #

Other strategies to consider #

Consider an additive approach #

Limit CSS selector complexity #

Use the content-visibility property #

Conclusion #

Find slow interactions in the field

What you should collect in the field and why #

Measure interactions in the field with the web-vitals JavaScript library #

Monitor full session duration, not just up to onload #

Get field data quickly with CrUX #

What if I don't have field data? #

Conclusion #

Optimize input delay

What is input delay? #

How to think about input delay #

How to minimize input delay #

Avoid recurring timers that kick off excessive main thread work #

Avoid long tasks #

Be mindful of interaction overlap #

Conclusion #

Script evaluation and long tasks

What is script evaluation? #

The relationship between scripts and the tasks that evaluate them #

Loading scripts with the <script> element #

Loading scripts with the <script> element and the type=module attribute #

Chromium-based browsers #

Safari and Firefox #

Loading scripts with dynamic import() #

Loading scripts in a web worker #

Trade-offs and considerations #

Compression efficiency #

Cache invalidation #

Nested modules and loading performance #

Conclusion #

Optimize Time to First Byte

How to Measure TTFB #

Understanding high TTFB with Server-Timing #

Ways to optimize TTFB #

Platform-specific guidance #

Hosting, hosting, hosting #

Use a Content Delivery Network (CDN) #

Used cached content where possible #

Avoid multiple page redirects #

Stream markup to the browser #

Use a service worker #

Use 103 Early Hints for render-critical resources #

Conclusion #

Our top Core Web Vitals recommendations for 2023

Largest Contentful Paint (LCP) #

Ensure the LCP resource is discoverable from the HTML source #

Ensure the LCP resource is prioritized #

Use a CDN to optimize document and resource TTFB #

Use the `content-visibility` property #

Measure interactions in the field with the `web-vitals` JavaScript library #

Monitor full session duration, not just up to `onload` #

Loading scripts with the `<script>` element #

Loading scripts with the `<script>` element and the `type=module` attribute #

Loading scripts with dynamic `import()` #

Understanding high TTFB with `Server-Timing` #

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

Use `content-visibility` to lazily render off-screen elements #

Use `async`/`await` to create yield points #

Built-in yield with continuation via `scheduler.yield` #

Injected `async` scripts #