Website speed: Core Web Vitals explained

01Three seconds in a parking lot: why speed matters

Someone is sitting in their car, in the parking lot in front of your shop, and wants to know if you are open. They open your website on their phone, with two bars of signal. The screen stays white. Then a huge image appears, then the text, then a cookie box that pushes everything down just as they tap «Opening hours»: they have tapped «Offers». They go back and open a competitor's listing. Three seconds, and you have lost a customer who was already at your door.

This is exactly the experience Google decided to measure with three numbers, the Core Web Vitals, the «vital signs» of a web page. They do not measure how beautiful a site is or how rich: they measure three precise moments in the experience of the person visiting it.

• Can I see something useful? LCP measures it.
• If I tap, does it respond? INP measures it.
• Does it stay still, or does it slip out from under my finger? CLS measures it.

Google openly recommends having good Core Web Vitals and considers them part of the page experience its systems reward. But it is honest about the other side too: the search engine always tries to show the most relevant content, even when the experience is not perfect. In other words: speed does not replace good content, but with equal content it makes the difference, and above all it makes the difference with people, who are the ones who buy.

In the chapter on web infrastructure I explained TTFB, the time the server takes to start responding. Here we look at everything that happens after, inside the browser: that is where most of the three numbers are decided.

02The three metrics and their thresholds

Each metric has three bands: good, needs improvement and poor. Google publishes the thresholds in its developer guide, and they are the same for every site, from the neighborhood shop to the big portal.

Why 75%, and not the average

The average hides problems: ten lightning-fast visits from the office computer cover up three disastrous visits from a budget phone in the countryside. The 75th percentile is stricter and fairer: it says that three visitors out of four had an experience at least that good. To pass, it is not enough for the site to work well for you; it has to work well for almost everyone, including people with a phone that is a few years old and a patchy connection.

03LCP: when the content that matters appears

LCP (Largest Contentful Paint, the largest piece of content painted) measures when the largest element visible on opening appears on screen: usually the main image, or the largest block of text, such as the title with the opening paragraph. It is the moment when the visitor thinks «there, it has arrived».

For LCP, what counts are images, background images loaded from CSS, video posters and blocks of text. A vector drawing written directly into the page, on the other hand, is not a candidate. The time is counted from when the page starts loading, so LCP includes everything: waiting for the server, downloading the files, painting.

The most frequent causes and the fixes

• Images that are too heavy. A photo taken with a phone easily weighs a few megabytes; on a phone screen a few hundred kilobytes are enough. You resize it to its real display size, compress it, use modern formats such as WebP or AVIF, and offer different sizes for different screens.
• The «lazy» main image. Deferred loading (loading="lazy") is great for images at the bottom of the page, but on the image at the top it delays LCP itself. That one must load right away, in fact it should be announced with high priority.
• Blocking CSS and fonts. Until the browser has downloaded the stylesheets it paints nothing. Few files, small ones, and fonts loaded so that the text shows immediately with a fallback font.
• A slow server. If TTFB already eats up a second, the rest has little margin: that is the part I cover in the chapter on infrastructure.
• Content built by JavaScript. If the main text appears only after a script has downloaded and assembled it, LCP waits for the script. The important content must arrive already written in the page.

04INP: does the page respond when you tap it?

Have you ever tapped «Add to cart» and seen nothing happen, tapped it again, and ended up with two products? That half-feeling of «has it frozen?» has a name: INP (Interaction to Next Paint, from the interaction to the next paint).

INP observes all the clicks, taps and key presses during the visit, and measures how much time passes from each one to the moment the screen shows the reaction. The final value essentially represents one of the slowest interactions of the visit. Under 200 milliseconds the page feels instant; over 500 it feels broken.

The enemy is called a «long task»

The browser has a single main thread to run JavaScript and paint the page. If a script occupies it for a long stretch (we speak of long tasks when they exceed 50 milliseconds), the user's tap waits in line. The usual culprits:

• too many third-party scripts: chats, counters, social widgets, ads, each with its own weight;
• page builders and dozens of plugins that load their code on every page, even where it is not needed. That is the topic of the chapter on the value of a professional developer;
• code that does everything at once: calculations, animations and loads started on opening, instead of when they are needed;
• huge pages, with thousands of elements to recalculate at every change.

The fixes follow: fewer scripts, loaded only where needed and after the content; tasks broken into small pieces that let the browser breathe; an immediate visual response to the tap (even just the button lighting up) before the heavy calculations.

05CLS: the page that slips out from under your finger

CLS (Cumulative Layout Shift) measures how much the visible content moves without you having done anything. It is the most irritating flaw of the three, because it makes you make mistakes: you read a line and it slips away, you want to tap a button and you tap the one that has just moved into its place.

How it is calculated, in simple words

Each shift gets a score made of two factors multiplied together: how much of the screen is affected and how far the elements moved relative to the size of the screen. Google's guide gives this example: if the unstable elements take up 75% of the screen and move by a quarter, the score is 0.75 × 0.25 = 0.1875. On its own, already over the good threshold of 0.1.

Shifts that are close in time are added together into «bursts» (with less than one second between one and the next, for a maximum of five seconds), and the page's CLS is the worst burst. Two important details:

• shifts that happen within half a second of a tap or key press of yours do not count: if you open a menu and the content moves, it is a reaction you expect;
• animations made with transforms (moving or enlarging an element without changing the surrounding layout) do not produce shifts: they are the right way to animate.

The fixes, almost all free

• Always give images a width and a height (or an aspect ratio in the CSS): the browser reserves the space even before downloading them.
• Reserve the space for everything that arrives later: banners, embedded maps, videos, reviews loaded from other services.
• Do not insert content above what the user is already looking at, unless they asked for it.
• Load fonts with care, choosing fallback fonts of a similar size, so that switching from one to the other does not move the lines.

06Lab and real world: two ways of measuring

«I ran the test and it gives me 98, so why does Google say the site is slow?» It is one of the questions I hear most often, and the answer is that you are looking at two different things.

How to read PageSpeed Insights in three steps

1. Look at the top part first, the real data: it tells you whether the page passes the Core Web Vitals assessment. If it says there is not enough data, the page has few visits and you look at the figure for the whole site.
2. Choose the mobile tab: for a local business it is almost always the device of the majority, and the strictest.
3. Use the lab for the causes: the diagnostics section lists images to reduce, blocking scripts and shifts, with the files responsible.

07The work plan: where to start

Improving Core Web Vitals is not a contest of tricks. It is orderly work, which starts from what weighs most and measures every step.

For a local business, speed on mobile matters even more: people searching «near me» almost always do it on the move, and choose in a few seconds. That is the topic of the chapter on local SEO. And if the site also needs to become an app to keep on the phone, the Core Web Vitals are the foundation for building a PWA that opens like a real app.

Frequently asked questions

Sources

1. web.dev (Google), «Web Vitals»: the three metrics, the thresholds and the 75th percentile.
2. web.dev, «Largest Contentful Paint», «Interaction to Next Paint» and «Cumulative Layout Shift»: definitions, bands and how the score is calculated.
3. web.dev, the announcement of March 12, 2024: INP replaces FID.
4. Google Search Central, «Understanding Core Web Vitals and Google search results» and «Page experience».
5. Chrome for Developers, CrUX report methodology: who is counted and which pages.
6. web.dev, guides to optimizing LCP, INP and CLS.

Chapter updated in October 2026. Thresholds and definitions come from Google's official documentation; the timings in the plates are examples to show the proportions, not measurements of any particular site.