Core Web Vitals Field Data vs Lab Data: What to Fix First

Core Web Vitals field data describes real-user experience; lab data describes a controlled test. When Lighthouse and Chrome UX Report (CrUX) disagree, first check the device, URL scope and measurement dates. Use the difference to frame an investigation, rather than choosing whichever number looks better. Google explains these measurement differences in its lab and field data guidesource.

For an owner, the useful question is what deserves work next. A score alone does not tell a developer what to change, show the business impact, or prove that a fix worked. NAVINES Beacon website monitoring helps connect supported observations to priorities, action items and AI-guided investigation. This guide shows how to make that handoff specific enough to verify.

What each performance source can tell you

• Lighthouse: examine the requested page under the test's device and network conditions. Use its diagnostics to investigate a reproducible problem.
• CrUX: review aggregated experience from eligible Chrome users. Keep mobile and desktop results separate when comparing them.
• Business data: use your own authorized analytics or records to investigate sales and engagement. Neither a Lighthouse score nor a CrUX trend proves lost revenue.

PageSpeed Insights can show both lab and field evidence. A good lab performance score does not automatically mean the real-user Core Web Vitals assessment passes. Google documents what each part measures in About PageSpeed Insightssource.

Read LCP, INP and CLS before the overall score

The Core Web Vitals are LCP for loading, INP for responsiveness, and CLS for visual stability. Google's good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, assessed at the 75th percentile. FCP and TTFB can add diagnostic context, but are not additional Core Web Vitals. See Google's Web Vitals definitionssource.

An ordinary Lighthouse page-load test does not reproduce the full range of real-user interactions behind field INP. Treat a lab responsiveness diagnostic as an investigation aid, not a replacement for the field metric. Likewise, post-load content can create layout shifts that a short lab run misses.

Check origin, page and history before comparing

Beacon currently collects origin-level CrUX history, whereas its current Lighthouse evidence concerns the page being tested. An origin such as https://example.com is broader than https://example.com/product. The CrUX History APIsource provides weekly points based on overlapping 28-day collection windows. These are not separate daily measurements.

Write both scopes into the work record. If the issue concerns one landing page, the origin trend supplies context but cannot prove that page is fixed. After a deployment, a new lab result may change before the rolling history reflects it. Record the deployment and recheck dates so the next reviewer knows what the comparison can establish.

Three ways to handle conflicting results

1. The lab test is weak but field history looks healthy

Repeat the affected page test using comparable conditions. Check whether the slow element is essential customer-facing content, a transient resource failure, or something specific to the tested device. Keep the finding open until you understand enough to choose a proportionate fix. Healthy aggregate history is context, not a reason to dismiss a reproducible problem on an important page.

2. The lab test looks healthy but field history is weak

Check whether the lab test covers the same page and device experience. Ask what happens after load and whether a recent release could explain the difference. If the answer requires actual visitor journeys or page-specific measurements, use an authorized source that provides them. A single improved test is not sufficient evidence to close the entire user-experience investigation.

3. Both sources point to a performance problem

Choose the affected customer journey, name the measurement to improve, and ask the developer to test a specific cause. For LCP, that might mean investigating the main image or delayed rendering; it is still a hypothesis until checked. Define how the reviewer will confirm the result before authorizing work. Agreement between two sources strengthens the case for investigation, but does not identify the cause by itself.

An example of a performance action item

Illustrative workflow, not a measured customer result: a mobile product-page test is slow while desktop appears healthy. Instead of assigning 'improve website speed', prepare a work record that a developer and business owner can both follow. The team can maintain any fields not available in its Beacon account in its existing work system.

• Evidence: affected URL, test time, mobile or desktop, measured metric, and whether the field result describes the page or origin.
• Priority: explain why this journey matters and distinguish possible business impact from verified revenue data.
• Next action: inspect the cause, propose one bounded change, and name the person responsible for approval.
• Status: record whether investigation, implementation or verification is still outstanding.
• Acceptance: retest the same URL, check the visible page and important interactions, then review later field history at the correct scope.

This is alert lifecycle tracking applied to performance: evidence stays connected to the action and its outcome. AI can help explain the observation and propose checks; the team remains responsible for the change and the closure decision.

What if CrUX has no data?

Missing public field history is not evidence that the website is slow or broken. Continue with available measurements, state the coverage gap, and avoid inventing a trend. Beacon can continue its supported review without that history. For product scope and supported metrics, see Core Web Vitals monitoring with Beacon.