Core Web Vitals explained: what they are and how to pass them

If you have ever opened Google Search Console, seen a wall of URLs flagged as "Poor" or "Needs improvement", and had no idea what LCP, INP or CLS actually meant, you are in good company. Core Web Vitals sound like something only a developer should worry about. In reality they are just Google's attempt to measure three things every visitor already feels: does the page load quickly, does it respond when I tap something, and does it stop jumping around while I read? This is a plain-English guide to what the three metrics are, the numbers you need to hit, and how to fix each one honestly — without pretending it is easier than it is.

What Core Web Vitals actually are

Core Web Vitals are a set of three metrics Google uses to score the experience of loading a page. They sit inside Google's wider "page experience" signals, alongside things like HTTPS and mobile-friendliness. Crucially, Google measures them on real visits from real people — data collected anonymously from Chrome users over the previous 28 days — not on a single test run in a lab. That distinction matters, and we will come back to it.

The three metrics each measure a different feeling:

• Largest Contentful Paint (LCP) — loading. How long until the biggest thing on screen (usually a hero image or heading block) has actually rendered. This is the closest thing to "how fast does the page feel".
• Interaction to Next Paint (INP) — responsiveness. When someone taps a button, opens a menu or fills a field, how long before the page visibly reacts. INP replaced the older First Input Delay (FID) metric in 2024, and it is stricter — it looks at all your interactions, not just the first.
• Cumulative Layout Shift (CLS) — stability. How much the content jumps around as the page loads. If you have ever gone to tap a link and an advert loaded and shoved it downwards so you hit the wrong thing, that is layout shift.

The numbers you need to hit

Each metric has three bands: good, needs improvement, and poor. To "pass", you want all three sitting in the good band. Here are the thresholds Google uses:

• LCP — good is 2.5 seconds or less; anything over 4 seconds is poor.
• INP — good is 200 milliseconds or less; over 500ms is poor.
• CLS — good is 0.1 or less; over 0.25 is poor. (CLS is a unitless score, not a time.)

There is one subtlety that trips almost everyone up. Google does not use your average visitor — it uses the 75th percentile. In plain terms, 75% of your visits need to hit the good band for the page to pass. That means the person on a three-year-old Android phone on patchy 4G counts just as much as the person on fibre with a new iPhone. It is a deliberately demanding bar, because it reflects the slowest quarter of your real audience rather than your best-case test.

Worth being honest about: INP is the one most sites fail. Loading and stability are largely solved by good build practice, but responsiveness exposes heavy JavaScript, and a large share of sites — particularly template-heavy ones stacked with plugins and third-party scripts — sit above the 200ms line.

Lab data vs field data — why your score "lies"

Run a page through PageSpeed Insights and you get two very different things on one screen, which is the single biggest source of confusion we see.

The big number at the top is a lab (or synthetic) test: one simulated load, on a throttled connection, in a controlled environment. It is useful for debugging because it is repeatable and gives you a diagnostic breakdown. But it is not what Google ranks on.

Google judges your Core Web Vitals on field data — real visits from real people over 28 days — not on a one-off lab score. If the two disagree, trust the field.

The field data (labelled "Discover what your real users are experiencing", drawn from the Chrome User Experience Report) is the anonymised record of actual visits. This is what feeds Search Console and what determines whether you pass. So it is entirely possible — normal, even — to see a green lab score of 95 and still be failing in Search Console, because your real visitors are on slower devices than the test assumes. Always let the field data have the final word. If you want the fuller picture of what slows real pages down, our guide on why your website is slow goes deeper on the causes.

How to fix each one

The good news is that most fixes are well understood. The honest caveat is that some are quick config changes and some mean genuinely rebuilding how the page is put together.

To improve LCP, start with the largest element — usually the hero image. Serve it in a modern format (WebP or AVIF), size it correctly rather than shipping a 4000px image into a 800px slot, and make sure it is not lazy-loaded (lazy-loading the thing above the fold is a common own goal). Then look at your server: slow hosting and a slow database response push LCP up before a single pixel renders. This is exactly why we lean towards server-rendered builds — the browser receives finished HTML rather than waiting for JavaScript to assemble the page.

To improve INP, the honest answer is usually "ship less JavaScript". Every script — analytics, chat widgets, A/B testing tools, cookie banners, ad tags — competes for the browser's main thread, and while it is busy running code it cannot respond to a tap. Audit what is actually loading, remove what you do not need, and defer what you do. On a heavily plugin-driven site this can be the hardest vital to move, because the weight is baked into the platform.

To improve CLS, reserve space for anything that loads late. Set explicit width and height on images and video so the browser holds the gap. Give ads and embeds a fixed container. Preload fonts so text does not reflow when the custom font swaps in. CLS is often the cheapest of the three to fix — frequently a handful of attributes rather than an architectural change.

Are they worth the effort?

Let us be straight about this, because plenty of agencies overstate it. Core Web Vitals are a Google ranking factor, but a modest one — relevant, genuinely useful content matters far more. Passing them will not vault a thin page to the top of a competitive term. If ranking is your goal, the vitals are a supporting act; the real work sits within technical SEO and content, and they fit inside the wider picture we cover in what technical SEO actually is.

The stronger argument is commercial, not algorithmic. Fast, stable pages keep people on the site and convert more of them — a fact that holds true whether or not Google is watching. A page that loads in 2 seconds and never jumps under a thumb simply earns more enquiries than one that stutters and shifts. That is the real return, and it is why we build every website to pass from day one rather than patching vitals in later.

If your Search Console is full of red and you would rather someone diagnosed exactly what is dragging your scores down — lab versus field, and which of the three is the real culprit — get in touch and we will take an honest look at where your pages actually stand.