Key answer: Core Web Vitals are Google's three user-experience metrics. They are LCP (main content load, target < 2.5 s), INP (interaction response, target < 200 ms) and CLS (layout stability, target < 0.1). They influence search rankings, and every second of delay measurably lowers conversion – speed is a sales function, not cosmetics.
Table of contents
The short answer
Core Web Vitals are the three measures Google uses to judge how a page feels: LCP (how quickly the main content appears; target < 2.5 s), INP (how quickly the page reacts to clicks; target < 200 ms) and CLS (whether the layout jumps; target < 0.1). Poor scores cost you twice: search positions, and abandonments after people arrive.
Speed is money – literally
Industry research has shown the same relationship for years: each extra second of load time cuts conversion by several to a dozen percent, and a large share of mobile users abandon pages that take more than ~3 seconds. The mechanism is mundane: waiting hurts, and the competition is one click back.
There is also a psychological trust threshold: a site that lags and jumps leaves the visitor thinking "nobody here cares about details" – a terrible message when you're asking for card details or a project enquiry.
The three metrics in plain words
LCP (Largest Contentful Paint): time until the largest element in the viewport renders (usually the hero image or headline). It is the moment the user feels "the page is here". Usual culprits: heavy images, slow servers, render-blocking scripts and fonts.
INP (Interaction to Next Paint): the delay between an interaction (click, keystroke) and the screen's response. It measures sluggishness. The culprit is almost always the same: too much JavaScript on the main thread.
CLS (Cumulative Layout Shift): the sum of layout jumps. You know it: you aim for a button and the content slides away because a banner loaded. Culprits: images without declared dimensions, injected ads and notices, fonts swapping with a jolt.
What genuinely improves the scores
- Images: AVIF/WebP formats, sizes matched to the screen (
srcset), lazy-loading below the fold, always with dimension attributes (this also cures CLS). - JavaScript: less of it. Audit third-party scripts (chats, pixels, maps – each one costs), defer loading, choose an architecture that serves HTML instead of rendering everything in the browser.
- Fonts: self-hosting,
font-display: swap, fewer weights. - Server and CDN: fast hosting, caching, serving from a location near the user.
- Architecture: the fundamental decision matters most – static or prerendered sites (e.g. Astro) start with scores that classic CMSs approach only with a stack of plugins. This site is an example, with green Core Web Vitals by design, not by patching.
Where to start
Measure (PageSpeed Insights + Search Console), fix in order of impact (usually: images → third-party scripts → fonts → server), measure again. And when commissioning a new site – put the requirement in the brief: "a full set of green Core Web Vitals on mobile", and write it into the contract. Cheaper than repairs after the fact.
We build websites with performance built in from the start – see how.