Core Web Vitals : ce qui fait vraiment bouger les chiffres
Les Core Web Vitals sont trois mesures de terrain de la sensation qu'une page procure : combien de temps avant que le contenu principal apparaisse, de combien il bouge pendant le chargement, et avec quelle rapidité il répond aux interactions. C'est un signal de classement et, plus important, cela est corrélé au fait que les gens restent.
Ce guide couvre ce que mesure chaque métrique, les causes précises derrière de mauvais scores, et les correctifs qui font bouger les données de terrain et pas seulement les scores de laboratoire.
Ce que mesurent les trois métriques#
Chacune a un seuil « bon » et un petit nombre de causes habituelles. Notez que le chiffre qui compte pour le classement, ce sont les données de terrain de vrais visiteurs, pas un score de laboratoire depuis votre ordinateur.
| Métrique | Bon | Mesure | Cause habituelle quand c'est mauvais |
|---|---|---|---|
| LCP | Sous 2,5 s | Temps avant l'affichage du plus grand élément visible | Image principale non optimisée, serveur lent, CSS bloquant le rendu |
| CLS | Sous 0,1 | De combien la mise en page bouge pendant le chargement | Images sans dimensions, bannières injectées, polices web tardives |
| INP | Sous 200 ms | Réactivité aux interactions | De longues tâches JavaScript bloquant le fil principal |
Les outils de laboratoire mesurent un chargement sur une machine. Les données de terrain sont le 75e centile des vraies visites, ce qui inclut de vieux mobiles sur de mauvais réseaux — précisément les visiteurs les plus susceptibles de partir.
Corriger le LCP#
Le LCP est presque toujours une image ou un titre bloqué derrière autre chose. Traitez ces points dans l'ordre ; les deux premiers corrigent la plupart des sites.
- Identifiez le véritable élément LCP dans les données de terrain. Optimiser la mauvaise image est l'effort gaspillé le plus fréquent.
- Ne chargez jamais l'image du LCP en différé. Donnez-lui fetchpriority="high" à la place.
- Servez-la dans un format moderne à la taille où elle s'affiche, avec srcset pour les écrans plus petits.
- Préchargez la police utilisée par le texte du LCP et utilisez font-display: swap pour que le texte ne soit pas invisible pendant l'attente.
- Retirez du head le CSS et le JavaScript bloquant le rendu ; intégrez le CSS critique si la page est assez petite.
- Réduisez le Time to First Byte avec du cache et un CDN : aucun travail front-end ne compense un serveur lent.
- Réduisez les scripts tiers sur le chemin critique. Chacun est une résolution DNS, une connexion et un fichier imprévisible.
Corriger le CLS#
Le décalage de mise en page est presque entièrement évitable et les correctifs sont peu coûteux. C'est aussi la métrique que les visiteurs ressentent le plus viscéralement : c'est elle qui fait appuyer au mauvais endroit.
- Renseignez les attributs width et height sur chaque image et vidéo pour que le navigateur réserve la place.
- Réservez la place des publicités, intégrations et iframes avec un conteneur à ratio d'aspect fixe.
- N'insérez jamais de contenu au-dessus du contenu existant après le chargement : les bandeaux cookies vont en bas, ou en surimpression.
- Alignez les métriques de la police de repli sur la police web, ou utilisez size-adjust, pour que le remplacement ne recompose pas la page.
- Évitez d'animer des propriétés de mise en page. Animez transform et opacity, qui ne déclenchent pas de recalcul.
- Donnez aux sections chargées dynamiquement une min-height pour qu'elles ne s'étendent pas depuis zéro.
Corriger l'INP#
L'INP a remplacé le First Input Delay et il est plus difficile, car il mesure chaque interaction de la visite plutôt que la seule première. Un mauvais INP, c'est presque toujours trop de JavaScript qui tourne sur le fil principal.
| Cause | Correctif |
|---|---|
| Gros paquet analysé au chargement | Découper le code ; ne charger que ce dont la page a besoin |
| Tâches longues au-delà de 50 ms | Découper le travail en morceaux et rendre la main au fil principal |
| Gestionnaires d'événements coûteux | Temporiser et sortir le travail lourd du chemin d'interaction |
| Balises tierces lourdes | Charger après l'interaction, ou supprimer : auditez ce que chacune rapporte |
| DOM volumineux (plus de 10 000 nœuds) | Virtualiser les longues listes ; simplifier le balisage très imbriqué |
| Sollicitation de mise en page dans les gestionnaires | Regrouper les lectures et les écritures au lieu de les alterner |
Sur les sites éditoriaux, le correctif INP le plus rentable consiste généralement à supprimer du JavaScript plutôt qu'à l'optimiser. Demandez ce que rapporte chaque script ; les gestionnaires de balises accumulent des scripts que personne ne se souvient d'avoir ajoutés.
Questions fréquentes
Quel impact ont les Core Web Vitals sur le classement ?
C'est un signal réel mais modéré, qui agit comme départage plutôt que comme substitut à la pertinence. Une page rapide sur le mauvais sujet ne dépasse pas une page plus lente qui répond à la requête. L'argument le plus fort pour les corriger est comportemental : des pages lentes et qui sautent perdent des visiteurs avant même que le classement entre en jeu.
Pourquoi mon score Lighthouse est-il bon et mes données de terrain mauvaises ?
Parce que Lighthouse simule un chargement sur votre machine avec votre connexion, et que les données de terrain sont le 75e centile de vraies visites, y compris des mobiles de trois ans sur des réseaux mobiles saturés. Quand les deux divergent, ce sont les données de terrain qui comptent. Utilisez les outils de laboratoire pour diagnostiquer, pas pour noter.
Dois-je corriger les trois métriques ?
Corrigez celles qui échouent, dans l'ordre de ce que vivent vos visiteurs. Le CLS est généralement le moins coûteux à corriger et le plus agaçant pour les utilisateurs, c'est donc un bon point de départ. Le LCP a le plus d'effet sur le fait que les gens attendent. L'INP compte le plus sur les sites interactifs et le moins sur des articles statiques.
En combien de temps les améliorations apparaissent-elles ?
Les données de terrain sont une fenêtre glissante de 28 jours, donc un mouvement significatif prend environ quatre semaines après qu'un correctif a atteint tous les visiteurs. Ne jugez pas un changement au bout de trois jours. Vérifiez en revanche les métriques de laboratoire immédiatement pour confirmer que le correctif a bien fait ce que vous attendiez.
core web vitalslcpclsinpvitesse de pageperformance web
