Core Web Vitals : ce qui fait vraiment bouger les chiffres

Les Core Web Vitals sont souvent traités comme une liste d'optimisations à appliquer. On les comprend mieux comme trois questions sur le comportement d'une page : à quelle vitesse le contenu principal apparaît-il, à quelle vitesse la page répond-elle quand on interagit avec elle, et la mise en page reste-t-elle stable pendant le chargement.

Largest Contentful Paint

Le LCP mesure le moment où le plus grand élément visible finit de s'afficher : généralement une image d'en-tête, un bloc de titre ou une vignette vidéo. L'erreur courante consiste à optimiser toute la page au lieu d'identifier quel est réellement l'élément LCP et de raccourcir son chemin.

1. Identifiez l'élément LCP avec des données de terrain plutôt qu'en devinant depuis un test de laboratoire
2. Assurez-vous qu'il est détectable dans le HTML initial, pas injecté par JavaScript
3. Préchargez-le s'il s'agit d'une image, et servez un format moderne à la bonne taille
4. Retirez les ressources bloquant le rendu situées avant lui dans le chemin critique
5. Vérifiez le temps de réponse du serveur : aucun travail front-end ne corrige une origine lente

Interaction to Next Paint

L'INP a remplacé le First Input Delay parce qu'il mesure toute l'interaction et non le seul délai initial. Il reflète la charge du fil principal au moment où un utilisateur tape ou clique.

• Réduisez le volume de JavaScript envoyé et analysé sur chaque route
• Découpez les tâches longues pour que le fil principal puisse répondre entre les blocs
• Évitez le travail déclenchant un recalcul de mise en page dans les gestionnaires de défilement et de redimensionnement
• Gardez l'état d'animation hors de l'état du framework lorsqu'il provoquerait un rendu par image
• Différez les scripts tiers non essentiels, souvent les plus gros contributeurs

Ce cinquième point mérite d'être souligné. Analytics, widgets de chat, gestionnaires de balises et scripts publicitaires consomment couramment plus de fil principal que le code du site lui-même. Mesurez-les individuellement avant de les défendre.

Cumulative Layout Shift

Le CLS est le plus simple à corriger et le plus souvent ignoré. Du contenu qui bouge sous le doigt d'un utilisateur au moment où il vise un bouton est un véritable défaut d'utilisabilité, pas seulement une métrique.

• Définissez largeur et hauteur des images et vidéos pour réserver l'espace avant leur chargement
• Réservez l'espace de tout ce qui est injecté après : bandeaux, intégrations, composants dynamiques
• Utilisez font-display et des polices de repli aux métriques ajustées pour éviter la refonte du texte au changement de police
• N'insérez jamais de contenu au-dessus du contenu existant une fois la page peinte

Données de laboratoire et données de terrain

Les outils de laboratoire exécutent une page dans des conditions synthétiques fixes. Les données de terrain enregistrent ce que de vrais utilisateurs ont vécu, sur de vrais appareils et de vrais réseaux. Ils divergent souvent, et lorsque c'est le cas, ce sont les données de terrain qui comptent, pour les utilisateurs comme pour le classement.

Servez-vous des outils de laboratoire pour diagnostiquer et itérer vite, car ils sont reproductibles. Servez-vous des données de terrain pour décider quoi traiter et si le travail a porté. Un site excellent en laboratoire et médiocre sur le terrain a généralement un problème qui n'apparaît que sur du matériel mobile de milieu de gamme.

Où l'effort paie généralement

D'après notre expérience, l'ordre est assez constant : temps de réponse serveur et ressources bloquant le rendu pour le LCP ; scripts tiers et taille des bundles pour l'INP ; images et contenu injecté pour le CLS. Commencez par là avant de chercher de petites optimisations.