Web

Core Web Vitals: the three numbers Google measures on your real visitors

Core Web Vitals are three measurements Google takes of how your pages behave for real visitors: how fast the main content loads, how quickly the page reacts when someone taps or clicks, and how much the layout jumps while it settles. They are not a vanity score. Google gathers them from actual Chrome users and folds them into how it judges page experience, so a slow or jumpy site is quietly working against you on every visit.

Most speed advice stops at a lab score from one test run on a fast laptop. Core Web Vitals are different because they come from the field: real sessions on real phones and real networks, the ones your customers actually use. That is the number worth caring about, and it is the number we build toward from the first line of markup.

The three metrics, in plain terms

Each vital measures a different kind of frustration. Together they describe whether a page feels fast, responsive, and stable instead of slow, sticky, and jittery.

Largest Contentful Paint (LCP)

LCP is loading. It marks the moment the largest visible thing, usually a hero image or a big headline, finishes drawing on screen. A healthy target is under about two and a half seconds on a mid-range phone. When LCP is bad, the cause is almost always an oversized image, a slow server response, or a script that blocks the page from painting.

Interaction to Next Paint (INP)

INP is responsiveness. It measures the lag between a tap or a click and the screen actually updating in reply. Google made it an official vital in 2024, replacing the older First Input Delay, because it captures every interaction on the page rather than just the first one. Heavy JavaScript running on the main thread is the usual reason a button feels dead for a beat after you press it.

Cumulative Layout Shift (CLS)

CLS is stability. It scores how much content jumps around as the page loads, the maddening moment when you go to tap a link and an ad or image shoves it out from under your thumb. It is caused by images and embeds that do not reserve their space, and by fonts or banners that load late and push everything down. The fix is unglamorous: give every image and embed explicit width and height so the browser can hold the space before the asset arrives, and keep late-loading banners out of the main layout flow.

Where the numbers come from

Two kinds of data get called Core Web Vitals, and confusing them wastes a lot of effort. Lab data comes from a tool like Lighthouse running one simulated load in a controlled environment, which is useful for debugging because it is repeatable. Field data comes from the Chrome User Experience Report: real Chrome visitors measured over a rolling window of the past twenty-eight days. Only the field data is what Google actually uses to assess page experience. A site can look fine in the lab and still fail in the field if real visitors are on slower phones or farther from the server. We optimize against both, but the field is the scoreboard.

Google does not grade on your best visit, either. It looks at the seventy-fifth percentile of real loads, which means roughly a quarter of your visitors can have a worse experience than a single headline number suggests. Passing is not an average you can hide a slow tail behind: the slower end of your audience still has to get a solid page, and that is the bar we build against.

Why Core Web Vitals are a build problem, not a plugin

Here is the part most owners are not told: you cannot bolt good vitals onto a heavy site with a caching plugin. The three metrics are a direct readout of architecture decisions made long before launch. How much JavaScript ships to the browser. Whether images are sized and served correctly. Whether fonts block text from appearing. How fast the server answers the first request. A plugin can paper over one of these for a while. It cannot change the foundation.

That is why the sites that pass cleanly tend to be the ones built with performance as a constraint rather than an afterthought. The decisions that move the numbers are structural:

Why mobile is where this is won or lost

Core Web Vitals are scored per device type, and mobile is almost always the harder, more important case. Your visitors are on mid-range phones over cellular connections, not the fast laptop a site often gets tested on. That gap is where most sites quietly fail: the hero image that loads instantly on desktop takes seconds on a phone, and the JavaScript that feels snappy on a laptop chokes a smaller processor. Building for the phone first is not a preference here. It is the condition the metrics are actually measured under.

How we engineer for Core Web Vitals

When we build a site, we treat these three metrics as design inputs, not a cleanup task at the end. The approach is boring on purpose, because boring is what holds up under real traffic:

We build on a static-first stack for exactly this reason: pages that are fast by default and simple enough to hand to the owner to manage without a developer on call. For the mechanics of the image half of the work, see our page on image optimization, and for the underlying framework choice, see how we use Astro.

What you actually get

The deliverable is a site engineered to meet the Core Web Vitals thresholds on the pages that carry your business, a stable baseline you can re-measure any time, and no ongoing dependency on a stack of plugins to prop up speed. Because the vitals come from real visitors, the numbers also hold up as you add content, provided new images and embeds follow the same rules. Good vitals feed into how search engines judge page experience, so the work compounds if you later invest in search. We only do that ongoing search work on sites we build: see /services/seo/ for how it fits together, and /pricing/ for how engagements are structured.

This is work we do for real: Wren Coffee Co is a premium private coffee cart we built a fast, client-managed custom site for.

We do SEO on websites we build. That is the engagement this page sits inside.