Fixing a CrUX vs Lab Data Mismatch

Two kinds of data, measuring different things

The Chrome UX Report only includes data from Chrome on desktop and Android. It does not include Safari, Firefox, or Chrome on iPhone and iPad, which uses Apple's browser engine. If a large share of your visitors use iPhones, CrUX describes only part of your audience, and your own analytics may show a different device mix from the one CrUX is summarising.

The Core Web Vitals checker shows both kinds of data side by side for the same URL, which is the starting point for working out where the gap comes from.

Are you even looking at the same page?

Before blaming devices or networks, check what each report is actually describing. This catches more mismatches than any other check.

• URL or origin. PageSpeed Insights shows field data for the exact URL when CrUX has enough visits to it. When it does not, it falls back to the whole origin and says so above the figures. An origin figure blends your slow blog archive with your fast home page, so it may bear no relation to the page you tested in the lab.
• URL groups. Search Console groups pages that look similar and reports one status for the group. A single slow template can pull a group into "poor" even if the example URL it lists is fine on its own.
• Mobile or desktop. Field data is split by device type. Make sure you compare the mobile field figure with a mobile lab run, not with the desktop one.
• The metric. A lab report without INP, next to a field report failing only on INP, will look like a mismatch. It is really a gap in what the lab can measure.
• Which URL was tested. Testing https://www.example.co.uk/ in the lab while CrUX reports on https://example.co.uk/, or on the non-https version, compares two different sets of visits.

The 28-day window and update timing

Field data is a rolling 28-day summary. If you shipped a fix a week ago, around three quarters of the visits in the current figure happened before the fix. The number moves gradually as old visits drop out, and a big improvement can take around four weeks to show fully.

• The CrUX data in PageSpeed Insights and the CrUX API is refreshed daily, but always covers the previous 28 days.
• The CrUX History API publishes weekly data points, which is the easiest way to see the trend line turn after a release.
• The public BigQuery dataset is published monthly, for whole origins rather than individual pages.
• Search Console's Core Web Vitals report can lag a few days behind CrUX. When you start validation on an issue, Search Console monitors it over a 28-day period before reporting whether the fix has passed.

The same lag works in the other direction. A regression released today will not show as a fail in the field for days, while a lab test shows it at once. That is the main argument for combining both: the lab for instant feedback on every release, the field for the verdict.

Why lab results look better than the field

• Slower real devices. Lighthouse simulates a mid-range phone. Many real visitors use older, cheaper or overheating phones with slower processors, which hits JavaScript-heavy pages hardest.
• Arrival through redirects and tracking links. Visitors from adverts, emails and social posts often go through one or more redirects and arrive with query strings such as utm_source or gclid. Field LCP includes the redirect time. Many CDNs and page caches treat each unique query string as a new page, so these visitors get an uncached, slow response that your clean lab URL never sees.
• Cookie banners and popups. Real visitors see consent banners, newsletter popups and chat prompts that may be suppressed, or dismissed differently, in a lab run.
• Logged-in and personalised pages. Account holders, basket contents and personalised recommendations can bypass the page cache and add work that a logged-out lab test avoids.
• Layout shift after load. Field CLS keeps counting while people scroll and use the page. Lazy-loaded adverts, late-loading embeds and infinite scroll can all cause shifts that a load-only lab test never reaches.
• Interactions. Field INP covers every tap and click. A slow menu or filter handler fails INP while lab TBT looks acceptable.
• Distance. Visitors far from your server see a slower first byte than a test machine near it.
• Single-page app navigation. In apps that change page with JavaScript, field CLS and INP from every route are attributed to the URL where the visit started, so the landing page can be blamed for problems on other screens.

Why the field can look better than the lab

The reverse happens too, and it is not a reason for concern on its own:

• Repeat visitors. Returning visitors have your CSS, JavaScript, fonts and images cached, so their pages load much faster than Lighthouse's empty-cache run.
• Back and forward cache. When someone presses back and the browser restores the page from its back/forward cache, the load is near-instant and those fast visits count in the field.
• Prerendering and prefetching. Pages prerendered through speculation rules, or prefetched by the referring site, can show very low LCP for real visitors.
• Fast audiences. An audience mostly on desktop office connections, or on new phones, will outperform the lab's deliberately modest device.

If the field passes comfortably and the lab fails, real visitors are having a good experience. Use the lab diagnostics to catch risks before they reach the field, but do not treat a lab fail as an emergency.

Getting faster, more detailed field data

CrUX tells you the result but not the cause, and not quickly. Your own real-user monitoring fills both gaps. Google's open-source web-vitals library measures the Core Web Vitals in each visitor's browser the same way Chrome does, and its attribution build explains what caused each result.

import { onLCP, onINP, onCLS } from 'web-vitals/attribution';

function send(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: Math.round(metric.name === 'CLS' ? metric.value * 1000 : metric.value),
    rating: metric.rating,
    page: location.pathname,
    navigationType: metric.navigationType,
    detail: metric.attribution
  });
  navigator.sendBeacon('/rum', body);
}

onLCP(send);
onINP(send);
onCLS(send);

Send the results to your own endpoint or into your analytics tool as events. Then report the 75th percentile by page template, device type and navigationType, which tells you whether a visit was a normal load, a reload, a back/forward restore or a prerender. Within a few days of a release you will know whether the fix is working, and the attribution tells you which element, script or interaction is responsible when it is not.

If you collect this data with an analytics tool that sets cookies, handle consent in the same way as the rest of your analytics. This is not legal advice.

The fix, step by step

When there is no field data at all

PageSpeed Insights sometimes shows no field data for a URL, or even for the whole origin, and Search Console may say there is not enough data. CrUX only publishes figures for pages and origins with enough eligible visits, and it only includes pages that are publicly available. A new site, a low-traffic page or a page behind a login will often have none.

This is not a penalty and not a failure. Without field data, Google has no Core Web Vitals figure to use for that page. In that situation:

• Use lab tests to catch obvious problems before they affect visitors.
• Add real-user monitoring if you want to know how real visitors are doing, even with small numbers.
• Check the origin-level figure, which may exist even when individual pages have none.
• Put most of your effort into content and crawlability until traffic grows.

For the metrics themselves, see the LCP guide, the INP guide and the guide to mobile-only failures, which covers the most common reason field results trail behind lab ones.