The Chrome UX Report (CrUX) explained

What CrUX is

CrUX is a dataset that reflects how real-world Chrome users experience popular destinations on the web. It is the official dataset of Google's Web Vitals program, so every Core Web Vital has a place in it. Chrome collects the measurements from real browsers around the world, Google combines them into distributions, and a set of free tools shows them.

Google Search uses the data to inform the page experience ranking factor, according to the Chrome documentation. How much that matters for your rankings is a separate question, which page speed and Google rankings answers carefully.

The dataset is the reason a lab test cannot settle whether you pass the Core Web Vitals. CrUX holds what happened to visitors. A lab test, as lab data and field data explains, holds what one simulated visit would experience.

Whose visits are counted

A visit is included only when the person and the browser meet every one of these conditions:

1. They use Chrome on a supported platform: Chrome on desktop (Windows, macOS, ChromeOS and Linux) or Chrome on Android, including native apps that use Custom Tabs and installed web apps (WebAPKs).
2. They have turned on usage statistic reporting.
3. They sync their browser history.
4. They have not set a Sync passphrase.

Some browsers never contribute: Chrome on iOS, native Android apps that use a WebView, and other Chromium browsers such as Microsoft Edge. Safari and Firefox are not Chromium, so they are not in the data either. Chrome does not publish what share of its users meet the conditions.

This has a practical meaning. CrUX is a large sample of your Chrome visitors, not all your visitors. If many of your customers use iPhones, their experience is invisible to CrUX. The numbers describe a real group, and the group may differ from your whole audience.

Which pages and sites are included

Both a whole site (an origin, such as https://www.example.com) and a single page must pass two tests. Pages and origins are added and removed automatically as they qualify. There is no way to submit one.

They must be publicly discoverable. CrUX uses the same indexability rules as search engines. A page is left out if any of these is true:

• It answers with a status code other than 200 after redirects.
• It is served with an X-Robots-Tag: noindex header or an equivalent.
• It has a <meta name="robots" content="noindex"> tag or an equivalent.

They must be popular enough. Chrome does not publish the number, but it is chosen so that the distributions are statistically sound. It is the same for pages and origins.

Some details change how the numbers add up:

• If an origin qualifies, the visits on all of its pages count towards the origin's data, even for pages that cannot be indexed on their own. A page that does not qualify still contributes to the origin.
• Query strings such as ?utm_medium=email and fragments such as #main are removed from addresses, so all visits to one page are grouped. The Chrome documentation warns that this can merge two different pages that differ only by a parameter, such as ?productID=101 and ?productID=102.
• A page is measured as the visitor sees it, at the top level. An iframe is not reported on its own, but its layout shifts count towards the page that contains it.
• A single-page app that changes views with JavaScript is measured as one page view, attributed to the first page. This is a limit of the browser interfaces CrUX is built on.

Why a page shows "no data"

Work through these:

1. Too few visits. The most common cause on small sites and on deep pages. Look at your whole site instead of one page.
2. The page cannot be indexed. Check the status code after redirects, the X-Robots-Tag header and any noindex tag. Lighthouse's SEO checks "Page is blocked from indexing" and "Page has unsuccessful HTTP status code" test the same things.
3. The audience is not in the sample. A site visited mostly from iOS may have few qualifying visits.
4. The page is new. There must be enough qualifying visits in the 28-day window.
5. Visits are spread thin. If every visitor gets a different address, for example an identifier in the path, no single address may have enough visits.

What is measured

The three Core Web Vitals are in the dataset: Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. So are First Contentful Paint and Time to First Byte. Most values are kept as histograms, which show the share of visits in each range, instead of as raw numbers. That is how the report can say that a certain share of visits had a good, a needs-improvement or a poor experience.

The marks use the 75th percentile: for each metric, three out of four visits were at least as good as the number shown. The CrUX API returns percentiles worked out from the full data. Google notes that they are synthetic values: they do not mean that a particular person had exactly that experience, only that a stated share had less.

Time to First Byte is collected only on full page loads. Other metrics are also collected on back and forward navigations, so the TTFB sample can be smaller and should not be compared directly with the others.

Each record can be split by:

• Form factor: phone, tablet or desktop, worked out from the browser's user agent.
• Effective connection type: a label for the estimated connection quality, such as 4g, 3g or slow-2g. Most visits are classed as 4g.
• Country: available in the BigQuery data, not in most other tools.

Where to see the data

Each tool reads the same dataset but updates at its own pace and with its own limits.

• PageSpeed Insights puts the data above the lab test and splits it by phone and desktop. It is the easiest way in. See PageSpeed Insights explained.
• Search Console groups pages that provide similar experiences and shows the Core Web Vitals for each group, with a sample of up to 20 pages per group. It is the best view of which part of a site has the problem.
• The CrUX API is free. It needs a Google Cloud key and allows 150 queries per minute for each project. It answers faster than PageSpeed Insights because it carries no lab test. The data is about two days behind today's date, because Google waits for complete days.
• The History API returns up to 25 weekly 28-day periods, so you can draw a trend line.
• The Dashboard and BigQuery use monthly data, released on the second Tuesday after each collection month. BigQuery holds origin-level records for every origin in the dataset back to 2017 and is the tool for comparing sites or countries. It has no page-level data, and percentiles come from coarse histograms, so they are approximate.

Because the windows differ, two tools can show different numbers for the same site on the same day. A rolling 28-day window and a calendar month are not the same period.

How to read the numbers

• Read the 75th percentile against the marks. A metric is good when its 75th percentile is within the "good" range. The three marks are on the Core Web Vitals page.
• Read phone and desktop separately. A site often passes on desktop and fails on phone.
• Expect a delay. The window is 28 days, so a fix reaches the number gradually. With steady traffic, visits after the fix are about a quarter of the window after a week, half after two weeks and all of it after four.
• Use the distribution, not only the percentile. The share of visits in the "poor" range tells you how many people had a bad experience, even when the 75th percentile looks fine.
• Compare like with like. The same device class, the same page or origin, the same period.
• Treat origin data and page data as different questions. The origin number is the average story of the whole site, and a fast home page can hide slow product pages.

What CrUX does not tell you

CrUX covers Chrome only, adds no detail by campaign, template or visitor type, shows nothing at the level of a single visit, and will not tell you why a number is bad. For that you need lab tools to find the cause, and sometimes your own real-user monitoring. Your own monitoring can include browsers CrUX leaves out, and it can split the data by any label you choose. The same browser interfaces that feed CrUX are available to your own scripts.

The data is also filtered and slightly randomized. Chrome adds a small amount of randomness so that sensitive totals, such as traffic volume, cannot be worked out from it. This does not change the accuracy of the aggregate statistics.

Check your own page

Run the free audit. If the report shows real-visitor data for your page, compare its 75th percentile with the marks and note the phone and desktop results separately. If it shows only site-level data or none, your page is below the visit threshold or cannot be indexed. Use the checklist above, and rely on the lab results and on Search Console groups in the meantime.

Sources

• CrUX methodology on Chrome for Developers: eligibility for users, origins and pages, the tools, metrics and dimensions, and data quality.
• About CrUX on Chrome for Developers.
• CrUX API and CrUX History API: keys, limits, percentiles and the delay.
• CrUX on BigQuery: monthly releases and what the dataset holds.