The Chrome UX Report, usually shortened to CrUX, is a public dataset Google publishes showing how real visitors using Chrome experience websites: how quickly pages load, how fast they respond to taps and clicks, and how much the layout jumps around. It is the main source of the field data behind Core Web Vitals.
How the Chrome UX Report works
Chrome collects performance measurements from users who have opted in to share usage statistics, have browsing history sync turned on, and have not set a sync passphrase. Google aggregates those measurements, strips out anything that identifies individuals, and publishes them by website (the origin, such as https://www.example.co.uk) and, where there is enough traffic, by individual URL.
The figures cover a rolling 28-day window and are split by device type: phone, desktop and tablet. For each metric, CrUX reports the share of visits that were good, needed improvement or were poor, and Google judges a page on the 75th percentile, meaning three out of four visits must reach the “good” threshold for the page to pass. The metrics include the three Core Web Vitals (Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift) plus supporting ones such as Time to First Byte and First Contentful Paint.
A site or page only appears in CrUX once it has enough eligible traffic. Smaller sites often have origin-level data but nothing for individual URLs, and brand-new sites may have none at all.
You can reach the data in several ways. PageSpeed Insights shows it at the top of each report, Search Console’s Core Web Vitals report groups your URLs using it, and the CrUX API and a monthly BigQuery dataset give raw access. The BigQuery dataset includes country-level tables, so you can look at visits from the United Kingdom on their own.
Why it matters
CrUX is what Google uses to assess page experience in search, so it is the version of your site speed that counts. A test you run yourself shows how a page performs on one simulated device at one moment; CrUX shows what your actual visitors went through, on their actual phones and broadband connections.
That difference matters for UK businesses with a mixed audience. A site whose customers mostly browse on older Android phones on patchy mobile signal may score well in a lab test on a fast laptop and still fail in CrUX. The reverse also happens: a page that looks slow in a lab test can pass comfortably because most real visitors have warm caches and good connections.
It is also the honest way to judge a speed project. Because CrUX trails 28 days, it shows whether a fix improved things for real people, not just on one test run.
Common mistakes
- Confusing lab scores with CrUX. The 0 to 100 performance score in Lighthouse is lab data. It is useful for diagnosis but is not what Google assesses.
- Expecting results the next day. After a fix, the 28-day window needs time to fill with new visits before the figures move fully.
- Reading origin data as page data. When a URL lacks its own data, tools fall back to the whole site, which can hide one very slow template.
- Ignoring the phone figures. Mobile and desktop are reported separately, and mobile is usually the harder one to pass.
How to act on it
Open PageSpeed Insights for your homepage and two or three of your most important templates, such as a service page and a product page, and read the field data section at the top before anything else. Note which metric fails and on which device. Then check Search Console’s Core Web Vitals report to see how many URLs share the problem, since it usually belongs to a template rather than one page.
Use lab tools to find the cause, fix it, and come back to CrUX four weeks later to confirm the change reached real visitors. If you have no field data because traffic is low, measure your own visitors with a real-user monitoring script instead. Speed work of this kind is part of the technical SEO work I do for UK sites.