Core Web Vitals: how to combine field and laboratory data

Executive brief

Key takeaways

• Core Web Vitals are field metrics evaluated at the 75th percentile.
• Lighthouse cannot measure real INP without user interactions.
• Field data confirms the problem; the lab helps explain the cause.
• Prioritize by page, journey, reach and evidence confidence.

Core Web Vitals measure loading, responsiveness and visual stability. According to web.dev documentation, a good experience requires LCP up to 2.5 seconds, INP up to 200 milliseconds and CLS up to 0.1, evaluated at the 75th percentile and separated between mobile and desktop.

These are field metrics. Real-user data exposes an aggregated symptom but rarely identifies the exact line of code, image or third party responsible. Laboratory tests do the reverse: they help debug one execution, but do not represent the whole population.

Combining both sources turns a score into a diagnosis.

What field data is

Field data comes from real visits. The Chrome User Experience Report (CrUX), for example, aggregates eligible Chrome experiences over a rolling period. Search Console and PageSpeed Insights use this data in different views.

It captures diversity in devices, networks, location, cache state, entry pages, interactions, conditional scripts and personalization. That diversity makes the signal closer to real experience while reducing direct causal attribution.

What laboratory data is

Laboratory tools run a page under controlled conditions. Lighthouse, DevTools and WebPageTest can simulate network, CPU, viewport and cache while exposing waterfalls, long tasks, dependencies and responsible elements.

The lab is appropriate for reproducing a problem, comparing before and after, finding render-blocking resources, inspecting LCP discovery, locating long tasks, observing layout shifts and creating regression tests.

Because conditions are artificial, results vary and should not be presented as “the site's speed” for every user.

How each metric appears

LCP

LCP can be measured in field and lab. The responsible element may change with viewport, content, cookie, experiment and device. Compare the lab element with first-party field attribution when possible.

INP

INP depends on real interactions throughout a visit. Automated loading without clicks or keystrokes cannot produce representative INP. Lighthouse uses Total Blocking Time as a laboratory signal related to main-thread availability, but TBT is not INP.

CLS

CLS can appear in both environments. In the field, shifts can happen after interactions or during long visits. A lab test may end before a late banner, ad or asynchronous block moves the page.

Read PageSpeed Insights in two parts

PageSpeed Insights generally presents available CrUX field experience first and a Lighthouse laboratory diagnosis second.

Ask:

1. Is the data for the URL or only the origin?
2. Which device is selected?
3. Is the evaluation an aggregated window or one run?
4. Which metric fails in the field?
5. Which element or resource chain appears in the lab?
6. Does the suggested opportunity relate to the failed metric?
7. Does the tested URL represent the affected template?

This order prevents teams from fixing every red item without proving its relationship to the main problem.

Why URL and origin can disagree

A URL may receive page-level data when volume is sufficient. Otherwise, the tool may show origin-level aggregation. An origin combines templates, journeys and performance levels.

A fast homepage can hide slow product pages. A heavy campaign may damage the aggregate even when the primary template is healthy. Group pages by type: home, category, product, article, search, checkout and landing page. Diagnosis and action usually belong to a template.

A six-step workflow

1. Confirm the field signal. Identify metric, device, page group and period. If public data is unavailable, mark it unknown and consider first-party web-vitals instrumentation.
2. Select representative URLs. Choose examples from the same template, including good and poor cases when possible.
3. Reproduce in the lab. Keep conditions comparable, run more than once and examine a median or distribution.
4. Find the concrete cause. For LCP, identify the element and discovery chain. For INP, capture interactions and tasks. For CLS, identify both the moved and causing elements.
5. Implement a bounded change. Avoid combining a CDN migration, JavaScript refactor and redesign if the goal is to learn which action worked.
6. Verify on the right timelines. The lab can react immediately after deployment. Aggregated field data needs new visits and an updated window.

Prioritize pages and fixes

Combine reach, journey importance, severity and confidence. A simple image fix across every product page may outrank a complex refactor in a low-traffic section. The lowest score is not always the largest opportunity.

Common interpretation mistakes

• “The score fell, so the site got worse.” One run varies with server, network, content and environment. Confirm a trend.
• “We pass in the lab, so we pass in the field.” The lab is one condition; users may have slower devices and untested interactions.
• “The largest estimated saving is the cause.” Lighthouse opportunities are estimates for one run. Connect the suggestion to the critical element.
• “Performance proves conversion.” Better performance removes one type of friction. Business impact depends on page, intent, offer and measurement.

Turn metrics into a backlog

Observation: product pages fail mobile LCP in the field; in the lab, the main image is discovered only after carousel JavaScript. Action: render the first image in HTML, apply srcset and prioritize only the LCP candidate. Acceptance: the image remains responsive, lab LCP improves across repeated tests and field data is monitored after deployment.

The Core Web Vitals overview explains the metrics. The detailed diagnostics cover LCP, INP and CLS.

Field and lab do not compete. One shows what a population experienced; the other helps explain why an execution behaved that way. Reliable decisions use both.

Direct answers

Frequently asked questions

Why does PageSpeed Insights show data different from Lighthouse?

Its field section may show aggregated CrUX data, while Lighthouse runs a laboratory test with simulated device and network conditions. Sources, periods and conditions differ.

Did a page without field data fail?

No. There may not be enough eligible volume to publish data. The correct state is unknown; use first-party measurement and laboratory evidence as complements.

Do I need a Lighthouse score of 100?

No. The score helps debugging, but it should remain subordinate to real experience, test stability and page objectives.