Addy Osmani on web.dev

Building a Better Web - Part 1: A faster YouTube on web

2022-10-20T00:00:00Z

The Chrome team often talks about "building a better web", but what does that mean? Web experiences should be fast, accessible, and use device capabilities in the moment when users need it most. Dogfooding is part of Google's culture, so the Chrome team has partnered with YouTube to share lessons learned along the way in a new series called, "Building a better web". The first part of the series will dive into how YouTube built a faster web experience.

The YouTube for mobile web Watch page passing the Core Web Vitals thresholds.

Building a faster web #

At YouTube, performance relates to how fast videos and other content—such as recommendations and comments—load on web pages. Performance is also measured by how quickly YouTube responds to user interactions such as search, player control, likes, and shares.

Growing developing markets, such as Brazil, India, and Indonesia are important for YouTube mobile web. Because many users in these regions have slower devices and limited network bandwidth, ensuring a fast and seamless experience is a critical goal.

To provide an inclusive experience for all users, YouTube set out to improve performance metrics such as Core Web Vitals through lazy-loading and code modernization.

Improving Core Web Vitals #

To identify areas of improvement, the YouTube team used the Chrome User Experience Report (CrUX) to see how real users were experiencing video watch and search result pages on mobile in the field. They realized their Core Web Vitals metrics had a lot of room for improvement, with their Largest Contentful Paint (LCP) metric clocking in at 4-6 seconds in some cases. This was substantially higher than their target of 2.5 seconds.

To identify areas for improvement, they turned to Lighthouse to audit the YouTube watch pages, revealing a low Lighthouse (lab) score with a First Contentful Paint (FCP) of 3.5 seconds and a LCP of 8.5 seconds.

Chrome sets a target of 1.8s for FCP and 2.5s for LCP as a gold standard. The FCP and LCP were clearly in the yellow and red at 3.5s and 8.5s, respectively.

To optimize FCP and LCP, the YouTube team dove into several experiments, resulting in two big discoveries.

The first discovery was that they could improve performance by moving the HTML for the Video Player above the script that makes the Video Player interactive. Lab tests indicated that this could improve both FCP and LCP from 4.4 seconds to 1.1 seconds.
The second discovery was that LCP only considers <video> element poster images and not frames from the video stream itself. YouTube has traditionally optimized for the fastest time until the video starts playing, so to improve LCP the team started also optimizing how quickly they could deliver their poster image. They experimented with a few variations of poster images and picked the one that scored the best in user testing. As a result of this work, both FCP and LCP showed marked improvement, with field LCP improving from 4.6 seconds to 2.0 seconds.

In the lab, we observed an improvement in FCP and LCP from 4.4s to 1.1s after this change landed. Experiment A: Using the actual video thumbnail works well on pages where the video starts out paused, but for auto-play video pages like the watch page it performed poorly in user studies. It also resulted in a drop in active users. Experiment B: Using a solid black poster image showed the best results in user studies. Users found the transition from solid black to the first frame of the video to be a less-jarring experience for autoplay videos.

Black thumbnail was deployed in production for all mobile web users July 2021 showing marked improvement in FCP and LCP, as seen in the above RUM analysis.

While bringing these optimizations to all platforms, YouTube also took advantage of the new fetchpriority attribute, which we use with <link rel=preload> to prioritize discovering and loading the poster image early:

<link as="image" rel="preload" href="poster.jpg" fetchpriority="high">

While these optimizations did improve LCP, the team felt that the current definition of the LCP metric wasn't fully capturing, from the user's perspective, when the "main content" of the page had loaded—which is the goal of LCP.

To address these concerns, members of the YouTube team partnered with members of the Chrome team to explore ways that the LCP metric could be improved to address their use case. After considering the feasibility and impact of a few options, the teams landed on a proposal to consider the paint time of the first frame of a video element as an LCP candidate.

Once this change lands in Chrome, the YouTube team is excited to continue their work optimizing for LCP. And the updated version of the metric will mean these optimizations will have a more direct impact on real-user experiences.

Modularization with lazy loading #

YouTube pages contained many modules that were eagerly loaded. To optimize how 50+ components were rendered, the team built a component to JS module map that would tell the client which modules to load. By marking components as lazy, the JS modules would load later, reducing the initial load time of the page and the amount of unused Javascript sent to the client.

However, after lazy loading was implemented, the team noticed a waterfall effect that lazy loaded components and their dependencies would load at suboptimal times.

To solve this problem, the team determined the minimal set of components needed in a view and batched them in a single network request. The results were improved page speed, reduced JavaScript parse time, and, ultimately, better initial rendering times.

State-management across components #

YouTube was experiencing performance issues due to its player controls, especially on older devices. Code analysis showed that the player, which allows users to control features such as playback speed and progress, had become over-componentized over time.

The YouTube video player allows users to control playback speed, follow progress, skip sections, and others. When a user taps on a particular control, the change in the state must be communicated to other controls e.g. a user tap on the progress bar must be shared to controls such as play-head, subtitles etc.

Each progress bar touch-move event triggered two extra style recalculations and took 21.17 ms during performance test runs in the lab. As new controls were added over time, the pattern of decentralized control would often cause circular dependencies and memory leaks, negatively impacting watch page performance.

Chrome DevTools with a 4 times CPU slow-down performance run.

To fix the issues due to decentralized control, the team updated the player UI to synchronize all updates, essentially refactoring the player to one top-level component that would pass down data to its children. This ensured only one UI update (render) cycle for any state change, eliminating chained updates. The new player progress bar touch-move event has no style recalculations during its JavaScript execution and now only requires 25% the time of the old player.

This code modernization also resulted in additional performance improvements such as improved watch load times on old devices, fewer abandoned playbacks, and a reduced number of non-fatal errors.

Conclusion #

As a result of YouTube's investment in performance, watch pages load much faster with 76% of YouTube's mobile website URLs now passing Core Web Vitals metric thresholds in the field. On desktop, lab LCP for the watch page was reduced from approximately 4.6 seconds to 1.6 seconds. Interaction and rendering performance of the site, especially on the YouTube video player, are seeing up to 75% less time spent in JavaScript execution than before.

Improvements to the performance of YouTube web over the last year have also improved business metrics, including watch time and daily active users. Based on the success of these efforts, we plan to continue exploring even more ways to optimize in the future.

In part two of this series, "Building an accessible web", you’ll read how YouTube made their website more accessible for screen-reader users.

With special thanks to Gilberto Cocchi, Lauren Usui, Benji Bear, Bo Aye, Bogdan Balas, Kenny Tran, Matthew Smith, Phil Harnish, Leena Sahoni, Jeremy Wagner, Philip Walton, Harleen Batra and both the YouTube and Chrome teams for their contributions to this work.

What's new in PageSpeed Insights

2021-11-03T00:00:00Z

Over the years, PageSpeed Insights (PSI) has evolved into a one-stop source for both field and lab data. It integrates information from the Chrome UX Report (CrUX) and Lighthouse diagnostics to provide insights that help improve the performance of your website.

Today, we are excited to announce an updated version of PSI! While it is a critical element in our speed tooling suite, the PSI code base was ten years old, contained a lot of legacy code, and was due for a redesign. We used this as an opportunity to address interface-related issues in PSI which have sometimes made it difficult for users to navigate the report. Our primary goals were to:

Make the UI more intuitive by clearly differentiating between data derived from a synthetic environment and data collected from users in the field.
Clearly communicate how the Core Web Vitals assessment is calculated in the UI.
Modernize the look and feel of PSI, leveraging Material Design.

This post introduces the new features in PSI which will be released later this year.

What's new? #

The PSI UI redesign aims to improve the presentation of the report data and add clarity and granularity to the data available in the report. The new UI is aimed to be more intuitive and helps developers quickly discover lab and field performance insights for their pages. The fundamental changes to the UI include:

Clear separation of field and lab data #

We have changed the UI to distinctly separate field data from lab data. Labels for "Field Data" and "Lab data" have been replaced with text that indicates what the data means and how it can help. We have also brought the Field data section to the top. The traditional lab-based performance score, which is currently shown at the top, has been moved down to the Lab data section to avoid ambiguity about the origin of the score.

Section for field data

Section for lab data

Core Web Vitals assessment #

The Core Web Vitals assessment result, which earlier appeared as a single word "passed" or "failed" in Field Data, now stands out as a separate subsection with a distinct icon.

Note that there is no change in the assessment process for Core Web Vitals. The Core Web Vitals metrics FID, LCP, and CLS, may be aggregated at either the page or origin level. For aggregations with sufficient data in all three metrics, the aggregation passes the Core Web Vitals assessment if the 75th percentiles of all three metrics are Good. Otherwise, the aggregation does not pass the assessment. If the aggregation has insufficient FID data, it will pass the assessment if both the 75th percentiles of LCP and CLS are Good. If either LCP or CLS has insufficient data, the page or origin-level aggregation cannot be assessed.

Labels for mobile and desktop performance #

We changed the navigation menu at the top and included links for mobile and desktop centrally on the report page. The links are now easily visible and distinctly indicate the platform for which the data is being shown. Doing this also helped make the navigation bar cleaner.

PSI mobile and desktop labels before

PSI mobile and desktop labels after

Origin Summary #

The Origin Summary, which provides the aggregated CrUX score for all pages from the origin, currently appears on click of a checkbox. We have moved this report section to a new tab, "Origin", under the Field Data section.

Additional helpful information #

The report now includes a new information section at the bottom of each field and lab card sharing the following details about the sampled data:

Data collection period
Visit durations
Devices
Network connections
Sample size
Chrome versions

This information should enhance the distinction between lab and field data and help users who have previously been uncertain how the two data sources (lab and field) might differ.

Expand view #

We have a new "Expand view" feature that adds a drill-down function to the field data section and allows you to view granular details for the Core Web Vitals metrics.

Page image #

We have removed the image of the loaded page, which appears right next to the field data. The image and thumbnails of the page displaying the loading sequence will both be available in the lab data section.

For up to date product documentation, visit https://developers.google.com/speed/docs/insights/.

Updates to web.dev/measure #

To reduce inconsistency between the different tools in our performance toolbox, we are also updating web.dev/measure to be directly powered by the PageSpeed Insights API.

Previously, developers would run reports via both the PSI tool and /measure and see different Lighthouse numbers. One of the main reasons for differences was because /measure originated all tests from the U.S. (due to it previously having a cloud backend that was US-based).

With /measure calling the same API directly as the PSI UI, developers will get a more consistent experience when using PSI and /measure. We have also made a few tweaks to /measure based on how users use the tool. This means that the signed-in experience for /measure will be going away, but the most used functionality—seeing multiple categories—will still be available for use.

web.dev/measure before

web.dev/measure after

PSI today #

Taking a step back, let's look at what the current PageSpeed Insights report offers. The PSI report includes performance data for both mobile and desktop devices in individual tabs and suggests how you may improve a page. The key components of the report in each case are similar and consist of the following:

Performance Score: The performance score appears at the top of the PSI report and summarizes the overall page performance. This score is determined by running Lighthouse to collect and analyze lab data about the page. A score of 90 or above is considered good, 50-90 needs improvement, and below 50 is poor.

