Que sont les Core Web Vitals ? LCP, INP et CLS expliqués

Que sont les Core Web Vitals ?

Les Core Web Vitals sont trois métriques que Google utilise pour mesurer l'expérience réelle d'une page : Largest Contentful Paint (LCP) pour le chargement, Interaction to Next Paint (INP) pour la réactivité et Cumulative Layout Shift (CLS) pour la stabilité visuelle. Une page est validée quand les trois sont « bonnes » au 75e centile des visites réelles.

Chaque métrique est évaluée séparément sur mobile et sur ordinateur, d'après ce que les vrais visiteurs ont vécu et non d'après un seul test. C'est pourquoi une page peut sembler rapide sur votre portable et échouer quand même.

Les trois métriques et leurs seuils

Les seuils sont publiés sur web.dev, où Google tient les définitions à jour.

Largest Contentful Paint (LCP)

Le LCP est le temps nécessaire pour que la plus grande image, le plus grand bloc de texte ou la plus grande vidéo de la zone visible soit affiché, compté depuis le début de la navigation du visiteur. Comme il démarre à la navigation, une réponse lente du serveur, les redirections et l'établissement de la connexion s'y ajoutent.

Interaction to Next Paint (INP)

L'INP observe chaque clic, appui et frappe de touche pendant une visite et retient le plus long, en ignorant les cas aberrants. Chacun est mesuré depuis l'action jusqu'au moment où le navigateur peut afficher l'image suivante. L'INP a remplacé le First Input Delay (FID) comme Core Web Vital le 12 mars 2024. Le FID ne mesurait que le délai avant le traitement de la première interaction et ignorait donc les interactions lentes survenant plus tard.

Cumulative Layout Shift (CLS)

Le CLS additionne les déplacements inattendus des éléments visibles. Il rapporte la plus grande série de décalages pendant la vie de la page : une seule bannière chargée tardivement qui repousse l'article vers le bas peut faire échouer une page.

Comment Google utilise les Core Web Vitals

Dans sa documentation Search, Google recommande vivement d'obtenir de bons Core Web Vitals pour réussir dans la recherche et les relie à l'expérience de page, qui correspond à ce que ses systèmes de classement principaux cherchent à récompenser. La documentation ne dit pas quel poids ils ont : considérez-les comme un facteur parmi d'autres. De bonnes valeurs ne compensent pas un contenu qui ne répond pas à la requête, mais elles évitent de perdre des visiteurs à cause d'une page lente ou qui saute.

Données terrain et données de laboratoire

Les données terrain viennent d'utilisateurs réels de Chrome et sont collectées dans le Chrome UX Report (CrUX) sur une fenêtre glissante de 28 jours. C'est ce qu'affiche le rapport Core Web Vitals de Google Search Console. Les données de laboratoire proviennent d'un outil comme Lighthouse, qui charge la page une fois sur un appareil et un réseau simulés.

Les deux divergent souvent. Un score de 95 en laboratoire dit seulement que la page était rapide dans ces conditions. Les vrais visiteurs arrivent avec des téléphones plus lents, des réseaux plus faibles et depuis d'autres pays. Servez-vous des données de laboratoire pour voir ce qui est lent et pourquoi, et des données terrain pour savoir si les visiteurs ont réellement une bonne expérience. La surveillance synthétique planifiée se place entre les deux : elle ressemble au laboratoire, mais tourne selon un calendrier, si bien que les régressions apparaissent avant que la fenêtre de 28 jours ne rattrape son retard.

Causes courantes de mauvais Core Web Vitals et corrections

LCP lent. Vérifiez d'abord le temps jusqu'au premier octet : réduisez les redirections, mettez les réponses en cache et utilisez un CDN. Rendez l'image du LCP repérable dans le HTML initial et préchargez-la si elle n'est référencée que depuis le CSS ou le JavaScript. Ajoutez fetchpriority="high" sur l'image susceptible d'être le LCP (une ou deux images au maximum) et ne la chargez jamais en différé. Allégez le fichier et réduisez le CSS bloquant le rendu et les scripts synchrones dans le head.

