Core Web Vitals are three metrics with unhelpful names that between them measure whether a page feels fast, responds when touched, and stays still while you read it. Here is what each one is actually measuring, and — more usefully — which fixes are worth spending developer hours on.
LCP: how long until the main thing appears
Largest Contentful Paint measures the time until the biggest visible element in the viewport has rendered. In practice that is almost always a hero image or a headline.
It is a good proxy for the honest question a visitor is asking, which is not “has the page technically begun loading” but “can I see the thing I came for yet”. Bad scores usually trace to one of three causes: an oversized, uncompressed hero image; render-blocking CSS or fonts sitting in front of it; or a slow server response before anything can start.
INP: how quickly the page responds when you touch it
Interaction to Next Paint replaced First Input Delay, and it is a stricter measure. Rather than timing only the first interaction, it looks at the delay between an interaction and the page visibly responding, across the whole visit.
Poor INP is nearly always JavaScript occupying the main thread. The browser cannot repaint because it is busy, so the tap or click appears to do nothing, and the user taps again. This is the metric most likely to be quietly terrible on a site loaded with third-party tags.
CLS: how much the page jumps around
Cumulative Layout Shift measures content moving after it has already appeared. It is the reason you tap the wrong button because an ad loaded a half-second late and pushed everything down.
The usual causes are images and embeds without declared dimensions, content injected above existing content, and web fonts swapping in at a different size to the fallback.
CLS is the one users describe as “the site feels broken” without being able to say why.
Which fixes are actually worth it
Roughly in order of return per hour spent:
- Compress images properly and serve modern formats. This is usually the single largest win and requires no architectural change.
- Set explicit width and height on every image, video and embed. Cheap, fast, and it removes most CLS outright.
- Remove or defer JavaScript you are not using — particularly third-party tags nobody can remember adding.
- Self-host fonts and set a sensible font-display, so text renders immediately rather than waiting on a network request.
- Only then start on server response time and architectural changes, which cost the most and typically move the numbers least.
What they are worth for ranking
Less than the amount of attention they receive. Core Web Vitals are a tiebreaker, not a primary ranking factor. A faster page will not outrank a genuinely more relevant one, and no amount of optimisation substitutes for answering the query properly.
That is not an argument for ignoring them, because their real value is not in ranking at all. A slow, unstable page loses people before your content gets a chance to be relevant. Treat them as conversion metrics that happen to have a small SEO benefit, and the prioritisation becomes much clearer.
Field data, not lab data
Testing tools that produce a score on demand are running a simulation on a synthetic connection. Useful for debugging, but not what is assessed.
What counts is field data — measurements collected from real visits on real devices and real networks. It is the field number that matters, and it can differ substantially from the lab score, usually because your own device and connection are better than your average visitor’s.
Fix these because they are costing you customers, not because you are chasing a ranking factor. The ranking benefit is small and contested. The conversion benefit is neither.
