Google’s New Webmaster Tool: Speed Report

The Speed Report is a new tool introduced to the GSC to aid SEOs and Webmasters in identifying key URLs slowing down their domains. CrUX has been leveraged to include real user experience into the “Speed Ranking” for each page.

FCP and FID have become the most important metrics in Load Time.

The “Speed Report” Overview

In November 2019, Google introduced a new “experimental” tool into the GSC which allows SEOs and Webmasters to interact with the “Page Speed” for both Mobile and Desktop users. The Speed Tool is an aggregated data measurement of how users really experience the load times of specific URLs, and even the site as a whole. The Tool scores pages based on BigQuery and PageSpeed Insights, which are weighted according to CrUX; and then a further measurement is taken through FCP and FID which is mixed with CrUX. In the end, a “Page Score” is determined: Fast – Moderate – Slow.

Prior to Nov 2019, Lighthouse was an isolate metric used by Google to determine web load time of a site. Since the introduction of CrUX and BigQuery, Google has begun aggregating site data into more realistic models which can more accurately predict a “speed score.” This will begin to overrule cheating the Lighthouse system through splash screens, and quick population techniques.

The speed report, in the words of Google: shows how fast your pages perform according to real world usage data (sometimes called field data). The data comes in two forms, the “Desktop” load times, and the “Mobile” load times. Since the 2017/18 migration to Mobile First Indexing (MFI), the emphasis on Mobile load time has become critical for all sites.

Improving your load time: Technical SEO.

Google believes that speed matters for 2 key reasons, which comes directly from their Support Forum:

  1. Longer page load times have a severe impact on Bounce Rate
  2. Pages considered slow may be demoted in Google Search

Both bounce rate, and page speed have always been considered in the ranking algorithm for Google. An example on industry metrics, and why bounce rates are important:

If page load time increases from 1 second to 3 seconds, bounce rate increases by 32%. Similarly, If page load time increases from 1 second to 6 seconds bounce rate increases by 106%.

Google Support

The relationship between load time and bounce rate is exponential, with each second increasing 1^x times the probability of a user bouncing, and even potentially pogo-sticking.

Explaining the Details of Speed Report

The data that is used in the Speed Report is extracted from CrUX, which is the “Chrome User Experience Report.” CrUX extracts data through the use of PageSpeed Insights, the Google developer tool; and Google BigQuery, which aggregates user experience across Google web crawlers, and identifies particular dimensions of each site.

CrUX, as a result, is the key behind the calculation of the speed index given to each page in the Speed Report. By combining PageSpeed Insights, and Google BigQuery, Google gets an overview of every page through both a User’s perspective, and a web crawler’s experience. These are both combined into the “CrUX” score.

There are three speeds that each page is capable of receiving:

  1. Fast
  2. Moderate
  3. Slow

Each label is attached to a page and can be different across a Desktop and a Mobile experience. For example, the Home Page of SEOSPIDRE, can have a moderate Mobile speed, but a fast Desktop speed. These are completely isolated metrics of each other, and influence the page ranking across mobile searches and desktop searches independently.

A URL speed, is the “slowest speed assigned to it.” There are two metrics taken into account when calculating the “speed score,” fast, moderate, or slow. If a URL has a fast FCP, but a slow FID, the page is labelled “slow,” because the speed score is dependant on the lowest score. This means your website, and URL’s, need to perform well on both metrics. While it’s still possible to specialise in “Desktop” load time, and sacrifice a fast mobile load time, because the rankings are independent, it’s not possible to have a fast FCP and slow FID for the sake of ranking well. As a result of this update, both FCP and FID need to be high, in order for the page to rank well.

FCP: First Contentful Paint. The time from when the user requests the URL until the browser renders the first visible element in the URL. This is important because it tells the reader that the URL is actually loading. In the Speed Report, an Aggregated FCP (Agg FCP) is used, which is the time it takes for 75% of the visits to a URL in the group to reach the FCP state.







FID: First Input Delay. The time from when a user first interacts with your page (when they clicked a link, tapped on a button, and so on) to the time when the browser responds to that interaction. This measurement is taken from whatever interactive element that the user first clicks. This is important on pages where the user needs to do something, because this is when the page has become interactive. Similarly to the Agg FCP, an Aggregated FID (Agg FID) metric is used, which is the lowest common FID for 95% of the visits to a URL in the group.







Validating Fixes

Knowing that pages are slow is important. Utilise the Lighthouse Tool provided by Google to get specific advice on adjustments that can be made to improve your load speed. Alternatively, you can personally conduct Technical SEO, or get an Agency, to optimise the load time of your page for better rankings.

