Core Web Vitals, explained for the person who has to fix them

Core Web Vitals get explained badly because they get explained by the people who measure them. What follows is the version for the person who has to go and change something.

There are three, they are each about a different kind of frustration, and each one points at a different part of the site.

Everything below is about which part of the site each number is accusing.

LCP: what the largest element usually is

LCP asks a simple question. From the moment the page starts loading, how long until the biggest visible thing has finished drawing?

That biggest thing is almost always your hero image. Sometimes it is a heading, occasionally a video poster. PageSpeed Insights will name it explicitly, and that is the first thing to look at, because it tells you what you are actually fixing.

When LCP is bad, it is one of four things, roughly in order of how often I see them:

The image is too big. Not visually: in bytes. A hero at three times the width it renders at is a download the visitor is waiting through.

The image is discovered late. The browser cannot fetch what it has not found. An image loaded by JavaScript, or set as a background on a class the stylesheet has to resolve first, is found later than one in an img tag in the HTML.

It is lazy-loaded. A hero marked lazy tells the browser not to hurry over the one thing the metric is measuring.

Something is blocking the render. A stylesheet or a synchronous script in the head that the browser must finish before it draws anything.

LCP is the one most worth fixing first, because it is the most fixable and because it is what a visitor experiences as "the site is slow".

INP: why it replaced FID

INP replaced First Input Delay in 2024, and the change is worth understanding because it made the metric much harder to pass.

FID measured the delay before the browser started responding to the first interaction. It was generous: it only looked at the first one, and it only measured the delay before processing began, not whether anything appeared afterwards.

INP measures all interactions through the visit, and it measures the whole path: tap, processing, and the next frame actually being painted. A button that acknowledges the tap in 40ms but takes 600ms to show the panel it opened scored well on FID and scores badly on INP, correctly.

Which is why the fix is usually not in the Designer. It is the chat widget, the testing tool, the session recorder, the tag manager firing six things on load. The work is deciding which of them needs to be there before the visitor has done anything, and the honest answer is usually one or two.

CLS: the causes nobody expects

CLS measures how much the page moved after you could see it. It is the metric behind the experience of reaching for a link and having something load above it, pushing the link away.

Four causes, and the first two are most of it.

Images with no dimensions. The browser does not know how tall the picture is until it arrives, so it reserves no space and everything below jumps when it does. Setting width and height attributes fixes this entirely, and it is a five-minute job.

Web fonts swapping. The fallback font is a different size, so when the real one loads every line of text reflows. Less visible than an image jump and it counts.

Anything injected at the top of the page. Cookie banners, announcement bars, "you are on the US site" prompts. Each one is a block of content inserted above everything else, after everything else has drawn.

Ads and embeds with no reserved space. Same problem as images, harder to control, and the fix is the same: reserve the space in the layout before the thing arrives.

CLS is the cheapest of the three to fix and the one most often ignored, because unlike the other two it does not make the site feel slow. It makes it feel unreliable, which is worse and harder to attribute.

What to fix first

If you are looking at three red numbers and one afternoon, here is the order.

Image dimensions. Fixes CLS, costs nothing, cannot break anything.

The hero image. Resize it, serve it from an Image element, make sure it is not lazy-loaded. Fixes most of LCP.

Audit the third-party scripts. Find the two that need to be on load and defer the rest. Fixes most of INP, and is the only one of the four that requires a conversation with somebody rather than a change.

Everything else. Font weights, render-blocking CSS, the long tail.

One thing to be clear about: these are measured from real visits, in Chrome, over a rolling 28-day window. A change you ship today does not show up in the field data tomorrow. PageSpeed's lab number moves immediately, which is how you confirm the fix worked; the field number is what Google actually uses, and it takes weeks to catch up. Do not conclude a fix failed because the scorecard did not move in a week.

Why your Webflow site is slow goes through the causes in more detail on the Webflow side, and the performance page shows what this site's own numbers are.