Core Web Vitals explained: LCP, INP and CLS

Core Web Vitals sound more intimidating than they are. Strip away the acronyms and they answer three questions a visitor asks without thinking: did the page load quickly, did it react when I tapped something, and did it stay put while I read it? Google turned those three instincts into measurable metrics, started using them as a ranking signal, and in doing so made page experience a business concern rather than a purely technical one.

What Core Web Vitals actually are

Core Web Vitals are a small set of user-experience metrics that Google publishes and updates as part of its wider page-experience signals. They exist because a page can rank on relevance yet still feel broken — slow to paint, laggy to touch, jumping around as adverts and images load in late. Rather than measure raw server speed, the Vitals measure the experience the visitor perceives. There are three of them, and Google gives each a clear threshold.

LCP — Largest Contentful Paint (loading)

LCP measures how long it takes for the largest visible element — usually a hero image, a headline or a big block of text — to render. It is the closest single number to "when did this page feel loaded?" Google's published threshold is 2.5 seconds or less for a good score, 2.5 to 4 seconds for "needs improvement", and anything over 4 seconds as "poor". Note that this is measured at the 75th percentile of visits, so a handful of fast loads will not rescue a page that is slow for most people.

INP — Interaction to Next Paint (responsiveness)

INP measures responsiveness: when someone taps a button, opens a menu or types into a field, how long before the page visibly reacts? It captures the worst-feeling interactions across a whole visit, not just the first one. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024, because FID only looked at the delay before the first interaction and missed everything a user did afterwards. Google's threshold for a good INP is 200 milliseconds or less, with 200 to 500ms needing improvement and above 500ms considered poor.

CLS — Cumulative Layout Shift (visual stability)

CLS measures how much the page moves around unexpectedly while it loads. If you have ever gone to tap a link and an image loading in above it shoved the button down so you hit the wrong thing, that is layout shift. CLS is a unitless score rather than a time: Google counts 0.1 or less as good, 0.1 to 0.25 as needs improvement, and above 0.25 as poor. It is the cheapest of the three to get right and the one most often ignored.

Field data versus lab data

This is where most confusion starts. There are two ways to measure the Vitals and they do not always agree. Field data comes from the Chrome User Experience Report (CrUX) — anonymised measurements from real Chrome users on real devices and connections over the previous 28 days. This is what Google actually uses for ranking, and what shows up in Search Console. Lab data comes from tools like Lighthouse and PageSpeed Insights, which load the page once in a controlled environment. Lab data is invaluable for debugging because it is repeatable, but it is a simulation. A page can score 100 in Lighthouse and still fail in the field if your real visitors are on mid-range phones and patchy mobile networks — which, in a mobile-first market, most of them are. When the two disagree, the field data is the one that counts.

Common causes and how to fix them

The good news is that most failing sites fail for the same handful of reasons, and none of them are exotic:

• Oversized, unoptimised images are the usual cause of a slow LCP. The fixes are dull and effective: serve modern formats like WebP or AVIF, size images to the space they occupy, compress them properly, and lazy-load anything below the fold while eagerly loading the hero. This overlaps heavily with on-page and technical SEO work.
• Render-blocking resources — CSS and JavaScript that the browser must fetch and process before it can paint — delay LCP. Inlining critical CSS, deferring non-essential scripts and trimming unused code all help.
• Images and embeds without dimensions are the classic CLS culprit. When the browser does not know how tall an image will be, it reserves no space, then reflows the page when the image arrives. Setting explicit width and height attributes (or a CSS aspect-ratio) reserves the space up front and the shift disappears.
• Heavy JavaScript is what wrecks INP. When the main thread is busy parsing and executing a large bundle, it cannot respond to taps. Breaking work into smaller tasks, removing unused libraries and being ruthless about third-party scripts is usually where the gains are.

Why this is an SEO and conversion issue, not just a developer's

It is tempting to file Core Web Vitals under "engineering" and move on. That is a mistake for two reasons. First, they are a genuine ranking signal — a slow, unstable page caps the return on every other bit of SEO you fund, because Google is measuring the experience your competitors may already be winning. Second, and more importantly, the same friction that hurts your Vitals hurts your revenue directly: people abandon pages that load slowly, and they do not convert on ones that jump around under their thumb. Page experience is a leak in the bucket, and pouring more traffic in only empties it faster.

This is exactly why we treat performance as an SEO problem rather than a hand-off. When we build and engineer sites, the standard we hold ourselves to is under 2.0 seconds for mobile LCP and 95-plus on PageSpeed — deliberately tighter than Google's pass mark, because "good enough for the algorithm" and "fast enough for a paying customer" are not the same bar. Hitting the threshold is the floor, not the goal.