CrUX vs Core Web Vitals: Metrics, Data Sources and When to Use Which

Two Terms That Get Mixed Up

In performance reviews I regularly hear sentences like "our Core Web Vitals are fine, Lighthouse gives us 95" or "CrUX says we're failing, but our dashboards look good". Both are signs of the same confusion. Core Web Vitals and CrUX answer different questions, and the tools built on them measure different things.

The short version:

• Core Web Vitals (CWV) are metrics: a small set of user-centric measurements Google defines, with thresholds for "good".
• CrUX (Chrome User Experience Report) is a dataset: real-world measurements of those metrics (and others), collected from opted-in Chrome users and published by Google.

One is the ruler; the other is a particular set of measurements taken with it.

Core Web Vitals: The Metrics

Since March 2024 the three Core Web Vitals are:

INP replaced First Input Delay (FID) in March 2024. It's a much stricter measure: FID only looked at the delay before the first interaction was handled, while INP considers the latency of interactions across the whole visit.

A page "passes" when the 75th percentile of real visits meets the "good" threshold for all three. That percentile matters: you're judged on your slower users, not the average one.

Supporting metrics such as TTFB (Time to First Byte) and FCP (First Contentful Paint) aren't Core Web Vitals, but they're essential for diagnosing why LCP is slow.

CrUX: The Dataset

CrUX collects performance data from Chrome users who have opted in to usage statistics and have sync enabled. Key characteristics:

• Real users, real devices, real networks. This is field data, not a simulation.
• Chrome only, on desktop and Android. Safari, Firefox and Chrome on iOS users aren't included. If a large share of your customers are on iPhones, CrUX doesn't see them.
• Aggregated over a rolling 28-day window. A fix you ship today takes weeks to show fully.
• Origin and URL level, only where there's enough traffic. Low-traffic pages often have no URL-level data and fall back to origin-level figures.
• Public. Anyone can look up your origin, which is useful for benchmarking competitors (and means they can see yours).

You reach CrUX through several surfaces:

The important point: CrUX is what Google uses for the page experience signals in Search. When SEO colleagues say "we're failing Core Web Vitals", they almost always mean CrUX, as shown in Search Console.

Where Lab Data and RUM Fit

CrUX isn't the only way to measure Core Web Vitals. There are three families of data, and a mature team uses all of them:

Lab data (Lighthouse, WebPageTest)

A synthetic test on a controlled device and network profile. Reproducible and immediate, so ideal for CI and for debugging a specific change. But it doesn't reflect your real users, and it can't measure INP properly because there's no real user interacting. Lighthouse uses Total Blocking Time (TBT) as a lab proxy for responsiveness.

A Lighthouse score of 95 tells you the page can be fast under test conditions. It says nothing about the customer on an ageing Android phone on a train.

CrUX (Google's field data)

Real users, but only Chrome, aggregated, delayed by up to 28 days and with no ability to slice by your own dimensions (logged-in vs anonymous, A/B variant, release version).

Your own RUM (Real User Monitoring)

Collect the metrics yourself from every visit using Google's open-source web-vitals library, and send them to your analytics or observability tool:

import { onCLS, onINP, onLCP, type Metric } from "web-vitals";
 
function send(metric: Metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,        // "good" | "needs-improvement" | "poor"
    id: metric.id,
    page: location.pathname,
    // attach your own dimensions here: release, experiment variant, device class
  });
  navigator.sendBeacon?.("/rum", body) || fetch("/rum", { body, method: "POST", keepalive: true });
}
 
onCLS(send);
onINP(send);
onLCP(send);

The library's attribution build goes further, telling you which element was the LCP element or which interaction caused a slow INP. That's the difference between "INP is poor" and "the filter dropdown on the product listing page is blocking the main thread for 400ms".

Commercial RUM tools (Datadog, New Relic, SpeedCurve, Sentry and others) do the same with dashboards included. Note that browser support for some metrics outside Chromium is still limited, so check what your tool actually collects from Safari users.

Which to Use When

Why the Numbers Disagree

Expect your RUM, CrUX and Lighthouse to show different values. Common reasons:

• Population: CrUX is Chrome-only and opted-in users; your RUM sees everyone you instrument.
• Time window: CrUX is a 28-day rolling aggregate; your dashboard may show yesterday.
• Percentile: make sure you're comparing p75 with p75, not with an average or median.
• Page mix: CrUX weights pages by real traffic; you may be testing your homepage while most traffic lands on product pages.
• Lab conditions: Lighthouse throttles CPU and network to a fixed profile that may be harsher or gentler than your users' reality.

None of these is "wrong". They're different lenses. Decide which one you report to the business (for SEO, that's CrUX) and which you use to diagnose (lab and RUM).

A Practical Setup by Stage

Startup: Check PageSpeed Insights and Search Console monthly. Add Lighthouse CI to the pipeline for your key templates with a simple performance budget. That's enough.

Scaleup: Add RUM with the web-vitals library into your existing analytics or observability tool, segmented by page template and release. Put a CrUX-based p75 trend on the engineering dashboard next to your RUM figures, so everyone learns why they differ.

Enterprise: A dedicated RUM product with attribution, performance budgets per team and page type, alerting on regressions after releases, and CrUX BigQuery analysis for competitive benchmarking.

In my earlier post on using Core Web Vitals as a replatforming success metric, the before-and-after numbers came from a mix of these sources. In hindsight, the most useful discipline was agreeing up front which source was the headline number and which were diagnostic.

The Takeaway

Core Web Vitals are the metrics; CrUX is Google's real-user dataset of them, and it's what Search uses. Use CrUX to report where you stand, lab tools to catch regressions before they ship, and your own RUM to understand real users by release, experiment and device, including the iPhone users CrUX can't see.