Core Web Vitals, explained without the jargon

We end up explaining this on discovery calls often enough that it deserved writing down. Here is Core Web Vitals without the vocabulary that usually surrounds it.

Speed is a feature people notice only in its absence, and then they leave rather than complain. Doing this properly once is usually cheaper than doing it approximately three times.

The short version

Google measures loading, interactivity, and visual stability. The reasoning matters more than the rule, because the rule has exceptions. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. That sounds obvious written down. It is still the thing most often skipped.

Largest contentful paint under 2.5 seconds is the bar. It is worth being explicit about, because assumptions differ quietly. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

What to do next

Field data from real visitors beats lab scores. Where this goes wrong is almost never a lack of knowledge. If it only works because one person remembers to do something, it does not work yet.

How to tell if yours is fine

Real-world numbers from actual visitors matter more than a score produced on a fast laptop. Three things worth confirming about Core Web Vitals before you move on:

• Someone can say what the current setup is without going to look
• Largest contentful paint under 2.5 seconds is the bar — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.