Elizabeth Sweeny 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

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

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

Speed tooling evolutions: highlights from Chrome Developer Summit 2019

2019-12-16T00:00:00Z

At Chrome Developer Summit, Paul Irish and I announced updates to Lighthouse—Lighthouse CI, new performance score formula, and more. Along with big Lighthouse news, we presented exciting performance tooling developments including new performance metrics, updates to PageSpeed Insights and Chrome User Experience Report (CrUX), and insights from the Web Almanac's analysis of the web ecosystem.

New performance metrics #

Measuring the nuances of a user's experience is the key to quantifying the impact it has on your bottom line and tracking improvements and regressions. Over time, new metrics have evolved to capture those nuances and fill in the gaps in measuring user experience. The newest addition to the metrics story are two field metrics—Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS)—which are being incubated in W3C Web Performance Working Group, and a new lab metric—Total Blocking Time (TBT).

Largest Contentful Paint (LCP) #

Largest Contentful Paint (LCP) reports the time when the largest content element becomes visible in the viewport.

Before Largest Contentful Paint, First Meaningful Paint (FMP) and Speed Index (SI) served to capture the loading experience after the initial paint, but these metrics are complex and often do not identify when the main content of the page has loaded. Research has shown that simply looking at when the largest element on the page is rendered better represents when the main content of a page is loaded.

The new Largest Contentful Paint metric will soon be available in Lighthouse reports and in the meantime you can measure LCP in JavaScript.

Total Blocking Time (TBT) #

Total Blocking Time (TBT) metric 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.

A task is considered long if it runs on the main thread for more than 50 milliseconds. Any millisecond over that is counted towards that task's blocking time.

The Total Blocking Time for a page is the sum of the blocking times of all long tasks that occured between FCP and TTI.

While Time to Interactive does a good job of identifying when the main thread calms down later in load, Total Blocking Time aims to quantify how strained the main thread is throughout load. This way, TTI and TBT complement each other and provide balance.

Cumulative Layout Shift (CLS) #

Cumulative Layout Shift (CLS) measures visual stability of a page and quantifies how often users experience unexpected layout shifts. Unexpected movement of content can be very frustrating and this new metric helps you address that problem by measuring how often it's occurring for your users.

A screencast illustrating how layout instability can negatively affect users.

Check out the detailed guide to Cumulative Layout Shift to learn how it's calculated and how to measure it.

The new Lighthouse performance score formula will soon de-emphasize FMP and FCI and include the three new metrics—LCP, TBT, and CLS—as they better capture when a page feels usable.

Check out Lighthouse performance scoring and the new web.dev metrics collection to learn more.

Field data (CrUX) thresholds adjusted in PageSpeed Insights #

Over the past year we have been analyzing web performance from the field via Chrome User Experience (CrUX) data. With insights from that data we reassessed the thresholds that we use to label a website "slow", "moderate", or "fast" in field performance.

In order to get an overall assessment for a site, PageSpeed Insights (PSI) uses a certain percentile of the total distribution of field data as the golden number for that site; the previous thresholds used were 90th percentile for First Contentful Paint and 95th percentile for First Input Delay (FID).

For example, if a site has an FCP distribution of 50% fast, 30% moderate, 20% slow, the 90th percentile FCP is in the slow section, making the overall field score for the site slow.

This has been adjusted to have a better overall distribution across websites and the new breakdown is:

Metric	Overall Percentile	Fast (ms)	Moderate (ms)	Slow (ms)
FCP	75th percentile	1000	1000-3000	3000+
FID	95th percentile	100	100-300	300+

For example, now if a site has an FCP distribution of 50% fast, 30% moderate, 20% slow, the 75th percentile FCP is in the moderate section, making the overall field score for the site moderate.

Canonical URL redirects in PageSpeed Insights #

To enable you to measure the user's experience as accurately as possible, the PageSpeed Insights team has added a reanalyze prompt to PSI. For sites that are redirected to a new URL, you're prompted to rerun the report on the landing URL for a more complete picture of your actual performance.

CrUX in the new Search Console Speed report #

Search Console rolled out their new Speed report a week before Chrome Dev Summit. It uses data from the Chrome User Experience Report to help site owners discover potential user experience problems. The Speed report automatically assigns groups of similar URLs into "Fast", "Moderate," and "Slow" buckets, and helps prioritize performance improvements for specific issues.

Web Almanac #

