Core Web Vitals in Plain English (and Why Your Rankings Care)

Three metrics. That's the whole system. Google collects real-world performance data from Chrome users across the entire internet, boils it down to three numbers per page, and uses them as one input — not the only input, one input — into ranking. Most of what gets written about Core Web Vitals either oversells them as a ranking silver bullet or ignores them as a technicality. Neither is accurate. Here is what each number actually measures, what the data says about how much it matters, and the fix list ranked by effort against payoff.

1. Largest Contentful Paint (LCP)

What it measures:the time from navigation start until the largest visible element in the viewport — usually a hero image or a headline block — finishes rendering. Google's threshold: 2.5 seconds or under is "good." Between 2.5 and 4 seconds is "needs improvement." Above 4 seconds is "poor."

Physical-world analogy:it's the difference between a trailhead sign that's visible from the parking lot and one buried past three switchbacks. The content exists either way. LCP measures how long the visitor waits before they can see the thing they came for.

What Google says vs. what the data shows: Google is explicit that Core Web Vitals are a minor ranking factor relative to content relevance and links. The data from client sites is more interesting than that disclaimer suggests: pages that move from "poor" to "good" LCP rarely jump rankings directly, but they consistently show lower bounce rates and higher scroll depth — and those behavioral signals correlate with ranking improvements over the following months. LCP's ranking effect is mostly indirect, and it's real anyway.

2. Interaction to Next Paint (INP)

What it measures: the delay between a user interaction — a tap, a click, a key press — and the next visual update on screen. Good: under 200 milliseconds. Needs improvement: 200–500 milliseconds. Poor: over 500 milliseconds. INP replaced First Input Delay as an official Vital in March 2024, and it measures responsiveness across the full page lifecycle, not just the first interaction.

Physical-world analogy:it's the gap between pulling a trigger and hearing the shot. A short gap feels like one motion. A long gap feels broken, even if the shot eventually fires.

What Google says vs. what the data shows: Google frames INP as a user-experience signal first, ranking signal second. The data on regulated-industry and e-commerce client sites — where a mistimed tap on a mobile menu or an add-to-cart button costs a conversion outright — shows INP correlating more tightly with conversion rate than with ranking position. Treat INP as a revenue metric that happens to also be a ranking metric, not the other way around.

3. Cumulative Layout Shift (CLS)

What it measures: how much visible content moves around unexpectedly as a page loads. Good: a score under 0.1. Needs improvement: 0.1–0.25. Poor: above 0.25. The classic offender is an image or an ad slot that loads without a reserved size, shoving the paragraph a reader was mid-sentence on down the screen.

Physical-world analogy:a trail map that keeps redrawing itself while you're trying to read it. Nothing about the destination changed. The ground under your feet did.

What Google says vs. what the data shows: Google calls CLS a stability signal, and the data backs a strong claim here specifically: CLS is the Vital most directly tied to accidental clicks and rage-quits, which means it's the one most directly tied to lost conversions on mobile. It is also, of the three, the cheapest to fix completely — which makes a poor CLS score the least defensible number on this whole list.

The fix list, ranked by effort against payoff

1. Layout reservations (lowest effort, high payoff). Set explicit width and height — or an aspect-ratio box — on every image, embed, and ad slot before it loads. This alone typically takes CLS from "poor" to "good" in an afternoon. There is close to no reason for any site to carry a bad CLS score in 2026.
2. Image weight (low effort, high payoff). Modern formats (AVIF, WebP), correctly sized source files instead of a 4000px photo scaled down in CSS, and lazy-loading everything below the fold. This is usually the single biggest lever on LCP, and it rarely requires touching application logic.
3. Font loading (low effort, medium payoff). Self-hosting fonts instead of a third-party request, preloading the primary font file, and setting a font-display strategy that avoids invisible text. Small effort, and it removes a common cause of both slow LCP and a late layout shift when the fallback font swaps out.
4. JavaScript bloat (medium effort, high payoff on INP). Auditing third-party scripts — chat widgets, marketing pixels, analytics tags stacked three deep from three different eras of the site's history — and removing or deferring anything not doing real work. This is the most common cause of poor INP on client sites we've audited, and it's usually a cleanup job, not a rebuild.
5. Hosting and server response time (higher effort, payoff depends on baseline). If Time to First Byte is already slow, no front-end optimization fixes it. This is the one item on the list that sometimes means a real infrastructure change — a faster host, a CDN, or in our case, choosing a fully static build over a server-rendered one so there's no backend round trip to wait on at all.

When not to chase a score

Here is the sentence most performance content won't write: a perfect 100 on a lab-test performance score is not a business goal, and chasing the last ten points on a synthetic score after the field data already reads "good" across all three Vitals is time spent for its own sake. We've had clients ask to keep tuning after their real-user data was already comfortably in the green, because a competitor's lab score in a tool was higher. Lab scores measure a single simulated visit on fixed hardware. Field data measures your actual visitors on their actual phones on their actual connections. When the two disagree, believe the field data — it's the one Google uses for ranking, and the one that reflects what a real customer experiences.

How to measure without fooling yourself

Two data sources exist and they answer different questions. Field data — the Chrome User Experience Report, visible in Search Console's Core Web Vitals report — reflects real visitors on real devices over the past 28 days. It's the only data Google uses for ranking, and it's the only data that can tell you whether last month's fix actually worked in the world instead of in a lab. Lab data — Lighthouse, PageSpeed Insights' simulated score — runs one test on one simulated connection and is useful for diagnosing why a page is slow, not for certifying that it isn't. A site with a mediocre lab score and excellent field data is not broken. A site with a flawless lab score and poor field data on real 4G connections in the mountains is the one with the actual problem, and it's the one a lab score alone will never surface.

Check Search Console's report monthly, not daily — the 28-day rolling window means daily checks mostly measure noise. Segment by device if traffic skews mobile, because a site that's fast on the desktop used to build it and slow on the mid-range Android phone most customers actually carry is a site with a field-data problem no lab test will catch. Fix the layout reservations first. They're free, they're permanent, and unlike almost everything else on this list, there is no version of "good enough" that doesn't apply to every single page on the site.