Chrome UX Report (CrUX): a practical Technical SEO guide

Core Web Vitals matter. Search rankings are influenced by real-user experience signals, and Google's own infrastructure lets you see exactly how your site performs in the wild. But most teams either ignore this data or misinterpret it—treating a single spike as a trend, or missing the geographic and device-level breakdowns that explain poor performance.

This guide walks you through Chrome UX Report (CrUX): a practical Technical SEO guide so you can measure what users actually experience, identify genuine problems, and prioritize fixes that move the needle on search visibility.

What is the Chrome UX Report (CrUX)?

The Chrome UX Report is Google's repository of real-user experience metrics collected from millions of Chrome browser sessions across the web. It's free, publicly available, and directly influences SEO rankings through Core Web Vitals. CrUX data represents actual user interaction—not synthetic lab tests—making it the source of truth for how your site performs in production.

Google updates CrUX monthly and rolls it into PageSpeed Insights, the CrUX API, and BigQuery. Importantly, CrUX measures three core signals:

• LCP (Largest Contentful Paint): how quickly the main content loads
• FID (First Input Delay): how responsive the page is to user interaction
• CLS (Cumulative Layout Shift): how stable the layout stays during load

Google also tracks secondary metrics like time to first byte (TTFB), first contentful paint (FCP), and interaction to next paint (INP). But the three core signals are what directly affect search rankings.

The 75th Percentile: What It Means for Your Site

CrUX reports the 75th percentile—not the median or average. This matters: a single user with a slow network doesn't sink your score, but if 25% of users experience poor performance, you fail the threshold.

Here's what the thresholds look like for a "good" rating:

If you're at the 75th percentile and you're "good" across all three, your page passes the Core Web Vitals assessment. If you're in "needs improvement" or "poor" at the 75th percentile, Google will deprioritize your page in rankings.

Real example: a product listing page might load in 2.0 seconds for 50% of users but hit 4.2 seconds at the 75th percentile due to slow networks or low-end devices. Your average looks great; your percentile fails. This is why CrUX is more honest than your local test run.

Per-URL vs. Per-Origin Data: The Granularity Question

CrUX gives you two levels of visibility:

• Origin-level: aggregated performance across your entire domain. Good for understanding overall health.
• URL-level: performance for a specific page. Requires a minimum sample size (usually 100+ sessions over 28 days).

Not every URL has enough traffic to appear in CrUX. PageSpeed Insights will show origin-level data for almost any site, but individual URLs only surface if they hit Google's sampling threshold.

Here's the practical implication: if you have a high-traffic homepage, you'll see URL-level metrics. If you have a niche blog post with 50 monthly visitors, you'll only see origin-level data. For SEO, this means you should monitor both and use origin data to baseline your technical foundation, then use URL data to debug specific bottlenecks on key pages.

Example workflow: Your origin-level LCP is 3.2 seconds (needs improvement). You dig into PageSpeed Insights for your homepage URL and see it's actually 2.1 seconds—good. Your checkout page URL is 5.8 seconds—poor. Now you know where to focus your engineering effort.

Accessing CrUX: PageSpeed Insights and the CrUX API

PageSpeed Insights is the easiest entry point. Visit pagespeed.web.dev, paste your URL, and scroll down to the "Real experience" section. You'll see your Core Web Vitals from CrUX if the URL qualifies. This data refreshes monthly, so check back on the same day each month to track trends.

For larger-scale analysis, use the CrUX API. It's free and doesn't require authentication beyond a Google Cloud project. You can query any public URL or origin and pull historical data for analysis.

Here's how to fetch CrUX data via the REST API:

curl -X POST https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{
    "origin": "https://yoursite.com"
  }'

The response includes percentile distributions for LCP, FID, CLS, and device/connection breakdowns. Use this data to build dashboards, trigger alerts, or feed performance metrics into your CI/CD pipeline.

For teams with heavy traffic analysis needs, CrUX data is also available in BigQuery. Query it directly alongside your own analytics to correlate user behavior with performance metrics—for example, "Did checkout conversion rate drop when LCP degraded last week?"

The 28-Day Rolling Window: Why Changes Take Time

CrUX operates on a 28-day rolling window. Each data point you see represents the past four weeks of Chrome user sessions. If you deploy a performance optimization today, the impact won't show in CrUX data for another month. This delays feedback and makes it harder to correlate fixes with metrics.