Field Data: Field data, sourced from the CrUX report dataset, provides insights into the real-world user experience. The data includes metrics such as First Contentful Paint (FCP), and measures Core Web Vitals (First Input Delay (FID), Largest Contentful Paint (LCP), and Cumulative Layout Shift (CLS). Along with the metric values, you can also see the distribution of pages where the value of a particular metric was Good, Needs Improvement, or Poor, indicated by green, amber, and red bars, respectively. The distribution and scores are shown based on page loads for users in the CrUX dataset. Scores are calculated for the last 28 days and are not available for new pages where sufficient real-user data may not be available.

Origin Summary: Users can click on the Show Origin Summary checkbox to view the aggregated score for the metrics for all pages served from the same origin over the last 28 days.

Lab Data: Lab performance score, calculated using Lighthouse, helps debug performance issues, as it is collected in a controlled environment. The report shows the performance using metrics likeFirst Contentful Paint, Largest Contentful Paint, Speed Index, Cumulative Layout Shift, Time to Interactive, and Total Blocking Time. Each metric is scored and labeled with an icon indicating Good, Needs improvement, or Poor. This section provides a good indication of performance bottlenecks pre-release and can help to diagnose problems, but may not capture real-world issues.

Audits: This section lists all the audits run by Lighthouse and lists down the passed audits along with opportunities for improvement and additional diagnostic information.

Challenges with the current PSI design #

As seen in the screenshot above, the different data points from lab and field data are not isolated clearly, and developers who are new to PSI may not easily understand the context of the data and what to do next. This confusion has resulted in many "How to" blog posts on deciphering the PSI report.

With the redesign, we hope to make interpreting the report easier for developers so that they move quickly from generating the PSI report to acting upon the insights included in it.

Learn more #

For more details on performance tooling updates, watch the keynote for Chrome Dev Summit 2021. We will keep you posted on the release date for PSI and the changes to web.dev/measure.

With thanks to Milica Mihajlija, Philip Walton, Brendan Kenny and Ewa Gasperowicz for their feedback on this article

Optimizing resource loading with the Fetch Priority API

2021-10-20T00:00:00Z

Browser support

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

Source

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

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

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

Summary #

A few key areas where Fetch Priority can help:

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

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

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

Fetch Priority is available in Chrome 101 or later.

Resource priority #

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

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

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

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

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

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

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

When would you need Fetch Priority? #

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

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

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

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

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

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

The `fetchpriority` attribute #

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

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

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

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

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

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

Browser priority and `fetchpriority` #

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

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

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

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

Use cases #

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

Increase the priority of the LCP image #

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

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

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

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

Lower the priority of above-the-fold images #

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

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

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

Lower the priority of preloaded resources #

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

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

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

Reprioritize scripts #

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

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

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

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

Lower the priority for non-critical data fetches #

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

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

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

Fetch Priority implementation notes #

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

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

Using Preload after Chrome 95 #

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

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

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

History #

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

Browser compatibility #

Browser support

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

Source

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

Conclusion #

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

Best practices for using third-party embeds

2021-10-05T00:00:00Z

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

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

What is an embed #

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

Not authored by you
Served from third-party servers

Embeds are frequently used in the following:

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

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

Performance impact of third-party embeds #

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

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

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

Loading best practices #

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

Script ordering #

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

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

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

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

Lazy-loading #

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

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

Native lazy-loading for `<iframe>` #

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

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

The loading attribute supports the following values:

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

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

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

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

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

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

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

lazysizes library #

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

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

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

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

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

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

Using data-lazy in Facebook #

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

Lazy-loading Instagram feeds #

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

Replace embeds with facades #

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

A map embed with a zoom in and out feature.

A map facade that is an image.

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

Use static images as facades #

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

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

Use dynamic images as facades #

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

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

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

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

Use click-to-load to enhance facades #

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

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

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

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

YouTube facade

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

A lite-YouTube embed

A YouTube embed

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

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

Remove or replace embeds with links #

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

Layout stability #

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

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

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

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

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

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

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

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

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

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

Layout Shift Terminator #

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

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

Layout Shift Terminator:

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

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

Conclusion #

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

Core Web Vitals workflows with Google tools

2021-08-09T00:00:00Z

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

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

Core Web Vitals are best measured in the field #

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

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

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

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

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

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

Collect your own field data if possible #

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

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

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

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

Understanding Google's tools #

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

Chrome User Experience Report (CrUX) #

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

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

When to use CrUX #

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

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

When not to use CrUX #

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

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

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

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

PageSpeed Insights (PSI) #

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

When to use PSI #

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

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

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

When not to use PSI #

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

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

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

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

Search Console #

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

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

When to use Search Console #

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

When not to use Search Console #

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

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

Lighthouse #

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

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

When to use Lighthouse #

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

When not to use Lighthouse #

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

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

Web Vitals extension #

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

When to use the Web Vitals extension #

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

When not to use the Web Vitals extension #

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

The Performance panel in Chrome DevTools #

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

When to use the Performance panel #

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

When not to use the Performance panel #

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

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

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

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

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

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

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

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

Analyze site performance with PageSpeed Insights #

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

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

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

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

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

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

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

Identify poorly performing pages in Search Console #

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

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

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

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

Step 2: Debug and optimize #

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

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

For more detailed guidance, see these guides:

Uncover opportunities with Lighthouse #

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

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

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

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

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

Analyze in real time with the Web Vitals extension #

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

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

Drill down with the Performance panel #

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

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

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

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

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

Debug Core Web Vitals in the field #

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

See debug performance in the field for more information.

Step 3: Monitor for changes #

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

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

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

View website health trends with field data #

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

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

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

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

Conclusion #

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

Evolving Cumulative Layout Shift in web tooling

2021-06-02T00:00:00Z

Today we would like to share how we are evolving measurement of the Cumulative Layout Shift (CLS) metric across a number of Chrome's web tooling surfaces. For developers, these changes will better reflect the user-experience for long-lived pages (such as those with infinite scroll or single-page apps). These updates to CLS will be rolling out to tools including Lighthouse, PageSpeed Insights, and Chrome UX Report.

We all wish we saw fewer layout shifts on the web. This is where the CLS metric has proved useful in measuring the visual stability of a web page. It helps to encourage sites to better set dimensions for content, such as images or ads, that may contribute to surprising jumps of content for their users.

The metric is named "cumulative" because the score of each individual shift is summed throughout the lifespan of a page. While all layout shifts on the web cause poor user experiences, long-lived pages like Single-Page Apps (SPAs) or infinite scroll apps naturally accumulate more CLS over time. By capping the aggregation to the worst 'window' of shifts, CLS can now be more consistently measured regardless of session duration.

As we announced in Evolving the CLS metric, we are adjusting the CLS metric to a maximum session window with a 1 second gap, capped at 5 seconds, this update better reflects the user experience for long lived pages. With this change in place, 70% of origins should not expect to see any CLS change at the 75th percentile, and the remaining 30% of origins will see an improvement.

Rolling out the windowing adjustment to CLS #

We've talked about the updated CLS definition being a max session window with a 1 second gap, capped at 5 seconds. What does that mean for tools?

Starting today, this change to CLS has been rolled out across a number of Chrome's web tooling surfaces including Lighthouse, PageSpeed Insights, and Chrome UX Report. Below you can see a summary of the CLS windowing adjustment rollout, as well as which tools still provide the ability to benchmark against the original implementation.

Tool	CLS windowing adjustment 'live'	"Old" CLS Availability
Lighthouse DevTools Panel	Canary channel, 2 June 2021	N/A
Lighthouse CLI	v8, released 1 June 2021	Available as totalCumulativeLayoutShift in Lighthouse v8
Lighthouse CI	v0.7.3, 3 June 2021	N/A
PageSpeed Insights (PSI)	1 June 2021	NA
PSI API	1 June 2021	Available in the `lighthouseResult` as `totalCumulativeLayoutShift`. Not available in the field `loadingExperience` data
Chrome UX Report (CrUX) - BigQuery	202105 dataset, published 8 June 2021	Available as `experimental.uncapped_cumulative_layout_shift` through 202111
Chrome UX Report (CrUX) - API	1 June 2021	After 1 June 2021, available as `experimental_uncapped_cumulative_layout_shift` December 14th, 2021

Chrome DevTools will also be updated to support the windowing adjustment shortly. The update to CLS has also been made to Search Console and will be reflective from 1 June, 2021.

For most developers, this change is expected to happen seamlessly with no action needed to take advantage of data from the fix.

"Old" CLS #

As a reminder, the "old" CLS measures layout shift over the entire lifespan of the page. As some developers may wish to monitor the older definition of CLS alongside the windowing-adjustment, we have good news to share: we are exposing "old CLS" in Lighthouse and CrUX.

In Lighthouse v8, it's available in the JSON as audits['cumulative-layout-shift'].details.items[0].totalCumulativeLayoutShift.

You'll find it as experimental_uncapped_cumulative_layout_shift in the CrUX API and as experimental.uncapped_cumulative_layout_shift in CrUX BigQuery.

After June 1st, CrUX API requests will return the "old CLS" metric:

{
  "origin": "https://web.dev",
  "metrics": [
    "experimental_uncapped_cumulative_layout_shift"
  ]
}

After June 8, the following CrUX BigQuery will compare old and new CLS:

WITH
  new_data AS (
  SELECT
    cls
  FROM
    `chrome-ux-report.all.202105`,
    UNNEST(layout_instability.cumulative_layout_shift.histogram.bin) AS cls
  WHERE
    origin = 'https://web.dev'
    AND effective_connection_type.name = '4G'
    AND form_factor.name = 'phone'),
  old_data AS (
  SELECT
    uncapped_cls
  FROM
    `chrome-ux-report.all.202105`,
    UNNEST(experimental.uncapped_cumulative_layout_shift.histogram.bin) AS uncapped_cls
  WHERE
    origin = 'https://web.dev'
    AND effective_connection_type.name = '4G'
    AND form_factor.name = 'phone')
SELECT
  cls.start AS start,
  cls.`END` AS `end`,
  cls.density AS cls_density,
  uncapped_cls.density AS uncapped_cls_density
FROM
  new_data
INNER JOIN
  old_data
ON
  new_data.cls.start = old_data.uncapped_cls.start

You will be able to continue relying on this data to be present for a period of up to 6 months, with "old CLS" being retired on December 14th, 2021.

Updating the CLS weighting in Lighthouse #

When CLS was first introduced in Lighthouse, it was a brand new sparkly metric. As such, in order to make sure developers had time to test, benchmark, and optimize against it, CLS was weighed less heavily in the performance score.

Now, after having had some time in the hands of developers, the Lighthouse score has increased the weight of CLS from 5% to 15%, consistent with the methodology of having Core Web Vitals be the most heavily weighted metrics in the Lighthouse score.

You can find the updated weightings of metrics in Lighthouse v8 in the scoring calculator.

Lighthouse 8.0's CLS implementation includes both windowing and CLS contribution from subframes. Prior to 8.0, CLS in Lighthouse didn't include subframes' CLS in the metric calculation, but now does. And just for confirmation, field CLS measured by CrUX also handles windowing and subframes similarly.

Still, the primary difference between lab and field CLS is that lab CLS's window of observation ends at "fully loaded" as determined under lab conditions, whereas in the field, the window of observation extends to the entire page lifetime, including post-load activity. That said, the windowing adjustment does mitigate this difference substantially.

Measuring in the field yourself #

Should you wish to measure the latest CLS implementation, you can also record this for your field data via RUM using the following PerformanceObserver snippet.

Or by relying directly on the Web Vitals JavaScript library, which has also been updated with this change.

Additional updates #

Outside of the updates to Cumulative Layout Shift, the following metrics-related updates have also been made to our web tooling:

We're updating to the most recent definition of the Largest Contentful Paint metric. CrUX API, PSI, PSI API, Search Console will update on June 1, 2021. CrUX BigQuery will update on June 8, 2021.
In CrUX, First Contentful Paint tri-binning thresholds have been updated to be, Good: [0-1.8s], Needs Improvement: (1.8s-3s), Poor: [3s-∞]

Conclusions #

We expect this change to reflect a smooth transition for most sites and encourage you to check out Web Vitals and Optimize CLS for tips and tricks on how to measure and optimize your layout shifts away. As always, feel free to reach out on the web-vitals-feedback group for feedback about the metrics and our tooling specific feedback forums for Lighthouse, and Chrome UX Report for tooling issues. Cheers!

With thanks to Johannes Henkel, Rick Viscomi, Vivek Sekhar, Rachel Andrew, Milica Mihajlija, Jeff Jose and Paul Irish for their feedback.

Hero image by Barn Images / @barnimages on Unsplash

Optimizing Web Vitals using Lighthouse

2021-05-11T00:00:00Z

Today, we'll cover new tooling features in Lighthouse, PageSpeed and DevTools to help identify how your site can improve on the Web Vitals.

As a refresher on the tools, Lighthouse is an open-source, automated tool for improving the quality of web pages. You can find it in the Chrome DevTools suite of debugging tools and run it against any web page, public or requiring authentication. You can also find Lighthouse in PageSpeed Insights, CI and WebPageTest.

Lighthouse 7.x includes new features like element screenshots, for easier visual inspection of parts of your UI impacting user-experience metrics (e.g. what nodes are contributing to layout shift).

We've also shipped support for element screenshots on PageSpeed Insights, enabling a way to more easily spot issues for one-off performance runs of pages.

Measure Core Web Vitals #

Lighthouse can synthetically measure the Core Web Vitals metrics including Largest Contentful Paint, Cumulative Layout Shift and Total Blocking Time (a lab proxy for First Input Delay). These metrics reflect loading, layout stability, and interaction readiness. Other metrics such as First Contentful Paint highlighted in the future of Core Web Vitals (CWV) are there too.

The "Metrics" section of the Lighthouse report includes lab versions of these metrics. You can use this as a summary view of what aspects of user-experience require your attention.

The new Web Vitals option in the DevTools Performance panel displays a track which highlights metric moments, such as Layout Shift (LS) shown above.

Field metrics, such as those found in the Chrome UX Report or RUM, do not have this limitation and are a valuable complement to lab data as they reflect the experience real users have. Field data can't offer the kinds of diagnostic information you get in the lab, so the two go hand in hand.

Identify where you can improve on Web Vitals #

Identify the Largest Contentful Paint element #

LCP is a measurement of perceived loading experience. It marks the point during page load when the primary–or "largest"–content has loaded and is visible to the user.

Lighthouse has a "Largest Contentful Paint element" audit that identifies what element was the largest contentful paint. Hovering over the element will highlight it in the main browser window.

If this element is an image, this information is a useful hint that you may want to optimize the loading of this image. Lighthouse includes a number of image optimization audits for helping you understand if your images could be better compressed, resized or delivered in a more optimal modern image format.

You might also find LCP Bookmarklet by Annie Sullivan useful for quickly identifying the LCP element with a red rectangle in just one click.

Preload late-discovered images to improve LCP #

To improve the Largest Contentful Paint, preload your critical hero images if they are being discovered late by the browser. A late discovery can happen if a JavaScript bundle needs to be loaded before the image is discoverable.

There are a few common questions we are asked about preloading LCP images that may also be worth briefly covering.

Can you preload responsive images? Yes. Let's say we have a responsive hero image as specified using srcset and sizes below:

<img src="lighthouse.jpg"
          srcset="lighthouse_400px.jpg 400w,
                  lighthouse_800px.jpg 800w,
                  lighthouse_1600px.jpg 1600w" sizes="50vw" alt="A helpful
Lighthouse">

Thanks to the imagesrcset and imagesizes attributes added to the link attribute, we can preload a responsive image using the same image selection logic used by srcset and sizes:

<link rel="preload" as="image" href="lighthouse.jpg"
           imagesrcset="lighthouse_400px.jpg 400w,
                        lighthouse_800px.jpg 800w,
                        lighthouse_1600px.jpg 1600w"
imagesizes="50vw">

Will the audit also highlight preload opportunities if the LCP image is defined via a CSS background? Yes.

Any image flagged as the LCP image whether via CSS background or <img> is a candidate if it's discovered at a waterfall depth of three or more.

Lazy loading offscreen images and avoiding this for LCP #

Offscreen images that are not critical to the initial user experience can be lazy-loaded. This is a technique that defers downloading an image until a user scrolls near it, which can reduce network contention for critical assets and in some cases improve LCP. The "Defer offscreen images" audit can help here:

Critical above-the-fold images, such as the Largest Contentful Paint image, should not be lazy loaded. Doing so can delay the LCP image loading. Lighthouse will highlight if an LCP image is being incorrectly lazy-loaded via the "Largest Contentful Paint image was lazily loaded" audit:

Identify CLS contributions #

Cumulative Layout Shift is a measurement of visual stability. It quantifies how much a page's content visually shifts around. Lighthouse has an audit for debugging CLS called "Avoid large layout shifts".

This audit highlights DOM elements that contribute the most to shifts of the page. In the Element column to the left you will see the list of these DOM elements and to the right, their overall CLS contribution.

Thanks to the new Lighthouse Element Screenshots feature, we can both see a visual preview of the key elements noted in the audit as well as click-to-zoom for a clearer view:

For post-load CLS, there can be value in persistently visualizing with rectangles which elements contributed the most to CLS. This is a feature you'll find in third-party tools like SpeedCurve's Core Web Vitals dashboard and which I love using Defaced's Layout Shift GIF Generator for:

For a site-wide view of layout shift issues, I get a lot of mileage out of Search Console's Core Web Vitals report. This lets me see the kinds of pages on my site with a high CLS (in this case helping self-identify what template partials I need to spend my time on):

Identifying CLS from images without dimensions #

To limit Cumulative Layout Shift being caused by images without dimensions, include width and height size attributes on your images and video elements. This approach ensures that the browser can allocate the correct amount of space in the document while the image is loading.

See Setting Height And Width On Images Is Important Again for a good write-up on the importance of thinking about image dimensions and aspect ratio.

Identifying CLS from advertisements #

Publisher Ads for Lighthouse allows you to find opportunities to improve the loading experience of ads on your page, including contributions to layout shift and long tasks that may push out how soon your page is usable by users. In Lighthouse, you can enable this via Community Plugins.

Remember that ads are one of the largest contributors to layout shifts on the web. It's important to:

Take care when placing non-sticky ads near the top of the viewport
Eliminate shifts by reserving the largest possible size for the ad slot

Avoid non-composited animations #

Animations which are non-composited can present themselves as janky on lower-end devices if heavy JavaScript tasks are keeping the main thread busy. Such animations can introduce layout shifts.

If Chrome discovers an animation couldn't be composited, it reports it to a DevTools trace Lighthouse reads, allowing it to list which elements with animations weren't composited and for what reason. You can find these in the Avoid non-composited animations audit.

Debug First Input Delay / Total Blocking Time / Long Tasks #

First Input measures the time from when a user first interacts with a page (e.g. when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction. Long JavaScript Tasks can impact this metric and the proxy for this metric, Total Blocking Time.

Lighthouse includes an Avoid long main-thread tasks audit which lists the longest tasks on the main thread. This can be helpful for identifying the worst contributors to input delay. In the left column we can see the URL of scripts responsible for long main-thread tasks.

To the right we can see the duration of these tasks. As a reminder, Long Tasks are tasks which execute for longer than 50 milliseconds. This is considered to block the main thread long enough to impact frame rate or input latency.

If considering third-party services for monitoring, I also quite like the main-thread execution timeline visual Calibre has for visualizing these costs, which highlights both parent and child tasks contributing to long tasks that impact interactivity.

Block network requests to see the before/after impact in Lighthouse #

Chrome DevTools supports blocking network requests to see the impact of individual resources being removed or not being available. This can be helpful for understanding the cost individual scripts (e.g such as third-party embeds or trackers) have on metrics like Total Blocking Time (TBT) and Time to Interactive.

Network request blocking happens to also work with Lighthouse! Let's take a quick look at the Lighthouse report for a site. The Perf score is 63/100 with a TBT of 400ms. Digging into the code, we find this site loads an Intersection Observer polyfill in Chrome which isn't necessary. Let's block it!

We can right-click on a script in the DevTools Network panel and click Block Request URL to block it. Here we'll do this for the Intersection Observer polyfill.

Next we can re-run Lighthouse. This time we can see our performance score has improved (70/100) as has Total Blocking Time (400ms => 300ms).

Replace costly third-party embeds with a facade #

It's common to use third-party resources for embedding videos, social media posts or widgets into pages. By default, most embeds eagerly load right away and can come with costly payloads that negatively impact the user-experience. This is wasteful if the third-party isn't critical (e.g. if the user needs to scroll before they see it).

One pattern to improve performance of such widgets is to lazy-load them on user interaction. This can be done by rendering a lightweight preview of the widget (a facade) and only load the full version if a user interacts with it. Lighthouse has an audit that will recommend third-party resources which can be lazy-loaded with a facade, such as YouTube video embeds.

As a reminder, Lighthouse will highlight third-party code that blocks the main thread for over 250ms. This can expose all kinds of third-party scripts (including ones authored by Google) that may be worth better deferring or lazy loading if what they render requires scrolling to view it.

Beyond Core Web Vitals #

Beyond highlighting the Core Web Vitals, recent versions of Lighthouse and PageSpeed Insights also try to provide concrete guidance you can follow for improving how quickly JavaScript-heavy web applications can load if you have source maps turned on.

These include a growing collection of audits for reducing the cost of JavaScript in your page, such as reducing reliance on polyfills and duplicates that may not be needed for the user-experience.

For more information on Core Web Vitals tooling, keep an eye on the Lighthouse team Twitter account and What's new in DevTools.

Hero image by Mercedes Mehling on Unsplash.

It's time to lazy-load offscreen iframes!

2020-07-24T00:00:00Z

Standardized lazy-loading for images landed in Chrome 76 via the loading attribute and later came to Firefox. We are happy to share that browser-level lazy-loading for iframes is now standardized and is also supported in Chrome and Chromium-based browsers.

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

Standardized lazy-loading of iframes defers offscreen iframes from being loaded until the user scrolls near them. This saves data, speeds up the loading of other parts of the page, and reduces memory usage.

This demo of <iframe loading=lazy> shows lazy-loading video embeds:

Why should we lazy-load iframes? #

Third-party embeds cover a wide range of use cases, from video players, to social media posts, to ads. Often this content is not immediately visible in the user's viewport. Rather, it's only seen once they scroll further down the page. Despite this, users pay the cost of downloading data and costly JavaScript for each frame, even if they don't scroll to it.

Based off Chrome's research into automatically lazy-loading offscreen iframes for Data Saver users, lazy-loading iframes could lead to 2-3% median data savings, 1-2% First Contentful Paint reductions at the median, and 2% First Input Delay (FID) improvements at the 95th percentile.

Additionally, lazy-loading off-screen iframes can impart benefits to Largest Contentful Paint (LCP). LCP candidates, such as images or text dependent on web fonts in order to render. Because iframes can often require a significant amount of bandwidth in order to load all of their subresources, lazy-loading offscreen iframes can significantly reduce bandwidth contention on network-constrained devices, leaving more bandwidth to load resources which contribute to a page's LCP.

How does built-in lazy-loading for iframes work? #

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

lazy: is a good candidate for lazy-loading.
eager: is not a good candidate for lazy-loading. Load right away.

Using the loading attribute on iframes works as follows:

<!-- Lazy-load the iframe -->
<iframe src="https://example.com"
        loading="lazy"
        width="600"
        height="400"></iframe>

<!-- Eagerly load the iframe -->
<iframe src="https://example.com"
        width="600"
        height="400"></iframe>

Not specifying the attribute at all will have the same impact as explicitly eagerly loading the resource.

If you need to dynamically create iframes via JavaScript, setting iframe.loading = 'lazy' on the element is also supported:

var iframe = document.createElement('iframe');
iframe.src = 'https://example.com';
iframe.loading = 'lazy';
document.body.appendChild(iframe);

iframe-specific lazy-loading behavior #

The loading attribute affects iframes differently than images, depending on whether the iframe is hidden. (Hidden iframes are often used for analytics or communication purposes.) Chrome uses the following criteria to determine whether an iframe is hidden:

The iframe's width and height are 4px or smaller.
display: none or visibility: hidden is applied.
The iframe is placed off-screen using negative X or Y positioning.
This criteria applies to both loading=lazy and loading=auto.

If an iframe meets any of these conditions, Chrome considers it hidden and won't lazy-load it in most cases. iframes that aren't hidden will only load when they're within the load-in distance threshold. Chrome shows a placeholder for lazy-loaded iframes that are still being fetched.

What impact might we see from lazy-loading popular iframe embeds? #

What if we could change the web at large so that lazy-loading offscreen iframes was the default? It would look a little like this:

Lazy-loading YouTube video embeds (saves ~500KB on initial page load):

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

Anecdote: when we switched to lazy-loading YouTube embeds for Chrome.com, we saved 10 seconds off of how soon our pages could be interactive on mobile devices. I have opened an internal bug with YouTube to discuss adding loading=lazy to its embed code.

Lazy-loading Instagram embeds (saves >100KB gzipped on initial load):

Instagram embeds provide a block of markup and a script, which injects an iframe into your page. Lazy-loading this iframe avoids having to load all of the script necessary for the embed. Given such embeds are often displayed below the viewport in most articles, this seems like a reasonable candidate for lazy-loading of their iframe.

Lazy-loading Spotify embeds (saves 514KB on initial load):

<iframe src="https://open.spotify.com/embed/album/1DFixLWuPkv3KT3TnV35m3"
        loading="lazy"
        width="300"
        height="380"
        frameborder="0"
        allowtransparency="true"
        allow="encrypted-media"></iframe>

Although the above embeds illustrate the potential benefits to lazy-loading iframes for media content, there's the potential to also see these benefits for ads.

Facebook's social plugins allow developers to embed Facebook content in their web pages. There's a number of these plugins offered, such as embedded posts, photos, videos, comments… The most popular is the Like plugin - a button that shows a count of who has "liked" the page. By default, embedding the Like plugin in a webpage (using the FB JSSDK) pulls in ~215KB of resources, 197KB of which is JavaScript. In many cases, the plugin may appear at the end of an article or near the end of a page, so loading it eagerly when it's offscreen may be suboptimal.

Thanks to engineer Stoyan Stefanov, all of Facebook's social plugins now support standardized iframe lazy-loading. Developers who opt in to lazy-loading via the plugins' data-lazy configuration will now be able to avoid it loading until the user scrolls nearby. This enables the embed to still fully function for users that need it, while offering data-savings for those who are not scrolling all the way down a page. We are hopeful this is the first of many embeds to explore standardized iframe lazy-loading in production.

Can I lazy-load iframes cross-browser? Yes #

iframe lazy-loading can be applied as a progressive enhancement. Browsers which support loading=lazy on iframes will lazy-load the iframe, while the loading attribute will be safely ignored in browsers which do not support it yet.

It is also possible to lazy-load offscreen iframes using the lazysizes JavaScript library. This may be desirable if you:

require more custom lazy-loading thresholds than what standardized lazy-loading currently offers
wish to offer users a consistent iframe lazy-loading experience across browsers

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

<iframe frameborder="0"
	  class="lazyload"
    allowfullscreen=""
    width="600"
    height="400"
    data-src="//www.youtube.com/embed/ZfV-aYdU4uE">
</iframe>

Use the following pattern to feature detect lazy-loading and fetch lazysizes when it's not available:

<iframe frameborder="0"
	  class="lazyload"
    loading="lazy"
    allowfullscreen=""
    width="600"
    height="400"
    data-src="//www.youtube.com/embed/ZfV-aYdU4uE">
</iframe>

<script>
  if ('loading' in HTMLIFrameElement.prototype) {
    const iframes = document.querySelectorAll('iframe[loading="lazy"]');

    iframes.forEach(iframe => {
      iframe.src = iframe.dataset.src;
    });

  } else {
    // Dynamically import the LazySizes library
    const script = document.createElement('script');
    script.src =
      'https://cdnjs.cloudflare.com/ajax/libs/lazysizes/5.2.2/lazysizes.min.js';
    document.body.appendChild(script);
  }

</script>

An option for WordPress users #

You might have many iframes scattered across years worth of post content in a WordPress site. You can optionally add the following code to your WordPress theme's functions.php file to automatically insert loading="lazy" to your existing iframes without having to manually update them each individually.

Note that browser-level support for lazy-loading iframes is also being worked on in WordPress core. The following snippet will check for the relevant flags so that, once WordPress has the functionality built-in, it will no longer manually add the loading="lazy" attribute, ensuring it is interoperable with those changes and will not result in a duplicate attribute.

// TODO: Remove once https://core.trac.wordpress.org/ticket/50756 lands.
function wp_lazy_load_iframes_polyfill( $content ) {
	// If WP core lazy-loads iframes, skip this manual implementation.
	if ( function_exists( 'wp_lazy_loading_enabled' ) && wp_lazy_loading_enabled( 'iframe', 'the_content' ) ) {
		return $content;
	}

	return str_replace( '<iframe ', '<iframe loading="lazy" ', $content );
}
add_filter( 'the_content', 'wp_lazy_load_iframes_polyfill' );

If your WordPress site utilizes caching (hint: it should), don't forget to rebuild your site's cache afterwards.

Conclusion #

Baking in standardized support for lazy-loading iframes makes it significantly easier for you to improve the performance of your web pages. If you have any feedback, please feel free to submit an issue to the Chromium Bug Tracker.

And, in case you missed it, check out web.dev's image and video lazy-loading collection for more lazy-loading ideas.

With thanks to Dom Farolino, Scott Little, Houssein Djirdeh, Simon Pieters, Kayce Basques, Joe Medley and Stoyan Stefanov for their reviews.

Prefetching in create-react-app with Quicklink

2020-06-08T00:00:00Z

This codelab shows you how to implement the Quicklink library in a React SPA demo to demonstrate how prefetching speeds up subsequent navigations.

Measure #

Before adding optimizations, it's always a good idea to first analyze the current state of the application.

Click Remix to Edit to make the project editable.
To preview the site, press View App. Then press Fullscreen .

The website is a simple demo built with create-react-app.

Complete the following instructions in the new tab that just opened:

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Network tab.
Select the Disable cache checkbox.
In the Throttling drop-down list, select Fast 3G to simulate a slow connection type.
Reload the app.
Type chunk into the Filter textbox to hide any resources that do not include chunk in their name.

The site uses route-based code splitting, thanks to which only the necessary code is requested at the beginning.

Clear the network requests in DevTools.
Within the app, click the Blog link to navigate to that page.

The JS and CSS chunks for the new route are loaded to render the page.

Next, you'll implement Quicklink in this site, so that these chunks can be prefetched in the home page, making the navigation faster.

This allows you to combine the best of both techniques:

Route-based code splitting tells the browser to only load the necessary chunks at a higher priority at page load time.
Prefetching tells the browser to load the chunks for in-viewport links at the lowest priority, during the browser's idle time.

Configure `webpack-route-manifest` #

The first step is to install and configure webpack-route-manifest, a webpack plugin that lets you generate a manifest file associating routes with their corresponding chunks.

Usually, you would need to install the library, but we've already done it for you. Here's the command that you would need to run:

npm install webpack-route-manifest --save-dev

config-overrides.js is a file placed in your project root directory where you can override existing behaviour of the webpack configuration, without having to eject the project.

To view the source, press View Source.

Open config-overrides.js for edit and add the webpack-route-manifest dependency at the beginning of the file:

const path = require('path');
const RouteManifest = require('webpack-route-manifest');

Next, configure the webpack-route-manifest plugin by adding the following code to the bottom of config-overrides.js:

module.exports = function override(config) {
  config.resolve = {
    ...config.resolve,
    alias: {
      '@assets': `${path.resolve(__dirname, 'src/assets')}`,
      '@pages': `${path.resolve(__dirname, 'src/pages')}`,
      '@components': `${path.resolve(__dirname, 'src/components')}`,
    },
  };

  config.plugins.push(
    new RouteManifest({
      minify: true,
      filename: 'rmanifest.json',
      routes(str) {
        let out = str.replace('@pages', '').toLowerCase();
        if (out === '/article') return '/blog/:title';
        if (out === '/home') return '/';
        return out;
      },
    }),
  );

  return config;
};

The new code does the following:

config.resolve declares variables with the internal routes to pages, assets and components.
config.plugins.push() creates a RouteManifest object and passes it the configuration so that the rmanifest.json file can be generated based on the site's routes and chunks.

The manifest.json file will be generated and made available at https://site_url/rmanifest.json.

Configure quicklink #

At this point you would need to install the Quicklink library in your project. For simplicity, we already added it to the project. Here's the command that you would need to run:

npm install --save quicklink

Open src/components/App/index.js for edit.

First, import the Quicklink higher order component (HOC):

import React, { lazy, Suspense } from 'react';
import { Route } from 'react-router-dom';

import Footer from '@components/Footer';
import Hero from '@components/Hero';
import style from './index.module.css';
import { withQuicklink } from 'quicklink/dist/react/hoc.js';

const Home = lazy(() => import(/* webpackChunkName: "home" */ '@pages/Home'));
const About = lazy(() => import(/* webpackChunkName: "about" */ '@pages/About'));
const Article = lazy(() => import(/* webpackChunkName: "article" */ '@pages/Article'));
const Blog = lazy(() => import(/* webpackChunkName: "blog" */ '@pages/Blog'));

Next, create an options object after the Blog variable declaration, to use as an argument when calling quicklink:

const options = {
	origins: []
};

Finally, wrap each route with the withQuicklink() higher order component, passing it an options parameter and the target component for that route:

const App = () => (
  <div className={style.app}>
    <Hero />
    <main className={style.wrapper}>
      <Suspense fallback={<div>Loading...</div>}>
        <Route path="/" exact component={withQuicklink(Home, options)} />
        <Route path="/blog" exact component={withQuicklink(Blog, options)} />
        <Route
          path="/blog/:title"
          component={withQuicklink(Article, options)}
        />
        <Route path="/about" exact component={withQuicklink(About, options)} />
      </Suspense>
    </main>
    <Footer />
  </div>
);

The previous code instructs to prefetch chunks for the routes wrapped with withQuicklink(), when the link comes into the view.

Measure again #

Repeat the first 6 steps from Measure. Don't navigate to the blog page yet.

When the home page loads the chunks for that route are loaded. After that, Quicklink prefetches the route's chunks for the in-viewport links:

These chunks are requested at the lowest priority and without blocking the page.

Clear the Network log again.
Disable the Disable cache checkbox.
Click the Blog link to navigate to that page.

The Size column indicates that these chunks were retrieved from the "prefetch cache", instead of the network. Loading these chunks without a Quicklink took approximately 580ms. Using the library it now takes 2ms, which represents a 99% reduction!

Speed up navigations in React with Quicklink

2020-06-08T00:00:00Z

Prefetching is a technique to speed up navigations by downloading the resources for the next page, ahead of time. Quicklink is a library that allows you to implement this technique at scale, by automatically prefetching links as they come into the view.

In multi-page apps the library prefetches documents (e.g. /article.html), for in-viewport links, so that when the user clicks on these links they can be picked up from the HTTP cache.

Single-page apps commonly use a technique called route-based code splitting. This allows the site to load the code for a given route only when the user navigates to it. These files (JS, CSS) are commonly referred to as "chunks".

With that said, in these sites, instead of prefetching documents the biggest performance gains come from prefetching these chunks before the page needs them.

Achieving this presents some challenges:

It's not trivial to determine which chunks (e.g. article.chunk.js) are associated with a given route (e.g. /article) before landing on it.
The final URL names of these chunks can't be predicted, as modern module bundlers typically use long-term hashing for versioning (e.g. article.chunk.46e51.js).

This guide explains how Quicklink solves these challenges and allows you to achieve prefetching at scale in React single page apps.

Determine chunks associated with each route #

One of the core components of quicklink is webpack-route-manifest, a webpack plugin that lets you generate a JSON dictionary of routes and chunks. This allows the library to know which files are going to be needed by each route of the application and prefetch them as the routes come into the view.

After integrating the plugin with the project, it will produce a JSON manifest file associating each route with its corresponding chunks:

{
  '/about': [
    {
      type: 'style',
      href: '/static/css/about.f6fd7d80.chunk.css',
    },
    {
      type: 'script',
      href: '/static/js/about.1cdfef3b.chunk.js',
    },
  ],
  '/blog': [
    {
      type: 'style',
      href: '/static/css/blog.85e80e75.chunk.css',
    },
    {
      type: 'script',
      href: '/static/js/blog.35421503.chunk.js',
    },
  ],
}

This manifest file can be requested in two ways:

By URL, e.g. https://site_url/rmanifest.json.
Through the window object, at window.__rmanifest.

Prefetch chunks for in-viewport routes #

Once the manifest file is available, the next step is to install Quicklink by running npm install quicklink.

Then, the higher order component (HOC) withQuicklink() can be used to indicate that a given route should be prefetched when the link comes into the view.

The following code belongs to an App component of a React app that renders a top menu with four links:

const App = () => (
  <div className={style.app}>
    <Hero />
    <main className={style.wrapper}>
      <Suspense fallback={<div>Loading…</div>}>
        <Route path="/" exact component={Home} />
        <Route path="/blog" exact component={Blog} />
        <Route path="/blog/:title" component={Article} />
        <Route path="/about" exact component={About} />
      </Suspense>
    </main>
    <Footer />
  </div>
);

To tell Quicklink that these routes should be prefetched as they come into the view:

Import the quicklink HOC at the beginning of the component.
Wrap each route with the withQuicklink() HOC, passing the page component and options parameter to it.

const options = {
  origins: [],
};
const App = () => (
  <div className={style.app}>
    <Hero />
    <main className={style.wrapper}>
      <Suspense fallback={<div>Loading…</div>}>
        <Route path="/" exact component={withQuicklink(Home, options)} />
        <Route path="/blog" exact component={withQuicklink(Blog, options)} />
        <Route
          path="/blog/:title"
          component={withQuicklink(Article, options)}
        />
        <Route path="/about" exact component={withQuicklink(About, options)} />
      </Suspense>
    </main>
    <Footer />
  </div>
);

The withQuicklink() HOC uses the path of the route as a key to obtain its associated chunks from rmanifest.json. Under the hood, as links come into the view, the library injects a <link rel="prefetch"> tag in the page for each chunk so they can be prefetched. Prefetched resources will be requested at the lowest priority by the browser and kept in the HTTP Cache for 5 minutes, after which point, the cache-control rules of the resource apply. As a result of this, when a user clicks on a link and moves to a given route, the chunks will be retrieved from the cache, greatly improving the time it takes to render that route.

Conclusion #

Prefetching can greatly improve load times for future navigations. In React single-page apps, this can be achieved by loading the chunks associated with each route, before the user lands in them. Quicklink's solution for React SPA uses webpack-route-manifest to create a map of routes and chunks, in order to determine which files to prefetch, when a link comes into the view. Implementing this technique throughout your site can greatly improve navigations to the point of making them appear instant.

Tools to measure Core Web Vitals

2020-05-28T00:00:00Z

The recently announced Web Vitals initiative provides unified guidance about quality signals that are essential for all sites to deliver a great user experience on the web. We're happy to announce that all of Google's popular tools for web developers now support measurement of Core Web Vitals, helping you more easily diagnose and fix user experience issues. This includes Lighthouse, PageSpeed Insights, Chrome DevTools, Search Console, web.dev's measure tool, the Web Vitals Chrome extension and a new (!) Chrome UX Report API.

With Google Search now including Core Web Vitals as the foundation for evaluating page experience, it's important that these metrics are as available and actionable as possible.

To begin your journey optimizing user-experience with Core Web Vitals, try the following workflow:

Use Search Console's new Core Web Vitals report to identify groups of pages that require attention (based on the field data).
Once you've identified pages that need work, use PageSpeed Insights (powered by Lighthouse and Chrome UX Report) to diagnose lab and field issues on a page. PageSpeed Insights (PSI) is available via Search Console or you can enter a URL on PSI directly.
Ready to optimize your site locally in the lab? Use Lighthouse and Chrome DevTools to measure Core Web Vitals and get actionable guidance on exactly what to fix. The Web Vitals Chrome extension can give you a real-time view of metrics on desktop.
Need a custom dashboard of Core Web Vitals? Use the updated CrUX Dashboard or new Chrome UX Report API for field data or PageSpeed Insights API for lab data.
Looking for guidance? web.dev/measure can measure your page and show you a prioritized set of guides and codelabs for optimization, using PSI data.
Finally, use Lighthouse CI on pull requests to ensure there are no regressions in Core Web Vitals before you deploy a change to production.

With that introduction, let's dive into the specific updates for each tool!

Lighthouse #

Lighthouse is an automated website auditing tool that helps developers diagnose issues and identify opportunities to improve the user experience of their sites. It measures several dimensions of user experience quality in a lab environment, including performance and accessibility. The latest version of Lighthouse (6.0, released mid-May 2020) includes additional audits, new metrics, and a newly composed performance score.

Lighthouse 6.0 introduces three new metrics to the report. Two of these new metrics—Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS)—are lab implementations of Core Web Vitals and provide important diagnostic information for optimizing user experience. Given their importance for assessing user experience, the new metrics are not only measured and included in the report, they are also factored in calculating the performance score.

The third new metric included in Lighthouse—Total Blocking Time (TBT)—correlates well with the field metric First Input Delay (FID), another Core Web Vitals metric. Following the recommendations provided in the Lighthouse report and optimizing against your scores sets you up to provide the best possible experience to your users.

All of the products that Lighthouse powers are updated to reflect the latest version, including Lighthouse CI which enables you to easily measure your Core Web Vitals on pull requests before they're merged and deployed.

To learn more about the latest updates to Lighthouse, check out our What's New in Lighthouse 6.0 blog post.

PageSpeed Insights #

PageSpeed Insights (PSI) reports on the lab and field performance of a page on both mobile and desktop devices. The tool provides an overview of how real-world users experience the page (powered by the Chrome UX Report) and a set of actionable recommendations on how a site owner can improve page experience (provided by Lighthouse).

PageSpeed Insights and the PageSpeed Insights API have also been upgraded to use Lighthouse 6.0 under the hood and now support measuring Core Web Vitals in both the lab and field sections of the report! Core Web Vitals are annotated with a blue ribbon as shown below.

While Search Console provides site owners with a great overview of groups of pages that need attention, PSI helps identify per-page opportunities to improve page experience. In PSI, you are able to clearly see whether or not your page meets the thresholds for a good experience across all Core Web Vitals at the top of the report, indicated by passes the Core Web Vitals assessment or does not pass the Core Web Vitals assessment.

CrUX #

The Chrome UX Report (CrUX) is a public dataset of real user experience data on millions of websites. It measures field versions of all the Core Web Vitals. Unlike lab data, CrUX data comes from opted-in users in the field. Using this data, developers are able to understand the distribution of real-world user experiences on their own or even competitors' websites. Even if you don't have RUM on your site, CrUX can provide a quick and easy way to assess your Core Web Vitals. The CrUX dataset on BigQuery includes fine-grained performance data for all Core Web Vitals and is available in monthly snapshots at the origin-level.

The only way to truly know how your site performs for your users is to actually measure its performance in the field as those users are loading and interacting with it. This type of measurement is commonly referred to as Real User Monitoring—or RUM for short. Even if you don't have RUM on your site, CrUX can provide a quick and easy way to assess your Core Web Vitals.

Introducing the CrUX API

Today we're happy to announce the CrUX API, a fast and free way to easily integrate your development workflows with origin and URL-level quality measurement for the following field metrics:

Largest Contentful Paint
Cumulative Layout Shift
First Input Delay
First Contentful Paint

Developers can query for an origin or URL and segment results by different form factors. The API updates daily and summarizes the previous 28 days worth of data (unlike the BigQuery dataset, which is aggregated monthly). The API also has the same relaxed public API quotas we place on our other API, the PageSpeed Insights API (25,000 requests per day).

Below is a demo using the CrUX API to visualize the Core Web Vitals metrics with distributions for good, needs improvement, and poor:

In future releases, we plan to expand the API to enable access to additional CrUX dataset dimensions and metrics.

Revamped CrUX Dashboard

The newly redesigned CrUX Dashboard allows you to easily track an origin's performance over time, and now you can use it to monitor the distributions of all of the Core Web Vitals metrics. To get started with the dashboard, check out our tutorial on web.dev.

We've introduced a new Core Web Vitals landing page to make it even easier to see how your site is performing at a glance. We welcome your feedback on all CrUX tooling; to share your thoughts and questions reach us at the @ChromeUXReport Twitter account or Google Group.

Chrome DevTools Performance panel #

Debug Layout Shift events in the Experience section

The Chrome DevTools Performance panel has a new Experience section that can help you detect unexpected layout shifts. This is helpful for finding and fixing visual instability issues on your page that contribute to Cumulative Layout Shift.

Select a Layout Shift to view its details in the Summary tab. To visualize where the shift itself occurred, hover over the Moved from and Moved to fields.

Debug interaction readiness with Total Blocking Time in the footer

The Total Blocking Time (TBT) metric can be measured in lab tools and is an excellent proxy for First Input Delay. TBT measures the total amount of time between First Contentful Paint (FCP) and Time to Interactive (TTI) where the main thread was blocked for long enough to prevent input responsiveness. Performance optimizations that improve TBT in the lab should improve FID in the field.

TBT is now shown in the footer of the Chrome DevTools Performance panel when you measure page performance:

Press `Control+Shift+J` (or `Command+Option+J` on Mac) to open DevTools.
Click the Performance tab.
Click Record.
Manually reload the page.
Wait for the page to load and then stop recording.

For more information, see What's New In DevTools (Chrome 84).

Search Console #

The new Core Web Vitals report in Search Console helps you identify groups of pages across your site that require attention, based on real-world (field) data from CrUX. URL performance is grouped by status, metric type and URL group (groups of similar web pages).

The report is based on the three Core Web Vitals metrics: LCP, FID, and CLS. If a URL does not have a minimum amount of reporting data for these metrics, it's omitted from the report. Try the new report to get a holistic view of performance for your origin.

Once you identify a type of page that has Core Web Vitals related issues, you can use PageSpeed Insights to learn about specific optimization suggestions for representative pages.

web.dev #

web.dev/measure allows you to measure the performance of your page over time, providing a prioritized list of guides and codelabs on how to improve. It's measurement is powered by PageSpeed Insights. The measure tool now also supports the Core Web Vitals metrics, as shown below:

Web Vitals extension #

The Web Vitals extension measures the three Core Web Vitals metrics in real-time for (desktop) Google Chrome. This is helpful for catching issues early on during your development workflow and as a diagnostic tool to assess performance of Core Web Vitals as you browse the web.

The extension is now available to install from the Chrome Web Store! We hope you find it useful. We welcome any contributions to improve it as well as feedback on the project's GitHub repository.

Quick highlights #

That's a wrap! What can you do next:

Use Lighthouse in DevTools to optimize your user experience and ensure you are setting yourself up for success with Core Web Vitals in the field.
Use PageSpeed Insights to compare your lab and field Core Web Vitals performance.
Try out the new Chrome User Experience Report API to easily access how well your origin and URL have performed against Core Web Vitals over the last 28 days.
Use the Experience section and footer in DevTools Performance panel to dive deep and debug against specific Core Web Vitals.
Use Search Console's Core Web Vitals report for a summary of how your origins are performing in the field.
Use the Web Vitals Extension to track a page's performance against Core Web Vitals in real-time.

We will cover more about our Core Web Vitals tooling at web.dev Live in June. Sign up to get updates on the event!: by Elizabeth and Addy, WebPerf Janitors

Optimize Cumulative Layout Shift

2020-05-05T00:00:00Z

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

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

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

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

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

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

The most common causes of a poor CLS are:

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

Understanding where your shifts are coming from #

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

CLS in lab tools versus field #

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

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

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

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

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

Identifying load CLS issues #

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

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

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

Identifying post-load CLS issues #

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

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

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

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

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

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

Measuring CLS elements in the field #

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

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

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

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

Common causes of CLS #

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

Images without dimensions #

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

Images without width and height specified.

Images with width and height specified.

Lighthouse 6.0 impact of setting image dimensions on CLS.

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

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

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

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

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

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

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

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

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

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

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

Modern best practice for setting image dimensions #

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

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

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

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

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

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

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

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

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

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

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

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

What about responsive images? #

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

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

What about art direction?

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

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

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

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

Ads, embeds, and other late-loaded content #

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

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

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

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

Statically reserve space for late-loading content #

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

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

Reserving space for ads can prevent layout shifts

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

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

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

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

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

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

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

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

Avoid inserting new content without a user interaction #

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

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

Dynamic content without space reserved.

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

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

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

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

Animations #

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

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

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

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

Web fonts #

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

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

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

The following tools can help you minimize this:

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

Read Best practices for fonts for other font best practices.

Reduce CLS by ensuring pages are eligible for the bfcache #

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

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

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

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

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

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

Conclusion #

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

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

Optimize First Input Delay

2020-05-05T00:00:00Z

I clicked but nothing happened! Why can't I interact with this page? 😢

First Contentful Paint (FCP) and Largest Contentful Paint (LCP) are both metrics that measure the time it takes for content to visually render (paint) on a page. Although important, paint times do not capture load responsiveness: or how quickly a page responds to user interaction.

First Input Delay (FID) is a Core Web Vitals metric that captures a user's first impression of a site's interactivity and responsiveness. It measures the time from when a user first interacts with a page to the time when the browser is actually able to respond to that interaction. FID is a field metric and cannot be simulated in a lab environment. A real user interaction is required in order to measure the response delay.

To help predict FID in the lab, we recommend Total Blocking Time (TBT). They measure different things, but improvements in TBT usually correspond to improvements in FID.

The main cause of a poor FID is heavy JavaScript execution. Optimizing how JavaScript parses, compiles, and executes on your web page will directly reduce FID.

Heavy JavaScript execution #

The browser cannot respond to most user input while it's executing JavaScript on the main thread. In other words, the browser can't respond to user interactions while the main thread is busy. To improve this:

Break up Long Tasks #

If you've already attempted to reduce the amount of JavaScript that loads on a single page, it can be useful to break down long-running code into smaller, asynchronous tasks.

Long Tasks are JavaScript execution periods where users may find your UI unresponsive. Any piece of code that blocks the main thread for 50 ms or more can be characterized as a Long Task. Long Tasks are a sign of potential JavaScript bloat (loading and executing more than a user may need right now). Splitting up long tasks can reduce input delay on your site.

Chrome DevTools visualizes Long Tasks in the Performance Panel

FID should improve noticeably as you adopt best practices like code-splitting and breaking up your Long Tasks. While TBT is not a field metric, it's useful for checking progress towards ultimately improving both Time To Interactive (TTI) and FID.

Optimize your page for interaction readiness #

There are a number of common causes for poor FID and TBT scores in web apps that rely heavily on JavaScript:

First-party script execution can delay interaction readiness #

JavaScript size bloat, heavy execution times and inefficient chunking can slow down how soon a page can respond to user input and impact FID, TBT, and TTI. Progressive loading of code and features can help spread this work out and improve interaction readiness.
Server-side rendered apps may look like they're getting pixels painted on the screen quickly, but beware of user interactions being blocked by large script executions (e.g. re-hydration to wire up event listeners). This can take several hundred milliseconds, sometimes even seconds, if route-based code splitting is being used. Consider shifting more logic server-side or generating more content statically during build time.

Below are the TBT scores before and after optimizing first-party script loading for an application. By moving costly script loading (and execution) for a non-essential component off the critical path, users were able to interact with the page much sooner.

Data-fetching can impact many aspects of interaction readiness #

Waiting on a waterfall of cascading fetches (e.g. JavaScript and data fetches for components) can impact interaction latency. Aim to minimize a reliance on cascading data fetches.
Large inline datastores can push out HTML parsing time and impact both paint and interaction metrics. Aim to minimize how much data needs to be post-processed on the client-side.

Third-party script execution can delay interaction latency too #

Many sites include third-party tags and analytics which can keep the network busy and make the main thread periodically unresponsive, impacting interaction latency. Explore on-demand loading of third-party code (e.g. maybe don't load those below-the-fold ads until they're scrolled closer to the viewport).
In some cases, third-party scripts can pre-empt first-party ones in terms of priority and bandwidth on the main thread, also delaying how soon a page is interaction-ready. Attempt to prioritize loading what you believe offers the greatest value to users first.

Use a web worker #

A blocked main thread is one of the main causes of input delay. Web workers make it possible to run JavaScript on a background thread. Moving non-UI operations to a separate worker thread can cut down main thread blocking time and consequently improve FID.

Consider using the following libraries to make it easier to use web workers on your site:

Comlink: A helper library that abstracts postMessage and makes it easier to use
Workway: A general purpose web worker exporter
Workerize: Move a module into a web worker

Reduce JavaScript execution time #

Limiting the amount of JavaScript on your page reduces the amount of time that the browser needs to spend executing JavaScript code. This speeds up how fast the browser can begin to respond to any user interactions.

To reduce the amount of JavaScript executed on your page:

Defer unused JavaScript
Minimize unused polyfills

Defer unused JavaScript #

By default all JavaScript is render-blocking. When the browser encounters a script tag that links to an external JavaScript file, it must pause what it's doing and download, parse, compile, and execute that JavaScript. Therefore you should only load the code that's needed for the page or responding to user input.

The Coverage tab in Chrome DevTools can tell you how much JavaScript is not being used on your web page.

To cut down on unused JavaScript:

Code-split your bundle into multiple chunks
Defer any non-critical JavaScript, including third-party scripts, using async or defer

Code-splitting is the concept of splitting a single large JavaScript bundle into smaller chunks that can be conditionally loaded (also known as lazy loading). Most newer browsers support dynamic import syntax, which allows for module fetching on demand:

import('module.js').then((module) => {
  // Do something with the module.
});

Dynamically importing JavaScript on certain user interactions (such as changing a route or displaying a modal) will make sure that code not used for the initial page load is only fetched when needed.

Aside from general browser support, dynamic import syntax can be used in many different build systems.

If you use webpack, Rollup, or Parcel as a module bundler, take advantage of their dynamic import support.
Client-side frameworks, like React, Angular, and Vue provide abstractions to make it easier to lazy-load at the component-level.

Aside from code-splitting, always use async or defer for scripts that are not necessary for critical-path or above-the-fold content.

<script defer src="…"></script>
<script async src="…"></script>

Unless there is a specific reason not to, all third-party scripts should be loaded with either defer or async by default.

Minimize unused polyfills #

If you author your code using modern JavaScript syntax and reference modern browsers APIs, you will need to transpile it and include polyfills in order for it to work in older browsers.

One of the main performance concerns of including polyfills and transpiled code in your site is that newer browsers shouldn't have to download it if they do not need it. To cut down on the JavaScript size of your application, minimize unused polyfills as much as possible and restrict their usage to environments where they're needed.

To optimize polyfill usage on your site:

If you use Babel as a transpiler, use @babel/preset-env to only include the polyfills needed for the browsers you plan on targeting. For Babel 7.9, enable the bugfixes option to further cut down on any unneeded polyfills
Use the module/nomodule pattern to deliver two separate bundles (@babel/preset-env also supports this via target.esmodules)
```
<script type="module" src="modern.js"></script>
<script nomodule src="legacy.js" defer></script>
```
Many newer ECMAScript features compiled with Babel are already supported in environments that support JavaScript modules. So by doing this, you simplify the process of making sure that only transpiled code is used for browsers that actually need it.

Developer tools #

A number of tools are available to measure and debug FID:

Lighthouse 6.0 does not include support for FID since it is a field metric. However, Total Blocking Time (TBT) can be used as a proxy. Optimizations that improve TBT should also improve FID in the field.
Chrome User Experience Report provides real-world FID values aggregated at the origin-level

With thanks to Philip Walton, Kayce Basques, Ilya Grigorik, and Annie Sullivan for their reviews.

Shopping for speed on eBay.com

2020-01-22T00:00:00Z

Speed was a company-wide initiative for eBay in 2019, with many teams determined to make the site and apps as fast as possible for users. In fact, for every 100 milliseconds improvement in search page loading time, eBay saw a 0.5% increase in "Add to Cart" count.

100_ms

Improvement in load time

0.5_%

Increase in "Add to Cart" count

Through the adoption of Performance Budgets (derived after doing a competitive study with the Chrome User Experience Report) and a focus on key user-centric performance metrics, eBay was able to make significant improvements to site speed.

eBay's speed improvements.

…and their Chrome User Experience Report data highlights these improvements, too.

Chrome User Experience Report data for First Contentful Paint and First Input Delay for the eBay.com origin.

There's still more work ahead but here's eBay's learnings so far.

Web Performance "cuts" #

The improvements eBay made were possible due to the reduction or "cuts" (in the size and time) of various entities that take part in a user's journey. This post covers topics that are relevant to the web developer community at large, rather than eBay-specific topics.

Reduce payload across all text resources #

One way to make sites fast is to simply load less code. eBay reduced their text payloads by trimming all the unused and unnecessary bytes of JavaScript, CSS, HTML, and JSON responses served to users. Previously, with every new feature, eBay kept increasing the payload of their responses, without cleaning up what was unused. This added up over time and became a performance bottleneck. Teams usually procrastinated on this cleanup activity, but you'd be surprised by how much eBay saved.

The "cut" here is the wasted bytes in the response payload.

Critical path optimization for above-the-fold content #

Not every pixel on the screen is equally important. The content above-the-fold is more critical than something below-the-fold. iOS/Android/desktop and web apps are aware of this, but what about services? eBay's service architecture has a layer called Experience Services, which the frontends (platform-specific apps and web servers) talk to. This layer is specifically designed to be view- or device-based, rather than entity-based like item, user, or order. eBay then introduced the concept of the critical path for Experience Services. When a request comes to these services, they work on getting the data for above-the-fold content immediately, by calling other upstream services in parallel. Once data is ready, it is instantly flushed. The below-the-fold data is sent in a later chunk or lazy-loaded. The outcome: users get to see above-the-fold content quicker.

The "cut" here is the time spent by services to display relevant content.

Image optimizations #

Images are one of the largest contributors to page bloat. Even small optimizations go a long way. eBay did two optimizations for images.

First, eBay standardized on the WebP image format for search results across all platforms, including iOS, Android, and supported browsers. The search results page is the most image-heavy page at eBay, and they were already using WebP, but not in a consistent pattern.

WebP images being served to supported browsers on eBay.com.

Second, though eBay's listing images are heavily optimized (in both size and format), the same rigor did not apply for curated images (for example, the top module on the homepage). eBay has a lot of hand-curated images, which are uploaded through various tools. Previously the optimizations were up to the uploader, but now eBay enforces the rules within the tools, so all images uploaded will be optimized appropriately.

The "cut" here is the wasted image bytes sent to users.

Predictive prefetch of static assets #

A user session on eBay is not just one page. It is a flow. For example, the flow can be a navigation from the homepage to a search page to an item page. So why don't pages in the flow help each other? That is the idea of predictive prefetch, where one page prefetches the static assets required for the next likely page.

With predictive prefetch, when a user navigates to the predicted page, the assets are already in the browser cache. This is done for CSS and JavaScript assets, where the URLs can be retrieved ahead of time. One thing to note here is that it helps only on first-time navigations. On subsequent navigations, the static assets will already be in the cache.

The "cut" here is the network time for CSS and JavaScript static assets on the first navigation.

Prefetching top search results #

When a user searches eBay, eBay's analytics data suggests that it is highly likely that the user will navigate to an item in the top 10 of the search results. So eBay now prefetches the items from search and keeps them ready for when the user navigates. The prefetching happens at two levels.

The first level happens server-side, where the item service caches the top 10 items in search results. When the user goes to one of those items, eBay now saves server processing time. Server-side caching is leveraged by platform-specific apps and is rolled out globally.

The other level happens in the browser cache, which is available in Australia. Item prefetch was an advanced optimization due to the dynamic nature of items. There are also many nuances to it: page impressions, capacity, auction items, and so on. You can learn more about it in LinkedIn's Performance Engineering Meetup presentation, or stay tuned for a detailed blog post on the topic from eBay's engineers.

The "cut" here can either be server processing time or network time, depending on where the item is cached.

Eager downloading of search images #

In the search results page, when a query is issued at a high level, two things happen. One is the recall/ranking step, where the most relevant items matching the query are returned. The second step is augmenting the recalled items with additional user-context related information such as shipping costs. eBay now immediately sends the first 10 item images to the browser in a chunk along with the header, so the downloads can start before the rest of the markup arrives. As a result, the images will now appear quicker. This change is rolled out globally for the web platform.

The "cut" here is the download start time for search result images.

Edge caching for autosuggestion data #

When users type in letters in the search box, suggestions pop-up. These suggestions do not change for letter combinations for at least a day. They are ideal candidates to be cached and served from a CDN (for a max of 24 hours), instead of requests going all the way to a data center. International markets especially benefit from CDN caching.

There was a catch, though. eBay had some elements of personalization in the suggestions pop-up, which can't be cached efficiently. Fortunately, it was not an issue in the platform-specific apps, as the user interface for personalization and suggestions could be separated. For the web, in international markets, latency was more important than the small benefit of personalization. With that out of the way, eBay now has autosuggestions served from a CDN cache globally for platform-specific apps and non-US markets for eBay.com.

The "cut" here is the network latency and server processing time for autosuggestions.

Edge caching for unrecognized homepage users #

For the web platform, the homepage content for unrecognized users is the same for a particular region. These are users who are either using eBay for the first time or starting a fresh session, hence no personalization. Though the homepage creatives keep changing frequently there is still room for caching.

eBay decided to cache the unrecognized user content (HTML) on their edge network (PoPs) for a short period. First-time users can now get homepage content served from a server near them, instead of from a faraway data center. eBay is still experimenting with this in international markets, where it will have a bigger impact.

The "cut" here is again both network latency and server processing time for unrecognized users.

Optimizations for other platforms #

iOS/Android app parsing improvements #

iOS/Android apps talk to backend services whose response format is typically JSON. These JSON payloads can be large. Instead of parsing the whole JSON to render something on the screen, eBay introduced an efficient parsing algorithm that optimizes for content that needs to be displayed immediately.

Users can now see the content quicker. In addition, for the Android app, eBay starts initializing the search view controllers as soon as the user starts typing in the search box (iOS already had this optimization). Previously this happened only after users pressed the search button. Now users can get to their search results faster. The "cut" here is the time spent by devices to display relevant content.

Android app startup time improvements #

This applies to cold start time optimizations for Android apps. When an app is cold started, a lot of initialization happens both at the OS level and application level. Reducing the initialization time at the application level helps users see the home screen quicker. eBay did some profiling and noticed that not all initializations are required to display content and that some can be done lazily.

More importantly, eBay observed that there was a blocking third-party analytics call that delayed the rendering on the screen. Removing the blocking call and making it async further helped cold start times. The "cut" here is the unnecessary startup time for Android apps.

Conclusions #

All the performance "cuts" eBay made collectively contributed towards moving the needle, and it happened over a period of time. The releases were phased in throughout the year, with each release shaving off tens of milliseconds, ultimately reaching the point where eBay is now:

The impact of eBay's speed efforts on their field metrics over time, as illustrated by the Chrome UX Report Dashboard.

Performance is a feature and a competitive advantage. Optimized experiences lead to higher user engagement, conversions, and ROI. In eBay's case, these optimizations varied from things that were low-effort to a few that were advanced.

Check out Speed by a thousand cuts to learn more and be on the lookout for more detailed articles by eBay engineers on their performance work in the near future.

Accessibility tips for web developers

2019-12-06T00:00:00Z

It's awesome to build sites that are inclusive and accessible to everyone. There are at least six key areas of disability you can optimize for: visual, hearing, mobility, cognition, speech, and neural. Many tools and resources can help here, even if you're totally new to web accessibility.

Over one billion people live with some form of disability. You might have been in a loud room at some point trying to hear the conversation around you or in a low-lighting condition trying to find something in the dark. Do you remember the frustration you felt with that circumstance? Now imagine if that temporary condition were permanent. How different would your experience on the web be?

To be accessible, sites need to work across multiple devices with varying screen sizes and different kinds of input, such as screen readers. Moreover, sites should be usable by the broadest group of users, including those with disabilities. Here's a sample of just a few disabilities your users may have:

Vision	Hearing	Mobility
Low vision Blindness Color blindness Cataracts Sun glare	Hard of hearing Deafness Noise Ear infection	Spinal cord injury Limited dexterity Hands full
Cognitive	Speech	Neural
Learning disability Sleepiness or distraction Migraine Autism Seizure	Ambient noise Sore throat Speech impediment Unable to speak	Depression PTSD Bipolar disorder Anxiety

Visual issues range from an inability to distinguish colors to no vision at all.

Ensure text content meets a minimum contrast ratio threshold.
Avoid communicating information using solely color and ensure that all text is resizable.
Ensure all user interface components can be used with assistive technologies such as screen readers, magnifiers, and braille displays. This entails ensuring that UI components are marked up such that accessibility APIs can programmatically determine the role, state, value, and title of any element.

Tip: The element inspection feature in the Chrome, Edge, and Firefox developer tools displays a tooltip of CSS properties that includes a quick check for color contrast ratio.

I personally live with low vision, and I often find myself zooming in on sites, their DevTools, and the terminal. While supporting zoom is almost never at the top of developers' to-do lists, it can make a world of difference to users like me.🤓

Hearing issues mean a user may have issues hearing sound emitted from a page.

Provide text alternatives for all content that is not strictly text.
Test that your UI components are still functional without sound.

Mobility issues can include the inability to operate a mouse, a keyboard, or a touch screen.

Make the content of your UI components functionally accessible from a keyboard for any actions one would otherwise use a mouse for.
Ensure pages are correctly marked up for assistive technologies—including screen readers, voice control software, and physical switch controls—which tend to use the same APIs.

Cognitive issues mean a user may require assistive technologies to help them with reading text, so it's important to ensure text alternatives exist.

Be mindful when using animations. Avoid video and animation that repeat or flash, which can cause issues for some users.

The prefers-reduced-motion CSS media query allows you to limit animations and autoplaying videos for users who prefer reduced motion:
```
/*
If the user expresses a preference for reduced motion, don't use animations on buttons.
*/
@media (prefers-reduced-motion: reduce) {
  button {
    animation: none;
  }
}
```
Avoid interactions that are timing-based.

This may seem like a lot of bases to cover, but we'll walk through the process for assessing and then improving the accessibility of your UI components.

Tip: The GOV.UK accessibility team has made some great accessibility dos and don'ts digital posters to spread awareness of best practices in your team:

Are your UI components accessible? #

Summary

When auditing your page's UI components for accessibility, ask yourself:

Can you use your UI component with the keyboard only?

Does the component manage focus and avoid focus traps? Can it respond to the appropriate keyboard events?
Can you use your UI component with a screen reader?

Have you provided text alternatives for any information presented visually? Have you added semantic information using ARIA?
Can your UI component work without sound?

Turn off your speakers and go through your use cases.
Can your UI component work without color?

Ensure your UI component can be used by someone who cannot see colors. A helpful tool for simulating color blindness is a Chrome extension called SEE. (Try all four forms of color blindness simulation available.) You may also be interested in the Daltonize extension, which is similarly useful.
Can your UI component work with high-contrast mode enabled?

All modern operating systems support a high contrast mode. High Contrast is a Chrome extension that can help here.

Standardized controls (such as <button> and <select>) have accessibility built in by the browser. They are focusable using the Tab key; they respond to keyboard events (like the Enter, Space, and arrow keys); and they have semantic roles, states, and properties used by accessibility tools. Their default styling should also meet the accessibility requirements listed above.

Custom UI components (with the exception of components that extend standard elements like <button>) do not have any built-in functionality, including accessibility, so you need to provide it. A good place to start when implementing accessibility is to compare your component to an analogous standard element (or a combination of several standard elements, depending on how complex your component is).

Tip: Most browser developer tools support inspecting the accessibility tree of a page. In Chrome DevTools, this is available via the Accessibility tab in the Elements panel:

Firefox also has an Accessibility panel:

Safari exposes accessibility information in the Elements panel's Node tab.

The following is a list of questions you can ask yourself when attempting to make your UI components more accessible.

Can your UI component be used with the keyboard alone? #

Ideally, ensure that all functionality in your UI component can be accessed via keyboard. When designing your user experience, think about how you would use your element with the keyboard alone and figure out a consistent set of keyboard interactions.

First, ensure that you have a sensible focus target for each component. For example, a complex component like a menu may be one focus target within a page but should then manage focus within itself so that the active menu item always takes focus.

Managing focus within a complex element.

Using tabindex #

The tabindex attribute allows elements and UI components to be focused using the keyboard. Keyboard-only and assistive technology users both need to be able to place keyboard focus on elements to interact with them. Built-in interactive elements (like <button>) are implicitly focusable, so they don't need a tabindex attribute unless you wish to change their position in the tab order.

There are three types of tabindex values:

tabindex="0" is the most common and places the element in the natural tab order (defined by the DOM order).
a tabindex value greater than 0 places the element in a manual tab order—all elements in the page with a positive tabindex value are visited in numerical order before elements in the natural tab order.
a tabindex value equal to -1 causes the element to be programmatically focusable, but not in the tab order.

For custom UI components, always use tabindex values of 0 or -1, as you won't be able to determine the order of elements on a given page ahead of time—and even if you did, the order may change. A tabindex value of -1 is particularly useful for managing focus within complex components as described above.

Also ensure that focus is always visible, whether by allowing the default focus ring style or by applying a discernible custom focus style. Remember not to trap keyboard users—they should be able to move focus away from an element using only the keyboard.

Using autofocus #

The HTML autofocus attribute allows an author to specify that a particular element should automatically take focus when the page is loaded. autofocus is already supported on all web form controls, including buttons. To autofocus elements in your own custom UI components, call the focus() method, supported on all HTML elements that can be focused (for example, document.querySelector('myButton').focus()).

Adding keyboard interaction #

Once your UI component is focusable, provide a good keyboard interaction story when a component is focused by handling appropriate keyboard events. For example, allow the user to use arrow keys to select menu options and Space or Enter to activate buttons. The ARIA design patterns guide provides some guidance here.

Finally, ensure that your keyboard shortcuts are discoverable. A common practice is to have a keyboard shortcut legend (on-screen text) to inform the user that shortcuts exist. For example, "Press ? for keyboard shortcuts." Alternatively, a hint such a tooltip can be used to inform the user about a shortcut.

The importance of managing focus cannot be overstated. One example is a navigation drawer. If you add a UI component to the page, you need to direct focus to an element inside of it; otherwise, users may have to tab through the entire page to get there. This can be a frustrating experience, so be sure to test focus for all keyboard navigable components in your page.

Tip: You can use Puppeteer to automate running keyboard accessibility tests for toggling UI states. WalkMe Engineering has a great guide on this I recommend reading.

// Example for expanding and collapsing a category with the Space key
const category = await page.$(`.category`);

// verify tabIndex, role and focus
expect(await page.evaluate(elem => elem.getAttribute(`role`), category)).toEqual(`button`);
expect(await page.evaluate(elem => elem.getAttribute(`tabindex`), category)).toEqual(`0`);
expect(await page.evaluate(elem => window.document.activeElement === elem, category)).toEqual(true);

// verify aria-expanded = false
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`false`);

