What is the Chrome UX Report (CrUX)?

What is the Chrome UX Report (CrUX)?

The Chrome UX Report (CrUX) is Google's public dataset of how real Chrome users experience the web. It collects Core Web Vitals and related metrics from opted-in Chrome users, and publishes them per origin and, where traffic allows, per URL. It is the field data behind PageSpeed Insights and the same real-user dataset Google uses for page experience.

Field data vs lab data

CrUX is field data: measurements from real devices and networks. Lab data, such as a Lighthouse run, is one simulated page load on a fixed device and network. Lab data is repeatable and good for debugging; field data shows what visitors actually get. The two can disagree because they measure different things, so neither one replaces the other.

What is in the dataset

• Users: only Chrome users who have usage statistic reporting on, sync their browser history and have no Sync passphrase. Desktop Chrome (Windows, macOS, ChromeOS, Linux) and Android Chrome count. Chrome on iOS, Android WebView and other Chromium browsers such as Edge do not.
• Pages: the origin or page must be publicly discoverable (HTTP 200 after redirects, no noindex) and popular enough. Google does not publish the visitor threshold. Query strings and fragments are stripped, so URL variants are merged.
• Metrics: LCP, INP, CLS, plus FCP, TTFB and round trip time.

What counts as good

Core Web Vitals are judged at the 75th percentile of page loads, split by mobile and desktop. The thresholds for "good" are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less. A page passes only when the slowest quarter of visits still meets them. TTFB is not a Core Web Vital; Google's rough guide for it is 0.8 seconds or less. INP replaced FID as a Core Web Vital in 2024.

How to get CrUX data

• PageSpeed Insights shows CrUX field data for a URL or origin, covering the previous 28-day collection period.
• The CrUX API answers one origin or URL per request, free up to 150 queries per minute per Google Cloud project. Data refreshes daily around 04:00 UTC and runs about two days behind.
• BigQuery holds the monthly dataset for custom analysis, released on the second Tuesday of the following month. It is free up to the BigQuery free-tier limits.
• The LoadFocus Core Web Vitals checker reads CrUX for any URL without signup.

A minimal API call for an origin, phones only:

curl -X POST 'https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"origin": "https://example.com", "formFactor": "PHONE", "metrics": ["largest_contentful_paint", "interaction_to_next_paint", "cumulative_layout_shift"]}'

The response gives histograms (good, needs improvement, poor) and a 75th percentile value for each metric you ask for.

Example: reading a result

Suppose the phone record for your origin shows an LCP p75 of 3.1 seconds. Your Lighthouse run in CI says 1.9 seconds. Both are right: the lab run used a fast simulated device, while a quarter or more of real phone visits take 3.1 seconds or longer. Start from the field number to decide what to fix, then use lab runs to confirm the fix works before it reaches users.

Common mistakes

• Expecting data for every page. Low-traffic URLs have no record. Fall back to the origin record or to your own measurements.
• Expecting a fix to show up tomorrow. The field window covers 28 days, so a fix is only fully visible about a month later.
• Treating it as all your users. It covers eligible Chrome users only, so Safari on iPhone is missing.
• Reading the origin number as one page. An origin record aggregates every page on the site.
• Still tracking FID. Audit and alert on INP.

CrUX, testing and monitoring

CrUX tells you what happened to real visitors, with a delay and without detail on which page load or session. It cannot alert you within minutes or reproduce a slow load. Pair it with scheduled lab checks (synthetic monitoring) and, if you need every browser and per-session detail, your own real user monitoring. The post Synthetic Monitoring vs Real User Monitoring compares the two, and how to monitor Core Web Vitals with alerts and reports covers the setup.

LoadFocus Page Speed Monitoring runs scheduled Lighthouse audits from 25 cloud regions and shows CrUX field data with a pass/fail badge next to them. To dig into one metric, see Largest Contentful Paint and Time to First Byte. API details are in the official CrUX API docs.

FAQ: Chrome UX Report

Is CrUX free?

Yes for PageSpeed Insights and the API, which is free up to 150 queries per minute per project. BigQuery is free up to the free-tier limits and billed beyond that.

Why is my site missing from CrUX?

The origin or URL may not have enough visitors, may not be publicly discoverable (login wall, noindex, non-200 response), or its visitors may not be eligible Chrome users. Google does not publish the exact traffic threshold.

How long until my fix shows in CrUX?

PageSpeed Insights reports the previous 28-day collection period, so the numbers move gradually and fully reflect a fix about four weeks later.

What is the difference between CrUX and Lighthouse?

CrUX is field data from real Chrome users. Lighthouse is lab data from one simulated load. Use CrUX to see the real experience and Lighthouse to debug and verify changes.

Can I look up a competitor in CrUX?

Yes, if the origin has enough public traffic. Origin-level data is available through PageSpeed Insights and the API for any eligible site.

What replaced FID?

Interaction to Next Paint (INP) became a stable Core Web Vital in 2024 and replaced First Input Delay.