Core Web Vitals: the number you are looking at is probably a simulation

Most Core Web Vitals advice skips the thing that decides whether any of it applies to you: there are two completely different sets of numbers with the same names, and only one of them counts.

Get that wrong and you can spend a week optimising a simulation.

The three metrics, briefly

LCP, largest contentful paint. How long until the biggest element in the viewport has rendered. In practice this is almost always the hero image or the headline block. Passing is under 2.5 seconds.

INP, interaction to next paint. How long the page takes to visibly respond after a tap or click, measured across the whole visit rather than only the first interaction. Passing is under 200 milliseconds. This replaced first input delay, and it is much harder to pass, because it looks at every interaction rather than the easiest one.

CLS, cumulative layout shift. How much content moves around unexpectedly during load, scored as a unitless number. Passing is under 0.1. The usual culprits are images without dimensions, ads and embeds that reserve no space, and web fonts that reflow the text when they swap in.

That is the whole vocabulary. The part that actually causes trouble is next.

Lab and field are not two views of the same thing

When you paste a URL into a testing tool, you get back two things that look alike and mean entirely different things.

Lab data is one simulated load. A headless browser fetches your page on a shared machine, applies a throttled network and CPU model on top, and reports what happened. It is repeatable in principle and noisy in practice, because the machine underneath is shared and busy. Run the same unchanged page several times and the numbers move. That movement is the tool, not your site.

Field data is aggregated from real Chrome users who visited your page over the previous 28 days, reported at the 75th percentile. It comes from the Chrome UX Report, which is the public dataset behind every field number you have ever seen in a speed tool. It reflects your actual audience on their actual devices and connections, it is what Google uses when these metrics influence ranking, and it is the only version that describes reality.

The practical rule that falls out of this is short:

If field data exists, it is the answer and the lab number is a diagnostic. If field data does not exist, you have a simulation and you should treat it as one.

Our own Core Web Vitals checker returns both and labels which is which, because a tool that shows you one number without saying where it came from is the reason this confusion is so widespread. The page speed checker sits next to it and answers the cruder question of whether the document itself is heavy, which is the one thing a single lab run genuinely can tell you.

Why the score moves when nothing changed

This deserves saying plainly, because it wastes an enormous amount of time.

A simulated LCP on an unchanged page varies between runs. Sometimes substantially. The simulation is competing for CPU with everything else running on the machine that served it, and the throttling model amplifies whatever contention it finds. This is not a rumour and it is not a complaint about a particular tool: Lighthouse ships its own documentation on variability, naming page-load nondeterminism, local network variability, client hardware and client resource contention as the sources, and recommending you compare aggregates rather than single runs.

We see this on our own pages routinely. The same unchanged page has returned simulated LCPs ranging from about 1.2 to 4.6 seconds across runs, which spans the entire scale from comfortably passing to clearly failing. It is why we treat a single lab reading as a hint rather than a measurement.

Three consequences worth internalising:

1. Never compare two single lab runs. Not before and after a change, not against a competitor. If you must use lab data to judge a change, run it several times on each side and compare the medians.
2. Never report a single lab number to anybody. It will be different when they check, and you will spend the meeting explaining measurement noise instead of the work.
3. A page that is structurally slow is slow in every run. That is what lab data is genuinely good for. It will not tell you your LCP is 2.9 seconds with any confidence, but it will reliably tell you that a two megabyte hero image is the reason it is not fast.

What actually moves each metric

Skipping the generic advice, because the causes concentrate hard.

For LCP, it is nearly always one of three things: the largest element is an image that is too big, or loaded lazily when it should not be, or discovered late because it arrives via CSS or JavaScript rather than in the HTML. Serve it in a modern format at the size it renders, put it in the markup, and give it high fetch priority. Everything else is rounding. The third case is worth dwelling on, because an element that only exists after JavaScript runs is late for a browser and absent entirely for a fetcher that does not run scripts.

For CLS, reserve space. Width and height on every image so the browser can hold the box before the bytes arrive, explicit dimensions on embeds and ads, and font loading configured so the fallback and the real face have similar metrics. CLS is the most fixable of the three and the one most often left broken.

For INP, the cause is long JavaScript tasks blocking the main thread when the user interacts. Break up the work, defer what is not needed for the first interaction, and be suspicious of third party scripts, which are usually the largest single contributor and the one nobody audits.

Where this sits in the wider picture

Core Web Vitals are worth fixing and are routinely over-weighted. In the sample of professional marketing sites we audited, they were not among the most commonly broken things we measured. Canonical targets, machine readable dates and author attribution all failed far more often, and each of those is cheaper to fix and more consequential for whether a page can be found and cited at all. That is the whole argument behind ordering SEO tips by measured failure rate rather than by how important they sound.

Google’s own framing supports the modest reading. Page experience is described as a set of signals rather than a ranking system, and the generative AI guidance published in May 2026 puts “providing a great page experience” in a list of ordinary SEO fundamentals rather than singling it out.

The sensible order is the one that matches how failures cascade. A page a crawler cannot reach does not benefit from a fast LCP. A page with no date and no author can render instantly and still not be quoted. Speed is worth real attention once the page is reachable, readable and attributable, and not before, which is the order the technical SEO checklist puts them in and the order our free audit reports them in.

Fix it because slow pages lose people. That reason survives every algorithm update.

Sources

Read on 15 August 2026. Thresholds move; check them rather than us.

• Google, Core Web Vitals and Google Search results, for how the metrics relate to Search and where the field data comes from.
• Google, understanding page experience in Google Search results, for the framing quoted above.
• web.dev, Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift, for the definitions and the passing thresholds.
• Chrome, the Chrome UX Report, for what field data actually is, the 28 day window and the 75th percentile.
• Lighthouse, variability, for the tool’s own account of why an unchanged page scores differently between runs.