// toggle category by pressing Space
await page.keyboard.press('Space');

// verify aria-expanded = true
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`true`);

Around 1–2% of people use a screen reader. Can you understand all important information and interact with the component using the screen reader and keyboard alone?

The following questions should help you address screen reader accessibility.

Do all components and images have meaningful text alternatives? #

Wherever information about the name or purpose of an interactive component is conveyed visually, provide an accessible text alternative.

For example, if your <fancy-menu> UI component only displays a gear icon to indicate that it's a settings menu, it needs an accessible text alternative, such as "settings," that conveys the same information. Depending on context, you can provide a text alternative using an alt attribute, an aria-label attribute, an aria-labelledby attribute, or plain text in the Shadow DOM. You can find general technical tips in WebAIM Quick Reference.

Any UI component that displays an image should provide a mechanism for providing alternative text for that image, analogous to the alt attribute.

Do your components provide semantic information? #

Assistive technology conveys semantic information that is otherwise expressed to sighted users via visual cues such as formatting, cursor style, or position. Standardized elements have this semantic information built-in by the browser, but for custom components you need to use ARIA to add the information.

As a rule of thumb, any component that listens to a mouse click or hover event should not only have some kind of keyboard event listener, but also an ARIA role and potentially ARIA states and attributes.

For example, a custom <fancy-slider> UI component might take an ARIA role of slider, which has some related ARIA attributes: aria-valuenow, aria-valuemin and aria-valuemax. By binding these attributes to the relevant properties on your custom component, you can allow users of assistive technology to interact with the element, change its value, and even cause the element's visual presentation to change accordingly.

