Core Web Vitals: making a site genuinely fast
Speed isn't a luxury: it's a Google ranking factor and a conversion driver. A breakdown of the Core Web Vitals — LCP, INP, CLS — and the concrete levers I use to keep them in the green.
"Works fine on my machine" isn't enough
The classic trap: the developer tests on fiber, a recent MacBook, with a warm cache. The real user, meanwhile, arrives on a mid-range phone, on flaky 4G, with an empty cache. Between the two, the experience has nothing in common.
The Core Web Vitals exist to measure what the user actually experiences. Google made them a ranking factor — and above all, they predict conversion: every extra second of loading drives visitors away.
The three metrics that matter
- LCP (Largest Contentful Paint) — the time before the main element (often the hero image or heading) appears. Target: under 2.5s.
- INP (Interaction to Next Paint) — responsiveness: the delay between a click and the visible response. Target: under 200ms. It's the crux on JavaScript-heavy sites.
- CLS (Cumulative Layout Shift) — stability: those layout jumps that make you click in the wrong place when an image or ad loads. Target: under 0.1.
A beautiful slow site is a failed site. Performance isn't the enemy of design — it's a constraint that forces clean choices.
The levers I use
Making a site fast is nothing magical, it's a sum of decisions:
- Images — modern format (AVIF/WebP), correct dimensions,
lazy loadingbelow the fold, and reserved space to avoid jumps (CLS). - Fonts —
font-display: swap, preloading the weights actually used, and above all: loading only those. - JavaScript — ship as little as possible. The fastest code is the code you don't send to the browser. Server components, deferred loading of the non-critical.
- Rendering — favor static (pre-generated at build) when the content allows: nothing beats a file that's already ready.
- Continuous measurement — a performance budget and monitoring (Lighthouse, Speed Insights) so a regression is seen before production, not after.
Measure in the field, not the lab
There are two ways to measure: lab data (Lighthouse, a controlled environment) and field data (real users, via the Chrome UX Report). Both are useful, but only the second reflects reality. A site can score 100 in the lab and disappoint in the field because of a slow connection or a modest device.
My discipline: optimize in the lab to go fast, but validate in the field before declaring victory.
Why it matters for a client
A fast site isn't just a technical flourish. It's more visitors who stay, better Google rankings, and more conversions. Speed is one of the rare improvements that serves the user, the ranking and the revenue all at once. That's why I treat it as a requirement, not a bonus.