Core Web Vitals: the three metrics that count

Everyone says their site "feels fast". Google does not have an opinion: it measures. And what it measures is three specific things, each with a name and a number you can check today.

They are called Core Web Vitals, and they are Google's way of putting figures on something as vague as "this page feels good". They do not replace having useful content — that still wins — but they do explain why a visitor leaves before reading you.

The three metrics that count

There are dozens of performance measurements. Only three are Core Web Vitals, and each answers a different question the person who just arrived is asking:

LCP (Largest Contentful Paint) — "has it loaded yet?". How long the largest thing on screen takes to appear: usually the main image or the headline. Good is under 2.5 seconds.
INP (Interaction to Next Paint) — "is it responding?". How long the page takes to react when you tap something. Good is under 200 milliseconds. It replaced the old FID, which only looked at the first click.
CLS (Cumulative Layout Shift) — "has it stopped moving?". How much the content jumps around while loading. It is the one that makes you reach for a button and get an ad under your finger instead. Good is under 0.1.

What nobody tells you

Speed is a ranking signal, but a small one. A slow page with the answer someone wants beats a lightning-fast one without it. Fix this so you stop losing the people who already arrive, not expecting it to lift your position on its own.

What makes each one worse

It is nearly always the same causes, and hardly any of them are mysterious:

Slow LCP: a huge uncompressed hero image, a server that is slow to answer, or stylesheets and scripts that block rendering before anything is visible.
High INP: too much JavaScript occupying the main thread. Usually third-party scripts — chat widgets, heatmaps, tracking pixels — piled up over the years.
Bad CLS: images with no width and height, ads or banners injected late that push the text down, and web fonts that resize everything when they load.

Nobody suffers CLS less than the search engine and more than the person trying to tap a button that moves.

Where to start

Ordered by what usually improves most for the least effort:

Give images dimensions. A width and height (or an aspect-ratio) on every image and iframe lets the browser reserve the space before downloading it. It is the cheapest CLS fix there is.
Compress the hero image and serve it in a modern format like WebP or AVIF. Lazy-load the ones further down, but never the hero: that is the very thing LCP measures.
Reserve room for whatever arrives late: cookie banners, ads, widgets. If the space is already there, nothing shifts.
Remove the JavaScript you no longer use. Go through the third-party scripts you added over time: many are still loading for a campaign that ended two years ago.
Look after your fonts: font-display: swap plus preloading the main face avoids that jump when the text changes typeface.

How to measure it properly

Here is a distinction that trips a lot of people up. There is lab data (a simulation on a fixed connection and device) and field data (what your real visitors actually experienced over the last 28 days). Google uses field data for ranking.

That is why a page can score well on a test and still have Core Web Vitals in the red: the test ran on a fast machine while your visitors arrive on a phone with poor signal. Always look at the field data, and measure on mobile, which is where almost everything falls down.

An audit with Screaming Cow shows you these three metrics alongside the rest of the analysis, so you see performance in the same place as the broken links and the titles, rather than in a separate tab you never open.

These look at one page

An audit crawls the whole site and reports what is wrong across every page it finds.

Audit a site

The Screaming Cow team

We write about what we see crawling pages: what breaks, why, and how to fix it.