What Core Web Vitals are
Core Web Vitals are Google's attempt to reduce "is this page a good experience?" to a small number of things that can be measured automatically in a real browser. There are three, and they are chosen to cover three separate ways a page can feel bad: it can be slow to show you anything, slow to respond when you touch it, or visually unstable while you are trying to read it.
| Metric | Measures | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP | Loading — when the largest element finished rendering | ≤ 2.5 s | 2.5 – 4.0 s | > 4.0 s |
| INP | Responsiveness — interaction latency across the visit | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| CLS | Visual stability — unexpected layout movement | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
A page passes only if all three pass. There is no averaging across metrics and no partial credit — two greens and a red is a fail, and this is the first thing people get wrong.
Largest Contentful Paint
LCP marks the moment the largest image or text block visible in the viewport finished rendering. It is a proxy for "the page looks loaded" — deliberately, because earlier metrics like First Contentful Paint can fire on a loading spinner and tell you nothing about whether the reader got the content.
The LCP element is usually a hero image, a background image, a video poster frame, or a large heading. It is chosen by the browser, it can change between viewports, and it is very often not the element you assumed. On mobile the LCP element is frequently different from desktop simply because a different set of things fits above the fold. If you are optimising LCP, find out which element it actually is before you change anything.
Interaction to Next Paint
INP measures how long it takes for the page to visibly respond after a user interacts — from the tap or click, through the event handlers, to the next frame the browser paints. It reports roughly the worst interaction of the visit rather than the average, on the reasonable basis that one two-second lag is what the user will remember.
A bad INP almost always means the main thread is busy: long JavaScript tasks, heavy event handlers, large re-renders, or third-party scripts monopolising the thread. It is the hardest of the three to fix, because the fix is usually "do less work in JavaScript" rather than a configuration change.
INP replaced First Input Delay in March 2024 and FID has since been removed from Google's field data entirely. If a tool or an article still reports FID, it is out of date. FID measured only the delay before the first interaction began processing — it ignored how long the work took and it ignored every interaction after the first, which made it easy to pass while still feeling sluggish.
Cumulative Layout Shift
CLS scores how much content moves around unexpectedly. It is a unitless number, not a
duration, and it is the one people most often misread — because
it accumulates over the entire visit, not just page load. A cookie banner
that appears after two seconds, an advertisement that loads late, a web font that swaps and
reflows the text, an image without width and height attributes
reserving its space: all of them push CLS up long after the page looked finished.
Shifts that immediately follow a user interaction are excluded, on the basis that content moving because you clicked something is expected rather than jarring.
How they are actually assessed
Three rules matter more than the thresholds themselves.
Field data, not lab data. Google assesses Core Web Vitals from real Chrome users, not from a test you run. A lab tool gives you a diagnosis; it does not give you the number that counts. See what real user monitoring is for why the two disagree and why that disagreement is useful.
The 75th percentile. Each metric is reported at p75 — the value three out of four visits came in under. Not the average, which a handful of fast desktop loads will flatter into meaninglessness.
A 28-day rolling window. Google's public field data set aggregates the previous 28 days. This is the single biggest source of "I fixed it and nothing happened": three days after a deploy, roughly 90% of the window is still made of pre-fix measurements.
How much do they matter for ranking?
Honestly: less than the amount of content written about them implies, and more than nothing. Core Web Vitals are one input among many, and relevance beats speed — a fast page about the wrong topic does not outrank a slow page that answers the query. They function closer to a tiebreaker between comparable results.
The stronger argument for caring is not the ranking signal at all. It is that the thresholds correspond to things users genuinely react to: a page that takes four seconds to show its main content, or moves under their thumb as they reach for a button, loses people regardless of what any search engine thinks about it.
Common mistakes to avoid
Chasing a Lighthouse score of 100. The performance score is a weighted blend of lab metrics, only some of which are Core Web Vitals — it does not contain INP at all, because INP needs a real interaction. A 100 in the lab and a failing field assessment is a completely normal combination, not a contradiction.
Assuming two out of three is a pass. All three must pass. A superb LCP does not offset a poor CLS.
Reading the blended number and ignoring the device split. Mobile and desktop usually differ by more than any optimisation you will ship. A combined figure hides which one is actually failing.
Treating CLS as a load-time problem. It runs for the whole visit. Fixing everything above the fold and still failing usually means something is shifting later — an ad slot, a lazy-loaded image, a font swap.
Optimising a page nobody visits. Field data is weighted by traffic. Effort spent on a page with 40 visits a month cannot move the assessment for your site.
Troubleshooting: why does my data look wrong?
Why does Search Console disagree with the tool I just ran? Because they are different measurements. Search Console reports field data at p75 over 28 days; your lab tool reports one synthetic run just now, on hardware and a network that are not your visitors'. Both can be correct simultaneously.
Why does my page have no INP data? Nobody interacted with it, or too few people did to form a percentile. This is normal on articles and landing pages.
Why did my score not move after the fix? The 28-day window. Wait for it to roll through, or use a monitoring tool with a shorter window so you can confirm the fix landed before Google's data catches up.
Why is one URL failing when the rest of the site passes? Check what is different about its traffic before you check its code — a page with a much higher share of mobile or international visitors will look worse on identical code.