Most content about core web vitals repeats the same generalities. Instead, let us look at what actually moves results, and the trade-offs that come with it.
The real cost of doing nothing
An untreated technical problem does not stay stable: it spreads. Every new piece published on a faulty structure inherits the defect, and remediation cost grows with volume.
That is why fixing a structural flaw on a hundred-page site beats waiting until you have a thousand. The work is the same; the cleanup is not.
How to measure that it works
Set the measurement before acting, not after. Record the starting value, the date, and the exact metric you expect to move. Without that initial snapshot, any conclusion is just an impression.
Prefer one metric per project. Following twelve curves at once feels like control, but makes it impossible to attribute a result to a cause.
Weight is not the only culprit
Cutting kilobytes helps, but load order often matters more. A lightweight render-blocking resource costs more than a heavy lazily-loaded image.
Start by identifying what blocks, then what weighs — in that order. The reverse leads to lengthy optimisation of elements with no perceptible effect.
Measure in the field, not the lab
A score obtained on a fibre-connected development machine says nothing about real experience. Field data, collected from actual visits, often reveals a considerable gap.
This is especially true on mobile, where network and CPU variability make averages misleading: look at the 75th percentile, not the mean.
What it changes for the reader
It is tempting to treat this as a purely technical constraint. In practice, each of these optimisations translates into a clearer, faster or more predictable experience for the person reading.
That is precisely why engines care about these criteria: they approximate, imperfectly, genuine user satisfaction.
Check before moving on
- Remove before adding
- Handle what affects the most pages first
- Measure before, not after
- Check the rendered source, not just the display
Visual stability, the detail that irritates
Content jumping during load causes frustration out of all proportion to its technical cause, often trivial: an undeclared image dimension, a badly calibrated fallback font.
These are the cheapest fixes in all of web performance, and among the most perceptible to users.
Automate what should be automated
Anything that must be repeated on every publication will eventually be forgotten. The rule is simple: if a check depends on human vigilance, it will fail on a deadline day.
Move those controls into the tool — validation on save, automatic alert, a correct default — rather than into a procedure nobody re-reads.
A concrete example
On an editorial site of roughly four hundred pages we supported, methodically applying this principle produced a measurable gain after eleven weeks: more pages actually crawled, and progress on mid-tail queries.
No spectacular action was taken. Most of the work consisted of removing what was in the way, before adding anything at all.
A budget, or nothing
Without an explicit ceiling, a page grows with every change. Setting a budget — in weight, requests and render time — turns performance into a design constraint rather than an occasional project.
The budget must be checked automatically, otherwise it becomes a polite intention nobody consults.
Read next
- WebP, AVIF et srcset : diviser le poids par trois
- Auto-héberger ses polices : vitesse et conformité
- Optimiser le LCP sans tout réécrire
In practice
Bring this list to your next weekly review and assign each item to a person, with a deadline. A technical topic without an owner stays an untreated technical topic.
