Core Web Vitals: what actually matters

Core Web Vitals generate more wasted effort than almost anything else in technical SEO. Businesses spend real money chasing a green score, and the score was never the objective.

The metrics measure something genuine — whether your site is unpleasant to use — and that is worth caring about regardless of search. But the relationship between the number and your rankings is much weaker than the industry's attention to it implies.

What the three actually measure

Largest Contentful Paint

How long until the main thing on the page appears. Usually the hero image or the headline block. This is the one users feel most directly, and it is the one most worth fixing.

Interaction to Next Paint

How quickly the page responds when someone taps or clicks. A page that looks loaded but ignores taps for a second scores badly here, and it is the most irritating failure to experience on a phone.

Cumulative Layout Shift

How much the content jumps around while loading. The cause is almost always images or embeds without reserved space, or a banner injected above content after render. It is the cheapest of the three to fix and the most likely to make someone tap the wrong thing.

Field data is what counts

The most common mistake: optimising against a lab tool. PageSpeed Insights runs a simulated test on a simulated device, and it is useful for diagnosis. The data that is actually used is field data — real measurements from real visitors on their real phones and connections.

A site can score poorly in the lab and pass in the field, or the reverse. Check the field section of the report, and Search Console's Core Web Vitals report, before deciding you have a problem at all.

A perfect score is not the goal

Passing the thresholds is the goal. Beyond that, the returns fall away sharply — going from a passing grade to a perfect one is engineering effort that would produce more value spent almost anywhere else.

It is also a ranking factor of modest weight. Between two closely matched pages it can matter; it will not lift a page that does not deserve to rank, and no amount of speed compensates for a page that does not answer the query.

Where the problem usually is

In practice, on a typical UK business site, in roughly this order:

• Images — uncompressed, wrong format, and far larger than the space they are displayed in. Usually the single biggest win, and often the easiest.
• Third-party scripts — chat widgets, analytics, heatmaps, consent tools, marketing tags. Each one is small, and collectively they dominate the load on many sites. Audit what is actually there; there are routinely tags for tools nobody uses any more.
• Web fonts — loading several weights of two families, blocking text from appearing while they arrive.
• Page builders — some popular WordPress builders generate markup so heavy that no amount of tuning fixes it. Occasionally the honest answer is that the platform is the problem.
• Hosting — cheap shared hosting produces a slow initial response that no front-end work can recover.

Do this before anything clever

Compress the images and serve them at display size. Remove the third-party scripts nobody uses. Reserve space for images and embeds so the layout stops jumping. Load the video embed only when someone asks for it rather than on page load.

That list resolves most sites, costs comparatively little, and is worth doing before anyone proposes a rebuild. We do this as site speed work, and it overlaps considerably with accessibility, because a page that is fast and stable is easier for everyone to use.

The reason worth caring

Not the ranking factor. A slow site loses people before they see anything, and on a phone on mobile data that happens in seconds. Every measurement of this points the same way: the visitors who leave because a page was slow are lost silently, without a bounce you would ever attribute to the cause.

Fix it because more of the people you already attract will stay. Treat any ranking benefit as a bonus.