Your PageSpeed score says one thing. Your visitors experience another. If you have ever fixed every warning in a lab test and still watched your Core Web Vitals report stay red, you have run into the gap between lab data and field data. The Chrome User Experience Report, usually shortened to CrUX, is where Google keeps the field side of that story. Learning to read it is the difference between guessing at speed work and knowing exactly what your real visitors are suffering through.
This guide explains what CrUX data actually is, where to find it for your WordPress site, how to read the numbers without misinterpreting them, and how to turn them into a fix list in the right order.
What CrUX Data Actually Is
CrUX is a public dataset of real-user performance measurements collected from Chrome. When a Chrome user visits a website and has usage statistics and crash reports enabled, Chrome records how that page actually performed on their device, on their connection, in their part of the world. Google aggregates those measurements and publishes them.
Three things about that definition matter for how you read the numbers:
First, it is real-user data. A lab test loads your page once, on a fast connection, on a powerful machine, with a clean browser. CrUX reflects thousands of messy real visits: cheap Android phones, congested mobile networks, browsers with extensions running, pages opened from a social app’s built-in browser. That is why field data almost always looks worse than lab data, and why Google treats it as the authoritative view.
Second, it is aggregated over a 28-day rolling window. The numbers you see today describe roughly the last four weeks of visits, not yesterday’s traffic. That is a feature, not a flaw: it smooths out one-off spikes. But it also means a fix you ship today will not show up in CrUX tomorrow. Expect to wait weeks, not days, before field data confirms an improvement.
Third, it only covers pages and origins with enough traffic. If your site is small, some or all of your URLs may show no CrUX data at all. That is normal for a new or low-traffic site, and it is not a penalty. It simply means you need another way to measure until traffic grows, which we will come back to.
Lab Data vs Field Data: Why the Two Disagree
PageSpeed Insights shows you both, side by side, and beginners often assume one of them is wrong. Usually neither is.
Lab data is a single controlled run. It is excellent for diagnosing a specific problem — it tells you which script blocked rendering, which image was oversized, which request chain delayed the page. But it describes one device, one location, one network condition.
Field data is the distribution of real visits. It cannot tell you which script caused a problem, but it tells you whether the problem actually hurts your visitors, and how badly. A heavy script that only runs on desktop may barely register in field data if most of your traffic is mobile, or the reverse.
The practical rule is simple: use lab data to find causes, use field data to set priorities. If lab data flags an issue but field data shows your visitors are fine, that issue can wait. If field data is red and lab data looks clean, your lab conditions are not matching your visitors, and you need to test on a throttled connection or a weaker device.
For a fuller testing routine that combines both kinds of data, see our guide on how to test your WordPress site speed the right way.
Where to Find Your CrUX Data
You do not need to query a database to start. There are three practical places to read CrUX data for a WordPress site, in order of usefulness.
1. PageSpeed Insights
Run any URL through PageSpeed Insights and scroll past the lab score to the section labelled “Discover what your real users are experiencing.” That is CrUX data for that URL, plus an origin-level summary covering your whole site. This is the fastest way to check a single important page, such as your homepage or a top landing page.
2. Google Search Console: Core Web Vitals Report
Search Console groups your indexed URLs by their field-data status: Good, Needs Improvement, or Poor, separately for mobile and desktop. This is the view that matters most for SEO, because it is the same classification Google uses when it talks about page experience. Open it, look at the mobile report first — most WordPress traffic is mobile, and mobile thresholds are where most sites fail — then open the worst group to see which URL patterns are affected.
3. The CrUX Dashboard
For a site-wide trend view, the free CrUX Dashboard template (built on Looker Studio) connects to the CrUX dataset and charts your metrics month by month, split by device and connection type. It takes a few minutes to set up, and it is worth it once you start making regular speed changes, because it shows whether a metric is genuinely trending in the right direction or just wobbling.
Querying the raw CrUX dataset in BigQuery is also possible, but for most site owners it is overkill. The three sources above cover every decision you actually need to make.
How to Read the Numbers
CrUX reports each Core Web Vital as a distribution, not a single score. That is the single most important thing to understand.
The p75 value
For each metric, Google reports the 75th percentile value, written as p75. In plain language: 75 percent of real visits performed at least this well, and 25 percent performed worse. Google grades the p75 against fixed thresholds:
- Largest Contentful Paint (LCP): good at 2.5 seconds or less, needs improvement up to 4 seconds, poor beyond that.
- Interaction to Next Paint (INP): good at 200 milliseconds or less, needs improvement up to 500 milliseconds, poor beyond that.
- Cumulative Layout Shift (CLS): good at 0.1 or less, needs improvement up to 0.25, poor beyond that.
When Search Console marks a URL “Poor” for LCP, it means the p75 of real visits was slower than the threshold, not that every visitor had a bad experience. A quarter of visits being slow is enough to fail.
The distribution bars
PageSpeed Insights also shows the share of visits in each bucket: what percentage were good, what percentage need improvement, what percentage were poor. Read these before you read the p75, because they tell you how widespread a problem is. A metric can pass at p75 while a large minority of visits still struggle, and that minority is often your mobile audience.
Origin level vs URL level
CrUX publishes data at two levels. Origin-level data aggregates every page on your domain. URL-level data covers one specific page. Origin data is almost always available before URL data, because it pools more visits. When you check a single page and see “not enough data,” fall back to the origin view — it still tells you how the site as a whole is doing, and it is the number Search Console leans on for small sites.
Mobile vs desktop, always separated
Never read a blended number. CrUX splits mobile and desktop because the two experiences are genuinely different: a page that loads in two seconds on a desktop broadband connection can take six on a mid-range phone. If you only glance at one, make it mobile.
A Worked Example: Reading a Report
Suppose you open Search Console and find your mobile report shows a group of URLs marked Poor for LCP, while INP and CLS are Good. Here is how to read that, step by step:
First, open one URL from the group in PageSpeed Insights and look at the field data. Suppose the LCP distribution shows most visits in the poor bucket. That confirms the problem is real and widespread, not a reporting quirk.
Second, check the lab section of the same report for the LCP element. PageSpeed names the element that painted largest — often a hero image, a heading block, or a large product photo. If it is an image, check whether it is lazy-loaded (a classic mistake: the hero image should never be lazy-loaded) and whether it is properly sized.
Third, compare desktop. If desktop LCP is Good while mobile is Poor, the problem is likely image sizing, mobile-specific scripts, or a theme element that only renders heavily on small screens — not your server.
That sequence — field data to confirm, lab data to diagnose, device comparison to narrow down — is the whole method. Our LCP checklist walks through the fixes in order, and the same logic applies to interaction problems and layout shift.
What to Fix First
Field data gives you a priority order almost for free. Work through it like this:
- Fix the worst metric first, not the easiest one. A Poor LCP hurts visitors more than a borderline CLS issue, even if the CLS fix is a five-minute job.
- Fix the URL group with the most traffic. Search Console shows example URLs per group; start with the pattern that covers your homepage, top posts, or product pages, not an obscure archive page.
- Fix mobile before desktop. If both are failing, mobile wins, because that is where most of your visitors are and where the thresholds bite hardest.
- Re-check with lab data after each change. Field data will take weeks to confirm the improvement, so use lab tests to verify the fix itself works, and let CrUX confirm the real-world effect later.
If all three metrics are Good, your job shifts from fixing to protecting: re-check the Search Console report monthly, and treat any new Poor group as an early warning that a plugin update, theme change, or new embed has introduced a regression.
Common Misreadings to Avoid
“My PageSpeed score dropped, so my CrUX must be worse”
Not necessarily. The lab score and field data move on different cycles. A theme update can change a lab score overnight while field data, averaged over 28 days, barely moves for weeks. Judge speed work by field data trends, not by a single lab run.
“No CrUX data means my site is failing”
No data means not enough Chrome visits to publish an aggregate. It is common for new sites and low-traffic pages, and Google does not penalize you for it. Keep improving with lab data, and check back as traffic grows. Our Core Web Vitals checklist covers the full set of fixes worth doing while you wait.
“One bad day ruined my numbers”
Because CrUX aggregates 28 days, a single bad day — a traffic spike, a host outage, a bot surge — is diluted, not decisive. If your numbers move sharply, look for a change that persisted for weeks: a new plugin, a theme update, a hosting change, a new ad or chat widget.
“Desktop is fine, so the site is fine”
Desktop field data flatters almost every WordPress site. Mobile is where the ranking signal and the visitors are. If you only have time to read one report, read mobile.
A Monthly CrUX Routine
Once you know how to read the data, the habit is cheap. Once a month, spend fifteen minutes on this:
- Open the Search Console Core Web Vitals report, mobile first, and note any new Poor or Needs Improvement groups.
- Open your homepage and one top-traffic page in PageSpeed Insights and compare the field distributions with last month’s.
- If a metric slipped, find the cause with lab data before changing anything.
- After shipping a fix, note the date. Then wait for the next 28-day window to roll through before judging the result in field data.
That discipline is what separates sites that keep getting faster from sites that chase scores. Lab tests tell you what to change. CrUX tells you whether it mattered to the people actually visiting. Read both, prioritize by field data, and your speed work will stop being guesswork.
