Core Web Vitals : les chantiers qui font vraiment bouger le score
Les Core Web Vitals sont devenus un passage obligé des audits, souvent traités comme une liste de cases à cocher. Dans les faits, trois ou quatre corrections apportent l’essentiel du gain. Voici lesquelles, et dans quel ordre les traiter.
Ce que Google mesure
Trois indicateurs, chacun sur une dimension différente de l’expérience :
- LCP — le temps d’affichage du plus grand élément visible. En clair : quand la page paraît chargée. Objectif : moins de 2,5 secondes.
- INP — le délai entre une action de l’utilisateur et la réponse visible de l’interface. Il a remplacé le FID début 2024 et il est nettement plus exigeant. Objectif : moins de 200 millisecondes.
- CLS — l’ampleur des décalages de mise en page pendant le chargement. Le bouton qui se déplace au moment où on le clique. Objectif : moins de 0,1.
Un point souvent négligé : Google se fonde sur les données réelles des visiteurs, pas sur le score de laboratoire. Un excellent résultat en test local ne garantit rien.
Les corrections à fort rendement
Dimensionner les images — corrige le CLS
Une image sans attributs width et height occupe une hauteur nulle jusqu’à son chargement, puis pousse brutalement le contenu. C’est la première cause de mauvais CLS, et la correction prend quelques minutes par gabarit. Le rapport effort/gain est imbattable.
Héberger les polices — corrige le LCP
Une police appelée sur un domaine tiers ajoute une résolution DNS, une négociation TLS et une requête avant que le moindre texte s’affiche. L’auto-héberger avec font-display: swap et un préchargement retire facilement 200 à 400 millisecondes au LCP.
Bénéfice annexe : plus aucune adresse IP de visiteur transmise à un tiers, ce qui règle au passage un point RGPD régulièrement soulevé.
Différer le JavaScript non essentiel — corrige l’INP
Les scripts de suivi, chats et bandeaux de consentement s’exécutent souvent avant le contenu et monopolisent le fil principal. Les charger en defer, ou après la première interaction, améliore l’INP sans rien retirer de fonctionnel.
Le bandeau de consentement mérite une attention particulière : beaucoup de solutions grand public sont, à elles seules, le principal frein à l’interactivité d’un site.
Servir des images au bon format — corrige le LCP
Une photographie en JPEG de 1,2 Mo devient un WebP de 180 Ko sans différence visible. Combiné au chargement différé des images hors écran, c’est le gain le plus important sur les sites riches en visuels.
Ce qui rapporte peu
Certaines recommandations d’outils automatiques ont un rendement faible :
- Minifier le CSS et le JavaScript quand la compression serveur est déjà active : le gain se compte en kilo-octets.
- Éliminer le CSS inutilisé sur un site vitrine : quelques dizaines de kilo-octets, pour un risque de régression visuelle réel.
- Passer à HTTP/3 : utile, mais sans commune mesure avec le fait de corriger une image de 2 Mo en haut de page.
L’ordre que nous suivons
Sur un audit de performance, notre séquence est constante :
- Mesurer sur données réelles, pas seulement en laboratoire.
- Identifier l’élément LCP — c’est presque toujours une image ou un titre bloqué par une police.
- Corriger les dimensions d’images et l’hébergement des polices.
- Traiter les scripts tiers, en commençant par le bandeau de consentement.
- Optimiser les formats d’images et le chargement différé.
- Re-mesurer avant d’aller plus loin.
Dans la grande majorité des cas, les points 3 et 4 suffisent à faire passer une page dans le vert. Le reste relève de l’optimisation fine, à réserver aux sites où le trafic le justifie.