Core Web Vitals: getting a website that loads in under one second
LCP, INP, CLS: what Core Web Vitals actually measure, the right tools to audit them, and a concrete method for getting a website under one second of load time.
A website that takes more than three seconds to display loses a large share of its visitors before it even finishes loading. Google knows this, and turned it into an official ranking factor through three precise metrics: the Core Web Vitals. Here’s what they actually measure, how to audit them without trusting the first number you see, and the method for getting a site under one second.
What the Core Web Vitals actually measure
Three metrics, each with a “good” threshold to aim for:
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Time to display the largest visible element on screen | ≤ 2.5 s | ≤ 4 s | > 4 s |
| INP (Interaction to Next Paint) | Responsiveness to a click, tap, or keystroke | ≤ 200 ms | ≤ 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Visual stability during loading (elements that “jump”) | ≤ 0.1 | ≤ 0.25 | > 0.25 |
INP replaced FID (First Input Delay) in 2024: it no longer measures only the first response delay, but responsiveness across the whole visit. A site can respond quickly to the first click and get sluggish afterward; INP captures that case.
Why it matters this much
Two reasons, independent of each other. The first is search ranking: since 2021, the Core Web Vitals have been part of Google’s ranking signals. It isn’t the number one factor, but with equivalent content, it’s the tiebreaker between two competing pages.
The second, more concrete reason is visitor behavior. A slow site, or one where buttons dodge the click right when you tap them, generates drop-off and forms that never get submitted. On mobile, with a less stable connection and a less powerful processor, these flaws are amplified — that’s often where the difference is made between a visitor who stays and one who leaves.
The tools to know where you stand, before touching anything
Before fixing anything, you need to measure correctly, which means telling apart two kinds of data:
- Lab data (Lighthouse in Chrome DevTools, PageSpeed Insights in “diagnostics” mode): a one-off simulation, on a standardized device and connection. Useful for debugging, but not what your real visitors experience.
- Field data (the “Discover what your real users are experiencing” tab in PageSpeed Insights, or the “Core Web Vitals” report in Search Console): aggregated measurements from the last 28 days, taken on your visitors’ actual devices and connections. This is the only data that counts for Google’s ranking.
A site can score perfectly in the lab and still perform poorly in real conditions if most of its traffic comes from lower-end mobile devices. Always cross-check both before drawing conclusions.
The method: the levers that actually make a difference
Reducing LCP
Most of the gain comes from three settings: serving images in the right format (AVIF or WebP) and at the right size, not letting JavaScript block the rendering of the main content, and preloading the image or font that makes up the page’s largest visible element.
Stabilizing CLS
The most common cause is simple: images or videos without dimensions (width/height or aspect-ratio) set in advance, which push content around as they load. Reserving the space upfront eliminates nearly all visual shifts.
Improving INP
The real lever is the amount of JavaScript executed during load. It’s one of the principles I apply on my own projects, detailed in this article on Astro and GSAP: ship zero JavaScript by default, and only load interaction scripts once they actually become useful.
A concrete example: before / after
On a typical technical rebuild, starting from a site built on a generic theme overloaded with scripts, here’s the rough order of magnitude of the gains from starting over on a cleaner base:
| Metric | Before rebuild | After rebuild |
|---|---|---|
| LCP | 4.1 s | 0.9 s |
| INP | 340 ms | 110 ms |
| CLS | 0.22 | 0.01 |
This isn’t magic: it’s the result of a technical website rebuild that treats performance as a design constraint from the start, rather than a fix applied afterward.
What to take away
The Core Web Vitals aren’t a score to chase just to tick a Google box. They’re three concrete symptoms — slowness, instability, heaviness — that, once fixed, translate directly into visitors who stay and forms that get submitted all the way through.
Let’s talk about your project
If your site is piling up red signals in Search Console, or you simply want to start from a fast foundation from the design stage onward, send me a message: I can audit your current situation and tell you precisely what’s weighing down your performance.