Five mistakes teams make with Core Web Vitals

Every audit we run turns up some version of this. These are the ones we run into repeatedly when we audit Core Web Vitals.

Speed is a feature people notice only in its absence, and then they leave rather than complain. Assume whoever inherits this will have half your context and none of your patience.

Where it usually goes wrong

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Google measures loading, interactivity, and visual stability
• Largest contentful paint under 2.5 seconds is the bar
• Never checking whether the fix actually worked

Field data from real visitors beats lab scores. In practice this is a scheduling problem more than a technical one. If it only works because one person remembers to do something, it does not work yet.

Turning this into a decision

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
• Google measures loading, interactivity, and visual stability — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.