Chrome UX Report (CrUX)

The field-data source the wiki kept citing but never paged. core-web-vitals, lighthouse's lab-vs-field caveat, and core-web-vitals-seo all turn on "CrUX field data is Google's real signal" — this is that dataset. CrUX is "a dataset that reflects how real-world Chrome users experience popular destinations on the web." URL-only ingest; source = official Chrome developer docs.

What it is — field, not lab

CrUX aggregates real-user (RUM) measurements from actual Chrome sessions worldwide, for the Core Web Vitals (core-web-vitals: LCP / INP / CLS) plus supporting metrics. This is the hard line under lighthouse: Lighthouse is lab data (one synthetic load on one machine); CrUX is field data (the distribution of what users actually got). A great lab score ≠ a good field score — and CrUX is the field side that Google Search uses.

Collection & eligibility

Re-read against the methodology docs 2026-08-12, which state the criteria far more concretely than this page did at ingest.

Collected from real browsers (no synthetic runs). A user contributes only if all three hold: usage-statistic reporting is enabled, browser history is synced, and no sync passphrase is set. Chrome "does not publish data about the proportions of users that meet these criteria" — so the size and shape of the sample behind every CrUX number is undisclosed.
Separate eligibility criteria for origins and pages. Publicly discoverable is mechanical: HTTP 200 after redirects, no X-Robots-Tag: noindex header, no <meta name="robots" content="noindex">. Sufficiently popular is not: "a minimum number of visitors" whose threshold is undisclosed. So CrUX covers popular pages, not the long tail (a sampling limit worth flagging vs. the web-almanac's crawl-based corpus).
Why the threshold is secret matters more than that it is (re-read 2026-09-02). The methodology gives the reason: "An exact number is not disclosed, but it has been chosen to ensure that we have enough samples to be confident in the statistical distributions for included pages." So the cut is statistical, not editorial. Google is not declining to report small sites; it cannot report them, because a percentile over too few sessions is noise. This wiki had been recording popular-page bias as a coverage choice. It is a property of the method, and it means no amount of effort by a low-traffic site gets it into CrUX — the remedy has to be first-party RUM, not patience.
A second exclusion, previously unrecorded. "Origins or pages having more than 20% of their total traffic excluded due to ineligible combinations of dimensions are excluded entirely from the dataset." A site can clear the popularity bar and still be dropped for the shape of its audience — too much traffic from device/country/connection combinations that are themselves ineligible. That is a second filter, independent of size, and nothing here can say how many origins it removes.
Platforms are enumerated: desktop Chrome on Windows, macOS, ChromeOS and Linux, or Chrome on Android. Nothing else.
Core Web Vitals are judged at the 75th percentile of the user distribution over a 28-day rolling window — "good" means most users, not the median, had a good experience. Neither figure appears on the pages cited here; both come from the wider Web Vitals methodology, and this page records them as the surrounding convention rather than as something the CrUX docs state.

Access surfaces

Public via the CrUX API, the CrUX History API, CrUX Vis, the BigQuery public dataset (monthly, queryable history), PageSpeed Insights, and third-party tools — the same RUM feed seen through different windows. Google Search consumes it for page-experience ranking. The History API and CrUX Vis were both missing from this page until the 2026-08-12 re-read; Search Console's Core Web Vitals report, which this page previously listed, is not named on the current overview.

Why it matters here

CrUX is the measurement substrate of the whole SEO/perf thesis: byte minimalism (page-weight/bundle-size) helps rankings only insofar as it moves CrUX Core Web Vitals (core-web-vitals-seo). It also sharpens the page-weight-vs-architecture tension — because CrUX measures delivered, executed experience, two pages of equal byte weight can post very different CrUX numbers depending on delivery (brotli) and main-thread cost (inp). Diagnose with lighthouse (lab), judge with CrUX (field).

How big is it? Google does not say

Checked 2026-09-02: no page in the CrUX documentation states how many origins the dataset covers. The BigQuery docs name an origin_summary table that "contains a list of all origins in the CrUX dataset; it is updated monthly" — so the number exists, is maintained, and is obtainable only by querying it yourself. The dataset used to judge page experience for Google Search does not publish its own size.

The coverage gap now has one measurement

The popular-page limit above was a stated caveat with no number attached to it. There is now one, from outside this wiki: ../static-site-wiki's Speedlify page records a weekly measurement of 1,145 sites built with Eleventy, of which only 118 have CrUX field data at all — roughly one in ten.

Read it for what it is. That corpus is self-selected (authors submitted their sites to a community showcase) and skewed small by construction, so 10% is not the web's coverage rate. What it does give is the first concrete instance of the gap's size in a population this wiki cares about: independently built, technically competent, low-traffic sites — the ones that would score well and cannot prove it. It is also the empirical form of the point above: those nine in ten are not badly optimized, they are unmeasurable by this instrument.

Caveat

Popular-page bias (eligibility threshold) + the 20% dimension rule + Chrome-only + opted-in users: CrUX is the best public field signal, not a census. Vendor-documented (Google), describing Google's own ranking input.

"Chrome-only" is narrower than it sounds. The docs name the exclusions: Chrome on iOS, Android apps using WebView, and other Chromium browsers, Microsoft Edge given as the example. So the field data behind a Google ranking signal omits every iPhone user of Google's own browser, every in-app browser view on Android, and the second-largest desktop Chromium browser. Combined with the undisclosed opt-in proportion above, the honest statement is that nobody outside Google can size the gap between CrUX and the population it stands in for — which is the strongest argument on this page for first-party RUM. The popular-page gap is exactly what first-party RUM fills: the web-vitals JS library instruments your own pages (long tail included) with numbers that match how Chrome reports to CrUX — CrUX is the aggregate window, web-vitals is the first-party feed.

core-web-vitals · inp · lighthouse · core-web-vitals-seo · web-almanac · web-vitals · static-site-wiki/speedlify · synthesis