Leena Sohoni on web.dev

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.

Leena Sohoni on web.dev

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 #

The `fetchpriority` attribute #

Browser priority and `fetchpriority` #

Native lazy-loading for `<iframe>` #