Comment améliorer vos Core Web Vitals

Ce guide est rangé dans l'ordre où je m'y prendrais vraiment. Si les mesures elles-mêmes sont nouvelles pour vous, commencez par Core Web Vitals : le guide complet et revenez ensuite.

Étape 0 : mesurer avant de toucher à quoi que ce soit

Passez la page dans PageSpeed Insights. Regardez d'abord les données terrain (vos vrais utilisateurs), puis la partie labo pour déboguer. Notez laquelle des trois échoue et sur quel appareil. Le mobile est en général le plus difficile, et c'est celui sur lequel Google s'appuie le plus.

Écrivez les chiffres de départ. Impossible de savoir si un changement a aidé sans avoir noté le point de départ, et « ça paraît plus rapide » n'est pas une mesure.

Améliorer le LCP (chargement)

Le LCP est le plus facile à corriger des trois. Avancez à peu près dans l'ordre d'impact. Le guide Optimize LCP de Google va plus loin sur chaque point.

• Accélérez la réponse du serveur. Un TTFB lent retarde tout le reste. Mettez le HTML en cache, placez un CDN devant votre site, et vérifiez que votre hébergement n'est pas le goulet d'étranglement.
• Arrêtez de bloquer l'affichage. Le CSS et le JavaScript bloquants retardent le premier rendu. Intégrez en ligne le peu de CSS nécessaire au haut de page, différez ou passez le reste en async, et supprimez les scripts inutiles. Voir render-blocking resources.
• Corrigez l'image LCP. C'est en général l'image d'en-tête. Compressez-la, servez un format moderne (AVIF ou WebP), dimensionnez-la pour l'appareil, et ne la chargez pas en lazy-load. Mettre l'image d'en-tête en lazy-load est l'une des erreurs les plus courantes.
• Aidez le navigateur à la trouver tôt. Ajoutez fetchpriority="high" sur l'image LCP, et préchargez-la si elle est découverte tard (par exemple un arrière-plan en CSS).
• Méfiez-vous du rendu côté client. Si le contenu au-dessus de la ligne de flottaison n'apparaît qu'après l'exécution du JavaScript, le LCP attend ce JavaScript. Faites un rendu côté serveur ou un pré-rendu de la partie importante.

Améliorer l'INP (réactivité)

L'INP, c'est le JavaScript qui s'écarte pour laisser la page répondre. Si l'INP est votre problème, la cause est presque toujours trop de script qui s'exécute sur le thread principal. La référence est Optimize INP.

• Envoyez moins de JavaScript. La tâche longue la moins chère est celle qu'on n'envoie jamais. Auditez votre bundle, retirez le code mort, et découpez le reste pour que chaque page ne charge que ce dont elle a besoin.
• Découpez les tâches longues. Une seule tâche longue bloque toutes les interactions derrière elle. Fractionnez le travail lourd en plus petits morceaux et rendez la main au thread principal entre chacun.
• Maîtrisez les scripts tiers. Gestionnaires de balises, widgets de chat, outils d'A/B testing et scripts publicitaires sont les casseurs d'INP habituels. Chargez-les plus tard, chargez-en moins, et demandez-vous si chacun mérite sa place.
• Déplacez les calculs lourds hors du thread principal. Le travail vraiment lourd (parsing, tri de longues listes) a sa place dans un web worker.
• Gardez un DOM raisonnable. Un DOM énorme rend chaque interaction plus coûteuse. Utilisez content-visibility pour les sections hors écran et n'affichez pas dix mille lignes d'un coup.

Rappel : les outils de labo ne mesurent pas l'INP, puisque personne ne clique. Ils affichent le Total Blocking Time comme approximation. Pour connaître votre vrai INP, il faut des données terrain, exactement le genre de chose qu'un test ponctuel ne donne pas.

Améliorer le CLS (stabilité visuelle)

Le CLS, c'est surtout réserver la place avant que le contenu n'arrive. Les bonnes pratiques sont documentées dans Optimize CLS.

• Donnez des dimensions aux médias. Définissez width et height (ou un aspect-ratio en CSS) sur chaque image, vidéo et iframe, pour que le navigateur garde la place avant le chargement du fichier.
• Réservez de l'espace pour le contenu tardif. Bandeaux cookies, pubs et intégrations qui surgissent en haut de page repoussent tout vers le bas. Donnez-leur un emplacement fixe d'emblée.
• Gérez les polices avec soin. Un changement de police peut faire sauter le texte. Préchargez les polices clés et utilisez font-display pour adoucir le basculement.
• N'insérez pas de contenu au-dessus de ce qu'on est en train de lire. S'il faut ajouter quelque chose dynamiquement, faites-le sous la ligne de flottaison ou dans une place déjà réservée.

N'oubliez pas le mobile

Ça vaut la peine de le redire : testez le mobile à part. Une page peut être bien verte sur ordinateur et rouge sur un téléphone milieu de gamme, parce que les téléphones ont des processeurs plus lents et des réseaux plus capricieux. Google évalue les deux séparément, et PerfHawk les affiche côte à côte pour la même raison. Si vous ne vérifiez jamais que sur votre portable, vous passez l'examen facile.

Re-mesurer, puis continuer à surveiller

Après chaque changement, relancez la page et comparez aux chiffres notés à l'étape 0. La vraie amélioration apparaît dans les données terrain au fil des semaines : CrUX rapporte une fenêtre glissante de 28 jours de visites réelles, soyez donc patient avec les mesures terrain.

Vient ensuite la partie que la plupart des équipes sautent : garder les gains. La performance régresse en silence. Une nouvelle image d'en-tête, une balise tierce ajoutée pour une campagne, une montée de version du framework, et trois semaines plus tard vous voilà de retour dans l'orange sans qu'aucune alarme n'ait sonné. Repérer ça demande un monitoring qui vérifie chaque jour, pas un pense-bête pour « retester un de ces jours ».