Core Web Vitals, explained without the jargon

Core Web Vitals sound like a compliance exercise. They are not. They are three attempts to measure feelings that everyone has had on a slow website, and once you see them that way the fixes stop being mysterious.

Largest Contentful Paint: how long until it looks loaded

LCP measures how long it takes for the biggest thing on the first screen to appear. Usually that is a hero image or a headline. The target is two and a half seconds on a mid-range phone.

The most common cause of a bad score is not server speed. It is an oversized hero image, frequently a four thousand pixel wide photograph rendered at four hundred pixels. Serving it at the width it actually displays, in a modern format, routinely takes several seconds off on its own.

The second most common cause is a font. If your headline waits for a web font to download, LCP waits with it. Showing a fallback face immediately and swapping when the real one arrives fixes it, at the cost of a flicker most visitors never notice.

Interaction to Next Paint: how long until it responds

INP measures the delay between a tap and something visibly happening. Target is two hundred milliseconds. This is the metric that captures the feeling of tapping a button twice because nothing happened the first time.

The usual culprit is the browser being busy running code while you are trying to use the page. Third-party scripts are the biggest offenders in our experience: a tag manager loading four analytics tools and a chat widget can eat a full second of a phone's attention on load. Audit what is on the page and delete what nobody looks at. Half of it is usually a tool somebody trialled two years ago.

Cumulative Layout Shift: how much it moves under your finger

CLS measures content jumping around as the page loads. It is the reason you have tapped the wrong link because an advert appeared above the one you wanted.

Almost all of it comes from elements that arrive without a reserved space: images without dimensions, banners injected at the top, fonts that swap to a different size. Reserving the space in advance costs nothing and fixes nearly every case.

What we do on a build

We set a performance budget before design starts, and it is a real constraint rather than an aspiration. If a proposed hero animation costs three hundred kilobytes, it has to displace something or it does not ship.

Then we test on a mid-range Android on a throttled connection, not on a laptop on office wifi. That gap is where most performance work quietly fails.

Does it move rankings?

Honestly, less than the people selling performance audits imply. It is a tiebreaker between pages that are otherwise similarly relevant, not a substitute for being relevant. Where it clearly does pay is conversion: on the catalogue rebuild we did for a furniture studio, pages per session roughly doubled after the load time dropped, and none of that was ranking. People simply stayed.