INP mauvais. La cause habituelle est une tâche longue sur le thread principal, souvent due au chargement et à l'analyse des scripts. Faites le minimum dans les gestionnaires d'événements, mettez d'abord l'écran à jour et reportez le reste, découpez les gros traitements avec setTimeout, évitez de lire la mise en page juste après avoir modifié des styles et gardez un DOM léger.

CLS élevé. Les causes typiques sont les images et vidéos sans dimensions, les polices qui s'affichent à une autre taille que leur police de secours, les publicités ou widgets qui se redimensionnent seuls et le contenu inséré au-dessus de ce que le visiteur lit. Indiquez largeur et hauteur (ou un ratio), réservez de la place pour tout ce qui charge tard et animez avec transform plutôt qu'avec des propriétés de mise en page. Un guide plus détaillé se trouve sur notre page d'optimisation des Core Web Vitals.

Comment mesurer et surveiller les Core Web Vitals

• Consultez vos chiffres d'utilisateurs réels. Le vérificateur gratuit de Core Web Vitals lit CrUX et affiche le LCP, l'INP et le CLS au 75e centile sur mobile et ordinateur, avec un résultat validé ou non. Les pages qui n'ont pas assez de trafic Chrome ne renvoient pas de données terrain.
• Diagnostiquez une page. Lancez le test de vitesse de site web après une modification pour voir ce qui est lent lors d'un test en laboratoire.
• Suivez l'évolution. La surveillance de la vitesse des pages lance des audits Lighthouse planifiés depuis 25 régions cloud et peut vous alerter quand une métrique dépasse vos seuils. Notre guide pour surveiller les Core Web Vitals avec alertes et rapports (en anglais) explique la mise en place, et le comparatif des outils Core Web Vitals (en anglais) recense les alternatives.

Comme les données terrain couvrent une fenêtre de 28 jours, une amélioration n'apparaît que progressivement. Comptez environ un mois pour que le rapport suive, et jugez d'abord un déploiement avec les chiffres de laboratoire et synthétiques.

Questions fréquentes : Core Web Vitals

Quelles valeurs de Core Web Vitals sont bonnes ?

Un LCP de 2,5 secondes ou moins, un INP de 200 millisecondes ou moins et un CLS de 0,1 ou moins, chacun au 75e centile des visites réelles. Une page n'est validée que si les trois sont bons.

Les Core Web Vitals comptent-ils pour le SEO ?

Google recommande vivement de bons Core Web Vitals pour réussir dans la recherche et les relie à ses consignes sur l'expérience de page. Il ne publie pas leur poids : améliorez-les d'abord pour vos visiteurs et voyez tout effet sur le classement comme un bonus. Ils ne remplacent jamais un contenu pertinent.

Qu'est-ce qui a remplacé le First Input Delay ?

L'Interaction to Next Paint (INP) a remplacé le FID comme Core Web Vital le 12 mars 2024. L'INP prend en compte toutes les interactions d'une visite, pas seulement la première.

Combien de temps avant qu'une amélioration apparaisse dans Search Console ?

Les données terrain couvrent les 28 derniers jours : une amélioration apparaît progressivement et se voit pleinement après environ quatre semaines. Les valeurs peuvent sembler inchangées pendant des jours après un déploiement, car la majeure partie de la fenêtre contient encore d'anciennes données.

Pourquoi mon score Lighthouse est élevé alors que mes Core Web Vitals échouent ?

Lighthouse est un test de laboratoire d'un seul chargement sur un appareil simulé. Les Core Web Vitals de la recherche reposent sur des données terrain de vrais visiteurs, avec des appareils et des réseaux plus lents. Vérifiez les deux et servez-vous du test en laboratoire pour trouver la cause.

Comment surveiller les Core Web Vitals en continu ?

Combinez le rapport Search Console pour les tendances d'utilisateurs réels avec des audits de laboratoire planifiés depuis plusieurs régions. La surveillance de la vitesse des pages lance Lighthouse selon un calendrier et vous alerte quand une métrique dépasse un budget.