Core Web Vitals Explained: LCP, CLS, and INP in Plain English

Three specific, measurable things

"Core Web Vitals" isn't one vague performance score — it's three named metrics, each measuring something distinct and specific about how a page feels to use:

• LCP (Largest Contentful Paint) — how long it takes for the biggest visible element ( usually a hero image or main heading) to finish loading.
• CLS (Cumulative Layout Shift) — how much visible content jumps around unexpectedly while the page loads, like text shifting down when a late-loading image or ad claims space above it.
• INP (Interaction to Next Paint) — how quickly the page visibly responds after a click or tap. INP replaced an older metric called FID in 2024 — if you've seen FID referenced in older articles, INP is its successor and measures responsiveness more comprehensively.

What counts as "good"

• LCP: 2.5 seconds or less is good. 2.5–4 seconds needs improvement. Above 4 seconds is poor.
• CLS: 0.1 or lower is good. 0.1–0.25 needs improvement. Above 0.25 is poor.
• INP: 200 milliseconds or less is good. 200–500ms needs improvement. Above 500ms is poor.

What usually causes a poor score

A worked example: chasing one LCP fix

Say a product page tests at LCP 4.2 seconds — solidly in "poor" territory. Lighthouse's diagnostics point at a 2.8MB hero image served at its original camera resolution and resized down to 800×600 purely with CSS, meaning the browser downloads the full multi-megabyte file regardless of how small it's displayed. Re-exporting that same image as a properly sized, compressed WebP file — same visual content, roughly 120KB instead of 2.8MB — is often the single highest-leverage change available, because LCP is directly waiting on that one file finishing its download. On a re-test, LCP dropping from 4.2s to under 2s off that one change alone is a realistic outcome, not an exaggerated one; unlike CLS or INP fixes, which usually require several small changes to add up to a visible difference, LCP frequently has one dominant bottleneck that's worth finding first.

Lab data versus field data

A Lighthouse-style test measures lab data — a simulated run under controlled conditions, useful for debugging because it's consistent and repeatable. Google's Chrome UX Report (CrUX) measures field data — real measurements from actual Chrome users visiting the page, which is what Google's ranking systems actually reference. The two can disagree: a page might test well in a lab simulation but perform worse for real visitors on slower connections or older devices. Checking both gives a fuller picture than either alone.

Why Google measures at the 75th percentile

Field data (CrUX) doesn't use an average — it uses the 75th percentile of real visits over a rolling 28-day window, and a page has to pass the "good" threshold at that percentile to count as good overall. That's a deliberately strict bar: it means at least three out of every four real visits need a good score, not just the typical one. A page that's fast for most visitors but has a long tail of slow experiences — say, on older phones or weak mobile connections — can fail this bar even while its median (50th percentile) score looks perfectly healthy. This is also why two site owners can look at "the same" performance data and disagree: a mean or median from an analytics tool and a CrUX 75th-percentile score are answering genuinely different questions, and only the second one is what Google's ranking systems actually reference.

Where Core Web Vitals actually sit in ranking

Google has been explicit that Core Web Vitals are a relatively small ranking signal, and specifically act as more of a tiebreaker than a primary factor: among pages that are otherwise similarly relevant to a query, the faster, more stable one gets a slight edge. A page with poor Core Web Vitals but genuinely better, more relevant content will still typically outrank a faster page that answers the query worse — this matters because it's common to see sites over-invest in shaving fractions of a second off LCP while leaving thin or outdated content untouched, when the content gap is very likely the larger problem. Treat Core Web Vitals as a real but secondary lever: worth fixing because it's measurable and directly improves the experience for every visitor, not because it's the biggest knob available for rankings.

It's also just one piece of a larger picture — crawlability, content depth, and broken links all matter independently of how fast a page loads. See what a website health score covers for where CWV fits alongside those other, non-performance factors.

It's also worth knowing where the numbers themselves come from, since "PageSpeed Insights," "Lighthouse," and "Core Web Vitals report" get used almost interchangeably but aren't quite the same thing. Lighthouse is the underlying lab-testing engine — the same one running inside Chrome DevTools, a CLI, or CheckSEO's own checker. PageSpeed Insights is Google's hosted tool that runs a Lighthouse test and layers real CrUX field data underneath it when available, which is why its report shows two clearly separated sections. The Core Web Vitals report inside Search Console is pure field data, aggregated across every page on your property rather than tested one URL at a time, which makes it the right place to spot a site-wide pattern (say, every product page sharing the same template regressing at once) that a single-URL test would never reveal on its own.

Test your own page

CheckSEO's Core Web Vitals Checker runs a real Lighthouse check and reports lab data alongside real-world Chrome UX Report field data when it's available for the URL.