Most teams meet Core Web Vitals as a report card. A tool turns three letters red, someone is told to fix the score before launch, a few images get compressed, and everyone moves on. The score goes green and the lesson is missed entirely.

Performance is not a grade you raise at the end. It is a property of how the product is built, and it decays the moment you stop paying attention. The teams whose sites stay fast are not the ones with the best last-minute audit. They are the ones who treated speed as a feature from the first commit.

What the three letters actually mean

The vitals are not arbitrary. Largest Contentful Paint asks how long until the main thing appears. Cumulative Layout Shift asks whether the page jumps around while it loads. Interaction to Next Paint asks whether the page responds when a user actually touches it. Strip away the acronyms and they all ask the same human question. Does this feel fast and stable to a real person on a real phone.

That reframing matters, because it turns an abstract score into something you can feel. You do not need a dashboard to notice a page that lurches as it loads. Your users certainly do not.

A good score on a fast laptop is not a result. It is a way to fool yourself.

Where the seconds actually go

When a page is slow, the cause is rarely a mystery, and it is rarely the thing people reach for first. It is images shipped far larger than they render. It is layout that shifts because nothing reserved space for an image or a font. It is the main thread choking on JavaScript the page did not need yet. It is a third-party script, added for one stakeholder, dragging the whole experience down.

None of these are fixed by a single heroic optimization. They are fixed by a hundred small defaults. Size your images. Reserve space for anything that loads late. Send less JavaScript. Be ruthless about third-party scripts. Speed is the sum of decisions, not a switch.

Measure where your users are

The most common self-deception in performance work is testing on the wrong machine. The site feels instant on the developer's laptop on office wifi, so it must be fine. Then it ships to someone on a three-year-old phone on a patchy connection, which is who actually uses it, and it crawls.

Measure on the hardware and the network your real audience has. The numbers that matter come from the field, not the lab. A lab score is a smoke test. Field data is the truth.

Build it in, do not bolt it on

The reason performance should be a feature and not a final audit is that the cheapest time to be fast is while you are building. Choosing the right image strategy upfront costs nothing. Retrofitting it across a finished site costs a sprint. Reserving layout space as you build is a habit. Hunting down every shift after the fact is a scavenger hunt.

So we treat the vitals as acceptance criteria, not as a cleanup task. A feature is not done when it works. It is done when it works and it is fast on the device your user actually holds. Make that the definition of done and the report card takes care of itself, permanently, instead of going red again the moment you look away.