Core Web Vitals: The Three Numbers Google Ranks On

Google measures three numbers on every page of every website it indexes, and those three numbers are part of how it decides which sites rank above which others in search results. The umbrella term is Core Web Vitals. The three numbers are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Each measures a specific aspect of how a real visitor experiences a real page on a real device.

For a small business owner, the practical question is "are mine green?" This post explains what each one is, why it matters, what passing looks like, and how to read your own.

Why these three

Google studied billions of pages and asked which technical measurements correlated most strongly with user satisfaction. They landed on three categories: how fast does the visible content load (LCP), how responsive is the page to interaction (INP), and how stable is the layout while the page is loading (CLS). Each measures a different failure mode that real visitors notice and complain about.

These are not synthetic lab tests. The metrics are collected from real visitors on real devices through Chrome's built-in telemetry, aggregated into the Chrome User Experience Report (CrUX) database, and used by Google's ranking algorithm. A site can pass synthetic tests and still fail Core Web Vitals if the field data shows real visitors having a bad time.

1. Largest Contentful Paint (LCP)

What it measures: the time from when the visitor clicks the link to when the largest visible element on the page (usually the hero image or the headline text) finishes rendering.

Threshold: 2.5 seconds is the green-zone ceiling. Above 4 seconds is red.

Why it matters: visitors abandon pages that look broken or slow during the first few seconds. The "largest visible element" is the proxy for "the visitor can tell the page has loaded." If that takes 5 seconds, the visitor probably is not still there when it finishes.

What causes failures: oversized hero images (the most common cause by a wide margin), render-blocking CSS, slow servers, and uncached images on a site without a CDN. The fix is almost always image optimization plus a fast CDN, both of which I cover in separate posts.

What passing looks like on my builds: 0.4 to 0.9 seconds, comfortably below the 2.5-second threshold. The hero image is AVIF, the CSS is purged and small, the host is Cloudflare's global edge.

2. Interaction to Next Paint (INP)

What it measures: when a visitor clicks a button, taps a link, or interacts with the page in any way, how long does it take for the page to visually respond. This metric replaced First Input Delay (FID) in March 2024; it is stricter and measures responsiveness throughout the visit, not just the first interaction.

Threshold: 200 milliseconds is the green ceiling. Above 500 ms is red.

Why it matters: a page that loads fast but feels sluggish under interaction is just as frustrating as one that loads slowly. Visitors who tap a button and see no response within 300 ms tend to tap again, then tap somewhere else, then leave.

What causes failures: heavy JavaScript that hogs the main thread, third-party scripts (advertising trackers, chat widgets, analytics platforms) that take hundreds of milliseconds to process each interaction, and CSS animations that trigger expensive reflows. WordPress sites with many plugins routinely fail INP.

What passing looks like on my builds: typically 30 to 80 ms, well below the 200 ms threshold. The sites I build run almost no JavaScript on the front end (a small navigation script, the search modal, a few interaction handlers); there is nothing on the main thread to block.

3. Cumulative Layout Shift (CLS)

What it measures: how much the page's layout jumps around while it is loading. A page that loads the headline first and then pushes everything down when the hero image arrives has a CLS event. The metric sums all such shifts across the visit.

Threshold: 0.1 is the green ceiling. Above 0.25 is red.

Why it matters: the visitor who is about to tap a button and has the button move out from under them taps the wrong thing instead. Most visitors do not articulate this as a "bad" experience, but they bounce more from sites that do it.

What causes failures: images without explicit width and height attributes (the browser does not know how much space to reserve, so the layout shifts when the image arrives), third-party embeds that load late and push content around, web fonts that swap from a fallback to the loaded version with different metrics, and ads that load after the rest of the page.

What passing looks like on my builds: 0.00 to 0.03, essentially perfect. Every image has explicit dimensions. There are no late-loading embeds. Web fonts are configured with size-adjust to match the fallback metrics. There are no ads.

How to check your own

Three free tools, in increasing order of depth.

Google PageSpeed Insights. Visit pagespeed.web.dev, paste your URL, run the test. The top of the report shows your Core Web Vitals from real visitor data (or "not enough data" if your site does not have enough Chrome users). The bottom shows a synthetic Lighthouse test of the same URL.

Search Console "Core Web Vitals" report. Inside Google Search Console, the dedicated report shows which URLs on your site are passing all three metrics, which are failing, and which have insufficient data. The breakdown by URL is more useful than the page-level test because it surfaces consistent failures across page types.

Chrome DevTools "Performance" tab. For diagnostic depth, the Performance tab can record a full page load and show every event that contributed to the metrics. This is the tool I use when investigating a specific failure; for most clients it is overkill.

What "passing" actually means for ranking

Google has been deliberately vague about how much Core Web Vitals affect ranking. The realistic summary based on what the search community has measured: passing all three thresholds is a small but real ranking signal, and failing them is a slightly larger negative signal. The effect is most pronounced when two pages are otherwise tied; the one with better Core Web Vitals wins the tiebreak.

For a small service business competing with a few local rivals, all of whom have mediocre sites, passing Core Web Vitals can be enough on its own to move from page two to page one. For a business in a competitive national category, Core Web Vitals matter but cannot make up for thin content or weak backlinks.

The practical implication: passing should be the floor, not the goal. A site that fails Core Web Vitals is leaving ranking points on the table that competitors can pick up; a site that passes is at parity with the technical floor of professional websites.

What I do at build time

For every site I build, the Core Web Vitals targets are part of the build pipeline:

• LCP target: in the green band (under 2.5 seconds). Achieved through image optimization, CSS purging, font preloading, and edge hosting.
• INP target: under 100 ms. Achieved through minimal front-end JavaScript and no third-party trackers on the main thread.
• CLS target: under 0.05. Achieved through explicit image dimensions, font-size-adjust, and no late-loading embeds.

The targets are tighter than Google's pass thresholds because performance degrades over time as content is added. A site that launches at 0.6s LCP is comfortably in the green for years; a site that launches at 2.4s LCP slips into the amber zone the first time a slightly heavier hero image lands.

If your current site is failing Core Web Vitals

The most common failure pattern across small-business sites is a single oversized hero image dragging LCP into the red. The fix is image optimization, which I cover in detail in a separate post. Closing that one issue often moves a site from "failing all three" to "passing all three" without touching anything else.

For sites with deeper performance issues (heavy JavaScript, many third-party trackers, slow hosting), the fix path is broader. The free five-point audit covers Core Web Vitals as part of the standard pass; the report names the specific causes and what each fix would involve.