In the opening keynote we announced the launch of the Web Almanac, an annual project that matches the stats and trends about the state of the web with the expertise of the web community. 85 contributors, made up of Chrome developers and the web community, have volunteered to work on the project, which analyzes 20 core aspects about the web addressing how sites are built, delivered, and experienced. Start exploring the Web Almanac to learn more about the state of performance, JavaScript, and third-party code on the web.

Learn more #

For more details about performance tooling updates from Chrome Developer Summit, watch the Speed tooling evolutions talk:

Lighthouse evolution: continuous integration, new performance score formula, and more

2019-12-16T00:00:00Z

In the Speed Tooling Evolutions talk at Chrome Developer Summit (CDS), Paul Irish and I presented the newest products and features coming from Google that can help you build and maintain an exceptionally fast experience for all your users. At the center of that story are additions to the Lighthouse family of performance monitoring tools.

Lighthouse CI alpha release #

The Lighthouse team has launched the alpha version of Lighthouse CI the new continuous integration product that enables you to run Lighthouse on every commit before pushing to production. Lighthouse CI runs Lighthouse multiple times, asserts static audit or metric thresholds, and then uploads Lighthouse reports to a server for visual diffing and basic category score history. Existing budgets.json configurations work seamlessly alongside the new expressive syntax for asserting any Lighthouse audit or category result.

Lighthouse CI supports Travis CI, Circle CI, and GitHub Actions out-of-the-box and any Ubuntu or container-based CI service with some configuration. You can install the Lighthouse CI server on-premise or use a docker image for instant setup. Free, public, temporary Lighthouse report storage is available as an alternative to get started right away.

Coming soon: Performance score updates #

Changes are coming to the Lighthouse Performance score version 6! In version 5 (as of November 2019), Lighthouse has five metrics that are weighted and blended to form the 0-100 Performance score: First Contentful Paint, Speed Index, First Meaningful Paint, Time to Interactive, and First CPU Idle.

See Lighthouse performance scoring for detailed information.

In Lighthouse version 6, new metrics, Largest Contentful Paint (LCP) and Total Blocking Time (TBT), are replacing First CPU Idle (FCI) and First Meaningful Paint (FMP). The weights of each of the five metrics will be adjusted to better balance different phases of load and interactivity measures.

The Lighthouse team is still working to ensure that all scoring curves are fine-tuned, and the metrics are mature and thoroughly tested. They aim to ship the Lighthouse v6 Performance score in January 2020.

Performance engineers sometimes find speed tools results difficult to reproduce due to two discrete challenges--variability and cross-environment inconsistency. Variability is the issue of seeing numbers change even when the testing environment remains the same. Cross-environment inconsistency is the issue of getting different results when running tests on the same page, but in differing environments (for example, DevTools and PageSpeed Insights). While the Lighthouse team is working on ways to mitigate variability, it's helpful to understand sources of variability and how you can deal with it. The Lighthouse team is also investigating calibration methods to reduce differences between environments, but it's fair to expect that different conditions and hardware lead to different measurements—at least for now.

Lighthouse Stack Packs #

Lighthouse can automatically detect if sites use a framework or a content management system (CMS) and include stack-specific advice in the report. Stack Packs add customized recommendations, curated by community experts (like you!), on top of Lighthouse report core audits.

At the moment, there are Stack Packs for Angular, WordPress, Magento, React, and AMP. To create your own Stack Pack, visit the GitHub repo or contact the Lighthouse team.

Coming soon: Lighthouse plugins as Chrome Extensions #

Lighthouse Plugins are another way you can take advantage of Lighthouse's extensibility. There are a lot of quality checks that Lighthouse core audits currently don't cover, either because they are only applicable to a subset of developers or because the team hasn't had the bandwidth to create the audits yet.

Lighthouse plugins allow community experts to implement a new set of checks that Lighthouse can run and add to the report as a new category. Right now, plugins only work in Lighthouse CLI, but the goal is to enable running them in the DevTools Audits panel too.

Community Plugins in DevTools Audits panel (beta)

When users install Lighthouse plugin extensions from the Chrome Web Store, DevTools will identify installed plugins and offer them as an option in the Audits panel. The Lighthouse team will be building the support for the plugin approach in the coming months, so stay tuned. In the meantime, you can create a plugin today as a node module and make it accessible to all Lighthouse users via the CLI!

Learn more #

For more details about Lighthouse and other performance tooling updates from CDS 2019, watch the Speed tooling evolutions talk:

Your feedback is invaluable in making Lighthouse better, so go on and try out Lighthouse CI, write a Stack Pack, or create a Lighthouse Plugin and let us know what you think.