Core Web Vitals explained in plain English

If you run a website, you have probably seen the phrase "Core Web Vitals" in a Google report or a speed-test tool and wondered how much it really matters. The short answer: these three numbers describe how fast and stable your pages feel to a real person, and Google uses them as a ranking signal. This post explains what each Core Web Vital measures, what counts as a good score, and the practical changes that move the needle.

What Core Web Vitals are

Core Web Vitals are a small set of metrics from Google that measure real-world page experience. Instead of one vague "speed" score, they break the experience into three specific questions:

• Did the main content load quickly?
• Did the page respond quickly when I tapped or clicked?
• Did the layout stay still, or did things jump around?

Each question maps to one metric: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Google measures them from actual visitors using the Chrome browser, then publishes the results in a public dataset called the Chrome User Experience Report. That is why the same page can score differently on a lab tool than it does in Google Search Console — one is a controlled test, the other is your real audience on real devices and networks.

Largest Contentful Paint: how fast the page feels

LCP measures how long it takes for the largest visible element to appear. That element is usually a hero image, a banner, or a big block of text. It is a good proxy for "the page looks ready" because the biggest thing on screen is usually the thing the visitor came to see.

Google's thresholds for LCP are:

• Good: 2.5 seconds or less
• Needs improvement: 2.5 to 4 seconds
• Poor: over 4 seconds

The number is measured at the 75th percentile, meaning three out of four visits must hit the target. A fast result for you on office wi-fi does not count for much if a quarter of your visitors are on a slow phone connection.

Common causes of a slow LCP are a slow server response, large unoptimised images, and render-blocking CSS or fonts. The fixes are usually unglamorous but effective: compress and correctly size your images, serve them in a modern format like WebP or AVIF, and make sure the hero image is not lazy-loaded. Reducing how long your server takes to send the first byte helps every visitor, because nothing can paint until that response arrives.

Interaction to Next Paint: how responsive the page feels

INP measures responsiveness. When a visitor taps a button, opens a menu, or types in a field, INP records how long it takes for the page to visually respond. It looks at interactions across the whole visit and reports a value close to the worst one, so a single janky moment can drag the score down.

Google's thresholds for INP are:

• Good: 200 milliseconds or less
• Needs improvement: 200 to 500 milliseconds
• Poor: over 500 milliseconds

INP replaced an older metric called First Input Delay in 2024. The change matters because First Input Delay only looked at the very first interaction, while INP watches the entire session. A page can feel fast on load and still feel sluggish once you start using it.

The usual culprit is JavaScript. When the browser is busy running a long script, it cannot respond to a tap until that work finishes. To improve INP, break up long tasks into smaller pieces, defer or remove scripts you do not need on first load, and be careful with heavy third-party tags such as analytics, chat widgets, and ad code. Every script you add competes for the same main thread that handles clicks.

Cumulative Layout Shift: how stable the page feels

CLS measures visual stability. You have felt a bad CLS score yourself: you go to tap a link, an image finishes loading above it, the whole page jumps, and you tap the wrong thing. CLS adds up every unexpected layout shift during the page's life into a single score.

Google's thresholds for CLS are:

• Good: 0.1 or less
• Needs improvement: 0.1 to 0.25
• Poor: over 0.25

CLS is unusual because it is not measured in seconds. It is a unitless score based on how much of the screen moved and how far. The good news is that layout shift is often the cheapest Core Web Vital to fix.

Most shifts come from a few predictable sources. Images and videos without width and height attributes let the browser reserve no space, so the page reflows when they load. Ads and embeds that load late push content down. Web fonts can cause text to reflow when they swap in. The fixes: always set explicit dimensions on media, reserve a fixed space for anything that loads asynchronously, and avoid inserting content above what the visitor is already reading.

How to measure and keep an eye on them

There are two ways to look at Core Web Vitals, and you need both. Lab data comes from tools like Lighthouse or PageSpeed Insights, which load your page in a controlled environment. Lab data is great for debugging because it is repeatable and gives you a clear before-and-after. Field data comes from real visitors and shows up in Google Search Console and PageSpeed Insights. Field data is what Google actually uses for ranking, so it is the score that counts.

The catch with field data is lag. It is a 28-day rolling average, so a fix you ship today may take weeks to show up. That delay is exactly why one-off testing is not enough. A page can pass today and quietly drift into the "needs improvement" range after a new feature, a marketing tag, or an unoptimised image slips into production.

This is where ongoing monitoring helps. SentinelWeb runs scheduled PageSpeed and Core Web Vitals checks against your pages, so a regression shows up as a tracked change instead of a surprise in next month's Search Console report. Catching a slow LCP the week it appears is far easier than untangling three months of unrelated changes.

The takeaway

Core Web Vitals are not a mysterious Google score. They are three honest questions about your pages: did the content load quickly, did the page respond quickly, and did it stay still while I used it. LCP, INP, and CLS each have a clear "good" threshold, and most fixes are well understood — right-size your images, trim your JavaScript, and reserve space for anything that loads late. Measure with lab tools while you work, watch field data for the real verdict, and check your scores on a schedule so a slow page never catches you off guard.