Is CrUX really enough to measure your site's user experience?

What is CrUX and why does Google use it?

The Chrome User Experience Report collects performance metrics from the Chrome browser of real users. Unlike synthetic tests (Lighthouse, PageSpeed Insights in lab mode), this data reflects the experience your visitors actually have: poor 3G connection, old smartphone, active ad blocker.

Google uses this data to feed the user experience report in Search Console and to determine if your site meets the thresholds for Core Web Vitals. It is the only officially recognized dataset for evaluating speed-related ranking signals.

Why prioritize field data over synthetic data?

Synthetic tests run under perfect lab conditions: well-placed server, fast connection, controlled environment. The result? A PageSpeed score of 95 that means absolutely nothing if your actual visitors struggle with an LCP of 6 seconds on their mobile network.

CrUX field data incorporates real variability: geography, network quality, outdated devices, browser extensions. It shows what the 75th percentile of your Chrome users actually experience — the threshold that Google uses to determine if you pass the Core Web Vitals.

What happens if my site has no CrUX data?

Not enough Chrome traffic for 28 rolling days? You disappear from CrUX. Google will show nothing in Search Console, and you won’t know if you are compliant with Core Web Vitals. Officially, Google claims to evaluate page by page when possible, otherwise at the domain level, or… it’s a mystery.

This is where it gets tricky: [To be verified] we do not know exactly how Google ranks pages without CrUX data. Some observe that Google might rely on synthetic data or simply ignore the signal. But there is no clear official confirmation.

• CrUX = exclusive source for the user experience report and Core Web Vitals in Search Console.
• Only real Chrome data counts — not Firefox, Safari, or Edge (even if it runs on Chromium).
• 28-day rolling window: insufficient traffic = complete absence of public data.
• 75th percentile threshold: 75% of your visits must meet the thresholds to be rated “Good”.
• Page by page evaluation when possible, otherwise aggregation at the origin level (full domain).

Is this statement consistent with observed practices in the field?

Yes and no. On one hand, all SEOs who monitor their Core Web Vitals do indeed see their Search Console data coming from CrUX — no surprise there. But on the other hand, we regularly observe sites without public CrUX data that continue to rank without visible penalties.

Either Google applies differential treatment (internal CrUX data vs. public API), or the weight of the Core Web Vitals remains marginal compared to other signals. Both hypotheses coexist, and Google never clearly chooses sides. [To be verified]: the delta between public CrUX and Google's internal data remains opaque.

What nuances should be added to this statement?

First nuance: CrUX only covers Chrome. If 40% of your traffic comes from mobile Safari (e-commerce, lifestyle media), you are optimizing for a minority of your actual users. The Core Web Vitals then become a skewed indicator of your true UX performance.

Second nuance: CrUX aggregates 28 days of data, with a time lag. An optimization deployed today will only reflect in Search Console 2-4 weeks later. During this time, you are flying blind. Using the CrUX API or BigQuery helps, but does not solve the lag issue.

In what cases does this rule not fully apply?

Sites with very low traffic: no CrUX data, thus no user experience report in Search Console. Google claims to evaluate at the origin level if page data is missing, but what about a new site with 50 Chrome visits/month? Crickets.

PWA or hybrid application sites: some interactions do not report to CrUX the same way. Soft navigations (SPAs, JS frameworks) do not always trigger the expected metrics, especially if poorly instrumented. Result: seamless experiences that display catastrophic LCP because the initial lazy-loading is not well tracked.

How can I check if my site has usable CrUX data?

First step: open Search Console > Experience > Core Web Vitals. If you see graphs with URLs rated Good/Needs Improvement/Poor, you have CrUX data. If everything is greyed out with “No data available,” either your Chrome traffic is insufficient, or your site is too new (less than 28 days of collection).

Second check: query the CrUX API directly (free, generous quotas). Query your origin (https://yourdomain.com) and your key URLs. You will immediately see if Google is collecting metrics and at what percentile you stand. More granular and responsive than Search Console.

What to do if my CrUX data is absent or insufficient?

No CrUX data? Two levers: increase Chrome traffic (SEO, SEA, social) or implement manual reporting via web-vitals.js to monitor your own users in real-time. Be careful, these private data will never replace CrUX for Google, but they give you an immediate actionable vision.

If your CrUX data exists but is terrible, don’t panic: Google evaluates at the 75th percentile. This means you can ignore the slowest 25% of users (old devices, poor connections in dead zones) without penalty. Focus your efforts on the median and P75, not on extreme outliers.

What mistakes should be avoided in interpreting CrUX data?

Classic mistake: confusing PageSpeed Insights (lab) and CrUX data (field). PSI displays both, but only CrUX counts for ranking. A poor Lighthouse score with a green CrUX? You’re good. The opposite? A real problem to fix, no matter your synthetic score.

Another trap: optimizing for Desktop while ignoring Mobile. Google indexes Mobile-First, and the Core Web Vitals weigh heavily on mobile where network conditions vary. If your Desktop CrUX is green but Mobile red, you have a prioritization issue.

• Check Search Console Core Web Vitals weekly to detect regressions.
• Query the CrUX API for your strategic URLs (conversions, SEO landing pages).
• Instrument web-vitals.js to monitor your users in real-time (CrUX has a 28-day lag).
• Segment your data: Mobile vs. Desktop, 4G vs. 3G, to target optimizations.
• Don’t just aim to pass the “Good” threshold — strive for P50 excellence for a competitive edge.
• Regularly audit heavy assets (fonts, images, third-party JS) that negatively impact CLS and LCP.