Measuring a website: Core Web Vitals without the jargon

A “fast” site does not mean much. Fast to load, to respond, to read without the text jumping around? So that the discussion rests on something other than impressions, Google defined a small set of measures called Core Web Vitals, which aim to summarise what a visitor really feels. There are three of them, and they are simpler than they look.

The three measures

LCP: when the main content appears

Largest Contentful Paint measures the moment the largest visible element of the page, most often the main image or a big headline, is displayed. It is a good approximation of the instant the visitor feels that the page is there. The published threshold for considering the result good is 2.5 seconds or less.

INP: responsiveness when you interact

Interaction to Next Paint observes all the interactions of a visit (clicks, taps, keyboard input) and keeps a value close to the worst: the delay between the gesture and the moment the screen updates. In 2024 it replaced the previous measure, which only looked at the very first interaction. A good result is 200 milliseconds or less.

CLS: layout stability

Cumulative Layout Shift measures how much elements move unexpectedly during loading. Everyone has had that moment of about to click a button when a late-loading image pushes it down. The score has no unit, and a good result is 0.1 or less.

These thresholds are assessed at the 75th percentile of real visits: for the page to count as good, three visitors out of four must have an experience at least as good as the threshold. A site with an excellent average but where a quarter of visitors, often on mobile, wait a long time does not pass.

Lab or field: two different answers

This is the most frequent source of confusion. There are two ways to measure, and they do not answer the same question.

• Lab measurements load the page in a controlled environment, with a simulated device and connection. Lighthouse is the well-known example. They are reproducible, ideal for debugging and comparing a before and an after, but they do not tell you what your visitors experience.
• Field measurements collect values from real visits, with their very varied devices and networks. The Chrome User Experience Report, fed by the browsers of consenting visitors, is the public source, and you can also collect your own measurements with the web-vitals library.

The two often diverge. An excellent Lighthouse score on your development computer and a mediocre experience on an entry-level phone over 4G are not contradictory: they measure different things. The lab serves to understand and fix, the field to know whether you succeeded.

The tools, and what they are for

• PageSpeed Insights displays both field data, when there is enough for your address, and a lab test.
• Lighthouse, in Chrome’s developer tools, for a detailed diagnosis and improvement leads.
• The Performance panel of the same tools, to see precisely what keeps the browser busy and when.
• The Search Console Core Web Vitals report, which groups your pages by type of problem.
• The `web-vitals` library, to send your own field measurements to the analytics tool of your choice.

Improving LCP

LCP is almost always a matter of the main image or of server response time. A few leads, in the usual order of effectiveness:

1. Do not delay the main element. An image at the top of the page must never be lazy-loaded: lazy loading is for what is off screen. You can give it high priority with fetchpriority="high".
2. Serve an image at the right size, in a modern format such as WebP or AVIF, with variants declared through srcset so that mobile does not download the large-screen image.
3. Reduce server response time: caching, efficient server-side rendering, delivery from a point close to the visitor.
4. Do not block rendering with bulky stylesheets or scripts loaded before the content.
5. Preload the font used by the main headline, or keep it from delaying the text with font-display: swap.

Improving CLS

Nearly all layout shifts have the same cause: the browser does not know how much room to reserve. The remedies are cheap.

• Declare the width and height of every image and video, or use the CSS aspect-ratio property, so the space exists before loading.
• Reserve room for ads, embeds and banners, instead of inserting them above content that is already displayed.
• Choose fallback fonts with metrics close to the final font, to limit the jump when it arrives.

Improving INP

INP degrades when the browser is busy at the moment the visitor acts. The culprit is almost always JavaScript that is too long or too plentiful.

• Ship less JavaScript. The fastest task is the one you do not run. A site that mostly displays without script starts with a considerable lead.
• Split long tasks so the browser can respond to a click between two chunks.
• Lighten the visible reaction to a gesture: show the expected feedback first, do the heavy work afterwards.
• Examine third-party scripts (analytics, widgets, chat), which often weigh more than the site’s own code.

The measurement traps

A single score is a poor compass: Lighthouse’s overall rating is a weighted summary that can rise while a real visitor’s experience does not change. Look at the three measures separately, and on mobile first, because that is where the gaps widen. Lab results vary from one run to the next: repeat the test before concluding that a change had an effect.

A metric optimised without looking at the visitor ends up measuring the optimisation.

Where to start

Choose the page that matters most, often the home page or a widely read article. Measure it in the lab to find what weighs, fix one thing at a time, then verify in the field after a few weeks, the time for data to build up. Then keep a simple budget, for example a limit on JavaScript weight and a maximum image size, checked automatically on every change, so that the gains are not lost at the next addition.