Field data vs lab data: why PageSpeed Insights results differ

Field data describes visits that already happened; lab data describes a controlled test. PageSpeed Insights puts both in one report, but they cover different devices, behavior and time periods. Use field data to understand real experiences and lab recordings to investigate causes and test changes.

A green Lighthouse score does not establish that real visitors pass Core Web Vitals. Equally, a slow synthetic run does not invalidate good field results. First identify what each number represents. The Core Web Vitals introduction explains the metrics; this guide explains why their measurements differ.

Start with the population and the question

CrUX, the Chrome User Experience Report, aggregates experiences from eligible Chrome users. It is not a census of everybody visiting your website. Participation depends on browser settings and supported environments, and a page needs enough eligible observations to appear in the public dataset. Google does not provide a universal public traffic number that guarantees inclusion.

Page eligibility also matters. Public discoverability and indexability are part of the requirements, so traffic alone does not establish that an account page or restricted application should have a CrUX record. You cannot submit a URL manually to force inclusion. Missing data therefore says that this source cannot answer the question, not that the page is fast or slow.

A Lighthouse navigation run loads a URL in a configured browser environment. It can provide detailed diagnostics without waiting for visitors, including before a release. That makes it useful for engineering, but the configured test is a sample scenario rather than your actual audience distribution.

The following comparison separates the questions each source can answer.

Read the percentile without turning it into an average

The displayed field metric is generally the 75th percentile, abbreviated p75. If LCP is 2.4 seconds at p75, at least 75% of the recorded experiences reached that milestone in 2.4 seconds or less. It does not mean that every visitor waited 2.4 seconds or that the arithmetic average was 2.4 seconds. This example illustrates interpretation, not a measured website.

The good thresholds are LCP at most 2.5 seconds, INP at most 200 milliseconds and CLS at most 0.1. Evaluate the device categories separately. A satisfactory desktop distribution cannot cancel a mobile problem, and the same threshold values apply to both categories.

Look at the distribution as well as the classification. A p75 just inside the good range can coexist with a substantial slow tail. Investigate whether that tail concentrates on a region, template or interaction before treating the overall green label as the end of the work.

For the exact field-versus-lab distinctions, Google's measurement comparison provides the underlying context. Keep the percentile and population attached whenever you share a metric with colleagues.

Check whether the field result belongs to the URL

PageSpeed Insights attempts to show URL-level field data, then may fall back to origin-level data when the URL lacks sufficient observations. An origin combines scheme, hostname and port. It is not the complete URL path, and it is not automatically every subdomain owned by the same organization.

Origin data can include several templates with different behavior. A slow product page and a fast article may contribute to the same aggregate. If the field panel describes the origin while the lab test describes one article, their disagreement does not establish that either measurement is defective.

Record the scope before copying a result into an issue. Write the tested URL, final destination, device, field scope and collection dates. A note saying only “mobile LCP is bad” leaves the developer to rediscover which population actually failed.

Do not relabel an origin result as a URL result in a dashboard. If the exact URL lacks field evidence, show that limitation and retain origin context separately. The PageSpeed Insights report guide explains where to check this distinction in the report.

Understand what throttling does and does not reproduce

Lighthouse can use simulated throttling to estimate performance under specified CPU and network constraints. Other configurations use different throttling methods. Read the report settings rather than assuming every Lighthouse run uses identical conditions, even when two tools display the same Lighthouse branding.

A desktop development machine, browser extensions, background load and a different test location can all affect comparisons. Repeated runs can vary without a code change. Save the browser and Lighthouse versions, strategy, environment and individual metric values, then compare repeated runs under matching conditions.

The test also has a state. A fresh navigation may encounter an empty browser cache, while returning visitors reuse resources. Conversely, the lab may receive a warm CDN response that a distant first visitor does not. “Cold” must name the cache layer; clearing local storage does not empty an edge cache.

Simulated conditions are useful because they expose expensive work consistently enough to investigate it. They are not a promise that a particular real phone will match the resulting number. Choose additional test scenarios from visitor evidence rather than rerunning one default profile until it becomes green.

Investigate the metric that explains the disagreement

For LCP, compare the actual largest element and its delivery path. Device width can select a different image or cause a different block to become the largest. Network distance, server response, resource discovery and rendering work can change which stage dominates. A small desktop asset may not represent the mobile page.

For CLS, extend the journey beyond initial loading. Scroll to delayed embeds, let advertising initialize, change consent state and test navigation back to the page. A loading-only audit can miss later movement that real visitors experience. The shifted heading may be the victim of a growing container above it, not the component that caused the problem.

For INP, test interactions. A normal Lighthouse navigation does not produce the same real-user INP distribution shown in CrUX. Total Blocking Time can reveal main-thread pressure during loading, but it is not interchangeable with INP. Controlled interactive tools can measure interaction latency; the limitation is the scenario and coverage, not that all laboratory measurement is impossible.

Reproduce the suspected action with Chrome DevTools: open a menu, type into search or change a product option. A page that loads cleanly may still perform expensive work on the first click. Keep the interaction, target and trace with the issue so another person can reproduce it.

Account for the rolling window after a release

CrUX results in PSI cover the previous 28 days and update daily. Immediately after a fix, most of that window can still describe the previous implementation. The new lab result and the historical field result are answering different temporal questions.

Mark the deployment time in monitoring. Look for fresh evidence from your own measurement and repeated lab scenarios while the public field window fills with new visits. Do not promise that a report will change after an exact number of hours, or assume that a poor label proves the release failed.

The visitor mix can also change during that window. A campaign reaching slower networks can alter the distribution even if the code improves. Compare relevant segments when your monitoring supports them and retain uncertainty when the public aggregate cannot separate the causes.

Add RUM when the aggregate cannot locate the cause

Real user monitoring, or RUM, can collect performance measurements from your own site with useful context such as template and deployment version. Plan the collection, consent requirements, retention and access before adding telemetry. Do not send account details, form values or full URLs containing sensitive query parameters.

The official web-vitals library handles important metric lifecycle details. In a project that installs and bundles that dependency, this module logs supported measurements locally without sending data to a server.

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

function reportMetric(metric) {
  console.log({
    name: metric.name,
    value: metric.value,
    id: metric.id,
    rating: metric.rating,
    navigationType: metric.navigationType
  });
}

onCLS(reportMetric);
onINP(reportMetric);
onLCP(reportMetric);

Replace the logger with an approved collection endpoint only after designing the backend. Metrics can be reported again as their values change, so define how the receiver updates records and avoids double counting. A callback is an observation, not automatically a new page visit. Missing INP can mean no qualifying interaction occurred; do not replace it with zero.

Your RUM distribution will not necessarily equal CrUX. Browser coverage, sampling, consent, navigation definitions and iframe visibility can differ. Use the attribution build when additional diagnostic detail is appropriate, but review what that detail contains before transmitting it.

Use each result for the decision it supports

For an engineering change, first reproduce the affected journey and demonstrate improvement under comparable conditions. For the visitor outcome, monitor field metrics with the scope and period clearly identified. For Search, distinguish Core Web Vitals evidence from the Lighthouse performance score; the score itself is not a ranking grade.

Choose one failing metric, one representative template and one repeatable journey. Save the baseline, change the suspected cause, and check functionality as well as timing. Use the PageSpeed analyzer when enabled and the Core Web Vitals guides to select the next investigation. The useful outcome is an explained disagreement that leads to a verified fix.