Once you believe you’ve made the necessary changes, you need to validate them within the GSC. Click Start Tracking in order to monitor instances of issue fixes. The monitoring session lasts for 28 days, at the end of which, if all issue validations are “Passed,” then Google removes the issues from the GSC, and rankings are likely to be improved. The tracking can be restarted at any time by clicking Restart Tracking.

Starting validation does not trigger re-indexing, or any other active behaviour from Google. Rather it restarts the CrUX monitoring period for your site.

Issue Validation Statuses

  1. Not Started – There are one or more URLs with an instance of this issue that have never been in a validation request
  2. Started – You have begun a validation attempt and no remaining instances of the issue have been found yet
  3. Looking Good – You started a validation attempt, and all issue instances that have been checked so far have been fixed
  4. Passed – All URLs are either in Passed or Other state. You must have clicked Validate fix to get to this state
    1. If instances disappeared without you requesting validation, state would change to N/A
  5. N/A – Google found that the issue was fixed on all URLs, even though you never started a validation attempt
  6. Failed – One or more URLs are in Failed state after a validation attempt

In terms of individual URL’s, there are other these are the specific Validation Statuses

  1. Pending – Google is awaiting enough data to determine whether or not this URL is still affected
  2. Fixed – The URL seems not to be affected by this issue any more
  3. Still Affected – The URL is still affected by the listed speed issue

Benchmarks, Averages, and Metrics

Google is putting significant emphasis on speed, which we’ve seen progressing more and more with the release of tools such as AMP, mobile first indexing, and even SERP fluctuations between dynamic/static content. Google have been pushing for better ECMAscript 6 indexing and JS understanding, in order to support the speed of JS sites.

All content is drawn from a studies commissioned by Google. Source.

Industry Benchmarks – Load Time.

  1. Global average mobile load time from 2017 – 2018 dropped by 7 seconds.
  2. Global average load time as of Feb 2018: 15 seconds
  3. 53% of mobile site visits leave if load time is >3 seconds
  4. Automative, retail, and technology sector sites have the slowest global average load times
  5. 70% of mobile sites took >5 seconds to load content above the fold, and >7 seconds to load visual content below the fold
  6. A 10 second load time on average, yields a 123% bounce rate

Based on the above data, the threshold between 3-5 seconds is critical. Ensuring your site stays under 3/4 seconds is the key in bringing down the bounce rate of your site.

National Averages

Average Speed Index

United States



United Kingdom

TTFB (Time to First Byte)

United States



United Kingdom

Page Weight (Bytes) – Delivery Payload

United States



United Kingdom

Important Conclusions

Drawing from the “Speed Report” tool that is newly introduced into the GSC, along with lots of new benchmarks, and metrics that are being presented by Google, it’s safe to say that Load Speed is becoming more important than ever.

These are the key takeaways from everything presented in the article, and from the information gathered from Google sources:

Bounce rate and Load Time are critical ranking factors – Google has published, commissioned, and marketed many case studies and opinions on the effect load time has on bounce rate, and has clearly stated that sites with high load time are less likely to rank well compared to their optimised counter parts.

CrUX is the key metric algorithmic factor that determines “Speed Score” – Chrome is becoming the leading browser, and is being heavily pushed into the market by Google. Ensuring that your site performs well on Chrome is thus a key aspect in determining the success of your site. Under the CrUX algorithm, a lot of the data extracted is aggregated, which means all user experiences should be high. Having a few extremely high load times, by countries with high latency, will result in skewing of the data, and highly modulated your aggregate rating.

FCP and FID are the fundamental load speed drivers, identified by Google – First Contentful Paint and First Input Delay are identified by Google specifically, and scored specifically, in order to generate an aggregate “speed” – which can very from high to moderate, to low. Between the metrics, it’s extremely important to have a high average, rather than an extremely high FCP and a low FID. Normally, these would result in, from a UX point of view, a reasonable load time. Google understands that both of these are critical in the population rate of a site, and URLs are scored based on their lowest of the two metrics.

Validating restarts the CrUX monitoring period, and takes 28 days to resolve – Quick load time resolution doesn’t exist. Once adjustments have been made on-site in order to improve load time, and you have personally validated them within the PageSpeed tools, it takes Google 28 days to confirm the changes. This is because CrUX leverages real user experience, and requires an undefined amount of data in order to have a high confidence interval. When making changes to your site, ensure you make as many changes as possible in a single motion and optimise the whole site, rather than do repetitions which would each require 28 days to resolve.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.