A range slider component.

<fancy-slider role="slider" aria-valuemin="1" aria-valuemax="5" aria-valuenow="2.5"></fancy-slider>

Can users understand everything without relying on color? #

Color shouldn't be used as the only means of conveying information, such as indicating a status, prompting the user for a response, or visualizing data. For example, if you have a pie chart, provide labels and values for each slice so users who have visual impairments can understand the information even if they can't tell where the slices begin and end:

An accessible pie chart. (From the W3C Web Accessibility Initiative.)

Is there sufficient contrast between text and images and their background? #

Any text content displayed in your component should meet the minimum WCAG AA-level contrast threshold. Consider providing a high-contrast theme that meets the higher AAA threshold, and ensure that user agent style sheets can be applied if users require custom contrast or different colors. You can use this Color Contrast Checker as an aid when designing your component.

Is the moving or flashing content in your components stoppable and safe? #

Content that moves, scrolls, or blinks for more than five seconds should be able to be paused, stopped or hidden. In general, avoid flashing content. If something must flash, make sure it flashes no more than three times per second.

Accessibility Tooling #

A number of tools are available that can assist with debugging the accessibility of your visual components.

Axe provides automated accessibility testing for your framework or browser of choice. Axe Puppeteer can be used for writing automated accessibility tests.
The Lighthouse Accessibility audits provide helpful insights for discovering common accessibility issues. The accessibility score is a weighted average of all accessibility audits based on Axe user impact assessments. For monitoring accessibility via continuous integration, see Lighthouse CI.

Tenon.io is useful for testing common accessibility problems. Tenon has strong integration support across build tools, browsers (via extensions), and even text editors.
There are many library- and framework-specific tools for highlighting accessibility issues with components. For example, web.dev explains how to use eslint-plugin-jsx-a11y to highlight accessibility issues for React components in your editor:

If you use Angular, codelyzer provides in-editor accessibility audits too:
You can examine the way that assistive technologies see web content by using Accessibility Inspector (Mac) or Windows Automation API Testing Tools and AccProbe (Windows). You can also see the full accessibility tree that Chrome creates by navigating to about://accessibility.
The best way to test for screen reader support on a Mac is using the VoiceOver utility. Use ⌘F5 to enable or disable it, Ctrl+Option ←→ to move through the page, and Ctrl+Shift+Option + ↑↓ to move up and down the accessibility tree. For more detailed instructions, see the full list of VoiceOver commands and the list of VoiceOver Web commands.
tota11y is a useful visualizer for assistive technology issues built by Khan Academy. It's a script that adds a button to your document that triggers several plugins for annotating things like insufficient contrast ratio and other a11y violations.
On Windows, NVDA is a free, open source screen reader that's fully featured and rapidly gaining in popularity. However, note that it has a much steeper learning curve for sighted users than VoiceOver.
ChromeLens helps develop for the visually impaired. It also has great support for visualizing keyboard navigation paths.
ChromeVox is a screen reader available as a Chrome extension and built into ChromeOS devices.

Conclusions #

We still have a long way to go to improve accessibility on the web. Per the Web Almanac:

4 out of every 5 sites have text that easily blends into the background, making it unreadable.
49.91% of pages still fail to provide alt attributes for some of their images.
Only 24% of pages that use buttons or links include textual labels for them.
Only 22.33% of pages provide labels for all their form inputs.

To learn more about accessibility fundamentals and help improve those statistics, I recommend the Accessible to all docs on web.dev. There's much we can do to build experiences that are more accessible for everyone.

Browser-level image lazy loading for the web

2019-08-06T00:00:00Z

Browser-level support for lazy loading images is now supported on the web! This video shows a demo of the feature:

You can use the loading attribute to lazy-load images without the need to write custom lazy loading code or use a separate JavaScript library. Let's dive into the details.

Browser compatibility #

Browser support

Chrome 77, Supported 77
Firefox 75, Supported 75
Edge 79, Supported 79
Safari 15.4, Supported 15.4

Source

Browsers that do not support the loading attribute simply ignore it without side effects.

Why browser-level lazy loading? #

According to the HTTP Archive, images are the most requested asset type for most websites and usually take up more bandwidth than any other resource. At the 90th percentile, sites send over 5 MB of images on desktop and mobile. That's a lot of cat pictures.

Previously, there were two ways to defer the loading of off-screen images:

Using the Intersection Observer API
Using scroll, resize, or orientationchange event handlers

Either option can let developers include lazy loading functionality, and many developers have built third-party libraries to provide abstractions that are even easier to use. With lazy loading supported directly by the browser, however, there's no need for an external library. Browser-level lazymloading also ensures that deferred loading of images still works even if JavaScript is disabled on the client.

The `loading` attribute #

Chrome loads images at different priorities depending on where they're located with respect to the device viewport. Images below the viewport are loaded with a lower priority, but they're still fetched as the page loads.

You can use the loading attribute to completely defer the loading of offscreen images that are reached by scrolling:

<img src="image.png" loading="lazy" alt="…" width="200" height="200">

Here are the supported values for the loading attribute:

lazy: Defer loading of the resource until it reaches a calculated distance from the viewport.
eager: Default loading behavior of the browser, which is the same as not including the attribute and means the image is loaded regardless of where it's located on the page. While this is the default, it can be useful to explicitly set this if your tooling automatically adds loading="lazy" if there is no explicit value, or if your linter complains if it is not explicitly set.

Relationship between the `loading` attribute and fetch priority #

The eager value is simply an instruction to load the image as usual, without delaying the load further if it is off-screen. It does not imply that the image is loaded any quicker than another image without the loading="eager" attribute.

Browsers prioritize resources based on various heuristics, and the loading attribute just states when the image resource is queued, not how it is prioritized in that queue. eager just implies the usual eager queueing browsers use by default.

If you want to increase the fetch priority of an important image (for example the LCP image), then Fetch Priority should be used with fetchpriority="high".

Note that an image with loading="lazy" and fetchpriority="high" will still be delayed while it is off-screen, and then fetched with a high priority when it is nearly within the viewport. It would likely be fetched with a high priority in this case anyway, so this combination should not really be needed nor used.

Distance-from-viewport thresholds #

All images that are above the fold—that is, immediately viewable without scrolling—load normally. Those that are far below the device viewport are only fetched when the user scrolls near them.

Chromium's implementation of lazy loading tries to ensure that offscreen images are loaded early enough so that they have finished loading once the user scrolls near to them. By fetching nearby images well before they become visible in the viewport, we maximize the chance they are already loaded by the time they become visible.

Compared to JavaScript lazy loading libraries, the thresholds for fetching images that scroll into view may be considered conservative.

The distance threshold is not fixed and varies depending on several factors:

The type of image resource being fetched
The effective connection type

You can find the default values for the different effective connection types in the Chromium source. These numbers, and even the approach of fetching only when a certain distance from the viewport is reached, may change in the future as the Chrome team improves heuristics to determine when to begin loading.

Improved data-savings and distance-from-viewport thresholds #

As of July 2020, Chrome has made significant improvements to align the image lazy loading distance-from-viewport thresholds to better meet developer expectations.

On fast connections (4G), we reduced Chrome's distance-from-viewport thresholds from 3000px to 1250px and on slower connections (3G or lower), changed the threshold from 4000px to 2500px. This change achieves two things:

<img loading=lazy> behaves closer to the experience offered by JavaScript lazy loading libraries.
The new distance-from-viewport thresholds still allow us to guarantee images have probably loaded by the time a user has scrolled to them.

You can find a comparison between the old vs. new distance-from-viewport thresholds for one of our demos on a fast connection (4G) below:

Old thresholds. vs new thresholds:

and the new thresholds vs. LazySizes (a popular JS lazy loading library):

We are committed to working with the web standards community to explore better alignment in how distance-from-viewport thresholds are approached across different browsers.

Images should include dimension attributes #

While the browser loads an image, it does not immediately know the image's dimensions, unless these are explicitly specified. To enable the browser to reserve sufficient space on a page for images, it is recommended that all <img> tags include both width and height attributes. Without dimensions specified, layout shifts can occur, which are more noticeable on pages that take some time to load.

<img src="image.png" loading="lazy" alt="…" width="200" height="200">

Alternatively, specify their values directly in an inline style:

<img src="image.png" loading="lazy" alt="…" style="height:200px; width:200px;">

The best practice of setting dimensions applies to <img> tags regardless of whether or not they are being loaded lazily. With lazy loading, this can become more relevant. Setting width and height on images in modern browsers also allows browsers to infer their intrinsic size.

In most scenarios images still lazy-load if dimensions are not included, but there are a few edge cases you should be aware of. Without width and height specified, image dimensions are 0×0 pixels at first. If you have a gallery of such images, the browser may conclude that all of them fit inside the viewport at the start, as each takes up practically no space and no image is pushed offscreen. In this case the browser determines that all of them are visible to the user and decides to load everything.

Also, specifying image dimensions decreases the chances of layout shifts happening. If you are unable to include dimensions for your images, lazy loading them can be a trade-off between saving network resources and potentially being more at risk of layout shift.

While lazy loading in Chromium is implemented in a way such that images are likely to be loaded once they are visible, there is still a small chance that they might not be loaded yet. In this case, missing width and height attributes on such images increase their impact on Cumulative Layout Shift.

Images that are defined using the <picture> element can also be lazy-loaded:

<picture>
  <source media="(min-width: 800px)" srcset="large.jpg 1x, larger.jpg 2x">
  <img src="photo.jpg" loading="lazy">
</picture>

Although a browser will decide which image to load from any of the <source> elements, the loading attribute only needs to be included to the fallback <img> element.

Avoid lazy loading images that are in the first visible viewport #

You should avoid setting loading=lazy for any images that are in the first visible viewport. This is particularly relevant for LCP images. See the article The performance effects of too much lazy-loading for more information.

It is recommended to only add loading=lazy to images which are positioned below the fold, if possible. Images that are eagerly loaded can be fetched right away, while images which are loaded lazily the browser currently needs to wait until it knows where the image is positioned on the page, which relies on the IntersectionObserver to be available.

Generally, any images within the viewport should be loaded eagerly using the browser's defaults. You do not need to specify loading=eager for this to be the case for in-viewport images.

<!-- visible in the viewport -->
<img src="product-1.jpg" alt="..." width="200" height="200">
<img src="product-2.jpg" alt="..." width="200" height="200">
<img src="product-3.jpg" alt="..." width="200" height="200">

<!-- offscreen images -->
<img src="product-4.jpg" loading="lazy" alt="..." width="200" height="200">
<img src="product-5.jpg" loading="lazy" alt="..." width="200" height="200">
<img src="product-6.jpg" loading="lazy" alt="..." width="200" height="200">

Graceful degradation #

Browsers that do not support the loading attribute will ignore its presence. While these browsers will of course not get the benefits of lazy loading, including the attribute has no negative impact on them.

FAQ #

Are there plans to automatically lazy-load images in Chrome? #

Previously, Chromium automatically lazy-loaded any images that were well suited to being deferred if Lite mode was enabled on Chrome for Android and the loading attribute was either not provided or set as loading="auto". However, Lite mode has been deprecated (as was the non-standard loading="auto") and there are currently no plans to provide automatically lazy-load of images in Chrome.

Can I change how close an image needs to be before a load is triggered? #

These values are hardcoded and can't be changed through the API. However, they may change in the future as browsers experiment with different threshold distances and variables.

Can CSS background images take advantage of the `loading` attribute? #

No, it can currently only be used with <img> tags.

Is there a downside to lazy loading images that are within the device viewport? #

It is safer to avoid putting loading=lazy on above-the-fold images, as Chrome won't preload loading=lazy images in the preload scanner and will also delay fetching such images until all layout is complete. See Avoid lazy-loading images that are in the first visible viewport for more information.

How does the `loading` attribute work with images that are in the viewport but not immediately visible (for example: behind a carousel, or hidden by CSS for certain screen sizes)? #

Using loading="lazy" may prevent them being loaded when they are not visible but within the calculated-distance. For example, Chrome, Safari and Firefox do not load images using display: none; styling—either on the image element or on a parent element. However, other techniques to hide images—such as using opacity:0 styling—will still result in the images being loaded. Always test your implementation thoroughly to ensure it's acting as intended.

What if I'm already using a third-party library or a script to lazy-load images? #

With full support of native lazy loading now available in modern browsers, you may wish to reconsider if you still need a third-party library or script to lazy-load images.

One reason to continue to use a third-party library along with loading="lazy" is to provide a polyfill for browsers that do not support the attribute, or to have more control over when lazy loading is triggered.

How do I handle browsers that don't support lazy loading? #

Create a polyfill or use a third-party library to lazy-load images on your site. The loading property can be used to detect if the feature is supported in the browser:

if ('loading' in HTMLImageElement.prototype) {
  // supported in browser
} else {
  // fetch polyfill/third-party library
}

For example, lazysizes is a popular JavaScript lazy loading library. You can detect support for the loading attribute to load lazysizes as a fallback library only when loading isn't supported. This works as follows:

Replace <img src> with <img data-src> to avoid an eager load in unsupported browsers. If the loading attribute is supported, swap data-src for src.
If loading is not supported, load a fallback (lazysizes) and initiate it. As per lazysizes docs, you use the lazyload class as a way to indicate to lazysizes which images to lazy-load.

<!-- Let's load this in-viewport image normally -->
<img src="hero.jpg" alt="…">

<!-- Let's lazy-load the rest of these images -->
<img data-src="unicorn.jpg" alt="…" loading="lazy" class="lazyload">
<img data-src="cats.jpg" alt="…" loading="lazy" class="lazyload">
<img data-src="dogs.jpg" alt="…" loading="lazy" class="lazyload">

<script>
  if ('loading' in HTMLImageElement.prototype) {
    const images = document.querySelectorAll('img[loading="lazy"]');
    images.forEach(img => {
      img.src = img.dataset.src;
    });
  } else {
    // Dynamically import the LazySizes library
    const script = document.createElement('script');
    script.src =
      'https://cdnjs.cloudflare.com/ajax/libs/lazysizes/5.1.2/lazysizes.min.js';
    document.body.appendChild(script);
  }
</script>

Here's a demo of this pattern. Try it out in an older browser to see the fallback in action.

Is lazy loading for iframes also supported in browsers? #

Browser support

Chrome 77, Supported 77
Firefox, Not supported
Edge 79, Supported 79
Safari 16.4, Supported 16.4

<iframe loading=lazy> has also been standardized and is already implemented in Chromium and Safari. This allows you to lazy-load iframes using the loading attribute. See this dedicated article about iframe lazy-loading for more information.

How does browser-level lazy loading affect advertisements on a web page? #

All ads displayed to the user in the form of an image or iframe lazy-load just like any other image or iframe.

How are images handled when a web page is printed? #

All images and iframes are immediately loaded if the page is printed. See issue #875403 for details.

Does Lighthouse recognize browser-level lazy loading? #

Lighthouse 6.0 and above factor in approaches for offscreen image lazy loading that may use different thresholds, allowing them to pass the Defer offscreen images audit.

Conclusion #

Baking in support for lazy loading images can make it significantly easier for you to improve the performance of your web pages.

Are you noticing any unusual behavior with this feature enabled in Chrome? File a bug!

Are long JavaScript tasks delaying your Time to Interactive?

2019-05-29T00:00:00Z

Long Tasks can keep the main thread busy, delaying user interaction. Chrome DevTools can now visualize Long Tasks, making it easier to see tasks to optimize.

If you use Lighthouse to audit your pages, you may be familiar with Time to Interactive, a metric representing when users can interact with your page and get a response. But did you know Long (JavaScript) Tasks can contribute heavily to a poor TTI?

What are Long Tasks? #

A Long Task is JavaScript code that monopolizes the main thread for extended periods of time, causing the UI to "freeze".

While a web page is loading, Long Tasks can tie up the main thread and make the page unresponsive to user input even if it looks ready. Clicks and taps often don't work because event listeners, click handlers etc have not yet been attached.

CPU-heavy Long Tasks occur due to complex work that takes longer than 50ms. Why 50ms? The RAIL model suggests you process user input events in 50ms to ensure a visible response within 100ms. If you don't, the connection between action and reaction is broken.

Are there Long Tasks in my page that could delay interactivity? #

Until now, you've needed to manually look for "long yellow blocks" of script over 50ms long in Chrome DevTools or use the Long Tasks API to figure out what tasks were delaying interactivity. This could be a little cumbersome.

To help ease your performance auditing workflow, DevTools now visualizes Long Tasks. Tasks (shown in gray) have red flags if they are Long Tasks.

Record a trace in the Performance panel of loading up a web page.
Look for a red flag in the main thread view. You should see tasks are now gray ("Task").
Hovering over a bar will let you know the duration of the task and if it was considered "long".

What is causing my Long Tasks? #

To discover what is causing a long task, select the gray Task bar. In the drawer beneath, select Bottom-Up and Group by Activity. This allows you to see what activities contributed the most (in total) to the task taking so long to complete. Below, it appears to be a costly set of DOM queries.

What are common ways to optimize Long Tasks? #

Large scripts are often a major cause of Long Tasks so consider splitting them up. Also keep an eye on third-party scripts; their Long Tasks can delay primary content from getting interactive.

Break all your work into small chunks (that run in < 50ms) and run these chunks at the right place and time; the right place may even be off the main thread, in a worker. Phil Walton's Idle Until Urgent is a good read on this topic. See also the optimize long tasks article for general strategies for managing and breaking up long tasks.

Keep your pages responsive. Minimizing Long Tasks is a great way to ensure your users have a delightful experience when they visit your site. For more on Long Tasks, check out User-centric Performance Metrics.

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

2019-05-24T00:00:00Z

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

Lighthouse now supports Performance Budgeting #

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Watch for more #

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

Rendering on the Web

2019-02-06T00:00:00Z

As developers, we are often faced with decisions that will affect the entire architecture of our applications. One of the core decisions web developers must make is where to implement logic and rendering in their application. This can be difficult, since there are a number of different ways to build a website.

Our understanding of this space is informed by our work in Chrome talking to large sites over the past few years. Broadly speaking, we would encourage developers to consider server-side rendering or static rendering over a full rehydration approach.

In order to better understand the architectures we're choosing from when we make this decision, we need to have a solid understanding of each approach and consistent terminology to use when speaking about them. The differences between these approaches help illustrate the trade-offs of rendering on the web through the lens of performance.

Terminology #

Rendering

Server-side rendering (SSR): rendering a client-side or universal app to HTML on the server.
Client-side rendering (CSR): rendering an app in a browser via JavaScript to modify the DOM.
Rehydration: "booting up" JavaScript views on the client such that they reuse the server-rendered HTML's DOM tree and data.
Prerendering: running a client-side application at build time to capture its initial state as static HTML.

Performance

Time to First Byte (TTFB): seen as the time between clicking a link and the first bit of content coming in.
First Contentful Paint (FCP): the time when requested content (article body, etc) becomes visible.
Interaction to Next Paint (INP): seen as a representative metric that assesses whether a page is responding consistently fast to user inputs.
Total Blocking Time (TBT): A proxy metric for INP, which calculates the amount of time the main thread was blocked during page load.

Server-side rendering #

Server-side rendering generates the full HTML for a page on the server in response to navigation. This avoids additional round-trips for data fetching and templating on the client, since it's handled before the browser gets a response.

Server-side rendering generally produces a fast FCP. Running page logic and rendering on the server makes it possible to avoid sending lots of JavaScript to the client. This helps to reduce a page's TBT, which can also lead to a lower INP, as the main thread is not blocked as often during page load. When the main thread is blocked less often, user interactions will have more opportunities run sooner. This makes sense, since with server-side rendering, you're really just sending text and links to the user's browser. This approach can work well for a large spectrum of device and network conditions, and opens up interesting browser optimizations like streaming document parsing.

With server-side rendering, users are less likely to be left waiting for CPU-bound JavaScript to run before they can use your site. Even where third-party JS can't be avoided, using server-side rendering to reduce your own first-party JavaScript costs can give you more budget for the rest. However, there is one potential trade-off with this approach: generating pages on the server takes time, which can may result in a higher TTFB.

Whether server-side rendering is enough for your application largely depends on what type of experience you are building. There is a long-standing debate over the correct applications of server-side rendering versus client-side rendering, but it's important to remember that you can opt to use server-side rendering for some pages and not others. Some sites have adopted hybrid rendering techniques with success. Netflix server-renders its relatively static landing pages, while prefetching the JS for interaction-heavy pages, giving these heavier client-rendered pages a better chance of loading quickly.

Many modern frameworks, libraries and architectures make it possible to render the same application on both the client and the server. These techniques can be used for server-side rendering. However, it's important to note that architectures where rendering happens both on the server and on the client are their own class of solution with very different performance characteristics and tradeoffs. React users can use server DOM APIs or solutions built atop them like Next.js for server-side rendering. Vue users can look at Vue's server-side rendering guide or Nuxt. Angular has Universal. Most popular solutions employ some form of hydration though, so be aware of the approach in use before selecting a tool.

Static rendering #

Static rendering happens at build-time. This apporach offers a fast FCP, and also a lower TBT and INP—assuming the amount of client-side JS is limited. Unlike server-side rendering, it also manages to achieve a consistently fast TTFB, since the HTML for a page doesn't have to be dynamically generated on the server. Generally, static rendering means producing a separate HTML file for each URL ahead of time. With HTML responses generated in advance, static renders can be deployed to multiple CDNs to take advantage of edge caching.

Solutions for static rendering come in all shapes and sizes. Tools like Gatsby are designed to make developers feel like their application is being rendered dynamically rather than generated as a build step. Static site generation tools such as 11ty, Jekyll, and Metalsmith embrace their static nature, providing a more template-driven approach.

One of the downsides to static rendering is that individual HTML files must be generated for every possible URL. This can be challenging or even infeasible when you can't predict what those URLs will be ahead of time, or for sites with a large number of unique pages.

React users may be familiar with Gatsby, Next.js static export or Navi—all of these make it convenient to author pages using components. However, it's important to understand the difference between static rendering and prerendering: static rendered pages are interactive without the need to execute much client-side JavaScript, whereas prerendering improves the FCP of a Single Page Application that must be booted on the client in order for pages to be truly interactive.

If you're unsure whether a given solution is static rendering or prerendering, try disabling JavaScript and load the page you want to test. For statically rendered pages, most of the functionality will still exist without JavaScript enabled. For prerendered pages, there may still be some basic functionality like links, but most of the page will be inert.

Another useful test is to use network throttling in Chrome DevTools, and observe how much JavaScript has been downloaded before a page becomes interactive. Prerendering generally requires more JavaScript to become interactive, and that JavaScript tends to be more complex than the progressive enhancement approach used by static rendering.

Server-side rendering versus static rendering #

Server-side rendering is not a silver bullet—its dynamic nature can come with significant compute overhead costs. Many server-side rendering solutions don't flush early, can delay TTFB, or double the data being sent (for example, inlined state used by JavaScript on the client). In React, renderToString() can be slow as it's synchronous and single-threaded. Newer React server DOM APIs supporting streaming, which can get the initial part of an HTML response to the browser sooner while the rest of it is still being generated on the server.

Getting server-side rendering "right" can involve finding or building a solution for component caching, managing memory consumption, applying memoization techniques, and other concerns. You're generally processing/rebuilding the same application multiple times—once on the client and once on the server. Just because server-side rendering can make something show up sooner doesn't suddenly mean you have less work to do—if you have a lot of work on the client after a server-generated HTML response arrives on the client, this can still lead to higher TBT and INP for your website.

Server-side rendering produces HTML on-demand for each URL, but can be slower than just serving static rendered content. If you can put in the additional leg-work, server-side rendering plus HTML caching can significantly reduce server render time. The upside to server-side rendering is the ability to pull more "live" data and respond to a more complete set of requests than is possible with static rendering. Pages requiring personalization are a concrete example of the type of request that would not work well with static rendering.

Server-side rendering can also present interesting decisions when building a PWA: is it better to use full-page service worker caching, or just server-render individual pieces of content?

Client-side rendering #

Client-side rendering means rendering pages directly in the browser with JavaScript. All logic, data fetching, templating and routing are handled on the client rather than the server. The effective outcome is that more passed to the user's device from the server, and that comes with its own set of trade-offs.

Client-side rendering can be difficult to get and keep fast for mobile devices. If minimal work is done, client-side rendering can approach the performance of pure server-side rendering, keeping a tight JavaScript budget and delivering value in as few round-trips as possible. Critical scripts and data can be delivered sooner using <link rel=preload>, which gets the parser working for you sooner. Patterns like PRPL are also worth evaluating in order to ensure initial and subsequent navigations feel instant.

The primary downside to client-side rendering is that the amount of JavaScript required tends to grow as an application grows, which can have negative effects on a page's INP. This becomes especially difficult with the addition of new JavaScript libraries, polyfills and third-party code, which compete for processing power and must often be processed before a page's content can be rendered.

Experiences that use client-side rendering that rely on large JavaScript bundles should consider aggressive code-splitting to lower TBT and INP during page load, and be sure to lazy-load JavaScript—"serve only what you need, when you need it". For experiences with little or no interactivity, server-side rendering can represent a more scalable solution to these issues.

For folks building single page applications, identifying core parts of the user interface shared by most pages means you can apply the application shell caching technique. Combined with service workers, this can dramatically improve perceived performance on repeat visits, as the application shell HTML and its dependencies can be loaded from CacheStorage very quickly.

Combining server-side rendering and client-side rendering via rehydration #

This approach attempts to smooth over the trade-offs between client-side rendering and server-side rendering by doing both. Navigation requests like full page loads or reloads are handled by a server that renders the application to HTML, then the JavaScript and data used for rendering is embedded into the resulting document. When done carefully, this achieves a fast FCP just like server-side rendering, then "picks up" by rendering again on the client using a technique called (re)hydration. This is an effective solution, but it can come with considerable performance drawbacks.

