How to get Core Web Vitals right
This is one of those topics that looks small until it costs you something. The short answer to Core Web Vitals is that it is mostly a sequence of small decisions, not one big one.
Performance work is mostly subtraction, which makes it unpopular and effective. Doing this properly once is usually cheaper than doing it approximately three times.
What is actually at stake
Google measures loading, interactivity, and visual stability. In practice this is a scheduling problem more than a technical one. The version that survives contact with a real deadline is the simple one.
The steps
- Establish what you have today before changing anything
- Largest contentful paint under 2.5 seconds is the bar
- Field data from real visitors beats lab scores
- Write down the decision so the next person does not re-litigate it
Field data from real visitors beats lab scores. That sounds obvious written down. It is still the thing most often skipped. The version that survives contact with a real deadline is the simple one.
Making it stick
What this looks like day to day
Speed is a feature people notice only in its absence, and then they leave rather than complain. 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
The point is not perfection, it is knowing which of these you have consciously chosen to skip.