A site can score 98 in Lighthouse and still fail Core Web Vitals in Search Console. Nothing is broken when that happens, and neither number is lying. They are two different measurements: one is a single scripted load on a simulated device, the other is a distribution of what real people on real networks experienced. Performance projects stall when a team treats the first as a prediction of the second, spends a quarter chasing a lab score, and finds the field assessment unchanged.
Key takeaways
- Lab data is a controlled reproduction; field data is a record of what happened. A lab tool loads one page, once, on a fixed device profile with a cold cache and no user interaction.
- Two of the three Core Web Vitals cannot be fully measured in a lab. Interaction to Next Paint needs a real person clicking, and layout shift accumulates over a whole visit rather than over the first few seconds.
- The assessment uses the 75th percentile, not the average. Three quarters of visits must be inside the threshold, which makes the slow tail the thing that decides the outcome.
- Field data lags and has a coverage floor. It summarises a rolling window of past visits, and low-traffic URLs may have no page-level data at all.
- Core Web Vitals are a weak ranking input. The business case for performance rests on abandonment and conversion, not on position changes.
Why the lab and the field disagree by design
A lab tool such as Lighthouse or PageSpeed Insights runs a synthetic load: a defined CPU and network throttle, an empty cache, no logged-in state, no consent banner accepted, and nobody touching the page. That determinism is the point. It makes results reproducible and lets you attribute a change to a code change rather than to conditions on a mobile network.
Field data makes the opposite trade, giving up reproducibility to gain reality. It contains the visitor on an old Android phone on a congested cell network, the visitor who returns with a warm cache, and the visitor who accepted a cookie banner that injected four tag manager scripts. Several of those conditions are exactly the ones producing your worst measurements, and none of them exist in the lab profile. So a lab score is a debugging instrument and a regression guard, not a forecast of the field assessment.
What the three Core Web Vitals actually measure
The metrics cover three distinct complaints a user can have: it took too long to show me anything useful, it did not react when I touched it, and it moved while I was reading. Google documents all three in its Web Vitals overview.
LCP: how long until the main content appeared
Largest Contentful Paint records the render time of the largest image or text block in the viewport. It is a proxy for "the page looks loaded", which is closer to perception than any server-side timing. A fast time to first byte does not guarantee a fast LCP, because the largest element often depends on resources discovered late: a hero image referenced in CSS, a webfont delaying text, or content rendered only after a JavaScript bundle executes.
INP: how responsive the page felt throughout the visit
Interaction to Next Paint replaced First Input Delay as a Core Web Vital in March 2024, and the difference matters. FID measured only the delay before the browser began processing the first interaction, excluding both the processing work itself and every later interaction. INP looks across all qualifying interactions and reports a high one, covering the full path from input to the next painted frame. A page can score well on the old metric and badly on the new one without any code changing, because the expensive work was never counted before. The mechanics are set out in web.dev's INP documentation.
CLS: how much the layout moved unexpectedly
Cumulative Layout Shift is a unitless score rather than a time, and it accumulates across the visit rather than stopping at load. Shifts following shortly after a user interaction are excluded, since someone who clicked "show more" expects movement. What counts is movement nobody asked for: an image without reserved dimensions, a late ad slot expanding, a font swap changing line heights, or a banner injected above the fold.
| Metric | Good | Poor | Measurable in a lab tool? |
|---|---|---|---|
| LCP | 2.5 s or less | Over 4.0 s | Yes, under one synthetic profile |
| INP | 200 ms or less | Over 500 ms | No; Total Blocking Time is the lab proxy |
| CLS | 0.1 or less | Over 0.25 | Partly; only shifts during the observed load |
The band between good and poor is "needs improvement". A URL group passes only when all three metrics are in the good band, so one weak metric decides the verdict regardless of the other two.
Why the 75th percentile, and why averages mislead
Averages hide the users you most need to see. A page served quickly to a majority on fast connections can carry a long tail of very slow visits, and the mean absorbs that tail almost completely. Optimising toward the mean optimises for people whose experience was already acceptable.
A percentile threshold changes the incentive, forcing attention onto the slower quarter: older devices, weaker networks, geographies further from your CDN edge, and pages where a heavy third-party script fires only under certain conditions. Mobile and desktop are assessed separately, so a desktop-only improvement does not rescue a mobile failure. This also explains a pattern that confuses teams reading their own monitoring: the median improves after a release while the field assessment does not move. Both readings can be correct. The release helped the typical visit and left the tail untouched.
Where field data comes from, and what it cannot see
The field numbers in Search Console and PageSpeed Insights originate in the Chrome User Experience Report, a public dataset of real-user measurements collected from eligible Chrome users. Google's Core Web Vitals documentation for Search describes how that data reaches the report. Four properties change how you read it.
- It lags. The values summarise a rolling window of recent visits, so a fix deployed today is diluted by weeks of pre-fix visits and the metric improves gradually rather than stepping down on release day.
- It has a traffic floor. A URL needs enough eligible samples for its own entry. Below that you see origin-level data, which can conceal a badly performing template entirely.
- It is Chrome only. Safari and Firefox visitors are absent, which matters most for sites with a heavy iOS audience.
- Search Console groups similar URLs. A failing group tells you a template has a problem; it does not tell you which URL to open first.
Because of the floor and the grouping, running your own real-user monitoring alongside it is worth the effort on larger sites. Your own collection covers every browser, has no lag, and can be segmented by template, country, device class or logged-in state, which is usually where the cause becomes visible.
What actually causes each metric to fail
Each metric has a small set of structural causes, and they are not interchangeable. Diagnosing the wrong one turns performance work into a long sequence of ineffective micro-optimisations.
| Metric | Where the time or movement comes from | Inspect first |
|---|---|---|
| LCP | Slow server response, render-blocking CSS and fonts, a large image discovered late or lazy-loaded, client-side rendering above the fold | Whether the LCP element is image or text, and when the browser learns it exists |
| INP | Long JavaScript tasks holding the main thread, oversized handlers, heavy re-rendering, tags firing on interaction | Which interaction is slow, and what runs at that moment |
| CLS | Images and iframes without dimensions, injected banners and ads, font swaps, content inserted above existing content | Whether the shift happens at load, after consent, or on scroll |
Third-party code deserves separate attention because it fails asymmetrically. A tag that is harmless in the lab, where no consent was granted and no personalisation ran, can dominate the main thread in the field. If field INP is poor while lab Total Blocking Time looks acceptable, the gap between those two conditions is the first place to look.
A working order for a performance project
Sequence matters more than tool choice, and this order avoids optimising a page the field data never flagged.
- Read the field data first. Establish which metric fails, on which device class, for which URL group.
- Pick a representative URL inside the failing group. The group is a template, so choose a page typical of it rather than the homepage by default.
- Reproduce under conditions closer to the failing segment. A test on a desktop machine over office wifi will not reproduce a mobile field failure.
- Fix one structural cause rather than a list of small ones. Reserving image dimensions, removing a render-blocking dependency, or deferring one heavy script usually moves a metric further than a dozen minor edits.
- Verify in the lab immediately, in the field after the window turns over. The lab confirms the change worked; only the field confirms it mattered, and that takes weeks.
Step five is where projects lose their evidence trail. Record the deployment date alongside the field readings so movement can later be attributed to a specific change rather than to whatever else happened that month. That is the same discipline that separates a result from a coincidence elsewhere in traffic work, as covered in our notes on common traffic measurement mistakes.
What performance is worth, and what it is not
Google treats page experience signals, Core Web Vitals included, as an input to ranking, and has been consistent that it is a small one relative to relevance and content quality. The page experience documentation states there is no single page experience score and that strong performance does not compensate for a page which fails to answer the query. A site failing all three metrics and ranking first is not an anomaly. Expecting a position gain from a performance sprint alone sets up a disappointment that later gets used to defund the work entirely.
The case that survives scrutiny is behavioural. Slow pages are abandoned before they render, unresponsive interfaces are abandoned mid-task, and layout shifts cause misclicks that end sessions. Each of those is a session you already paid to acquire, whatever the channel. That makes performance a conversion-side investment, measured accordingly: abandonment by device class, funnel step completion, and conversion rate segmented by performance cohort where your analytics supports it.
Sequenced properly, this work belongs in the same bucket as landing page quality. Establish what your current traffic does before assuming you need more of it, using the approach in our guide to measuring conversion rate against a baseline, and treat page speed as one lever among several in improving what happens after the click. A page that renders in a second and still does not convert has a different problem.
Frequently asked questions
Why does my Lighthouse score not match Search Console?
They measure different things. Lighthouse runs one synthetic load under a fixed device and network profile with an empty cache and no interaction. Search Console reports aggregated real-user measurements at the 75th percentile over a rolling recent window. A high lab score with a failing field assessment usually means your audience runs slower devices or networks than the lab profile, or that the problem appears only under conditions the lab never creates, such as an accepted consent banner.
How long after a fix should the field data change?
Longer than most release cycles allow for. Because the reported value summarises a rolling window of past visits, pre-fix visits keep contributing until they age out. Expect gradual movement over weeks rather than a step change, and use lab measurements in the interim to confirm the technical effect.
Can I improve INP without removing JavaScript?
Sometimes, because INP is about main thread availability rather than bundle size in itself. Breaking long tasks into smaller pieces, deferring non-urgent work until after the next paint, and moving expensive computation off the interaction path can all help without deleting code. If third-party tags occupy the main thread during interactions, though, deferring them is usually the shorter route.
Do Core Web Vitals matter for a site with very little traffic?
They still affect users, but the field report may not show them. Below the sample threshold you see origin-level data or none at all, which leaves lab tools and your own monitoring as the usable evidence. Fix the structural causes visible in the lab and judge success by abandonment and conversion rather than by a field assessment that will not populate.
Try Traffic Creator free
GA4-visible traffic, credits that never expire, 195+ countries — start with 2,000 free visits, no credit card.
Start Your Free Trial →