The primary downside of server-side rendering with rehydration is that it can have a significant negative impact on TBT and INP, even if it improves FCP. Server-side rendered pages can deceptively appear to be loaded and interactive, but can't actually respond to input until the client-side scripts for components are executed and event handlers have been attached. This can take seconds or even minutes on mobile.

Perhaps you've experienced this yourself—for a period of time after it looks like a page has loaded, clicking or tapping does nothing. This quickly becoming frustrating, as the user is left to wonder why nothing is happening when they try to interact with the page.

A rehydration problem: one app for the price of two #

Rehydration issues can often be worse than delayed interactivity due to JavaScript. In order for the client-side JavaScript to be able to accurately "pick up" where the server left off without having to re-request all of the data the server used to render its HTML, current server-side rendering solutions generally serialize the response from a UI's data dependencies into the document as script tags. The resulting HTML document contains a high level of duplication:

As you can see, the server is returning a description of the application's UI in response to a navigation request, but it's also returning the source data used to compose that UI, and a complete copy of the UI's implementation which then boots up on the client. Only after bundle.js has finished loading and executing does this UI become interactive.

Performance metrics collected from real websites using server-side rendering and rehydration indicate its use should be discouraged. Ultimately, the reason comes down to the user experience: it's extremely easy to end up leaving users in an "uncanny valley", where interactivity feels absent even though the page appears to be ready.

There's hope for server-side rendering with rehydration, though. In the short term, only using server-side rendering for highly cacheable content can reduce TTFB, producing similar results to prerendering. Rehydrating incrementally, progressively, or partially may be the key to making this technique more viable in the future.

Streaming server-side rendering and progressive rehydration #

Server-side rendering has had a number of developments over the last few years.

Streaming server-side rendering allows you to send HTML in chunks that the browser can progressively render as it's received. This can result in a fast FCP, as markup arrives to users faster. In React, streams being asynchronous in [renderToPipeableStream()]—compared to synchronous renderToString()—means backpressure is handled well.

Progressive rehydration is also worth considering, and something that React has landed. With this approach, individual pieces of a server-rendered application are "booted up" over time, rather than the current common approach of initializing the entire application at once. This can help reduce the amount of JavaScript required to make pages interactive, since client-side upgrading of low priority parts of the page can be deferred to prevent blocking the main thread, allowing user interactions to occur sooner after the user initiates them.

Progressive rehydration can also help avoid one of the most common server-side rendering rehydration pitfalls, where a server-rendered DOM tree gets destroyed and then immediately rebuilt—most often because the initial synchronous client-side render required data that wasn't quite ready, perhaps awaiting resolution of a Promise.

Partial rehydration #

Partial rehydration has proven difficult to implement. This approach is an extension of the idea of progressive rehydration, where the individual pieces (components/views/trees) to be progressively rehydrated are analyzed and those with little interactivity or no reactivity are identified. For each of these mostly-static parts, the corresponding JavaScript code is then transformed into inert references and decorative functionality, reducing their client-side footprint to nearly zero.

The partial hydration approach comes with its own issues and compromises. It poses some interesting challenges for caching, and client-side navigation means we can't assume server-rendered HTML for inert parts of the application will be available without a full page load.

Trisomorphic rendering #

If service workers are an option for you, "trisomorphic" rendering may also be of interest. It's a technique where you can use streaming server-side rendering for initial/non-JS navigations, and then have your service worker take on rendering of HTML for navigations after it has been installed. This can keep cached components and templates up to date and enables SPA-style navigations for rendering new views in the same session. This approach works best when you can share the same templating and routing code between the server, client page, and service worker.

SEO considerations #

Teams often factor in the impact of SEO when choosing a strategy for rendering on the web. Server-side rendering is often chosen for delivering a "complete looking" experience crawlers can interpret with ease. Crawlers may understand JavaScript, but there are often limitations worth being aware of in how they render. Client-side rendering can work, but often not without additional testing and leg-work. More recently, dynamic rendering has also become an option worth considering if your architecture depends heavily on client-side JavaScript.

When in doubt, the mobile friendly test tool is invaluable for testing that your chosen approach does what you're hoping for. It shows a visual preview of how any page appears to Google's crawler, the serialized HTML content found (after JavaScript executed), and any errors encountered during rendering.

Wrapping up #

When deciding on an approach to rendering, measure and understand what your bottlenecks are. Consider whether static rendering or server-side rendering can get you most of the way there. It's perfectly okay to mostly ship HTML with minimal JavaScript to get an experience interactive. Here's a handy infographic showing the server-client spectrum:

Credits #

Thanks to everyone for their reviews and inspiration:

Jeffrey Posnick, Houssein Djirdeh, Shubhie Panicker, Chris Harrelson, and Sebastian Markbåge

Web Performance Made Easy - Google I/O 2018 edition

2018-08-21T00:00:00Z

We've been pretty busy over the past year trying to figure out how to make the Web faster and more performant. This led to new tools, approaches and libraries that we’d like share with you in this article. In the first part, we’ll show you some optimization techniques we used in practice when developing The Oodles Theater app. In the second part, we’ll talk about our experiments with predictive loading and the new Guess.js initiative.

The need for performance #

The Internet gets heavier and heavier every year. If we check the state of the web we can see that a median page on mobile weights at about 1.5MB, with the majority of that being JavaScript and images.

The growing size of the websites, together with other factors, like network latency, CPU limitations, render blocking patterns or superfluous third-party code, contributes to the complicated performance puzzle.

Most users rate speed as being at the very top of the UX hierarchy of their needs. This isn't too surprising, because you can't really do a whole lot until a page is finished loading. You can't derive value from the page, you can't admire its aesthetics.

Fig. 1. How important is speed to users? (Speed Matters, Vol. 3)

We know that performance matters to the users, but it can also feel like a secret discovering where to start optimizing. Fortunately, there are tools that can help you on the way.

Lighthouse - a base for performance workflow #

Lighthouse is a part of Chrome DevTools that allows you to make an audit of your website, and gives you hints on how to make it better.

We recently launched a bunch of new performance audits that are really useful in everyday development workflow.

Fig. 2. New Lighthouse audits

Let’s explore how you can take advantage of them on a practical example: The Oodles Theater app. It’s a little demo web app, where you can try out some of our favourite interactive Google Doodles and even play a game or two.

While building the app, we wanted to make sure that it was as performant as possible. The starting point for optimization was a Lighthouse report.

Fig. 3. Lighthouse report for Oodles app

The initial performance of our app as seen on Lighthouse report was pretty terrible. On a 3G network, the user needed to wait for 15 seconds for the first meaningful paint, or for the app to get interactive. Lighthouse highlighted a ton of issues with our site, and the overall performance score of 23 mirrored exactly that.

The page weighted about 3.4MB - we desperately needed to cut some fat.

This started our first performance challenge: find things that we can easily remove without affecting the overall experience.

Performance optimization opportunities #

Remove unnecessary resources #

There are some obvious things that can be safely removed: whitespace and comments.

Fig. 4. Minify and compress JavaScript and CSS

Lighthouse highlights this opportunity in the Unminified CSS & JavaScript audit. We were using webpack for our build process, so in order to get minification we simply used the Uglify JS plugin.

Minification is a common task, so you should be able to find a ready-made solution for whichever build process you happen to use.

Another useful audit in that space is Enable text compression. There is no reason to send uncompressed files, and most of the CDNs support this out of the box these days.

We were using Firebase Hosting to host our code, and Firebase enables gzipping by default, so by the sheer virtue of hosting our code on a reasonable CDN we got that for free.

While gzip is a very popular way of compressing, other mechanisms like Zopfli and Brotli are getting traction as well. Brotli enjoys support in most browsers, and you can use a binary to pre-compress your assets before sending them to the server.

Use efficient cache policies #

Our next step was to ensure that we don’t send resources twice if unnecessary.

The Inefficient cache policy audit in Lighthouse helped us notice that we could be optimizing our caching strategies in order to achieve exactly that. By setting a max-age expiration header in our server, we made sure that on a repeated visit the user can reuse the resources they have downloaded before.

Ideally you should aim at caching as many resources as securely possible for the longest possible period of time and provide validation tokens for efficient revalidation of the resources that got updated.

Remove unused code #

So far we removed the obvious parts of the unnecessary download, but what about the less obvious parts? For example, unused code.

Fig. 5. Check code coverage

Sometimes we include in our apps code that is not really necessary. This happens especially if you work on your app for a longer period of time, your team or your dependencies change, and sometimes an orphan library gets left behind. That's exactly what happened to us.

At the beginning we were using Material Components library to quickly prototype our app. In time we moved to a more custom look and feel and we forgot entirely about that library. Fortunately, the code coverage check helped us rediscover it in our bundle.

You can check your code coverage stats in DevTools, both for the runtime as well as load time of your application. You can see the two big red stripes in the bottom screenshot - we had over 95% of our CSS unused, and a big bunch of JavaScript as well.

Lighthouse also picked up this issue in the unused CSS rules audit. It showed a potential saving of over 400kb. So we got back to our code and we removed both the JavaScript and CSS part of that library.

Fig. 6. If we drop MVC adapter our styles drop to 10KB!

This brought our CSS bundle down 20-fold, which is pretty good for a tiny, two-line-long commit.

Of course, it made our performance score go up, and also the Time to Interactive got much better.

However, with changes like this, it’s not enough to check your metrics and scores alone. Removing actual code is never risk-free, so you should always look out for potential regressions.

Our code was unused in 95% - there’s still this 5% somewhere. Apparently one of our components was still using the styles from that library - the little arrows in the doodle slider. Because it was so small though, we could just go and manually incorporate those styles back into the buttons.

Fig. 7. One component was still using the removed library

So if you remove code, just make sure you have a proper testing workflow in place to help you guard against potential visual regressions.

Avoid enormous network payloads #

We know that large resources can slow down web page loads. They can cost our users money and they can have a big impact on their data plans, so it's really important to be mindful of this.

Lighthouse was able to detect that we had an issue with some of our network payloads using the Enormous network payload audit.

Fig. 8. Detect enormous network payloads

Here we saw that we had over 3mb worth of code that was being shipped down – which is quite a lot, especially on mobile.

At the very top of this list, Lighthouse highlighted that we had a JavaScript vendor bundle that was 2mb of uncompressed code. This is also a problem highlighted by webpack.

As the saying goes: the fastest request is the one that's not made.

Ideally you should be measuring the value of every single asset you're serving down to your users, measuring the performance of those assets, and making a call on whether it's worth actually shipping down with the initial experience. Because sometimes these assets can be deferred, or lazily loaded, or processed during idle time.

In our case, because we're dealing with a lot of JavaScript bundles, we were fortunate because the JavaScript community has a rich set of JavaScript bundle auditing tools.

Fig. 9. JavaScript bundle auditing

We started off with webpack bundle analyzer, which informed us that we were including a dependency called unicode which was 1.6mb of parsed JavaScript, so quite a lot.

We then went over to our editor and using the Import Cost Plugin for Visual code we were able to visualize the cost of every module that we were importing. This allowed us to discover which component was including code that was referencing this module.

We then switched over to another tool, BundlePhobia. This is a tool which allows you to enter in the name of any NPM package and actually see what its minified and gzipped size is estimated to be. We found a nice alternative for the slug module we were using that only weighed 2.2kb, and so we switched that up.

This had a big impact on our performance. Between this change and discovering other opportunities to trim down our JavaScript bundle size, we saved 2.1mb of code.

We saw 65% improvements overall, once you factor in the gzipped and minified size of these bundles. And we found that this was really worth doing as a process.

So, in general, try to eliminate unnecessary downloads in your sites and apps. Make an inventory of your assets and measure their performance impact can make a really big difference, so make sure that you're auditing your assets fairly regularly.

Lower JavaScript boot-up time with code splitting #

Although large network payloads can have a big impact on our app, there's another thing that can have a really big impact, and that is JavaScript.

JavaScript is your most expensive asset. On mobile, if you're sending down large bundles of JavaScript, it can delay how soon your users are able to interact with your user interface components. That means they can be tapping on UI without anything meaningful actually happening. So it's important for us to understand why JavaScript costs so much.

This is how a browser processes JavaScript.

Fig. 10. JavaScript processing

We first of all have to download that script, we have a JavaScript engine which then needs to parse that code, needs to compile it and execute it.

Now these phases are something that don't take a whole lot of time on a high-end device like a desktop machine or a laptop, maybe even a high-end phone. But on a median mobile phone this process can take anywhere between five and ten times longer. This is what delays interactivity, so it's important for us to try trimming this down.

To help you discover these issues with your app, we introduced a new JavaScript boot-up time audit to Lighthouse.

Fig. 11. JavaScript boot up time audit

And in the case of the Oodle app, it told us that we had 1.8 seconds of time spent in JavaScript boot-up. What was happening was that we were statically importing in all of our routes and components into one monolithic JavaScript bundle.

One technique for working around this is using code splitting.

Code splitting is this notion of instead of giving your users a whole pizza’s worth of JavaScript, what if you only gave them one slice at a time as they needed it?

Code splitting can be applied at a route level or a component level. It works great with React and React Loadable, Vue.js, Angular, Polymer, Preact, and multiple other libraries.

We incorporated code splitting into our application, we switched over from static imports to dynamic imports, allowing us to asynchronously lazy load code in as we needed it.

Fig. 13. Code splitting with dynamic imports

The impact this had was both shrinking down the size of our bundles, but also decreasing our JavaScript boot up time. It took it down to 0.78 seconds, making the app 56% faster.

In general, if you're building a JavaScript-heavy experience, be sure to only send code to the user that they need.

Take advantage of concepts like code splitting, explore ideas like tree shaking, and check out webpack-libs-optimizations repo for a few ideas on how you can trim down your library size if you happen to be using webpack.

Optimize images #

In the Oodle app we're using a lot of images. Unfortunately, Lighthouse was much less enthusiastic about it than we were. As a matter of fact, we failed on all three image-related audits.

We forgot to optimize our images, we were not sizing them correctly, and also we could get some gain from using other image formats.

Fig. 14. Lighthouse image audits

We started with optimizing our images.

For one-off optimization round you can use visual tools like ImageOptim or XNConvert.

A more automated approach is to add an image optimization step to your build process, with libraries like imagemin.

This way you make sure that the images added in the future get optimized automatically. Some CDNs, for example Akamai or third-party solutions like Cloudinary, Fastly or Uploadcare offer you comprehensive image optimization solutions. so you can also simply host your images on those services.

If you don't want to do that because of the cost, or latency issues, projects like Thumbor or Imageflow offer self-hosted alternatives.

Fig. 15. Before and after optimization

Our background PNG was flagged in webpack as big, and rightly so. After sizing it correctly to the viewport and running it through ImageOptim, we went down to 100kb, which is acceptable.

Repeating this for multiple images on our site allowed us to bring down the overall page weight significantly.

Use the right format for animated content #

GIFs can get really expensive. Surprisingly, the GIF format was never intended as an animation platform in the first place. Therefore, switching to a more suitable video format offers you large savings in terms of file size.

In Oodle app, we were using a GIF as an intro sequence on the home page. According to Lighthouse, we could be saving over 7mb by switching to a more efficient video format. Our clip weighted about 7.3mb, way too much for any reasonable website, so instead we turned it into a video element with two source files - an mp4 and WebM for wider browser support.

Fig. 16. Replace Animated GIFs with video

We used the FFmpeg tool to convert our animation GIF into the mp4 file. The WebM format offers you even larger savings - the ImageOptim API can do such conversion for you.

ffmpeg -i animation.gif -b:v 0 -crf 40 -vf scale=600:-1 video.mp4

We managed to save over 80% of our overall weight thanks to this conversion. This brought us down to around 1mb.

Still, 1mb is a large resource to push down the wire, especially for a user on a restricted bandwidth. Luckily we could use Effective Type API to realize they're on a slow bandwidth, and give them a much smaller JPEG instead.

This interface uses the effective round-trip time and downing values to estimate the network type the user is using. It simply returns a string, slow 2G, 2G, 3G or 4G. So depending on this value, if the user is on below 4G we could replace the video element with the image.

if (navigator.connection.effectiveType) { ... }

It does remove a little bit from the experience, but at least the site is usable on a slow connection.

Lazy-load off-screen images #

Carousels, sliders, or really long pages often load images, even though the user cannot see them on the page straight away.

Lighthouse will flag this behavior in the off-screen images audit, and you can also see it for yourself in the network panel of DevTools. If you see a lot of images incoming while only a few are visible on the page, it means that maybe you could consider lazy loading them instead.

Lazy loading is not yet supported natively in the browser, so we have to use JavaScript to add this capability. We used Lazysizes library to add lazy loading behavior to our Oodle covers.

<!-- Import library -->
import lazysizes from 'lazysizes'  <!-- or -->
<script src="lazysizes.min.js"></script>

<!-- Use it -->

<img data-src="image.jpg" class="lazyload"/>
<img class="lazyload"
    data-sizes="auto"
    data-src="image2.jpg"
    data-srcset="image1.jpg 300w,
    image2.jpg 600w,
    image3.jpg 900w"/>

Lazysizes is smart because it does not only track the visibility changes of the element, but it also proactively prefetches elements that are near the view for the optimal user experience. It also offers an optional integration of the IntersectionObserver, which gives you very efficient visibility lookups.

After this change our images are being fetched on-demand. If you want to dig deeper into that topic, check out images.guide - a very handy and comprehensive resource.

Help browser deliver critical resources early #

Not every byte that's shipped down the wire to the browser has the same degree of importance, and the browser knows this. A lot of browsers have heuristics to decide what they should be fetching first. So sometimes they'll fetch CSS before images or scripts.

Something that could be useful is us, as authors of the page, informing the browser what's actually really important to us. Thankfully, over the last couple of years browser vendors have been adding a number of features to help us with this, e.g. resource hints like link rel=preconnect, or preload or prefetch.

These capabilities that were brought to the web platform help the browser fetch the right thing at the right time, and they can be a little bit more efficient than some of the custom loading, logic-based approaches that are done using script instead.

Let's see how Lighthouse actually guides us towards using some of these features effectively.

The first thing Lighthouse tells us to do is avoid multiple costly round trips to any origin.

Fig. 17. Avoid multiple, costly round trips to any origin

In the case of the Oodle app, we’re actually heavily using Google Fonts. Whenever you drop a Google Font stylesheet into your page it's going to connect up to two subdomains. And what Lighthouse is telling us is that if we were able to warm up that connection, we could save anywhere up to 300 milliseconds in our initial connection time.

Taking advantage of link rel preconnect, we can effectively mask that connection latency.

Especially with something like Google Fonts where our font face CSS is hosted on googleapis.com, and our font resources are hosted on Gstatic, this can have a really big impact. So we applied this optimization and we shaved off a few hundred milliseconds.

The next thing that Lighthouse suggests is that we preload key requests.

Fig. 18. Preload key requests

<link rel=preload> is really powerful, it informs the browser that a resource is needed as part of the current navigation, and it tries to get the browser fetching it as soon as possible.

Now here Lighthouse is telling us that we should be going and preloading our key web font resources, because we're loading in two web fonts.

Preloading in a web font looks like this - specifying rel=preload, you pass in as with the type of font, and then you specify the type of font you're trying to load in, such as woff2.

The impact this can have on your page is quite stark.

Fig. 19. Impact of preloading resources

Normally, without using link rel preload, if web fonts happen to be critical to your page, what the browser has to do is it first of all has to fetch your HTML, has to parse your CSS, and somewhere much later down the line, it'll finally go and fetch your web fonts.

Using link rel preload, as soon as the browser has parsed your HTML it can actually start fetching those web fonts much earlier on. In the case of our app, this was able to shave a second off the time it took for us to render text using our web fonts.

Now it's not quite that straightforward if you're going to try preloading fonts using Google Fonts, there is one gotcha.

The Google Font URLs that we specify on our font faces in our stylesheets happened to be something that the fonts team update fairly regularly. These URLs can expire, or get updated on a regular frequency, and so what we would suggest to do if you want complete control over your font loading experience is to self-host your web fonts. This can be great because it gives you access to things like link rel preload.

In our case we found the tool Google Web Fonts Helper really useful in helping us offline some of those web fonts and set them up locally, so check that tool out.

Whether you're using web fonts as part of your critical resources, or it happens to be JavaScript, try to help the browser deliver your critical resources as soon as possible.

Experimental: Priority Hints #

We've got something special to share with you today. In addition to features like resource hints, as well as preload, we've been working on a brand new experimental browser feature we’re calling priority hints.

Fig. 20. Priority hints

This is a new feature that allows you to hint to the browser how important a resource is. It exposes a new attribute - importance - with the values low, high or auto.

This allows us to convey lowering the priority of less important resources, such as non-critical styles, images, or fetch API calls to reduce contention. We can also boost the priority of more important things, like our hero images.

In the case of our Oodle app, this actually led to one practical place where we could optimize.

Fig. 21. Set priority for the initially visible content

Before we added lazy loading to our images, what the browser was doing is, we had this image carousel with all of our doodles and the browser was fetching all the images at the very start of the carousel with a high priority early on. Unfortunately, it was the images in the middle of the carousel that were most important to the user. So what we did was, we set the importance of those background images to very low, the foreground ones to very high, and what this had was a two second impact over slow 3G, and how quickly we were able to fetch and render those images. So a nice positive experience.

We're hoping to bring this feature to Canary in a few weeks, so keep an eye out for that.

Have a web font loading strategy #

Typography is fundamental to good design, and if you're using web fonts you ideally don't want to block rendering of your text, and you definitely don't want to show invisible text.

We highlight this in Lighthouse now, with the avoid invisible text while web fonts are loading audit.

Fig. 22. Avoid invisible text while Web Fonts are loading

If you load your web fonts using a font face block, you're letting the browser decide what to do if it takes a long time for that web font to fetch. Some browsers will wait anywhere up to three seconds for this before falling back to a system font, and they'll eventually swap it out to the font once it's downloaded.

