What is this data?
Chrome collects speed measurements from real people as they browse, with their consent, and Google publishes them as the Chrome UX Report, or CrUX. It is the data behind the Core Web Vitals report in Google Search Console and the “real users” part of PageSpeed Insights. Google says it uses Core Web Vitals in its ranking systems.
This is different from a lab test. A lab test loads your page once on one machine. This data comes from every eligible visit over four weeks, on whatever phones and connections your visitors really have.
How this test works
We ask Google’s CrUX History API for your page or your site and draw what it returns. Nothing is measured by our server, and we don’t visit your page.
Each point on a chart covers 28 days, and Google adds a new point every week, so neighbouring points overlap. A change you make today shows up gradually over the next four weeks. The charts go back up to 40 weeks.
The figure shown for each metric is the 75th percentile: three out of four visits were this fast or faster. It is the figure Google uses to judge a page. Under each chart, a bar shows how the latest period’s visits divide into good, needs improvement and poor.
What is a good result?
Google sets two marks for each metric. The three Core Web Vitals are Largest Contentful Paint (good up to 2.5 seconds, poor above 4), Interaction to Next Paint (good up to 200 ms, poor above 500) and Cumulative Layout Shift (good up to 0.1, poor above 0.25). A page passes Google’s Core Web Vitals assessment when all three are good at the 75th percentile. First Contentful Paint (1.8 and 3 seconds) and Time to First Byte (0.8 and 1.8 seconds) are shown as supporting metrics.
The scores at the top are built on those marks, one for each of the five metrics Google sets marks for. A metric anywhere in Google’s “good” range scores 100, and one anywhere in the “poor” range scores 0. Between the two marks the score falls in a straight line, so the middle of the “needs improvement” range is 50, and a figure only just past the “good” mark still scores in the high nineties. The colour of each ring follows Google’s verdict, not the number: a metric that needs improvement is yellow even at 97. The marks are Google’s; turning them into a score from 0 to 100 is Seokla’s. The heading of the report goes by the three Core Web Vitals alone, as Google’s assessment does.
Round Trip Time is scored too, but on a different footing. Google has no good or poor mark for it. The Chrome UX Report sorts connections into three bands, low (under 75 ms), medium (75 to 275 ms) and high (over 275 ms), and the score is built on those the same way: 100 for low, 0 for high, and a straight line across the medium band, from 100 at 75 ms to 0 at 275 ms. Keep in mind that it describes your visitors’ connections more than your site.
The breakdowns
Below the charts, three bar charts show how visits divide. The first is what the largest element was, text or an image. The second and third show how visitors arrived (new loads, reloads, back and forward, the back/forward cache, prerendering) and which devices they used. Each bar is the share for the latest 28 days, with the share at the start of the period beside it. Google sets no good or poor marks for these, so they have no score. They help explain the metrics above them.
Ad metrics
For pages that show ads, Chrome also reports four experimental ad metrics, and we show the latest figure for each in a plain ring, in a block of their own below the charts. Ad Count is how many ads a visitor has in view at once, on average. Ad Density is the share of the screen that ads cover. Ad Weight: CPU is the processor time that ad frames use during a visit, and Ad Weight: Network is how much data is downloaded for ads. Each is the 75th percentile across visits.
Google sets no good or poor marks for these, so they have no score and no colour. Google marks them as experimental and may change them. They are published only for pages with ads on sites that list at least one authorized seller in their ads.txt file; for other pages the block is simply not shown.
What this test can’t tell you
Google publishes data only where there are enough visits. A new or quiet page often has none. In that case we show the figures for the whole site and say so. If the site has none either, there is nothing to show.
The data covers Chrome users who have usage statistics turned on. It doesn’t include Safari or Firefox, or Chrome on iPhones. It tells you that a metric is slow, not why. For the cause, use a lab test such as the TTFB Test or the Network Dependency Tree on this site, or Lighthouse.