Core Web Vitals Without the Score Obsession
There are three metrics, three thresholds, and one scoring rule that catches almost everyone out. Most of the confusion around Core Web Vitals comes from treating a lab score as though it were the assessment, when the assessment is made from entirely different data.
The three, and what each is really about
Largest Contentful Paint marks when the biggest element in the viewport finished rendering. Good is 2.5 seconds or less, poor is over 4. In practice it is about one element — usually a hero image, a background, or a heading waiting on a web font — and usually about how early the browser learns it needs that resource rather than how big the resource is.
Interaction to Next Paint measures how long the page took to visibly respond after someone interacted, across the whole visit. Good is 200 milliseconds or less. It is the hardest of the three to fix because the answer is nearly always to run less JavaScript, not to change a configuration value. It also replaced First Input Delay in 2024 — if a tool still reports FID, it is out of date.
Cumulative Layout Shift scores how much content moved unexpectedly. Good is 0.1 or less. The thing people get wrong is that it accumulates over the entire visit, not just page load: a cookie banner appearing after two seconds, a late advertisement, or an image without dimensions all push it up long after the page looked finished.
All three, or it is a fail
There is no averaging between metrics and no partial credit. Two greens and a red is a fail. Teams routinely optimise LCP into excellent shape and remain unassessed as passing because CLS is quietly poor, and no amount of further LCP work will change that.
Why your score and your assessment disagree
A lab tool runs a simulated device on a throttled connection and produces a weighted score, which does not include INP at all — INP needs a real interaction, and a lab run does not interact. The assessment that matters is made from field data: real visits, at the 75th percentile, aggregated over a rolling 28-day window.
So a score of 100 alongside a failing assessment is normal and consistent, not a contradiction. It usually means your traffic is more mobile, more distant or more bandwidth-constrained than the simulation assumed.
The 28-day window explains "I fixed it and nothing happened"
Field data is aggregated over the previous 28 days. Three days after a fix, roughly 90% of the window is still made of pre-fix measurements, so the number has barely moved and the fix looks ineffective. It is not; it is being diluted. A monitoring tool with a shorter window is how you confirm a fix landed without waiting a month to find out.
What to actually do
Look at the field data split by device before touching anything, because mobile and desktop routinely differ by more than any optimisation you are likely to ship, and the blended number hides which one is failing. Then fix the metric that is actually failing, on the pages that actually get traffic — effort spent on a page with forty visits a month cannot move a traffic-weighted assessment.
Tools mentioned here
NetTests.NET covers the underlying concepts in more depth in its guide on this.