We're trying to avoid this invisible text, so in this case we wouldn't have been able to see this week's classic doodles if the web font had taken too long. Thankfully, with a new feature called font-display, you actually get a lot more control over this process.

    @font-face {
      font-family: 'Montserrat';
      font-style: normal;
      font-display: swap;
      font-weight: 400;
      src: local('Montserrat Regular'), local('Montserrat-Regular'),
          /* Chrome 26+, Opera 23+, Firefox 39+ */
          url('montserrat-v12-latin-regular.woff2') format('woff2'),
            /* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
          url('montserrat-v12-latin-regular.woff') format('woff');
    }

Font display helps you decide how web fonts will render or fallback based on how long it takes for them to swap.

In this case we're using font display swap. Swap gives the font face a zero second block period, and an infinite swap period. This means the browser's going to draw your text pretty immediately with a fallback font if the font takes a while to load. And it's going to swap it once the font face is available.

In the case of our app, why this was great is that it allowed us to display some meaningful text very early on, and transition over to the web font once it was ready.

Fig. 23. Font display outcome

In general, if you happen to be using web fonts, as a large percentage of the web does, have a good web font loading strategy in place.

There are a lot of web platform features you can use to optimize your loading experience for fonts, but also check out Zach Leatherman's Web Font Recipes repo, because it's really great.

Reduce render-blocking scripts #

There are other parts of our application that we could push earlier in the download chain to provide at least some basic user experience a little bit earlier.

On the Lighthouse timeline strip you can see that during these first few seconds when all the resources are loading, the user cannot really see any content.

Fig. 24. Reduce render-blocking stylesheets opportunity

Downloading and processing external stylesheets is blocking our rendering process from making any progress.

We can try to optimize our critical rendering path by delivering some of the styles a bit earlier.

If we extract the styles that are responsible for this initial render and inline them in our HTML, the browser is able to render them straight away without waiting for the external stylesheets to arrive.

In our case, we used an NPM module called Critical to inline our critical content in index.html during a build step.

While this module did most of the heavy lifting for us, it was still a little bit tricky to get this working smoothly across different routes.

If you are not careful or your site structure is really complex, it might be really difficult to introduce this type of pattern if you did not plan for app shell architecture from the beginning.

This is why it's so important to take performance considerations early on. If you don't design for performance from the start, there is a high chance that you will you run into issues doing it later.

In the end our risk paid off, we managed to make it work and the app started delivering content much earlier, improving our first meaningful paint time significantly.

The outcome #

That was a long list of performance optimizations we applied to our site. Let's take a look at the outcome. This is how our app loaded on a medium mobile device on a 3G network, before and after the optimization.

The Lighthouse performance score went up from 23 to 91. That's pretty nice progress in terms of speed. All of the changes were fueled by us continuously checking and following the Lighthouse report. If you'd like to check out how we technically implemented all of the improvements, feel free to take a look at our repo, especially at the PRs that landed there.

Predictive performance - data-driven user experiences #

We believe that machine learning represents an exciting opportunity for the future in many areas. One idea that we hope will spark more experimentation in the future, is that real data can really guide the user experiences we’re creating.

Today, we make a lot of arbitrary decisions about what the user might want or need, and therefore what is worth being prefetched, or preloaded, or pre-cached. If we guess right we are able to prioritize a small amount of resources, but it's really hard to scale it to the whole website.

We actually have data available to better inform our optimizations today. Using the Google Analytics reporting API we can take a look at the next top page and exit percentages for any URL on our site and therefore drive conclusions on which resources we should prioritize.

If we combine this with a good probability model, we avoid wasting our user’s data by aggressively over-prefetching content. We can take advantage of that Google Analytics data, and use machine learning and models like Markov chains or neural network in order to implement such models.

Fig. 25. Data-driven Bundling for Web Apps

In order to facilitate this experiments, we're happy to announce a new initiative we're calling Guess.js.

Fig. 26. Guess.js

Guess.js is a project focused on data-driven user experiences for the web. We hope that it's going to inspire exploration of using data to improve web performance and go beyond that. It's all open source and available on GitHub today. This was built in collaboration with the open source community by Minko Gechev, Kyle Matthews from Gatsby, Katie Hempenius, and a number of others.

Check out Guess.js, let us know what you think.

Summary #

Scores and metrics are helpful in improving speed of the Web, but they are just the means, not the goals themselves.

We've all experienced slow page loads on the go, but we now have an opportunity to give our users more delightful experiences that load really quickly.

Improving performance is a journey. Lots of small changes can lead to big gains. By using the right optimization tools and keeping an eye on the Lighthouse reports, you can provide better and more inclusive experience to your users.

With special thanks to: Ward Peeters, Minko Gechev, Kyle Mathews, Katie Hempenius, Dom Farolino, Yoav Weiss, Susie Lu, Yusuke Utsunomiya, Tom Ankers, Lighthouse & Google Doodles.

Loading Third-Party JavaScript

2018-02-28T00:00:00Z

You've optimized all of your code, but your site still loads too slowly. Who's the culprit?

Often, performance problems slowing pages down are due to third-party scripts: ads, analytics, trackers, social media buttons, and so on.

Third-party scripts provide a wide range of useful functionality, making the web more dynamic, interactive, and interconnected. These scripts may be crucial to your website's functionality or revenue stream. But third-party scripts also come with many risks that should be taken into consideration to minimize their impact while still providing value.

Why do you need to be careful about third-party scripts?

They can be a performance concern
They can be a privacy concern
They might be a security concern
They can be unpredictable and change without you knowing
They can have unintended consequences

Ideally, you’ll want to ensure third-party script is not impacting the critical rendering path. In this guide, we’ll walk through how to find and fix issues related to loading third-party JavaScript.

What do we mean by third-party scripts? #

Third-party JavaScript often refers to scripts that can be embedded into any site directly from a third-party vendor. These scripts can include ads, analytics, widgets and other scripts that make the web more dynamic and interactive.

Examples of third-party scripts include:

Social sharing buttons (Twitter, Facebook, G+)
Video player embeds (YouTube, Vimeo)
Advertising iframes
Analytics & metrics scripts
A/B testing scripts for experiments
Helper libraries (such as date formatting, animation, or functional libraries)

<iframe
  width="560"
  height="315"
  src="https://www.youtube.com/embed/mo8thg5XGV0"
  frameborder="0"
  allow="autoplay; encrypted-media"
  allowfullscreen
>
</iframe>

One example of this is the YouTube video player embed script that allows you to embed a video into your page.

Unfortunately, embedding third-party scripts means we often rely on them to be fast in order to avoid slowing our pages down. Third-party scripts are a predominant cause of performance slowdowns and are often caused by resources outside of your control.

These issues can include:

Firing too many network requests to multiple servers. The more requests a site has to make, the longer it can take to load.
Sending too much JavaScript that keeps the main thread busy. Too much JavaScript can block DOM construction, delaying how quickly pages can render. CPU-intensive script parsing and execution can delay user interaction and cause battery drain.
Sending large, unoptimized image files or videos. This can consume data and cost users money.
Third-party scripts loaded without care can be a single-point of failure (SPOF)
Insufficient HTTP caching, forcing resources to be fetched from the network often
Lack of sufficient server compression of resources
Blocking content display until they complete processing. This can also be true for async A/B testing scripts.
Use of legacy APIs (e.g document.write()) known to be harmful to the user experience
Excessive DOM elements or expensive CSS selectors.
Including multiple third-party embeds can lead to multiple frameworks and libraries being pulled in several times. This is wasteful and exacerbates the performance issues.
Third-party scripts often use embed techniques that can block window.onload if their servers respond slowly, even if the embed is using async or defer.

Context is important and the solution to costly third-parties can depend on your site and your ability to configure how you load third-party code. Thankfully, a number of solutions and tools exist to find and fix issues with third-party resources.

How do you identify third-party script on a page? #

Unless you’re aware which third-party scripts are loaded by your site and what their performance impact is, it’s impossible to know how to optimize them. Many free web speed test tools can highlight costly third-parties including Chrome DevTools, PageSpeed Insights and WebPageTest. These tools display rich diagnostic information that can tell you how many third-party scripts your site is loading, and which take the most time to execute.

WebPageTest’s waterfall view can highlight the impact of heavy third-party script use. Below is an example of the requests required to load the main content for a site vs. the tracking and marketing scripts (credit: Tags Gone Wild).

WebPageTest’s domain breakdown can also be useful for visualizing how much content comes from third-party origins. It breaks this down by both total bytes and the number of requests:

When you see a problematic script, figure out what the script does and ask yourself whether the script is really that necessary. Do an A/B test to balance the perceived value versus its impact on key user engagement or performance metrics.

How do I measure the impact of third-party script on my page? #

Lighthouse Boot-up Time Audit #

The Lighthouse JavaScript boot-up time audit highlights scripts that have a costly script parse, compile or evaluation time. This can be useful for discovering CPU-intensive third-party scripts.

Lighthouse Network Payloads Audit #

The Lighthouse Network Payloads audit identifies network requests (including those from third-parties) that may slow down page load time. Avoiding these requests or highlighting their cost to ad-networks can save users money they would have spent on cellular data.

Chrome DevTools Network Request Blocking #

Chrome DevTools allows you to see how your page behaves when a particular script, stylesheet or other resource isn’t available. This is done with network request blocking, a feature that can help measure the impact of blocking (dropping) specific third-party resources from your page.

To enable request blocking, right click on any request in the Network panel and select "Block Request URL". A Request blocking tab will display in the DevTools drawer, letting you manage which requests have been blocked.

Chrome DevTools Performance Panel #

The Performance panel in Chrome DevTools helps identify issues with your page’s web performance. Clicking the record button and loading your page presents you with a waterfall representing where your site is spending time. At the bottom of the Performance panel, you will see a drawer starting with "Summary". Navigate to the “Bottom-up” tab.

Here, you can use the "Group by product" option in the Bottom-Up tab to group third-parties by the time they spent. This helps identify which third-party products were the most costly. The Network panel also supports an option to highlight requests by product.

To learn more about how to analyze page load performance with the Chrome DevTools, see Get started with analyzing runtime performance.

A good workflow for measuring the impact of third-party scripts is:

Measure how long it takes to load your page using the Network panel.
- To emulate real-world conditions, we recommend turning on network throttling and CPU throttling. On faster connections and desktop hardware, the impact of expensive scripts may not be as representative as it would on a mobile phone.
Block the URLs or domains responsible for third-party scripts you believe are an issue (see Chrome DevTools Performance Panel for identifying costly scripts).
Reload the page and re-measure how long the page takes without loading these blocked third-party scripts. You should hopefully see an improvement.
- There may be value in doing 3 or more runs of measurement and looking at the median for more stable figures. As third-party content can occasionally pull in different resources per page load, this could give you a more realistic spread. DevTools now supports multiple recordings in the performance panel, making this a little easier.

Measuring impact of Third-Party tags with WebPageTest #

WebPageTest supports blocking individual requests from loading (which can be useful for blocking content like ads and third-party embeds) to measure their impact.

Under "Advanced Settings" is a Block tab. This can be used to specify a list of domains to block, simulating what it would be like if they didn't load at all.

A workflow for using this feature is to:

Test a page as normal
Repeat the test with certain third-parties blocked
Compare the two results (paying attention to the filmstrip). Results can be compared by selecting them from your Test History and clicking ‘Compare’.

Below we can see the difference between filmstrips both with and without third-party resources blocked. It can be useful to try this out for individual third-party origins to determine which ones have the biggest impact on your page-load performance:

The impact of blocking third-party resources on a page using WPT’s "block requests" feature from “Using WebPageTest To Measure The Impact Of Third-Party Tags” by Andy Davies

which takes a list of domains to block and blockDomainsExcept
takes a list of domains and blocks anything not on the list.

WebPageTest also has a single-point of failure (SPOF) tab. This allows you to simulate a timeout or complete failure to load a resource.

The difference between "SPOF" and "Block" is that SPOF slowly times out. This can make it useful for testing network resilience of third-party content to determine how well your pages hold up when services are under heavy load or temporarily unavailable.

Detecting expensive iframes using Long Tasks #

When scripts in third-party iframes take a long time to run, they can block the main thread delaying other tasks from running. These long tasks can cause a negative user experience leading to sluggish event handlers or dropped frames.

To detect long tasks for Real User Monitoring (RUM), we can use the JavaScript PerformanceObserver API and observe longtask entries. As these entries contain an attribution property, we can track down which frame context was responsible for the task.

Below is an example that will log longtask entries to the console, including one for an "expensive" iframe:

<script>
  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      // Attribution entry including "containerSrc":"https://example.com"
      console.log(JSON.stringify(entry.attribution));
    }
  });

  observer.observe({entryTypes: ['longtask']});
</script>

<!-- Imagine this is an iframe with expensive long tasks -->
<iframe src="https://example.com"></iframe>

To learn more about monitoring Long Tasks, read Phil Walton’s User-centric Performance Metrics.

How do you load third-party script efficiently? #

If a third-party script is slowing down your page load, you have several options to improve performance:

Load the script using the async or defer attribute to avoid blocking document parsing.
Consider self-hosting the script if the third-party server is slow.
Consider removing the script if it doesn't add clear value to your site.
Consider Resource Hints like <link rel=preconnect> or <link rel=dns-prefetch> to perform a DNS lookup for domains hosting third-party scripts.

Use async or defer #

JavaScript execution is parser blocking. This means when the browser encounters a script it must pause DOM construction, hand this over to the JavaScript engine and allow script execution before proceeding with DOM construction.

The async and defer attributes change this behavior.

With async, the browser downloads the script asynchronously while it continues to parse the HTML document. When the script finishes downloading, parsing is blocked while the script executes.
With defer, the browser downloads the script asynchronously while it continues to parse the HTML document. The script doesn't run until the parsing is complete.

If that's too many words, here's a pretty picture:

Credit: Growing with the web

In general, you should always use async or defer for third-party scripts (unless the script does something necessary for the critical rendering path):

Use async if it's important to have the script run earlier in the loading process. This might include some analytics scripts, for example.
Use defer for less critical resources. A video player that's below-the-fold, for example.

Should you ever load third-party scripts without async or defer? You could make a case for this if the script is a crucial part of your site functionality. For example, if you're loading your main UI library or framework from a CDN, it will be badged as "third-party script" in DevTools, but should be treated as an essential part of your site, not an add-on.

Note that not all scripts work if loaded asynchronously. Check the docs for any third-party scripts you're using. If you're using a script that can't be loaded asynchronously, you might want to consider an alternative, or eliminating the script if possible. Some third parties may highly recommend to load their scripts sync (to get ahead of other scripts), even if they would work fine async so do due diligence when evaluating strategies for loading third-party scripts.

Use Resource Hints to reduce connection setup time #

Establishing connections to third-party origins can take a significant amount of time - particularly on slow networks. Many steps can add up to delays including DNS lookups, redirects, and potentially several round trips to each third-party server to handle the request.

You can use Resource Hints like to perform a DNS lookup for domains hosting third-party scripts. When the request for them is finally made, time can be saved as the DNS lookup has already been carried out.

<link rel="dns-prefetch" href="http://example.com" />

If the third-party domain you are referencing uses HTTPS, you may also consider as this will both perform the DNS lookup and resolve TCP round-trips and handle TLS negotiations. These other steps can be very slow as they involve looking at SSL certificates for verification, so consider Resource Hints seriously if you find third-party setup time to be an issue.

<link rel="preconnect" href="https://cdn.example.com" />

"Sandbox" scripts with an iframe #

There are cases where third-party scripts can be loaded directly into an iframe. By restricting such scripts to iframes, they won’t block execution of the main page. This is the same approach that AMP takes to keeping JavaScript out of the critical path. Note that this approach will still block the onload event so try not to attach critical functionality to onload.

Chrome also supports Permissions Policy (formerly Feature Policy) - a set of policies which allow a developer to selectively disable access to certain browser features. This can prevent third-party content introducing unwanted behaviors to a site.

Self-host third-party scripts #

Self-hosting third-party scripts may be an option if you would like more control over a script’s loading story. For example, if you wanted to reduce DNS or round-trip times, or improve HTTP caching headers. Self-hosting may be a viable consideration if a script is considered critical.

Self-hosting can come with a number of big caveats:

Scripts can go out of date. This can be a large issue as it prevents you from getting important security fixes without manually updating.
Scripts that are self-hosted won’t get automatic updates due to an API change. One example: a publisher with 90% of their revenue from ads discovers that ads didn’t serve for half a day due to an API change that their self-hosted script didn’t account for, leading to loss in income.

An alternative to self-hosting scripts would be using Service Workers to cache them. This can give you greater control over how often they are re-fetched from the network. This could also be used to create a loading strategy where requests for non-essential third parties are throttled until the page reaches a key user moment.

A/B Test smaller samples of users #

A/B testing (or split-testing) is a technique for experimenting with two versions of a page to determine which one performs best. This is done by enabling both variants (A and B) for different samples of your website traffic. The page that provides a better conversion rate wins.

A/B testing is a very useful tool for analyzing user experience and behavior.

However, by design, A/B testing delays rendering to figure out which experiment needs to be active. JavaScript is often used to check if any of your users belong to an A/B test experiment and then enable the correct variant. This pattern can lead to 100% of your users being sent down large, costly script even if they don’t belong to the sample receiving the experiment.

A good alternative in this case is to send A/B testing scripts for only a subset of your user base (e.g 10% vs 100%), ideally attempting to decide whether they belong in a test sample on the server-side. This improves the loading experience for the majority of users while still making split-testing possible.

Lazy load Third-Party Resources #

Embedded third-party resources (such as ads or videos) can be a big contributor to slow page speed when constructed poorly. Lazy loading can be used to only load embedded resources when necessary. For example, serving an ad in the footer only when a user scrolls down the page. Another pattern is lazy loading content after the main page content loads but before a user might otherwise interact with the page.

DoubleClick have guidance on how to lazy-load ads in their official documentation. If used properly, lazy loading can increase the overall viewability percentage of an ad. For example, Mediavine switched tolazy-loading ads and saw a 200% improvement in page load speed.

Efficient lazy loading with Intersection Observer #

Historically, solutions for detecting if an element is visible in the viewport (in order to lazy-load its content) have been error-prone, often causing the browser to become sluggish. Solutions have often listened for scroll or resize events, then used DOM APIs like getBoundingClientRect() to calculate where elements are relative to the viewport. This works, but is not efficient.

IntersectionObserver is a browser API that allows us to efficiently detect when an observed element enters or exits the browser's viewport. Learn more about how to use it for lazy loading resources. LazySizes also hasoptional support for IntersectionObserver.

Analytics can be complicated #

Analytics scripts should never slow down your page load experience, but if you defer the load too long you can miss valuable analytics data. Fortunately, there are some well-known patterns for initializing analytics lazily while retaining early page-load data.

Phil Walton's blog post, The Google Analytics Setup I Use on Every Site I Build covers one such pattern for Google Analytics.

What patterns should I avoid with third-party script? #

Avoid document.write() #

Third-party scripts sometimes use document.write() to inject and load scripts. This is particularly true of older services that haven’t been updated in some time. Thankfully, many third-parties offer an option to asynchronously load themselves, which allows third-party scripts to load without blocking the display of the rest of the content on the page.

The fix for document.write() is to simply not inject scripts using it. As of Chrome 53, Chrome DevTools will log warnings to the console for problematic use of document.write():

To discover the use of document.write() at scale, you can check for HTTP headers sent to your browser when this intervention for Chrome happens. Lighthouse can also highlight any third-party scripts still using document.write() in the Lighthouse report:

Use Tag Managers but use them wisely #

A "tag" is a snippet of code that allows digital marketing teams to collect data, set cookies or integrate third-party content like social media widgets into a site. These tags have a cost to your page's loading performance - additional network requests, heavy JavaScript dependencies, images and resources the tag itself may pull in.

Managing these tags can become a real mess over time as marketing teams wish to add more ways to understand users and engineering tries to minimize the impact tags can have on user experience. To keep experiences fast, we recommend using a Tag manager. Tag managers:

allow many pieces of third-party embed code to be managed from a single place (usually a user-interface)
attempt to minimize how much third-party tags need to be deployed to sites.

Google Tag Manager (GTM) is one such popular tag manager:

"Google Tag Manager is an asynchronous tag, meaning that when it executes, it does not block other elements from rendering on the page. It also causes the other tags that are deployed via Google Tag Manager to be deployed asynchronously, meaning that a slow loading tag won’t block other tracking tags."

Tag managers may improve page load performance by reducing how many calls to external resources are needed - as long as you are not pulling in a large number of tags. They also allow tags a way to collect values in a single unique place. For GTM, this is the Data Layer. If multiple third parties wish to trigger conversion-tracking data, they can do this by pulling from the Data Layer.

Risks when using Tag managers

When using a tag manager, great care needs to be taken to avoid slowing down how quickly pages load. This is because:

Anyone with credentials and access can easily add not just more tags, but any JavaScript they want. Although tag managers can load tags asynchronously, this can still lead to an excess of costly HTTP requests being made and executed. This can be minimized by only allowing one user to publish versions.
Anyone can configure too many tag manager auto-event listeners. Every auto-event listener needs to be executed & the more code and network requests there are, the longer it can take for a page to fully load. With our performance guidance encouraging that you respond to events within 50ms, every tag manager event listener added eats away at that goal.

Avoid scripts that pollute the global scope #

Third-party scripts injected into the unknown can sometimes load a number of their own JavaScript dependencies. This can pollute the global scope and cause accidental breakage in pages.

There is also no guarantee that code loaded from a third-party will remain the same as what you saw during testing. New features can be pushed out by third parties at any time, potentially breaking your page. Self-testing, sub-resource integrity and securely transmitting third-party code (to reduce the risk of in-transit modifications) can help here.

Be sure to conduct careful audits of the third-party scripts you load to ensure they’re being good actors.

Mitigation strategies #

Adding third-party scripts to a page implies a level of trust in the origin. There are some strategies you can take to minimize their impact on performance and security:

HTTPS is a must. Sites working over HTTPS shouldn’t have third-parties working over HTTP. An HTTPS page that includes content fetched using HTTP is called a mixed content page and will run into Mixed Content warnings.
Consider the sandbox attribute on iframes. From a security perspective, this allows you to restrict the actions available from the iframe. Restrictions include allow-scriptscontrolling whether the context can run scripts.
Consider Content Security Policy (CSP). Through a HTTP header in your server’s response, you can define behaviors that are trusted in the page. CSP can be used to detect and mitigate against the effects of certain attacks, such as Cross Site Scripting (XSS).

CSP is particularly powerful as it includes directives such as script-src that specifies what are valid, allowed sources for JavaScript. Below is an example of how this can be used in practice:

// Given this CSP header Content-Security-Policy: script-src
https://example.com/ // The following third-party script will not be loaded or
executed

<script src="https://not-example.com/js/library.js"></script>

Conclusion #

With sites relying on more third-party scripts than ever, it’s paramount not to ignore third-party script performance. Good things you can do:

Become familiar with some of the most effective third-party script optimization methods like only loading tags that support the async loading pattern.
Understand how to identify and fix issues with third-party script loading. This can help you take back control of your page load performance.

Third-party script optimization should be followed by on-going real-time performance monitoring of your scripts and communication with your third-party providers. The web is evolving at a rapid pace and a script’s locally observed performance gives no guarantees that it will perform as well in the future or in the wild.

Webpack

2018-02-08T00:00:00Z

Modern web applications often use a bundling tool to create a production "bundle" of files (scripts, stylesheets, etc.) that is optimized, minified and can be downloaded in less time by your users. In Web Performance Optimization with webpack, we will walk through how to effectively optimize site resources using webpack. This can help users load and interact with your sites more quickly.

webpack is one of the most popular bundling tools in use today. Taking advantage of its features for optimizing modern code, code-splitting scripts into critical and non-critical pieces and stripping out unused code (to name but a few optimizations) can ensure your app has a minimal network and processing cost.

Inspired by Code-splitting in Bundle Buddy by Susie Lu

Let’s get started by looking at optimizing one of the costliest resources in a modern app – JavaScript.

JavaScript Start-up Optimization

2017-11-30T00:00:00Z

As we build sites more heavily reliant on JavaScript, we sometimes pay for what we send down in ways that we can’t always easily see. In this article, we’ll cover why a little discipline can help if you’d like your site to load and be interactive quickly on mobile devices. Delivering less JavaScript can mean less time in network transmission, less spent decompressing code and less time parsing and compiling this JavaScript.

Network #

When most developers think about the cost of JavaScript, they think about it in terms of the download and execution cost. Sending more bytes of JavaScript over the wire takes longer the slower a user’s connection is.

This can be a problem as the effective network connection type a user has might not actually be 3G, 4G or Wi-Fi. You can be on coffee-shop Wi-Fi but connected to a cellular hotspot with 2G speeds.

You can reduce the network transfer cost of JavaScript through:

Only sending the code a user needs.
- Use code-splitting to break up your JavaScript into what is critical and what is not. Module bundlers like webpack support code-splitting.
- Lazily loading in code that is non-critical.
Minification
- Use UglifyJS for minifying ES5 code.
- Use babel-minify or uglify-es to minify ES2015+.
Compression
- At minimum, use gzip to compress text-based resources.
- Consider using Brotli ~q11. Brotli outperforms gzip on compression ratio. It helped CertSimple save 17% on the size of compressed JS bytes and LinkedIn save 4% on their load times.
Removing unused code.
- Identify opportunities for code that can be removed or lazily loaded in with DevTools code coverage.
- Use babel-preset-env and browserlist to avoid transpiling features already in modern browsers. Advanced developers may find careful analysis of their webpack bundles helps identify opportunities to trim unneeded dependencies.
- For stripping code, see tree-shaking, Closure Compiler’s advanced optimizations and library trimming plugins like lodash-babel-plugin or webpack’s ContextReplacementPlugin for libraries like Moment.js.
Caching code to minimize network trips.
- Use HTTP caching to ensure browsers cache responses effectively. Determine optimal lifetimes for scripts (max-age) and supply validation tokens (ETag) to avoid transferring unchanged bytes.
- Service Worker caching can make your app network resilient and give you eager access to features like V8’s code cache.
- Use long-term caching to avoid having to re-fetch resources that haven't changed. If using Webpack, see filename hashing.

Parse/Compile #

Once downloaded, one of JavaScript’s heaviest costs is the time for a JS engine to parse/compile this code. In Chrome DevTools, parse and compile are part of the yellow "Scripting" time in the Performance panel.

The Bottom-Up and Call Tree tabs show you exact Parse/compile timings:

Chrome DevTools Performance panel > Bottom-Up. With V8’s Runtime Call Stats enabled, we can see time spent in phases like Parse and Compile

But, why does this matter?

Spending a long time parsing/compiling code can heavily delay how soon a user can interact with your site. The more JavaScript you send, the longer it will take to parse and compile it before your site is interactive.

Byte-for-byte, JavaScript is more expensive for the browser to process than the equivalently sized image or Web Font — Tom Dale

Compared to JavaScript, there are numerous costs involved in processing equivalently sized images (they still have to be decoded!) but on average mobile hardware, JS is more likely to negatively impact a page’s interactivity.

JavaScript and image bytes have very different costs. Images usually don’t block the main thread or prevent interfaces from getting interactive while being decoded and rasterized. JS however can delay interactivity due to parse, compile and execution costs.

When we talk about parse and compile being slow; context is important — we’re talking about average mobile phones here. Average users can have phones with slow CPUs and GPUs, no L2/L3 cache and which may even be memory constrained.

Network capabilities and device capabilities don’t always match up. A user with an amazing Fiber connection doesn’t necessarily have the best CPU to parse and evaluate JavaScript sent to their device. This is also true in reverse… a terrible network connection, but a blazing fast CPU. — Kristofer Baxter, LinkedIn

Below we can see the cost of parsing ~1MB of decompressed (simple) JavaScript on low and high-end hardware. There is a 2–5x difference in time to parse/compile code between the fastest phones on the market and average phones.

This graph highlights parse times for a 1MB bundle of JavaScript (~250KB gzipped) across desktop and mobile devices of differing classes. When looking at the cost of parse, it’s the decompressed figures to consider e.g ~250KB gzipped JS decompresses to ~1MB of code.

What about a real-world site, like CNN.com?

On the high-end iPhone 8 it takes just ~4s to parse/compile CNN’s JS compared to ~13s for an average phone (Moto G4). This can significantly impact how quickly a user can fully interact with this site.

Above we see parse times comparing the performance of Apple’s A11 Bionic chip to the Snapdragon 617 in more average Android hardware.

This highlights the importance of testing on average hardware (like the Moto G4) instead of just the phone that might be in your pocket. Context matters however: optimize for the device and network conditions your users have.

Google Analytics can provide insight into the mobile device classes your real users are accessing your site with. This can provide opportunities to understand the real CPU/GPU constraints they’re operating with.

Are we really sending down too much JavaScript? Err, possibly :)

Using HTTP Archive (top ~500K sites) to analyze the state of JavaScript on mobile, we can see that 50% of sites take over 14 seconds to get interactive. These sites spend up to 4 seconds just parsing and compiling JS.

Factor in the time it takes to fetch and process JS and other resources and it’s perhaps not surprising that users can be left waiting a while before feeling pages are ready to use. We can definitely do better here.

Removing non-critical JavaScript from your pages can reduce transmission times, CPU-intensive parsing and compiling and potential memory overhead. This also helps get your pages interactive quicker.

Execution time #

It’s not just parse and compile that can have a cost. JavaScript execution (running code once parsed/compiled) is one of the operations that has to happen on the main thread. Long execution times can also push out how soon a user can interact with your site.

If script executes for more than 50ms, time-to-interactive is delayed by the entire amount of time it takes to download, compile, and execute the JS — Alex Russell

To address this, JavaScript benefits from being in small chunks to avoid locking up the main thread. Explore if you can reduce how much work is being done during execution.

Other costs #

JavaScript can impact page performance in other ways:

Memory. Pages can appear to jank or pause frequently due to GC (garbage collection). When a browser reclaims memory, JS execution is paused so a browser frequently collecting garbage can pause execution more frequently than we may like. Avoid memory leaks and frequent gc pauses to keep pages jank free.
During runtime, long-running JavaScript can block the main-thread causing pages that are unresponsive. Chunking up work into smaller pieces (using requestAnimationFrame() or requestIdleCallback() for scheduling) can minimize responsiveness issues which can help improve First Input Delay (FID) and Interaction to Next Paint (INP).

Patterns for reducing JavaScript delivery cost #

When you’re trying to keep parse/compile and network transmit times for JavaScript slow, there are patterns that can help like route-based chunking or PRPL.

PRPL #

PRPL (Push, Render, Pre-cache, Lazy-load) is a pattern that optimizes for interactivity through aggressive code-splitting and caching:

Let’s visualize the impact it can have.

We analyze the load-time of popular mobile sites and Progressive Web Apps using V8’s Runtime Call Stats. As we can see, parse time (shown in orange) is a significant portion of where many of these sites spend their time:

Wego, a site that uses PRPL, manages to maintain a low parse time for their routes, getting interactive very quickly. Many of the other sites above adopted code-splitting and performance budgets to try lowering their JS costs.

Progressive Bootstrapping #

Many sites optimize content visibility at the expensive of interactivity. To get a fast first paint when you do have large JavaScript bundles, developers sometimes employ server-side rendering; then "upgrade" it to attach event handlers when the JavaScript finally gets fetched.

Be careful — this has its own costs. You 1) generally send down a larger HTML response which can push our interactivity, 2) can leave the user in an uncanny valley where half the experience can’t actually be interactive until JavaScript finishes processing.

Progressive Bootstrapping may be a better approach. Send down a minimally functional page (composed of just the HTML/JS/CSS needed for the current route). As more resources arrive, the app can lazy-load and unlock more features.

Progressive Bootstrapping by Paul Lewis

Loading code proportionate to what’s in view is the holy grail. PRPL and Progressive Bootstrapping are patterns that can help accomplish this.

Conclusions #

Transmission size is critical for low end networks. Parse time is important for CPU bound devices. Keeping these low matters.

Teams have found success adopting strict performance budgets for keeping their JavaScript transmission and parse/compile times low. See Alex Russell’s "Can You Afford It?: Real-world Web Performance Budgets" for guidance on budgets for mobile.

It’s useful to consider how much JS "headroom" the architectural decisions we make can leave us for app logic.

If you’re building a site that targets mobile devices, do your best to develop on representative hardware, keep your JavaScript parse/compile times low and adopt a Performance Budget for ensuring your team are able to keep an eye on their JavaScript costs.

Learn More #

Chrome Dev Summit 2017 - Modern Loading Best Practices
JavaScript Start-up Performance
Solving the web performance crisis — Nolan Lawson
Can you afford it? Real-world performance budgets — Alex Russell
Evaluating web frameworks and libraries — Kristofer Baxter
Cloudflare’s Results of experimenting with Brotli for compression (note dynamic Brotli at a higher quality can delay initial page render so evaluate carefully. You probably want to statically compress instead.)
Performance Futures — Sam Saccone

Data-binding revolutions with Object.observe()

2014-05-20T00:00:00Z

Introduction #

A revolution is coming. There’s a new addition to JavaScript that’s going to change everything you think you know about data-binding. It’s also going to change how many of your MVC libraries approach observing models for edits and updates. Are you ready for some sweet performance boosts to apps that care about property observation?

Okay. Okay. Without further delay, I’m happy to announce Object.observe() has landed in Chrome 36 stable. [WOOOO. THE CROWD GOES WILD].

Object.observe(), part of a future ECMAScript standard, is a method for asynchronously observing changes to JavaScript objects… without the need for a separate library. It allows an observer to receive a time-ordered sequence of change records which describe the set of changes which took place to a set of observed objects.

// Let's say we have a model with data
var model = {};

// Which we then observe
Object.observe(model, function(changes){

    // This asynchronous callback runs
    changes.forEach(function(change) {

        // Letting us know what changed
        console.log(change.type, change.name, change.oldValue);
    });

});

Anytime a change is made, it gets reported:

With Object.observe() (I like to call it O.o() or Oooooooo), you can implement two-way data-binding without the need for a framework.

That’s not to say you shouldn’t use one. For large projects with complicated business logic, opinionated frameworks are invaluable and you should continue to use them. They simplify the orientation of new developers, require less code maintenance and impose patterns on how to achieve common tasks. When you don’t need one, you can use smaller, more focused libraries like Polymer (which already take advantage of O.o()).

Even if you find yourself heavily using a framework or MV* library, O.o() has the potential to provide them with some healthy performance improvements, with a faster, simpler implementation whilst keeping the same API. For example, last year Angular found that in a benchmark where changes were being made to a model, dirty-checking took 40ms per update and O.o() took 1-2ms per update (an improvement of 20-40x faster).

Data-binding without the need for tons of complicated code also means you no longer have to poll for changes, so longer battery life!

If you're already sold on O.o(), skip-ahead to the feature introduction, or read ahead for more on the problems it solves.

What do we want to observe? #

When we’re talking about data observation, we’re usually referring to keeping an eye out for some specific types of changes:

Changes to raw JavaScript objects
When properties get added, changed, deleted
When arrays have elements spliced in and out of them
Changes to the prototype of the object

The importance of data-binding #

Data-binding starts to become important when you care about model-view control separation. HTML is a great declarative mechanism, but it’s completely static. Ideally, you just want to declare the relationship between your data and the DOM and keep the DOM up to date. This creates leverage and saves you a lot of time writing really repetitive code that just sends data to and from the DOM between your application’s internal state or the server.

Data-binding is particularly useful when you have a complex user-interface where you need to wire up relationships between multiple properties in your data models with multiple elements in your views. This is pretty common in the single-page applications we’re building today.

By baking a way to natively observe data in the browser, we give JavaScript frameworks (and small utility libraries you write) a way to observe changes to model data without relying on some of the slow hacks the world uses today.

What the world looks like today #

Dirty-checking

Where have you seen data-binding before? Well, if you use a modern MV* library for building your webapps (e.g Angular, Knockout) you’re probably used to binding model data to the DOM. As a refresher, here’s an example of a Phone list app where we’re binding the value of each phone in a phones array (defined in JavaScript) to a list item so that our data and UI are always in sync:

<html ng-app>
  <head>
    ...
    <script src='angular.js'></script>
    <script src='controller.js'></script>
  </head>
  <body ng-controller='PhoneListCtrl'>
    <ul>
      <li ng-repeat='phone in phones'>
        
        <p></p>
      </li>
    </ul>
  </body>
</html>

and the JavaScript for the controller:

var phonecatApp = angular.module('phonecatApp', []);

phonecatApp.controller('PhoneListCtrl', function($scope) {
  $scope.phones = [
    {'name': 'Nexus S',
     'snippet': 'Fast just got faster with Nexus S.'},
    {'name': 'Motorola XOOM with Wi-Fi',
     'snippet': 'The Next, Next Generation tablet.'},
    {'name': 'MOTOROLA XOOM',
     'snippet': 'The Next, Next Generation tablet.'}
  ];
});

Anytime the underlying model data changes, our list in the DOM gets updated. How does Angular achieve this? Well, behind the scenes it’s doing something called dirty-checking.

The basic idea with dirty-checking is that anytime data could have changed, the library has to go and check if it did change via a digest or change cycle. In Angular’s case, a digest cycle identifies all expressions registered to be watched to see if there’s a change. It knows about a model’s previous values and if they have changed, a change event is fired. For a developer, the main benefit here is that you get to use raw JavaScript object data which is pleasant to use and composes fairly well. The downside is that it has bad algorithmic behavior and is potentially very expensive.

The expense of this operation is proportional to the total number of observed objects. I may need to do a lot of dirty checking. Also may need a way to trigger dirty-checking when data might have changed. There are lots of clever tricks frameworks use for this. It's unclear if this is ever going to be perfect.

The web ecosystem should have more ability to innovate and evolve its own declarative mechanisms, e.g.

Constraint-based model systems
Auto-persistence systems (e.g persisting changes to IndexedDB or localStorage)
Container objects (Ember, Backbone)

Container objects are where a framework creates objects which on the inside hold the data. They have accessors to the data and they can capture what you set or get and internally broadcast. This works well. It's relatively performant and has good algorithmic behavior. An example of container objects using Ember can be found below:

// Container objects
MyApp.president = Ember.Object.create({
  name: "Barack Obama"
});
 
MyApp.country = Ember.Object.create({
  // ending a property with "Binding" tells Ember to
  // create a binding to the presidentName property
  presidentNameBinding: "MyApp.president.name"
});
 
// Later, after Ember has resolved bindings
MyApp.country.get("presidentName");
// "Barack Obama"
 
// Data from the server needs to be converted
// Composes poorly with existing code

The expense of discovering what changed here is proportional to the number of things that changed. Another problem is now you're using this different kind of object. Generally speaking you have to convert from data you're getting from the server to these objects so they're observable.

This doesn't compose particularly well with existing JS code because most code assumes it can operate on raw data. Not for these these specialized kinds of objects.

`Introducing Object.observe()` #

Ideally what we want is the best of both worlds - a way to observe data with support for raw data objects (regular JavaScript objects) if we choose to AND without the need to dirty-check everything all the time. Something with good algorithmic behavior. Something that composes well and is baked into the platform. This is the beauty of what Object.observe() brings to the table.

It allows us to observe an object, mutate properties and see the change report of what has changed. But enough about the theory, let’s look at some code!

Object.observe() and Object.unobserve() #

Let’s imagine that we have a simple vanilla JavaScript object representing a model:

// A model can be a simple vanilla object
var todoModel = {
  label: 'Default',
  completed: false
};

We can then specify a callback for whenever mutations (changes) are made to the object:

function observer(changes){
  changes.forEach(function(change, i){
      console.log('what property changed? ' + change.name);
      console.log('how did it change? ' + change.type);
      console.log('whats the current value? ' + change.object[change.name]);
      console.log(change); // all changes
  });
}

We can then observe these changes using O.o(), passing in the object as our first argument and the callback as our second:

Object.observe(todoModel, observer);

Let’s start making some changes to our Todos model object:

todoModel.label = 'Buy some more milk';

Looking at the console, we get back some useful information! We know what property changed, how it was changed and what the new value is.

Woo! Goodbye, dirty-checking! Your tombstone should be carved in Comic Sans. Let’s change another property. This time completeBy:

todoModel.completeBy = '01/01/2014';

As we can see we once again successfully get back a change report:

Great. What if we now decided to delete the ‘completed’ property from our object:

delete todoModel.completed;

As we can see, the report of changes returned includes information about the deletion. As expected, the new value of the property is now undefined. So, we now know you can find out when properties have been added. When they've been deleted. Basically, the set of properties on an object ("new", "deleted", "reconfigured") and it's prototype changing (proto).

As in any observation system, a method also exists to stop listening out for changes. In this case, it’s Object.unobserve(), which has the same signature as O.o() but can be called as follows:

Object.unobserve(todoModel, observer);

As we can see below, any mutations made to the object after this has been run no longer result in a list of change records being returned.

Specifying changes of interest #

So we’ve looked at the basics behind how to get back a list of changes to an observed object. What if you’re interested in only a subset of changes that were made to an object rather than all of them?. Everyone needs a spam filter. Well, observers can specify only those types of changes they wish to hear about through an accept list. This can be specified using the third argument to O.o() as follows:

Object.observe(obj, callback, optAcceptList)

Let’s walk through an example of how this can be used:

// Like earlier, a model can be a simple vanilla object

var todoModel = {
  label: 'Default',
  completed: false

};


// We then specify a callback for whenever mutations 
// are made to the object
function observer(changes){
  changes.forEach(function(change, i){
    console.log(change);
  })

};

// Which we then observe, specifying an array of change 
// types we're interested in

Object.observe(todoModel, observer, ['delete']);

// without this third option, the change types provided 
// default to intrinsic types

todoModel.label = 'Buy some milk'; 

// note that no changes were reported

If however we now delete the label, notice that this type of change does get reported:

delete todoModel.label;

If you don’t specify a list of accept types to O.o(), it defaults to the "intrinsic" object change types (add, update, delete, reconfigure, preventExtensions (for when an object becoming non-extensible isn’t observable)).

Notifications #

O.o() also comes with the notion of notifications. They’re nothing like those annoying things you get on a phone, but rather useful. Notifications are similar to Mutation Observers. They happen at the end of the micro-task. In the browser context, this is almost always going to be at the end of the current event handler.

The timing is nice because generally one unit of work is finished and now observers get to do their work. It’s a nice turn-based processing model.

The workflow for using a notifier looks a little like this:

Let’s look at an example of how notifiers might be used in practice to define custom notifications for when properties on an object are get or set. Keep an eye on the comments here:

// Define a simple model
var model = {
    a: {}
};

// And a separate variable we'll be using for our model's 
// getter in just a moment
var _b = 2;

// Define a new property 'b' under 'a' with a custom
// getter and setter

Object.defineProperty(model.a, 'b', {
    get: function () {
        return _b;
    },
    set: function (b) {

        // Whenever 'b' is set on the model
        // notify the world about a specific type
        // of change being made. This gives you a huge
        // amount of control over notifications
        Object.getNotifier(this).notify({
            type: 'update',
            name: 'b',
            oldValue: _b
        });

        // Let's also log out the value anytime it gets
        // set for kicks
        console.log('set', b);

        _b = b;
    }
});

// Set up our observer
function observer(changes) {
    changes.forEach(function (change, i) {
        console.log(change);
    })
}

// Begin observing model.a for changes
Object.observe(model.a, observer);

Here we report when the value of the data properties change ("update"). Anything else the object’s implementation chooses to report (notifier.notifyChange()).

Years of experience on the web platform have taught us that a synchronous approach is the first thing you try because its the easiest to wrap your head around. The problem is it creates a fundamentally dangerous processing model. If you're writing code and say, update the property of an object, you don't really want a situation having update the property of that object could have invited some arbitrary code to go do whatever it wanted. It's not ideal to have your assumptions invalidated as you're running through the middle of a function.

If you're an observer, you ideally don't want to be called if someone is in the middle of something. You don't want to be asked to go to do work on an inconsistent state of the world. End up doing a lot more error checking. Trying to tolerate a lot more bad situations and generally, its a hard model to work with. Async is harder to deal with but its a better model at the end of the day.

The solution to this problem is synthetic change records.

Synthetic change records #

Basically, if you want to have accessors or computed properties it is your responsibility to notify when these values change. It’s a little extra work but it is designed as a sort of first-class feature of this mechanism and these notifications will be delivered with the rest of the notifications from underlying data objects. From data properties.

Observing accessors and computed properties can be solved with notifier.notify - another part of O.o(). Most observation systems want some form of observing derived values. There are lots of ways to do this. O.o makes no judgement as to the "right" way. Computed properties should be accessors which notify when the internal (private) state changes.

Again, webdevs should expect libraries to help make notifying and various approaches to computed properties easy (and reduce boilerplate).

Let’s set up the next example, which is a circle class. The idea here is that we have this circle and there’s a radius property. In this case the radius is an accessor and when its value changes it’s actually going to notify for itself that the value changed. This will be delivered with all other changes to this object or any other object. Essentially, if you’re implementing an object you want to have synthetic or computed properties or you have to pick a strategy for how this is going to work. Once you do, this will fit into your system as a whole.

Skip past the code to see this working in DevTools.

function Circle(r) {
  var radius = r;
 
  var notifier = Object.getNotifier(this);
  function notifyAreaAndRadius(radius) {
    notifier.notify({
      type: 'update',
      name: 'radius',
      oldValue: radius
    })
    notifier.notify({
      type: 'update',
      name: 'area',
      oldValue: Math.pow(radius * Math.PI, 2)
    });
  }
 
  Object.defineProperty(this, 'radius', {
    get: function() {
      return radius;
    },
    set: function(r) {
      if (radius === r)
        return;
      notifyAreaAndRadius(radius);
      radius = r;
    }
  });
 
  Object.defineProperty(this, 'area', {
    get: function() {
      return Math.pow(radius, 2) * Math.PI;
    },
    set: function(a) {
      r = Math.sqrt(a/Math.PI);
      notifyAreaAndRadius(radius);
      radius = r;
    }
  });
}
 
function observer(changes){
  changes.forEach(function(change, i){
    console.log(change);
  })
}

Accessor properties #

A quick note on accessor properties. We mentioned earlier that only the value changes are observable for data properties. Not for computed properties or accessors. The reason is that JavaScript doesn't really have the notion of changes in value to accessors. An accessor is just a collection of functions.

If you assign to an accessor JavaScript just invokes the function there and from its point of view nothing has changed. It just gave some code the opportunity to run.

The problem is semantically we can look at our above assignment to the value - 5 to it. We ought to be able to know what happened here. This is actually an unsolvable problem. The example demonstrates why. There is really no way for any system to know what is meant by this because this can be arbitrary code. It can do whatever it wants in this case. It’s updating the value every time it is accessed and so asking whether it changed doesn’t make much sense.

Observing multiple objects with one callback #

Another pattern possible with O.o() is the notion of a single callback observer. This allows a single callback to be used as an "observer" for lots of different objects. The callback will be delivered the full set of changes to all objects it observes at the “end of the microtask” (Note the similarity to Mutation Observers).

Large-scale changes #

Maybe you’re working on a reaaaally big app and regularly have to work with large-scale changes. Objects may wish to describe larger semantic changes which will affect lots of properties in a more compact way (instead of broadcasting tons of property changes).

O.o() helps with this in the form of two specific utilities: notifier.performChange() and notifier.notify(), which we’ve already introduced.

Let’s look at this in an example of how large-scale changes can be described where we define a Thingy object with some math utilities (multiply, increment, incrementAndMultiply). Any time a utility is used, it tells the system that a collection of work comprises a specific type of change.

For example: notifier.performChange('foo', performFooChangeFn);

function Thingy(a, b, c) {
  this.a = a;
  this.b = b;
}

Thingy.MULTIPLY = 'multiply';
Thingy.INCREMENT = 'increment';
Thingy.INCREMENT_AND_MULTIPLY = 'incrementAndMultiply';


Thingy.prototype = {
  increment: function(amount) {
    var notifier = Object.getNotifier(this);

    // Tell the system that a collection of work comprises 
    // a given changeType. e.g
    // notifier.performChange('foo', performFooChangeFn);
    // notifier.notify('foo', 'fooChangeRecord');
    notifier.performChange(Thingy.INCREMENT, function() {
      this.a += amount;
      this.b += amount;
    }, this);

    notifier.notify({
      object: this,
      type: Thingy.INCREMENT,
      incremented: amount
    });
  },

  multiply: function(amount) {
    var notifier = Object.getNotifier(this);

    notifier.performChange(Thingy.MULTIPLY, function() {
      this.a *= amount;
      this.b *= amount;
    }, this);

    notifier.notify({
      object: this,
      type: Thingy.MULTIPLY,
      multiplied: amount
    });
  },

  incrementAndMultiply: function(incAmount, multAmount) {
    var notifier = Object.getNotifier(this);

    notifier.performChange(Thingy.INCREMENT_AND_MULTIPLY, function() {
      this.increment(incAmount);
      this.multiply(multAmount);
    }, this);

    notifier.notify({
      object: this,
      type: Thingy.INCREMENT_AND_MULTIPLY,
      incremented: incAmount,
      multiplied: multAmount
    });
  }
}

We then define two observers for our object: one which is a catch-all for changes and another which will only report back on specific accept types we’ve defined (Thingy.INCREMENT, Thingy.MULTIPLY, Thingy.INCREMENT_AND_MULTIPLY).

var observer, observer2 = {
    records: undefined,
    callbackCount: 0,
    reset: function() {
      this.records = undefined;
      this.callbackCount = 0;
    },
};

observer.callback = function(r) {
    console.log(r);
    observer.records = r;
    observer.callbackCount++;
};

observer2.callback = function(r){
	console.log('Observer 2', r);
}


Thingy.observe = function(thingy, callback) {
  // Object.observe(obj, callback, optAcceptList)
  Object.observe(thingy, callback, [Thingy.INCREMENT,
                                    Thingy.MULTIPLY,
                                    Thingy.INCREMENT_AND_MULTIPLY,
                                    'update']);
}

Thingy.unobserve = function(thingy, callback) {
  Object.unobserve(thingy);
}

We can now start playing with this code. Let's define a new Thingy:

var thingy = new Thingy(2, 4);

Observe it and then make some changes. OMG, so fun. SO many thingies!

// Observe thingy
Object.observe(thingy, observer.callback);
Thingy.observe(thingy, observer2.callback);

// Play with the methods thingy exposes
thingy.increment(3);               // { a: 5, b: 7 }
thingy.b++;                        // { a: 5, b: 8 }
thingy.multiply(2);                // { a: 10, b: 16 }
thingy.a++;                        // { a: 11, b: 16 }
thingy.incrementAndMultiply(2, 2); // { a: 26, b: 36 }

Everything inside of the "perform function" is considered to be the work of “big-change”. Observers which accept “big-change” will only receive the “big-change” record. Observers which do not will receive the underlying changes resulting from the work which “perform function” did.

Observing arrays #

We’ve talked for a while about observing changes to objects but what about arrays?! Great question. When someone tells me, "Great question." I never hear their answer because I'm busy congratulating myself for asking such a great question, but I digress. We have new methods for working with arrays too!

Array.observe() is a method that treats large-scale changes to itself - for example - splice, unshift or anything which implicitly changes it length - as a "splice" change record. Internally it uses notifier.performChange("splice",...).

Here’s an example where we observe a model "array" and similarly get back a list of changes when there are any changes to the underlying data:

var model = ['Buy some milk', 'Learn to code', 'Wear some plaid'];
var count = 0;

Array.observe(model, function(changeRecords) {
  count++;
  console.log('Array observe', changeRecords, count);
});

model[0] = 'Teach Paul Lewis to code';
model[1] = 'Channel your inner Paul Irish';

Performance #

The way to think about the computational performance impact of O.o() is to think about it like a read cache. Generally speaking, a cache is a great choice when (in order of importance):

The frequency of reads dominates the frequency of writes.
You're able to create a cache which trades the constant amount of work involved during writes for algorithmically better performance during reads.
The constant time slowdown of writes is acceptable.

O.o() is designed for use-cases like 1).

Dirty-checking requires keeping a copy of all the data you're observing. This means you incur a structural memory cost to dirty-checking you just don't get with O.o(). Dirty-checking, whilst a decent stop-gap solution, is also a fundamentally leaky abstraction which can create unnecessary complexity for applications.

Why? Well, dirty-checking has to run any time data may have changed. There simply isn't a very robust way to do this and any approach to it has significant downsides (e.g checking on a polling interval risks visual artifacts and race conditions between code concerns). Dirty-checking also requires a global registry of observers, creating memory-leak hazards and tear-down costs O.o() avoids.

Let’s take a look at some numbers.

The below benchmark tests (available on GitHub) allow us to compare dirty-checking vs O.o(). They're structured as graphs of Observed-Object-Set-Size vs Number-Of-Mutations. The general result is that dirty-checking performance is algorithmically proportional to the number of observed objects while O.o() performance is proportional to the number of mutations which were made.

Dirty-checking

Chrome with Object.observe() switched on

Polyfilling Object.observe() #

Great - so O.o() can be used in Chrome 36, but what about using it in other browsers? We’ve got you covered. Polymer’s Observe-JS is a polyfill for O.o() which will use the native implementation if it’s present, but otherwise polyfills it and includes some useful sugaring on top. It offers an aggregate view of the world that sums up changes and delivers a report of what has changed. Two really powerful things it exposes are:

You can observe paths. This means you can say, I would like to observe "foo.bar.baz" from a given object and they’ll tell you when the value at that path changed. If the path is unreachable, it considers the value undefined.

Example of observing a value at a path from a given object:

var obj = { foo: { bar: 'baz' } };

var observer = new PathObserver(obj, 'foo.bar');
observer.open(function(newValue, oldValue) {
  // respond to obj.foo.bar having changed value.
});

It will tell you about array splices. Array splices are basically the minimal set of splice operations you will have to perform on an array in order to transform the old version of the array into the new version of the array. This is a type of transform or different view of the array. It’s the minimum amount of work you need to do to move from the old state to the new state.

Example of reporting changes to an array as a minimal set of splices:

var arr = [0, 1, 2, 4];

var observer = new ArrayObserver(arr);
observer.open(function(splices) {
  // respond to changes to the elements of arr.
  splices.forEach(function(splice) {
    splice.index; // index position that the change occurred.
    splice.removed; // an array of values representing the sequence of elements which were removed
    splice.addedCount; // the number of elements which were inserted.
  });
});

Frameworks and Object.observe() #

As mentioned, O.o() will give frameworks and libraries a huge opportunity to improve the performance of their data-binding in browsers that support the feature.

Yehuda Katz and Erik Bryn from Ember confirmed that adding support for O.o() is in Ember's near-term roadmap. Angular's Misko Hervy wrote a design doc on Angular 2.0's improved change detection. Their long term approach will be to take advantage of Object.observe() when it lands in Chrome stable, opting for Watchtower.js, their own change detection approach until then. Suuuuper exciting.

Conclusions #

O.o() is a powerful addition to the web platform which you can go out and use today.

We’re hopeful that in time the feature will land in more browsers, allowing JavaScript frameworks to get performance boosts from access to native object observation capabilities. Those targeting Chrome should be able to use O.o() in Chrome 36 (and above) and the feature should also be available in a future Opera release.

So, go forth and talk to the authors of JavaScript frameworks about Object.observe() and how they’re planning on using it to improve the performance of data-binding in your apps. There are most definitely exciting times ahead!

Resources #

With thanks to Rafael Weinstein, Jake Archibald, Eric Bidelman, Paul Kinlan and Vivian Cromwell for their input and reviews.

Synchronized cross-device mobile testing

2013-11-25T00:00:00Z

Introduction #

If you're a web developer targeting the multi-device web, you likely have to test your sites and web apps across a number of different devices and configurations. Synchronized testing can help here and is an effective way to automatically perform the same interaction across a number of devices and browsers at the same time.

Synchronized testing can help solve two particularly time-consuming problems:

Keeping all your devices in sync with the URL you want to test. Manually loading them on each device is so yesterday, takes longer and makes it easier to miss out on regressions.
Synchronizing interactions. Being able to load up a page is great for visual testing, but for interaction testing you ideally also want to be able to synchronize scrolls, clicks and other behaviours.

Thankfully if you have access to some of your target devices, there are a number of tools aimed at improving the flow from your desktop to your mobile devices. In this article, we will look at Ghostlab, Remote Preview, Adobe Edge Inspect and Grunt.

This is my desk. Well, it used to be my desk. It's now just a mobile museum.

Tools #

GhostLab (Mac) #

GhostLab for Mac by Vanamco

Ghostlab is a commercial Mac application ($49) designed to synchronise testing for sites and web apps across multiple devices. With minimum setup it allows you to simultaneously sync:

Clicks
Navigation
Scrolls
Form input (e.g login forms, sign-up)

This makes testing your site's end-to-end user experience on multiple devices very straightforward. Once you've opened your page in a browser on your devices, any changes to navigation (including refreshes) cause any other connected devices to refresh instantly. Ghostlab supports watching local directories, so this refresh also happens when you save edits to local files, keeping everything in sync always!

I found setting up Ghostlab a painless process. To get started, download, install and run the trial (or full version if you're in the buying mood). You will then want to connect your Mac and the devices you wish to test to the same Wifi network so that they're discoverable.

Once Ghostlab is running, you can either click "+" to add a URL for testing or simply drag it from your browser's address bar. Alternatively, drag the local folder you wish to test over into the main window and a new site entry will be created. For this article, I'm testing a live version of http://html5rocks.com. Cheeky, eh? ; )

Choose a URL or local directory on your machine

You can then kick-start off a new Ghostlab server by clicking the ">" play button next to the name of your site. This starts a new server, available at an IP address specific to your network (e.g http://192.168.21.43:8080).

Ghostlab server locally proxying content from our URL

Here, I've connected up a Nexus 4 and pointed Chrome for Android to the IP address Ghostlab gave me. That's all I have to do. Ghostlab doesn't require that you install a dedicated client per device like some other solutions and it means you can start testing even more quickly.

Any device you connect to the Ghostlab URL will be added to the list of connected clients in the sidebar to the right of the main Ghostlab window. Double-clicking the device name displays additional details such as the screen size, OS and so on. You should now be able to test navigating and synchronizing clicks! Yay.

Ghostlab is also able to display some stats about connected devices like the UA string, viewport width and height, device pixel density, aspect ratio and more. At any time, you can manually change the base URL you are inspecting by clicking the settings cog next to an entry. This opens up a configuration window that looks like the below:

Configure files to watch, HTTP headers, character sets and more.

I can now select one of my other connected devices, click on different links around HTML5Rocks and the navigation is synchronized both on my desktop Chrome (where I entered in the same Ghostlab URL) as well as across all of my devices.

What's even better is that Ghostlab has an option allowing you to proxy all links going through the network so that instead of a click on http://192.168.21.43:8080/www.html5rocks.com navigating to www.html5rocks.com/en/performance (for example), which would break the automatic cross-device refresh suffered by other solutions, it can just translate this link into http://192.168.21.43/www.htm5rocks.com/en/performance so that navigating is completely seamless across all my devices.

To enable, check "Load all content through Ghostlab" under the "Content Loading" tab.

Ghostlab can rewrite URLs so all resources are loaded through the Ghostlab proxy. Useful for synchronizing navigations to multiple pages

Seeing it in action:

Synchronized testing of an Android, Windows 8 and Firefox OS phone with Ghostlab

Ghostlab is capable of loading any number of sites or windows across any supported browser. This doesn't just let you test your site at different resolutions, but how your code behaves on different browsers and platforms. Yay!

Synchronizing scroll, clicks and navigation across all of the test devices

Ghostlab allows you to configure the setup for the project workspace you're previewing and you can specify whether you would like changes to the directory to be watched and refreshed when detected. This means changes cause all connected clients to be refreshed. No more manual refreshes!

You may be wondering what else Ghostlab can help with. Whilst it's certainly not a swiss-army knife, it also supports remote code inspection on connected devices. Through the main interface, double-clicking on any device name should bring up a "debug" option which will launch a version of the Chrome DevTools for you to play around with.

Ghostlab makes this possible via the bundled Weinre remote web inspector, which lets you debug scripts and tweak styles on connected devices. Similar to the remote debugging experience available for Chrome for Android, you can select elements, run some performance profiling and debug scripts.

All in all, I was impressed with how quickly I was able to use Ghostlab for everyday testing across devices. If you're a freelancer, you might find the cost of the commercial license a little high (see below for more options). However, I'm happy to recommend Ghostlab otherwise.

Adobe Edge Inspect CC (Mac, Windows) #

Adobe's Creative Cloud subscription includes Edge Inspect

Adobe Edge Inspect is part of the Adobe Creative Cloud subscription package, but also comes available as a free trial. It allows you to drive multiple iOS and Android devices with Chrome (via the Edge Inspector Chrome extension), so that if you browse to a particular URL all of your connected devices stay in sync.

To get set up, first sign up for an Adobe Creative Cloud account or login to an existing account if you already have one. Next, download and install Edge Inspect from Adobe.com (available for Mac and Windows at present, but not Linux - sorry!). Note the docs for Edge Inspect are useful to keep at hand.

Once installed, you'll want to get the Edge inspect extension for Chrome so that you can synchronize browsing between connected devices.

The Edge Inspect CC Chrome Extension

You will also need to install an Edge Inspect client on each device you wish to sync actions with. Thankfully clients are available for iOS, Android and Kindle.

With the installation process behind us, we can now start inspecting our pages. You'll need to make sure all your devices are connected to the same network for this to work.

Start up Edge Inspect on your desktop, the Edge Inspect extension in Chrome and then the app on your devices (see below):

Connecting a device up to the Edge Inspect extension

We can now navigate to a site like HTML5Rocks.com on desktop and our mobile device will automatically navigate to the same page.

Driving navigation of a URL across multiple connected devices

In the extension, you'll also now see your device listed with a <> symbol next to it as in the screenshot below. Clicking this will launch an instance of Weinre allowing you to inspect and debug your page.

Connected devices appear with a <> symbol next to them, which can be used to launch the Weinre debugger

Weinre is a DOM viewer and console, and lacks features from the Chrome DevTools like JavaScript debugging, profiling, and network waterfall. While it is the bare minimum of developer tooling, it's useful for sanity-checking DOM and JavaScript state.

Debugging with Weinre

The Edge Inspect extension also supports generating screenshots from connected devices with ease. Useful for layout testing or just getting captures of your page to share with others.

Screenshot generation with Edge Inspect

For developers already paying for CC, Edge Inspect is a great solution. It does however come with a few caveats such as each device requiring a dedicated client to be installed and a little extra setup work that you may not find with an alternative like Ghostlab.

Remote Preview (Mac, Windows, Linux) #

Remote Preview is an open source tool where you host HTML pages and content that you can display on multiple devices.

Remote preview executes an XHR call at an interval of every 1100ms to check if a URL in a configuration file has changed. If it finds that it has, the script updates the src attribute of an iframe loaded into the page for each device, loading the page into it. If there are no changes detected, the script will continue polling until a change is made.

Synchronized URL testing across 27+ devices

This is great for chaining devices together and easily changing a URL across all of them. To get started:

Download Remote Preview and move all of the files for it into a locally accessible server. This can be Dropbox, a development server or something else.
Load up "index.html" from this download on all of your target devices. This page will be used as a driver and will load up the page you want to test using an iframe.
Edit "url.txt" (included in the download and now served on your server) with the URL you wish to preview. Save this file.
Remote Preview will notice that the url.txt file has changed and will refresh all connected devices to load up your URL.

Whilst a lo-fi solution, Remote Preview is free and works.

Grunt + Live-Reload (Mac, Windows, Linux) #

Grunt (and Yeoman) are command-line tools used for scaffolding and building projects on the front-end. If you're already using these tools and have live-reload setup, it's easy to update your workflow to enable cross-device testing where each change you make in your editor causes a reload in any of the devices you've opened up your local app on.

You're probably used to using grunt server. When run from the root directory of your project, it watches for any changes to your source files and automatically refreshes the browser window. This is thanks to the grunt-contrib-watch task which we run as part of the server.

If you happen to have used Yeoman to scaffold out your project, it will have created a Gruntfile with everything you need to get live-reload working on your desktop. To get it functioning cross-device, you just need to change one property, which is the hostname (on your desktop). It should be listed under connect. If you notice hostname is set to localhost just change it to 0.0.0.0. Next run grunt server and as usual, a new window should open displaying a preview of your page. The URL will probably look like http://localhost:9000 (9000 is the port).

Fire up a new tab or terminal and use ipconfig | grep inet to discover your system's internal IP. It may look like 192.168.32.20. The last step is to open up a browser like Chrome on the device you would like to synchronize livereloads to and type in this IP address followed by the port number from earlier. i.e 192.169.32.20:9000.

That's it! Live-reload should now cause any edits you make to source files on your desktop to trigger reloads in both your desktop browser and the browser on your mobile device. Awesome!

Saved edits on desktop now trigger a live-reload in your desktop browser as well as mobile browsers on devices with the same URL

Cross-device live-reload in action. Each edit/save gives you a real-time for of your current page, great for responsive design testing.

Yeoman also has a Mobile generator available which makes setting this workflow up a breeze.

Emmet LiveStyle #

Emmet LiveStyle is a browser and editor plugin that brings live CSS editing to your development workflow. It is currently available for Chrome, Safari and Sublime Text and supports bi-directional (editor to browser and vice-versa) editing.

Emmet LiveStyle doesn't force a complete browser refresh when you make changes, but instead pushes CSS edits across the DevTools remote debugging protocol. What this means is that you can see changes made in your desktop editor in any connected version of Chrome, whether it be on desktop Chrome or Chrome for Android.

LiveStyle has what it calls "multi-view mode", which is ideal for testing and tweaking responsive designs across windows and devices. In multi-view mode, all editor updates are applied to all windows as are DevTools updates for the same page.

With the LiveStyle package installed, to get started with live CSS editing:

Start up Sublime Text and open up a CSS file in a project
Start Chrome and go to the page with the CSS you would like to edit
Open DevTools and go to the LiveStyle panel. Check the "Enable LiveStyle" option. Note: DevTools will need to be kept open during your live editing session for each window in order for style updates to be applied.
When this has been enabled, a list of stylesheets will be displayed on the left and a list of your editor files on the right. Select the editor file to be associated with the browser. That's it! Boom.

Now the list of editor files will be automatically updated when you edit, create, open or close files.

Changes to CSS in Sublime being instantly patched across different browser windows and an emulator.

Conclusions #

Cross-device testing is still a new and fast moving space with many new contenders in development. Thankfully there exist a number of free and commercial tools for assuring your compatibility and testing across a wide number of device sets.

That said, there's still a lot of potential for improvement in this area and we would encourage you to think about how the tooling for testing across devices can be further improved. Anything that reduces setup time and improves your cross-device workflow is a win.

Issues #

Perhaps the largest issues I ran into during testing with these tools was devices regularly going to sleep. This isn't a deal-breaker, but does get annoying after a while. Where possible it's a good idea to set your devices to not sleep as a workaround, however, keep in mind that this can drain your battery unless you're always plugged in.

I didn't personally run into any major issues with GhostLab. At $49 some may find the price a little steep; however, keep in mind if you're using it regularly it more or less pays for itself. One of the nicest things about the setup was not having to worry about installing and managing a client per target device. The same URL worked everywhere.

With Adobe Edge Inspect, I found having to install and use specific clients on each device a little bit tedious. I also found it didn't consistently refresh all of the clients connected up, meaning I had to do this myself from the Chrome extension. It also requires a subscription to Creative Cloud and is limited to loading up sites in the client rather than in a selected browser on your devices. This may limit your ability to accurately test.

Remote Preview functioned as advertised, but is extremely lightweight. This means for anything more than refreshing your site across devices, you'll need a more advanced tooling option. It won't for example, synchronize clicks or scrolls.

Recommendations #

If you're looking for a free cross-platform solution to get you started, I recommend using Remote Preview. For those working in a company looking for a paid-for solution, GhostLab has been consistently excellent in my experience but is only available for the Mac. For Windows users, Adobe Edge Inspect is your best call and minus some quirks, does generally get the job done.

Grunt and LiveStyle are also excellent for augmenting your live iteration during development.

Building web apps with Yeoman and Polymer

2013-10-10T00:00:00Z

Introduction #

Allo’ Allo’. Anyone writing a web app knows how important it is to keep oneself productive. It's a challenge when you have to worry about tedious tasks like finding the right boilerplate, setting up a development and testing workflow and minifying and compressing all your sources.

Fortunately modern front-end tooling can help automate much of this, leaving you to focus on writing a kick-ass app. This article will show you how to use Yeoman, a workflow of tools for web apps to streamline creating apps using Polymer, a library of polyfills and sugar for developing apps using Web Components.

Meet Yo, Grunt and Bower #

Yeoman is a man in a hat with three tools for improving your productivity:

yo is a scaffolding tool that offers an ecosystem of framework-specific scaffolds, called generators that can be used to perform some of the tedious tasks I mentioned earlier.
grunt is used to build, preview and test your project, thanks to help from tasks curated by the Yeoman team and grunt-contrib.
bower is used for dependency management, so that you no longer have to manually download and manage your scripts.

With just a command or two, Yeoman can write boilerplate code for your app (or individual pieces like Models), compile your Sass, minimize and concatenate your CSS, JS, HTML and images and fire up a simple web server in your current directory. It can also run your unit tests and more.

You can install generators from Node Packaged Modules (npm) and there are over 220 generators now available, many of which have been written by the open-source community. Popular generators include generator-angular, generator-backbone and generator-ember.

With a recent version of Node.js installed, head to your nearest terminal and run:

$ npm install -g yo

That's it! You now have Yo, Grunt and Bower and can run them directly from the command-line. Here’s the output of running yo:

Polymer Generator #

As I mentioned earlier, Polymer is a library of polyfills and sugar which enables the use of Web Components in modern browsers. The project allows developers to build apps using the platform of tomorrow and inform the W3C of places where in-flight specifications can be further improved.

generator-polymer is a new generator that helps you scaffold out Polymer apps using Yeoman, letting you easily create and customize Polymer (custom) elements via the command line, and import them using HTML Imports. This saves you time by writing the boilerplate code for you.

Next, install Polymer’s generator by running:

$ npm install generator-polymer -g

That's it. Now your app has Web Component super-powers!

Our newly installed generator has a few specific bits you’ll have access to:

polymer:element is used to scaffold out new individual Polymer elements. For example: yo polymer:element carousel
polymer:app is used to scaffold your initial index.html, a Gruntfile.js containing build-time configuration for your project as well as Grunt tasks and a folder structure recommended for the project. It will also give you the option of using Sass Bootstrap for your project’s styles.

Let’s build a Polymer app #

We're going to build a simple blog using some custom Polymer elements and our new generator.

To begin, go to the terminal, make a new directory and cd into it using mkdir my-new-project && cd $_. You can now kick-start your Polymer app by running:

$ yo polymer

This gets the latest version of Polymer from Bower and scaffolds out an index.html, directory structure and Grunt tasks for your workflow. Why not grab a coffee while we wait for the app to finish getting ready?

Okay, so next we can run grunt server to preview what the app looks like:

The server supports LiveReload, meaning you can fire up a text editor, edit a custom element and the browser will reload on save. This gives you a nice real-time view of your app’s current state.

Next, let's create a new Polymer element to represent a Blog post.

$ yo polymer:element post

Yeoman asks us a few questions such as whether we would like to include a constructor or use an HTML Import to include the post element in index.html. Let's say No to the first two options for now and leave the third option blank.

$ yo polymer:element post

[?] Would you like to include constructor=''? No

[?] Import to your index.html using HTML imports? No

[?] Import other elements into this one? (e.g 'another_element.html' or leave blank)

    create app/elements/post.html

This creates a new Polymer element in the /elements directory named post.html:

<polymer-element name="post-element"  attributes="">

    <template>

    <style>
        @host { :scope {display: block;} }
    </style>

    <span>I'm <b>post-element</b>. This is my Shadow DOM.</span>

    </template>

    <script>

    Polymer('post-element', {

        //applyAuthorStyles: true,

        //resetStyleInheritance: true,

        created: function() { },

        enteredView: function() { },

        leftView: function() { },

        attributeChanged: function(attrName, oldVal, newVal) { }

    });

    </script>

</polymer-element>

It contains:

Boilerplate code for your custom element, allowing you to use a custom DOM element type in your page (e.g <post-element>)
A template tag for ‘native’ client-side templating and sample scoped styles for encapsulating the styles of your element
Element registration boilerplate and lifecycle events.

Working with a real source of data #

Our blog will need a place to write and read new posts. To demonstrate working with a real data service, we’re going to use the Google Apps Spreadsheets API. This allows us to easily read in the content of any spreadsheet created using Google Docs.

Let’s get this set up:

In your browser (for these steps, Chrome is recommended) open up this Google Docs Spreadsheet. It contains sample post data under the following fields:
- ID
- Title
- Author
- Content
- Date
- Keywords
- E-mail (of the author)
- Slug (for your post’s slug URL)
Go to the File menu and select Make a copy to create your own copy of the spreadsheet. You are free to edit the content at your leisure, adding or removing posts.
Go to the File menu once again and select Publish to the web.
Click start publishing
Under Get a link to the published data, from the last text box, copy the key portion of the URL provided. It looks like this: https://docs.google.com/spreadsheet/ccc?key=0AhcraNy3sgspdDhuQ2pvN21JVW9NeVA0M1h4eGo3RGc#gid=0
Paste the key into the following URL where it says your-key-goes-here: https://spreadsheets.google.com/feeds/list/your-key-goes-here/od6/public/values?alt=json-in-script&callback=. An example using the key above might look like https://spreadsheets.google.com/feeds/list/0AhcraNy3sgspdDhuQ2pvN21JVW9NeVA0M1h4eGo3RGc/od6/public/values?alt=json-in-script.
You can paste the URL into your browser and navigate to it to view the JSON version of your blog content. Take note of the URL then spend a little time reviewing the format of this data as you will need to iterate over it in order to display it on screen later.

The JSON output in your browser may look a little daunting, but don’t worry!. We’re really only interested in the data for your posts.

The Google Spreadsheets API outputs each of the fields in your blog spreadsheet with a special prefix post.gsx$. For example: post.gsx$title.$t, post.gsx$author.$t, post.gsx$content.$t and so on. When we iterate over each “row” in our JSON output, we’ll reference these fields to get back the relevant values for each post.

You can now edit your newly scaffolded post element to bind portions of markup to the data in your spreadsheet. To do so, we introduce an attribute post, which will read for the post title, author, content and other fields we created earlier. The selected attribute (which we will populate later) is used to only show a post if a user navigates to the correct slug for it.

<polymer-element name="post-element" attributes="post selected">

    <template>

    <style>
        @host { :scope {display: block;} }
    </style>

        <div class="col-lg-4">

            <template if="[[post.gsx$slug.$t === selected]]">

            <h2>
                <a href="#[[post.gsx$slug.$t]]">
                [[post.gsx$title.$t  ]]
                </a>
            </h2>

            <p>By [[post.gsx$author.$t]]</p>

            <p>[[post.gsx$content.$t]]</p>

            <p>Published on: [[post.gsx$date.$t]]</p>

            <small>Keywords: [[post.gsx$keywords.$t]]</small>

            </template>

        </div>

    </template>

    <script>

    Polymer('post-element', {

        created: function() { },

        enteredView: function() { },

        leftView: function() { },

        attributeChanged: function(attrName, oldVal, newVal) { }

    });

    </script>

</polymer-element>

Next, let's create a blog element which contains both a collection of posts and the layout for your blog by running yo polymer:element blog.

$ yo polymer:element blog

[?] Would you like to include constructor=''? No

[?] Import to your index.html using HTML imports? Yes

[?] Import other elements into this one? (e.g 'another_element.html' or leave blank) post.html

    create app/elements/blog.html

This time we import the blog into index.html using HTML imports as we would like it to appear in the page. For the third prompt specifically, we specify post.html as the element we would like to include.

As before, a new element file is created (blog.html) and added to /elements, this time importing post.html and including <post-element> within the template tag:

<link rel="import" href="post.html">

<polymer-element name="blog-element"  attributes="">

    <template>

    <style>
        @host { :scope {display: block;} }
    </style>

    <span>I'm <b>blog-element</b>. This is my Shadow DOM.</span>

        <post-element></post-element>

    </template>

    <script>

    Polymer('blog-element', {

        //applyAuthorStyles: true,

        //resetStyleInheritance: true,

        created: function() { },

        enteredView: function() { },

        leftView: function() { },

        attributeChanged: function(attrName, oldVal, newVal) { }

    });

    </script>

</polymer-element>

As we asked for the blog element to be imported using HTML imports (a way to include and reuse HTML documents in other HTML documents) to our index, we can also verify that it has been correctly added to the document <head>:

<!doctype html>
    <head>

        <meta charset="utf-8">

        <meta http-equiv="X-UA-Compatible" content="IE=edge">

        <title></title>

        <meta name="description" content="">

        <meta name="viewport" content="width=device-width">

        <link rel="stylesheet" href="styles/main.css">

        <!-- build:js scripts/vendor/modernizr.js -->

        <script src="bower_components/modernizr/modernizr.js"></script>

        <!-- endbuild -->

        <!-- Place your HTML imports here -->

        <link rel="import" href="elements/blog.html">

    </head>

    <body>

        <div class="container">

            <div class="hero-unit" style="width:90%">

                <blog-element></blog-element>

            </div>

        </div>

        <script>
        document.addEventListener('WebComponentsReady', function() {
            // Perform some behaviour
        });
        </script>

        <!-- build:js scripts/vendor.js -->

        <script src="bower_components/polymer/polymer.min.js"></script>

        <!-- endbuild -->

</body>

</html>

Fantastic.

Adding dependencies using Bower #

Next, let’s edit our element to use the Polymer JSONP utility element to read in posts.json. You can either get the adapter by git cloning the repository or installing polymer-elements via Bower by running bower install polymer-elements.

Once you have the utility, you’ll need to include it as an import in your blog.html element with:

<link rel="import" href="../bower_components/polymer-jsonp/polymer-jsonp.html">

Next, include the tag for it and supply the url to our blog posts spreadsheet from earlier, adding &callback= to the end:

<polymer-jsonp auto url="https://spreadsheets.google.com/feeds/list/your-key-value/od6/public/values?alt=json-in-script&callback=" response="[[posts]]"></polymer-jsonp>

With this in place, we can now add templates to iterate over our spreadsheet once it has been read in. The first outputs a table of contents, with a linked title for a post pointing at the slug for it.

<!-- Table of contents -->

<ul>

    <template repeat="[[post in posts.feed.entry]]">

    <li><a href="#[[post.gsx$slug.$t]]">[[post.gsx$title.$t]]</a></li>

    </template>

</ul>

The second renders one instance of post-element for each entry found, passing the post content through to it accordingly. Notice that we’re passing through a post attribute representing the post content for a single spreadsheet row and a selected attribute which we will populate with a route.

<!-- Post content -->

<template repeat="[[post in posts.feed.entry]]">

    <post-element post="[[post]]" selected="[[route]]"></post-element>

</template>

The repeat attribute you see being used in our template creates and maintains an instance with [[ bindings ]] for every element in the array collection of our posts, when it is provided.

Now in order for us to get the current [[route]] populated, we’re going to cheat and use a library called Flatiron director which binds to [[route]] whenever the URL hash changes.

Thankfully there’s a Polymer element (part of the more-elements package) that we can grab for it. Once copied to the /elements directory, we can reference it with <flatiron-director route="[[route]]" autoHash></flatiron-director>, specifying route as the property we wish to bind to and tell it to automatically read the value of any hash changes (autoHash).

Putting everything together we now get:

    <link rel="import" href="post.html">

    <link rel="import" href="polymer-jsonp/polymer-jsonp.html">

    <link rel="import" href="flatiron-director/flatiron-director.html">

    <polymer-element name="blog-element"  attributes="">

      <template>

        <style>
          @host { :scope {display: block;} }
        </style>

        <div class="row">

          <h1><a href="/#">My Polymer Blog</a></h1>

          <flatiron-director route="[[route]]" autoHash></flatiron-director>

          <h2>Posts</h2>

          <!-- Table of contents -->

          <ul>

            <template repeat="[[post in posts.feed.entry]]">

              <li><a href="#[[post.gsx$slug.$t]]">[[post.gsx$title.$t]]</a></li>

            </template>

          </ul>

          <!-- Post content -->

          <template repeat="[[post in posts.feed.entry]]">

            <post-element post="[[post]]" selected="[[route]]"></post-element>

          </template>

        </div>

        <polymer-jsonp auto url="https://spreadsheets.google.com/feeds/list/0AhcraNy3sgspdHVQUGd2M2Q0MEZnRms3c3dDQWQ3V1E/od6/public/values?alt=json-in-script&callback=" response="[[posts]]"></polymer-jsonp>

      </template>

      <script>

        Polymer('blog-element', {

          created: function() {},

          enteredView: function() { },

          leftView: function() { },

          attributeChanged: function(attrName, oldVal, newVal) { }

        });

      </script>

    </polymer-element>

Woo! We now have a simple blog that's reading data from JSON and using two Polymer elements scaffolded with Yeoman.

Working with 3rd party elements #

The element ecosystem around Web Components has been growing lately with component gallery sites like customelements.io beginning to appear. Looking through the elements created by the community, I found one for fetching gravatar profiles and we can actually grab and add it to our blog site too.

Copy the gravatar element sources to your /elements directory, include it via HTML imports in post.html and then add to your template, passing in the email field from our spreadsheet as the source of the username. Boom!

<link rel="import" href="gravatar-element/src/gravatar.html">

<polymer-element name="post-element" attributes="post selected">

    <template>

    <style>
        @host { :scope {display: block;} }
    </style>

        <div class="col-lg-4">

            <template if="[[post.gsx$slug.$t === selected]]">

            <h2><a href="#[[post.gsx$slug.$t]]">[[post.gsx$title.$t]]</a></h2>

            <p>By [[post.gsx$author.$t]]</p>

            <gravatar-element username="[[post.gsx$email.$t]]" size="100"></gravatar-element>

            <p>[[post.gsx$content.$t]]</p>

            <p>[[post.gsx$date.$t]]</p>

            <small>Keywords: [[post.gsx$keywords.$t]]</small>

            </template>

        </div>

    </template>

    <script>

    Polymer('post-element', {

        created: function() { },

        enteredView: function() { },

        leftView: function() { },

        attributeChanged: function(attrName, oldVal, newVal) { }

    });

    </script>

</polymer-element>

Let’s take a look at what this gives us:

Beautiful!

In a relatively short time, we've created a simple application composed of several web components without having to worry about writing boilerplate code, manually downloading dependencies or setting up a local server or build workflow.

Optimizing your application #

The Yeoman workflow includes another open-source project called Grunt - a task runner that can run a number of build-specific tasks (defined in a Gruntfile) to produce an optimized version of your application. Running grunt on its own will execute a default task the generator has setup for linting, testing and building:

grunt.registerTask('default', [

    'jshint',

    'test',

    'build'

]);

The jshint task above will check with your .jshintrc file to learn your preferences, then run it against all of the JavaScript files in your project. To get the full run down of your options with JSHint, check the docs.

The test task looks a little like this, and can create and serve your app for the test framework we recommend out of the box, Mocha. It will also execute your tests for you:

grunt.registerTask('test', [

    'clean:server',

    'createDefaultTemplate',

    'jst',

    'compass',

    'connect:test',

    'mocha'

]);

As our app in this case is fairly simplistic, we'll leave writing tests up to you as a separate exercise. There are a few other things we'll need to have our build process handle, so let's take a look at what the grunt build task defined in our Gruntfile.js will do:

grunt.registerTask('build', [

    'clean:dist',    // Clears out your .tmp/ and dist/ folders

    'compass:dist',  // Compiles your Sassiness

    'useminPrepare', // Looks for <!-- special blocks --> in your HTML

    'imagemin',      // Optimizes your images!

    'htmlmin',       // Minifies your HTML files

    'concat',        // Task used to concatenate your JS and CSS

    'cssmin',        // Minifies your CSS files

    'uglify',        // Task used to minify your JS

    'copy',          // Copies files from .tmp/ and app/ into dist/

    'usemin'         // Updates the references in your HTML with the new files

]);

Run grunt build and a production ready version of your app should be built, ready for you to ship. Let’s try it out.

Success!

If you get stuck, a pre-built version of polymer-blog is available for you to check out https://github.com/addyosmani/polymer-blog.

What more do we have in store? #

Web Components are still in a state of evolution and as such so is the tooling around them.

We’re currently looking at how one might go about concatenating their HTML imports for improved loading performance via projects like Vulcanize (a tool by the Polymer project) and how the ecosystem for components might work with a package manager like Bower.

We’ll let you know as and when we have better answers to these questions, but there are lots of exciting times ahead.

Installing Polymer standalone with Bower #

If you would prefer a lighter start to Polymer, you can install it standalone directly from Bower by running:

bower install polymer

which will add it to your bower_components directory. You can then reference it in your application index manually and rock the future.

What do you think? #

Now you know how to scaffold out a Polymer app using Web Components with Yeoman. If you have feedback on the generator, please do let us know in the comments or file a bug or post to the Yeoman issue tracker. We would love to know if there is anything else you would like to see the generator do better as it's only through your use and feedback that we can improve :)

Addy Osmani on web.dev

Building a Better Web - Part 1: A faster YouTube on web

Building a faster web #

Improving Core Web Vitals #

Modularization with lazy loading #

State-management across components #

Conclusion #

What's new in PageSpeed Insights

What's new? #

Clear separation of field and lab data #

Core Web Vitals assessment #

Labels for mobile and desktop performance #

Origin Summary #

Additional helpful information #

Expand view #

Page image #

Updates to web.dev/measure #

PSI today #

Challenges with the current PSI design #

Learn more #

Optimizing resource loading with the Fetch Priority API

Summary #

Resource priority #

When would you need Fetch Priority? #

The fetchpriority attribute #

Browser priority and fetchpriority #

Use cases #

Increase the priority of the LCP image #

Lower the priority of above-the-fold images #

Lower the priority of preloaded resources #

Reprioritize scripts #

Lower the priority for non-critical data fetches #

Fetch Priority implementation notes #

Using Preload after Chrome 95 #

History #

Browser compatibility #

Conclusion #

Best practices for using third-party embeds

What is an embed #

Performance impact of third-party embeds #

Loading best practices #

Script ordering #

Lazy-loading #

Native lazy-loading for <iframe> #

lazysizes library #

Using data-lazy in Facebook #

Lazy-loading Instagram feeds #

Replace embeds with facades #

Use static images as facades #

Use dynamic images as facades #

Use click-to-load to enhance facades #

Remove or replace embeds with links #

Layout stability #

Layout Shift Terminator #

Conclusion #

Core Web Vitals workflows with Google tools

Core Web Vitals are best measured in the field #

Collect your own field data if possible #

Understanding Google's tools #

Chrome User Experience Report (CrUX) #

When to use CrUX #

When not to use CrUX #

PageSpeed Insights (PSI) #

When to use PSI #

When not to use PSI #

Search Console #

When to use Search Console #

When not to use Search Console #

Lighthouse #

When to use Lighthouse #

When not to use Lighthouse #

Web Vitals extension #

When to use the Web Vitals extension #

When not to use the Web Vitals extension #

The Performance panel in Chrome DevTools #

When to use the Performance panel #

When not to use the Performance panel #

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

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

Analyze site performance with PageSpeed Insights #

The `fetchpriority` attribute #

Browser priority and `fetchpriority` #

Native lazy-loading for `<iframe>` #

Configure `webpack-route-manifest` #

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