This is the critical difference from synthetic testing tools (like Lighthouse in your CI/CD pipeline), which give instant feedback. CrUX is slower but truthful; Lighthouse is fast but optimistic.

Practical consequences:

• Deploy a fix on day one of the window. For 27 days, your CrUX metrics include data from before the fix. Only on day 28 do you see the improvement reflected.
• If you check CrUX daily, you'll see no change for three weeks, then a sudden shift. Don't panic; this is expected.
• Plan for one cycle (28 days) to validate that your optimization actually worked at scale.

Example: your team reduces image size on your homepage on November 1st. Your LCP drops from 3.8 to 2.9 seconds in your lab. But CrUX won't reflect this until December 1st, because the data is still a rolling window that includes all of November. If you optimize again on November 15th before seeing results, you'll muddy your analysis.

The best practice is to pick one high-impact optimization, deploy it, and measure CrUX data 30+ days later. This discipline prevents the trap of constant tweaking based on noise.

Segmenting Performance: Device, Connection, and Geography

Raw percentiles hide important patterns. CrUX lets you drill into performance by:

• Device: desktop, mobile, tablet
• Connection type: 4G, 3G, 2G, slow-2G, offline
• Geography: by country (requires additional API parameters)

Your mobile LCP might be 4.2 seconds (poor) while desktop is 1.8 seconds (good). This is common because mobile devices have less CPU and memory, and users often experience slower networks. If you only look at origin-level metrics, you'll underestimate mobile performance problems—and mobile rankings are critical.

A travel site serving Asia-Pacific regions might have acceptable LCP in Australia (2.1s) but poor LCP in India (5.3s) because of regional infrastructure and network capacity. Knowing this drives CDN placement and image optimization decisions.

You can query the CrUX API with additional dimensions:

{
  "origin": "https://yoursite.com",
  "formFactor": "MOBILE",
  "effectiveConnectionType": "4G"
}

Use this to build a performance matrix: test all combinations of device + connection, then prioritize the segment with the worst 75th percentile performance. If mobile-4G is already good, don't waste effort there; focus on mobile-3G where users struggle.

Common Mistakes

Mistake 1: Confusing CrUX with lab data. Your local Lighthouse test says LCP is 1.8 seconds on a fast network, but CrUX shows 3.2 seconds at the 75th percentile. Both are correct; they measure different things. CrUX wins for SEO because it's what Google ranks on. Lab data helps you debug, but don't ship a fix based solely on lab improvement—validate it in CrUX after 28 days.

Mistake 2: Ignoring low-traffic URLs. If a URL doesn't appear in CrUX, you might assume it's performing fine. Wrong. It has too few sessions to report—but Google still crawls it. Use origin-level CrUX as a proxy and supplement with your own synthetic testing (Lighthouse CI) for low-traffic pages.

Mistake 3: Over-optimizing for the average. If 50% of your users are on desktop with 100 Mbps and 50% are on mobile with 3G, your average looks acceptable. But the 3G users at the 75th percentile might be suffering. Don't chase the mean; chase the 75th percentile, especially in mobile.

Mistake 4: Treating a one-month dip as a trend. CrUX data bounces due to random fluctuation in user mix and network conditions. A 0.3-second LCP increase one month might revert the next month. Only act on large, persistent changes (e.g., an increase that holds for two consecutive months).

Mistake 5: Not linking CrUX metrics to business outcomes. You optimized LCP and it's now "good" at the 75th percentile. Great—but did this move the search ranking needle? Did conversion rate improve? CrUX is a signal, not a guarantee. Correlate CrUX improvements with rankings and conversions to prove ROI.

Key Takeaways

• CrUX reports real-user performance at the 75th percentile—not averages. This is what Google ranks on.
• Access CrUX free via PageSpeed Insights or the CrUX API. PageSpeed is quickest; the API scales for multi-URL monitoring.
• Origin-level data appears for almost every site; URL-level data requires sufficient traffic. Use both in your analysis.
• The 28-day rolling window means performance improvements take a full month to surface in CrUX. Plan accordingly and avoid over-tweaking.
• Segment by device, connection, and geography. The 75th percentile on mobile-3G matters more than the average on desktop—especially for SEO.
• CrUX is diagnostic, not prescriptive. Pair it with lab testing (Lighthouse) to understand where problems come from.
• Validate that Core Web Vitals improvements correlate with search ranking and conversion gains. Performance for its own sake doesn't pay the bills.