Core Web Vitals : ce qui compte vraiment

Les Core Web Vitals sont souvent réduits à un score coloré dans un outil d'audit. C'est dommage, car ils décrivent quelque chose de très concret : ce que ressent une personne quand elle charge et utilise votre site. Comprendre ce qu'ils mesurent permet d'agir au bon endroit, plutôt que de courir après un chiffre.

Trois indicateurs, trois questions

Google a retenu trois métriques, chacune répondant à une question simple du point de vue de l'utilisateur.

LCP : le contenu principal s'affiche-t-il vite ?

Le Largest Contentful Paint mesure le moment où le plus grand élément visible à l'écran est affiché : souvent l'image principale, une vidéo de couverture ou un grand bloc de texte. C'est une bonne approximation du moment où la page « semble chargée ».

Seuil considéré comme bon : 2,5 secondes ou moins.

INP : la page réagit-elle quand on interagit ?

L'Interaction to Next Paint mesure le délai entre une interaction (clic, appui, saisie au clavier) et la mise à jour visuelle qui suit. Il observe les interactions tout au long de la visite et retient l'une des plus lentes. Une page peut s'afficher vite et pourtant sembler figée quand on clique sur un menu : c'est ce que capte l'INP.

Seuil considéré comme bon : 200 millisecondes ou moins.

CLS : la mise en page reste-t-elle stable ?

Le Cumulative Layout Shift mesure les décalages inattendus de la mise en page. Le texte qui descend au moment où une image apparaît, le bouton qui se déplace sous le doigt à cause d'un bandeau inséré : c'est ce que le CLS quantifie. Il s'agit d'un score sans unité.

Seuil considéré comme bon : 0,1 ou moins.

Le 75e percentile : ce que vivent vos vrais visiteurs

Un détail change tout : ces seuils s'évaluent au 75e percentile des visites réelles. Autrement dit, une page est jugée bonne si au moins trois visites sur quatre respectent le seuil.

Conséquence directe : ce n'est pas l'expérience sur votre ordinateur récent avec une bonne connexion qui compte, mais celle d'une grande partie de vos visiteurs, y compris sur des téléphones plus modestes et des réseaux moins rapides. Les mesures sont d'ailleurs distinguées entre mobile et ordinateur.

Données terrain et données de laboratoire

C'est la source de confusion la plus fréquente.

• Les données terrain proviennent de vrais utilisateurs. Pour les navigateurs Chrome qui partagent ces statistiques, elles sont agrégées dans le rapport CrUX (Chrome User Experience Report). On les retrouve dans PageSpeed Insights, en haut du rapport, et dans le rapport Signaux Web essentiels de la Search Console. Ce sont elles qui reflètent l'expérience réelle.
• Les données de laboratoire sont produites par une simulation : un chargement unique, sur un appareil et un réseau émulés. C'est ce que produit Lighthouse, et la partie basse de PageSpeed Insights. Elles sont précieuses pour diagnostiquer et comparer avant/après, mais ne représentent pas vos utilisateurs.

Deux conséquences pratiques. D'abord, un bon score de laboratoire ne garantit pas de bonnes données terrain, et inversement. Ensuite, l'INP dépend d'interactions réelles : un test de laboratoire qui se contente de charger la page ne peut pas le mesurer directement.

Les leviers concrets

La plupart des problèmes viennent des mêmes sources. Voici où regarder en priorité.

Les images

• Servez des images dimensionnées pour leur affichage, dans des formats modernes comme WebP ou AVIF.
• Ne chargez pas en différé l'image principale visible dès l'arrivée : c'est souvent elle qui détermine le LCP. Au contraire, signalez-la comme prioritaire.
• Chargez en différé les images situées plus bas dans la page.
• Indiquez toujours la largeur et la hauteur, ou un ratio, pour que le navigateur réserve la place.

Les polices

• Limitez le nombre de familles et de graisses chargées.
• Hébergez les fichiers au plus près du site et préchargez celle qui sert au premier affichage.
• Choisissez une stratégie d'affichage qui montre le texte immédiatement, et ajustez la police de secours pour que le remplacement ne décale pas la mise en page.

Le JavaScript

C'est le principal responsable d'un mauvais INP.

• Réduisez la quantité de code envoyée : supprimez les dépendances inutiles, découpez le code par page, retardez ce qui n'est pas nécessaire au premier affichage.
• Évitez les tâches longues sur le fil principal : un traitement lourd déclenché par un clic bloque la réponse visuelle.
• Surveillez les scripts tiers : outils de suivi, widgets, pixels publicitaires. Chacun a un coût, et ils s'additionnent.

Les réservations d'espace

La majorité des problèmes de CLS se règlent en réservant la place à l'avance.

• Dimensions explicites sur les images, vidéos et iframes.
• Espace réservé pour les bandeaux de cookies, les encarts et les contenus chargés après coup.
• Animations réalisées avec des transformations plutôt qu'en modifiant la taille ou la position des éléments dans le flux.

En résumé

Les Core Web Vitals ne sont pas une fin en soi. Ils traduisent trois qualités qu'un visiteur perçoit immédiatement : un affichage rapide, une interface réactive, une page stable. Visez les seuils officiels sur vos données terrain, servez-vous du laboratoire pour diagnostiquer, et traitez les causes : images, polices, JavaScript et réservations d'espace.

Si vous souhaitez un regard extérieur sur les performances de votre site, Studio Aplomb peut vous aider à prioriser ce qui aura un vrai effet.