Core Web Vitals: Why a Fast Site Wins

Speed is the one quality improvement where the business case needs no argument. A slow site loses people before they read a word, and the people it loses are disproportionately the ones on a phone, on mobile data, who found you from a search — in other words, new customers.

Google measures this with three numbers, collected from real Chrome users rather than a lab test. Here is what they are and what actually moves them.

The three numbers

Largest Contentful Paint (LCP) — how long until the biggest thing on screen appears. Usually a hero image or a headline. Good is under 2.5 seconds. This is the "is it there yet" metric and it is the one that matters most for whether someone stays.

Interaction to Next Paint (INP) — when someone taps or clicks, how long before the page visibly responds. Good is under 200 milliseconds. This replaced the older First Input Delay because it measures every interaction, not just the first, which turned out to be a much fairer picture.

Cumulative Layout Shift (CLS) — how much the page jumps around while loading. Good is under 0.1. This is the metric behind the universal experience of reaching for a button and having an advert push it out from under your thumb.

The threshold is that 75 percent of visits must hit "good". You are not being graded on your average; you are being graded on whether most people had a decent experience.

What usually breaks them

In our experience the causes are boringly consistent.

LCP is almost always images. A 3 MB photograph served at full resolution to a phone, with no modern format and no dimensions. The fixes are unglamorous: serve WebP or AVIF, size the image to what is actually displayed, mark the hero image as high priority and never lazy-load it, and lazy-load everything below the fold.

The second cause is render-blocking resources — a stylesheet or a font that the browser must fetch before it can paint anything. Self-hosting fonts and inlining the small amount of CSS needed for the first screen usually fixes it.

INP is almost always JavaScript. Too much of it, running on the main thread, blocking the browser from responding. The honest question for most small business sites is how much of that JavaScript is doing anything the visitor asked for. A carousel library, three tracking scripts, a chat widget and an animation framework can easily add up to a second of blocked main thread on a mid-range Android phone.

CLS is almost always missing dimensions. Images and iframes without width and height, web fonts that swap and reflow the text, banners injected at the top of the page after load, and content that expands when a script finishes. Reserve the space before it is filled and the problem disappears.

What actually moves the numbers

In rough order of return on effort:

1. Fix the hero image. Correct format, correct size, high priority, explicit dimensions. This one change frequently takes a failing LCP into the green on its own.
2. Delete JavaScript you are not using. Every removed script helps twice: less to download, less to execute. Start with the analytics and marketing tags nobody has looked at in a year.
3. Render on the server. If the page arrives as HTML rather than as an empty shell that JavaScript fills in, you have removed the largest single source of delay. This is the main reason we build with a server-rendering framework.
4. Self-host fonts, and load at most two weights. A third-party font request is a whole extra connection before any text can appear.
5. Reserve space for everything that loads late. Images, embeds, ads, cookie banners.
6. Serve from somewhere near your visitors. A Dutch business on a US server is paying a round trip on every request for no reason.

Measure it properly

Two tools, and the difference between them matters.

PageSpeed Insights gives you a lab score and, if you have enough traffic, the field data from real Chrome users. The field data is what counts for search; the lab score is a diagnostic.

Search Console has a Core Web Vitals report showing your real users grouped by page type. This is the one to trust, because it is measuring your actual visitors on their actual devices.

One warning worth repeating: do not chase the number 100. A lab score of 100 on a page that real users find slow is worth nothing, and the last few points usually cost more than they return. Get into the green on the field data and spend the remaining effort on content.

Is it really a ranking factor?

Yes, and it is worth being precise about how much. Core Web Vitals are part of Google's page experience signals. They are real but modest compared to relevance and content quality. A fast page about nothing will not outrank a slow page that answers the question.

Where speed genuinely decides things is between pages of similar quality — which is most competitive searches — and, far more importantly, in what happens after the click. Faster pages keep more of the people who arrive. That effect is much larger than the ranking effect, and it applies whether or not Google is watching.

The short version

Fix your images, delete the JavaScript you do not need, render on the server, and reserve space for anything that loads late. That is most of the work. Then measure with field data and stop when you are in the green, because the next thing you do with that hour will be worth more than another two points.