PageSpeed good, Core Web Vitals failed: read the right data

If PageSpeed looks good but Core Web Vitals failed, check the data source before you change WordPress. The green Lighthouse score and the failed Core Web Vitals assessment can both be correct because they measure different populations, time periods and conditions.

PageSpeed good, Core Web Vitals failed: read the scope first

PageSpeed Insights puts two measurement systems on one report. Its field section comes from the Chrome User Experience Report, or CrUX. Its lab section comes from Lighthouse. Google describes that split in its PageSpeed Insights CrUX guide (opens in a new tab).

Field data answers, “What did eligible Chrome visitors experience?” Lab data answers, “What happened in this controlled test?” A strong lab score does not cancel a poor field result.

Before reading any metric, record four labels:

CrUX reports the 75th percentile for the Core Web Vitals. When all three metrics have sufficient data, a pass requires LCP, INP and CLS to be in the good range at that percentile. The current good thresholds are LCP at 2.5 seconds or less, INP at 200 milliseconds or less, and CLS at 0.1 or less.

The page versus origin label matters as much as the number. If a URL has insufficient CrUX data, PageSpeed Insights can fall back to origin-level data. If the origin also lacks enough data, the field section can show no data while the Lighthouse test is still available.

Annotate the report before diagnosing WordPress

Copy this table beside the PageSpeed report you are reading. Fill the PageSpeed rows from the report in front of you. Do not move a Lighthouse value into a field-data row just because a field value is missing.

This site publishes its own real-visitor Core Web Vitals on its performance page, field data from its own visitors, and lists the Lighthouse score budgets it holds itself to. The public page gives enough information to demonstrate the labeling step without inventing a PageSpeed value.

On that performance page, a metric appears as the 75th percentile once 50 page loads have arrived for that device class in the rolling 28-day window. Until then it shows “Collecting” with a running count. Open the page when you audit the site and read the current status there. That 50-load rule belongs to this site’s reporting system, not CrUX. Google does not disclose the exact CrUX popularity threshold.

Do not equate the site’s “phones under 768 px” bucket with a CrUX device label. They come from separate measurement systems with separate segmentation rules.

Compare devices and time windows before comparing numbers

The pagespeed field data vs lab data mismatch often comes from time and population rather than a broken tool.

CrUX in PageSpeed Insights covers a rolling 28-day collection period. Its values can move as older visits leave that window and newer visits enter it. A deployment today can improve a lab run immediately while the field number still contains weeks of earlier traffic.

Lab data has the opposite property. It is current, but narrow. Google’s lab and field data explanation (opens in a new tab) notes that a lab test uses one device, one network and one location, while field data contains the range of devices, networks, locations and user behavior seen in visits.

That difference also explains why the PageSpeed performance score can change when the page did not change. Lighthouse documents score variation from changing underlying conditions, including dynamic content and traffic routing. A single score is therefore a sample, not a permanent property of the URL. See Google’s Lighthouse performance scoring documentation (opens in a new tab).

Compare like with like:

• Match mobile field data to mobile diagnostics first.
• Keep URL-level field data separate from origin-level field data.
• Compare field periods that contain the same deployment when checking whether a release helped.
• Repeat a lab run when one result is far from the others, then inspect the metric and trace rather than averaging the headline score into a new target.

Inspect coverage limits before treating missing field data as a result

“No data” is not a pass, fail or speed grade. It means the requested CrUX record is unavailable at that scope.

Google’s CrUX methodology (opens in a new tab) says pages and origins must be publicly discoverable and sufficiently popular to appear. Google does not publish the exact visitor threshold. CrUX also contains only eligible Chrome experiences, so it does not represent every visit to the site.

That explains why two sites can show different kinds of field data in PageSpeed Insights. One URL may have enough data for a URL-level record, another may show only origin data, and another origin may show no field data.

INP has another coverage wrinkle. A visit with no qualifying click, tap or key interaction has no INP value for that page load (opens in a new tab). PageSpeed’s CrUX guide also notes that some pages can lack sufficient INP data and be assessed on the other available Core Web Vitals.

For a low-traffic WordPress page, do not read origin fallback as proof that the tested template is slow. First find whether the failing field result belongs to the URL or to the origin.

Choose the next diagnostic from the mismatch

The next test should follow the failing measurement. Chasing the Lighthouse total can send you toward code that is unrelated to the visitor problem.

INP deserves the same source discipline. Google recommends starting with field evidence when it exists, then reproducing the slow interaction in the lab. Its INP optimization guidance describes that field-to-lab sequence.

This is the point where “lighthouse vs crux” stops being a debate. Field data selects the problem worth investigating. Lab data helps reproduce a cause under controlled conditions.

Why a good lab run can coexist with a failed field assessment

A Core Web Vitals failure is based on the field assessment, not the Lighthouse performance score. The field result summarizes eligible visits over the rolling collection window. The lab score summarizes the conditions of the current Lighthouse run.

The two sources can also observe different behavior. A user may scroll far enough to trigger content that shifts later, or interact with a menu, filter or checkout control that a load-only lab run never touches. Web.dev notes that field CLS covers the page lifecycle, while load-focused lab testing can miss post-load shifts.

A good lab run therefore tells you that the tested page performed well under that run’s conditions. It does not tell you that the 75th percentile of visitors passed every Core Web Vital.

Use the failure to pick the right performance guide

Once you have identified the failing scope and metric, move to the guide that owns that problem. For a store where loading, checkout or front-end work is the next task, use the WooCommerce Core Web Vitals performance guide instead of tuning a generic Lighthouse score.

If the mismatch spans templates, devices or visitor segments and you need page traces plus field-data interpretation, the WordPress performance optimization service covers that diagnostic work.