Core Web Vitals in 2026 — why speed is design, not optimization

Speed is not a phase of a project. It is the residue of decisions made in the first week, long before anyone opens a measurement tool.

Core Web Vitals are not an abstract score. Each one describes a specific moment in the experience of a real person waiting in front of a screen.

LCP — Largest Contentful Paint

The moment the largest visible element in the first viewport finishes rendering: usually the hero image, sometimes the headline block. Good is under 2.5 seconds. Past 4 seconds you are in the red. LCP does not ask how fast the server responded; it asks how fast something meaningful appeared.

INP — Interaction to Next Paint

The responsiveness metric that replaced FID. It measures the delay between an interaction — tap, click, keypress — and the next frame the browser paints, accounting for the worst interactions across a whole session rather than only the first. Good is under 200 ms. Poor is past 500 ms. This is the metric JavaScript punishes hardest: if the main thread is busy hydrating or running a third-party script, the finger presses into nothing.

CLS — Cumulative Layout Shift

How much the content jumps under that finger. Good is under 0.1. This is less a speed problem than a layout hygiene problem: images without declared dimensions, fonts that change text metrics on swap, banners injected above a paragraph someone is already reading.

All three are reported at the 75th percentile of real visitors, split between mobile and desktop. How the site feels on your laptop is irrelevant. What matters is the third visitor out of four, on a mid-range phone, on a mediocre network.

There is a widespread belief that performance gets sorted at the end, with an optimization pass. It does not. By the end of a project the expensive decisions have already been made, and they have become the visual identity of the site. Nobody cuts the hero a week before launch.

Three things are settled on day one:

• Image strategy. An 8 MB background video or an uncompressed 4 MB photograph over a mobile connection means seconds, not milliseconds. No amount of CDN configuration repairs an art direction decision that demands an enormous file above the fold.
• Fonts. Every family, every weight, every character set is another request on the critical path. Two families at two weights each is a healthy budget. Five weights plus a display face plus an accent face is a promise of poor LCP and jumping text.
• Layout stability. If the design includes a banner slot, a reviews widget or an embedded map, that space has to be reserved in the layout with fixed dimensions. Otherwise CLS is written into the design before it is written into the code.

A fast site is not achieved by cutting things at the end. It is achieved by choosing fewer things at the beginning.

The same logic applies to architecture. Choosing between server rendering and a heavy client application is a performance decision, not a matter of taste — the trade-offs are laid out in the piece on server components and architecture.

This deserves honesty rather than borrowed statistics. The mechanism is clear enough without percentages.

A waiting visitor has three options: wait, tap again, or leave. On mobile, where attention is fragmented and the back button sits a centimetre away, the third option is the cheapest one for them. Every additional second adds people who never got as far as the offer.

The cost then propagates:

• Paid traffic gets more expensive. You pay for the click whether or not the page loaded. A slow landing page converts ad budget into measured abandonment.
• Conversion erodes quietly. A form that freezes for a fraction of a second on every keystroke does not produce a complaint; it produces an abandoned form.
• Search position slips at the margin. Core Web Vitals are a real signal, but a secondary one. They do not beat content relevance. Between two comparable pages, though, the fast one wins — and infrastructure counts as much as copy, as the technical side of SEO shows.

The most common confusion in any performance conversation.

Lighthouse is lab: a simulation on an invented device and an invented network, producing a repeatable number. It is an excellent diagnostic instrument. It is not reality.

CrUX — the Chrome User Experience Report — is field: aggregated measurements from real users on their real phones and real networks, over a rolling 28-day window. That is what the search engine sees, and that is what counts.

The practical consequence: Lighthouse tells you why it is slow, CrUX tells you whether it is slow. Do not chase a score of 100. Chase a green 75th percentile on mobile across all three metrics. And be patient — field data moves in weeks, not hours, so a good deploy will not show up the next morning.

After enough audits, the list of culprits becomes boringly consistent.

• The hero image. Served without AVIF or WebP, without srcset, sometimes at retina resolution for a phone that does not need it. It is the number one cause of poor LCP.
• Web fonts. Loaded late, with no preload on the critical file, no sensible font-display, no fallback with matching metrics. The result is invisible text followed by a layout jump.
• The tag manager. One container through which six scripts accumulate over a year, none of them ever reviewed again. Each one eats main thread and degrades INP.
• Embeds and banners. Maps, video players, review widgets, consent boxes that appear a second late and shove the page downward. Guaranteed CLS.
• Excessive hydration. Pages where nine tenths of the content is static, yet the entire tree becomes interactive on load.

• Set a performance budget before design starts: maximum weight above the fold, maximum number of fonts, an approved list of third-party scripts.
• Serve the hero in a modern format, sized per breakpoint, with width and height declared and a preload on the critical variant.
• Reserve space for everything that loads asynchronously, using aspect-ratio or min-height.
• Defer every third-party script not required for the first frame, and demand a justification for each new one.
• Move work off the main thread: ship less JavaScript, make components interactive only where interaction actually happens.
• Monitor in the field, continuously. A performance regression always arrives from the direction you are not watching.

The same discipline — less, but done properly — is what produces accessible interfaces too; accessibility and performance reinforce each other.

Do not speak in metrics. Speak in consequences.

A client does not feel 2.8 seconds of LCP. They feel that a competitor looks more serious. The honest translation sounds like this: every element we add above the fold costs waiting time, and waiting time costs customers. We are not saying no because it cannot be built; we are saying that everything has a price in seconds, and the budget of seconds is finite.

Then show rather than explain. One test on a real phone, on mobile data, with their site next to a competitor, ends the discussion in thirty seconds. If you want to see that discipline applied, our work is built on exactly these rules.