Spokes.wiki Search About
Dataset source ↗ source url updated Wed Aug 12 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

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).
  • 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).

Caveat

Popular-page bias (eligibility threshold) + 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 · synthesis