Core Web Vitals : le guide complet

Les trois Core Web Vitals sont le Largest Contentful Paint (LCP) pour le chargement, l'Interaction to Next Paint (INP) pour la réactivité, et le Cumulative Layout Shift (CLS) pour la stabilité visuelle. Une page est validée quand 75 % des visites réelles atteignent le seuil « bon » sur les trois. Google confirme que ces mesures sont utilisées par ses systèmes de classement.

Petite note de vocabulaire : en France, les développeurs disent « Core Web Vitals », pas « signaux web essentiels ». On garde donc le terme anglais dans ce guide.

Les trois mesures en un coup d'œil

Les trois sont mesurées au 75e centile des visites, et le mobile et l'ordinateur sont notés séparément. Le 75e centile a son importance : il signifie que trois visiteurs sur quatre ont une expérience au moins aussi bonne que ce chiffre. Se fier à la moyenne masque votre quart le plus lent, c'est-à-dire en général celui qui part.

Les seuils viennent directement de la référence web.dev de Google. Ils bougent rarement : une fois confortablement en dessous, vous pouvez surtout surveiller les régressions.

Largest Contentful Paint (LCP)

Le LCP, c'est le moment où le plus gros élément visible à l'écran finit de s'afficher : en général une image d'en-tête, une bannière, ou un grand bloc de titre. C'est un bon indicateur du « la page a l'air prête », parce que c'est l'élément sur lequel l'œil se pose.

Quand le LCP est lent, la cause est presque toujours l'une de ces quatre : un serveur lent à répondre (TTFB), du CSS ou du JavaScript bloquant qui retarde l'affichage, une image d'en-tête trop lourde ou découverte trop tard, ou du contenu qui n'apparaît qu'après l'exécution du JavaScript. Bonne nouvelle : le LCP est le plus facile à corriger des trois. Le guide Optimize LCP de Google est ma référence.

Interaction to Next Paint (INP)

L'INP mesure la réactivité. À chaque fois que quelqu'un tape, clique ou appuie sur une touche, le navigateur doit réagir et afficher le résultat. L'INP regarde toutes ces interactions sur l'ensemble de la visite et retient à peu près la pire. Visez 200 ms ou moins.

L'INP a remplacé le First Input Delay le 12 mars 2024. La différence est plus honnête que ne l'était le FID : le FID ne mesurait que le délai avant la première interaction, que la plupart des pages passaient sans effort. L'INP mesure le délai complet jusqu'à l'affichage suivant, pour chaque interaction. Si votre page embarque beaucoup de JavaScript, c'est là que ça se voit : les tâches longues bloquent le thread principal et la page ne peut pas répondre tant qu'elles ne sont pas terminées. Les corrections sont dans Optimize INP.

Un point à connaître : les outils de labo ne mesurent pas vraiment l'INP, faute de vraie personne pour cliquer. Lighthouse affiche le Total Blocking Time à la place, comme approximation. C'est une raison majeure pour laquelle les données terrain comptent, on y revient.

Cumulative Layout Shift (CLS)

Le CLS, c'est celui que tout le monde ressent mais que peu mesurent. C'est la somme des décalages de mise en page inattendus : vous allez toucher un bouton, une image se charge au-dessus, toute la page saute, et vous cliquez sur une pub à la place. Le bon seuil est 0,1 ou moins.

Les coupables habituels : les images et les intégrations sans largeur ni hauteur définies, le contenu injecté en haut de page (bandeaux cookies, pubs, widgets qui chargent en retard), et les polices web qui font sauter le texte au moment de leur affichage. L'essentiel se prévient en réservant la place avant que le contenu n'arrive. Le guide Optimize CLS détaille les bonnes pratiques.

Données de labo vs données terrain : pourquoi deux outils ne sont pas d'accord

Ça perturbe presque tout le monde, alors soyons clairs. Il y a deux façons d'obtenir les Core Web Vitals, et elles répondent à des questions différentes.

Les données de labo viennent d'un test synthétique. Un outil comme Lighthouse charge votre page une fois, sur un appareil et un réseau simulés, dans des conditions propres. C'est reproductible et très pratique pour déboguer, parce qu'on peut changer une chose et relancer. Mais c'est un appareil, un réseau, un instant. Il ne voit pas vos vrais utilisateurs, et il ne mesure pas l'INP.

Les données terrain viennent des vrais utilisateurs de Chrome via le Chrome UX Report (CrUX). C'est le 75e centile des visites réelles sur une fenêtre glissante de 28 jours, sur les téléphones, ordinateurs et connexions que votre audience utilise vraiment. C'est sur ces données que repose l'évaluation de Google. Le hic : une page a besoin d'assez de trafic pour apparaître dans CrUX, donc les pages récentes ou peu visitées n'ont souvent pas de données terrain.

Une page peut donc obtenir 98 en test de labo et échouer sur le terrain, parce que vos vrais visiteurs sont sur des téléphones de trois ans et une 4G capricieuse, pas sur une connexion de centre de données. Aucun des deux chiffres n'est faux. Ce sont des réponses à deux questions : « cette page est-elle capable d'être rapide ? » et « est-elle rapide pour les gens qui l'utilisent vraiment ? » Il vous faut les deux.

Les Core Web Vitals influencent-ils le SEO ?

Oui, mais gardez le sens des proportions. Google choisit ses mots avec soin : « les Core Web Vitals sont utilisés par nos systèmes de classement », et en même temps « la recherche Google cherche toujours à montrer le contenu le plus pertinent, même si l'expérience de la page est médiocre » (source).

Relisez. La vitesse ne sauvera pas un contenu pauvre, et elle ne fera pas passer devant une réponse nettement meilleure. Mais quand deux pages se valent sur la pertinence, la plus rapide et la plus stable a l'avantage, et une page franchement lente perd des visiteurs avant même le premier mot. Voyez les Core Web Vitals comme une composante d'un contenu utile, pensé pour les gens, pas comme une astuce de classement.

Comment les mesurer

Quelques moyens gratuits et officiels de vérifier une page :

• PageSpeed Insights lance Lighthouse et affiche les données terrain CrUX au même endroit. Le meilleur point de départ.
• Le rapport Signaux web essentiels de la Search Console regroupe vos URL par statut à partir des données terrain : utile pour voir les problèmes à l'échelle du site.
• Lighthouse dans les outils de développement de Chrome, pour déboguer à la main.
• La bibliothèque JavaScript web-vitals si vous voulez enregistrer vous-même les mesures réelles.

Chacun de ces outils donne un instantané. C'est la limite. Un rapport vous dit où vous en êtes aujourd'hui ; il ne vous dira pas qu'une mise en production mardi dernier a fait passer en douce le LCP mobile de 2,3 à 3,1 secondes. La performance dérive entre les versions, et un contrôle ponctuel ne voit pas la dérive. C'est le rôle d'un monitoring.