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

Que sont les Core Web Vitals ?

Chaque Core Web Vital couvre un moment précis de la visite. Les données proviennent de vrais utilisateurs de Chrome :

• Chargement (LCP) : le temps nécessaire pour afficher le contenu principal à l'écran
• Interactivité (INP) : le temps que met la page à réagir à un clic, un appui ou une touche du clavier
• Stabilité (CLS) : à quel point le contenu bouge pendant le chargement

La sélection évolue. En mars 2024, l'INP a remplacé le First Input Delay (FID). Le FID mesurait uniquement l'attente avant la prise en charge de la première interaction. L'INP mesure chaque interaction du début à la fin, et bien plus de sites échouent.

Quand valide-t-on les Core Web Vitals ?

Google classe chaque métrique en Bon, À améliorer ou Médiocre. Vous validez le test quand au moins 75 % des visites de la page dans CrUX affichent un bon LCP, un bon INP et un bon CLS. Google examine l'URL en priorité. Si cette URL a trop peu de trafic, il bascule sur un groupe d'URL similaires, ou sur l'ensemble de l'origine. PageSpeed Insights affiche ce résultat tout en haut de la page : « Core Web Vitals Assessment: Passed » ou « Failed ».

Pourquoi le 75e percentile ?

La médiane ne renseigne que sur la moitié la plus rapide des visiteurs. Un percentile plus strict ferait échouer toute la page pour quelques visites dans un train avec une seule barre de réseau. Le p75 se situe entre les deux : trois visites sur quatre doivent être bonnes.

Un ordinateur portable connecté au Wi-Fi du bureau ne vous apprend pas grand-chose. Les visites qui décident du p75 proviennent de téléphones plus lents sur réseau mobile.

Les trois métriques des Core Web Vitals

Largest Contentful Paint (LCP) : chargement

Le Largest Contentful Paint mesure le chargement : le temps écoulé entre le début de la navigation et l'affichage du plus grand élément visible dans le viewport.

Cet élément doit comporter du contenu : une image (les images d'arrière-plan et les posters vidéo comptent aussi) ou un bloc de texte. Sur la plupart des pages, l'élément LCP est l'image hero ou le titre principal.

Le score est bon en dessous de 2,5 secondes. Dans les notes de version CrUX d'août 2026, 68,1 % des origines y parviennent, soit le taux le plus bas des trois.

Le LCP suit ce que voit le visiteur. Dès que le plus grand élément est à l'écran, la plupart des gens pensent que la page est prête, même si des scripts continuent de charger. Cette métrique a été conçue pour répondre à une question : « Quand le contenu d'une page est-il visible ? ».

Quand l'élément LCP tarde à s'afficher, la cause est souvent banale. loading="lazy" sur l'image hero. Une image hero définie en arrière-plan CSS, que le navigateur ne découvre qu'après réception de la feuille de style. Un script de slider qui doit s'exécuter avant d'afficher le premier slide. Corrigez d'abord la découverte, puis préchargez l'image si le HTML la masque encore, attribuez-lui fetchpriority="high" et réduisez la taille du fichier. Le guide du Largest Contentful Paint détaille les quatre phases du LCP.

Interaction to Next Paint (INP) : interactivité

L'Interaction to Next Paint mesure l'interactivité : le délai nécessaire pour mettre à jour l'écran après qu'un visiteur a cliqué, appuyé ou pressé une touche. Le défilement et le survol ne comptent pas.

Chaque interaction est chronométrée depuis l'entrée utilisateur, en passant par le JavaScript qu'elle déclenche, jusqu'à l'affichage de la frame suivante. La page retient la durée de son interaction la plus lente. Sur les pages comportant beaucoup d'interactions, Google ignore une valeur aberrante toutes les 50 interactions, ce qui correspond environ au 98e percentile.

Un audit Lighthouse classique ne peut pas mesurer l'INP. Il charge la page sans jamais cliquer sur rien. La métrique de lab la plus proche est le Total Blocking Time. L'INP est généralement bien inférieur au TBT, mais quand le TBT baisse, l'INP a tendance à suivre.

Souvent, le gestionnaire de clic est rapide en lui-même. C'est le main thread qui est occupé par autre chose au moment du clic : un tag manager, un widget de chat, un framework encore en cours d'hydratation. La majeure partie de ce JavaScript peut être différée ou planifiée. 85,3 % des origines affichaient un bon INP en août 2026, contre 87,2 % en mars (notes de version CrUX). C'est le seul Core Web Vital qui s'est dégradé au cours de l'année passée. Le guide de l'Interaction to Next Paint montre comment repérer les interactions lentes.

Cumulative Layout Shift (CLS) : stabilité visuelle

Le Cumulative Layout Shift mesure la stabilité visuelle : l'ampleur des mouvements de contenu visible sans action du visiteur. Vous voulez appuyer sur un lien et la page saute.

Chaque décalage reçoit un score : la fraction d'impact (la part du viewport touchée) multipliée par la fraction de distance (la distance parcourue par le contenu, par rapport au viewport). Les décalages rapprochés sont cumulés dans une session window. Le CLS de la page correspond à sa pire session window.

Les causes habituelles : des images sans dimensions width et height ; des publicités, bannières de cookies et embeds qui repoussent le contenu vers le bas à leur arrivée ; ou une police web plus large ou plus haute que son fallback. Pour les polices, auto-hébergez-les et choisissez le bon réglage de font-display. Le CLS est la métrique la mieux maîtrisée par les sites : 81,5 % des origines avaient un bon CLS en août 2026. Plus de détails dans le guide du Cumulative Layout Shift.

Pourquoi les Core Web Vitals sont importants

• Les visiteurs partent. Un bouton qui ne réagit pas pendant une demi-seconde reçoit deux clics, puis la page est abandonnée. Google a réuni des études de cas de sites ayant corrigé leurs Core Web Vitals, avec à la clé une baisse du taux de rebond et davantage de conversions.
• Le positionnement. Les Core Web Vitals sont un facteur de classement pour Google. Un facteur mineur. Quand deux pages se valent, la plus rapide prend l'avantage.
• Le mobile. La majorité du trafic se fait probablement sur mobile, et c'est là que les pages échouent. Le Web Almanac 2025 (la dernière édition) montre que 48 % des pages mobiles valident le test, contre 56 % sur ordinateur.
• Google Ads. La convivialité de la page de destination influe sur votre Quality Score. Une landing page lente le tire vers le bas, et chaque clic coûte plus cher.

Google documente aussi précisément la manière dont chaque métrique est mesurée, jusqu'au code source du navigateur. Pour un facteur de classement, c'est presque du jamais vu.

Étude de cas Vodafone

Vodafone Italie a amélioré son Largest Contentful Paint de 31 % et a obtenu 8 % de ventes en plus, 15 % de leads supplémentaires et une progression de 11 % du ratio panier par visite (source : étude de cas web.dev).

Field data vs. lab data

Les field data (aussi appelées données de Real User Monitoring ou RUM) proviennent de vos vrais visiteurs, sur leurs propres appareils et réseaux. Le jeu de données CrUX de Google regroupe des field data d'utilisateurs de Chrome ayant donné leur accord. Les Core Web Vitals reposent exclusivement sur des field data.

Les lab data proviennent d'un test sur un appareil simulé dans un environnement fixe. Lighthouse et WebPageTest produisent des lab data. Un test en lab produit à peu près le même résultat à chaque exécution, ce qui en fait un bon outil de débogage. Il ne reflète pas ce que vivent vos visiteurs.

Lighthouse affiche 100, alors pourquoi est-ce que j'échoue ?

Parce que Google se base sur CrUX pour son classement, alors que Lighthouse ne teste qu'une seule visite simulée. Vos visiteurs utilisent des téléphones Android d'entrée de gamme et le mauvais Wi-Fi d'un hôtel, et ils cliquent sur des éléments auxquels Lighthouse ne touche jamais. L'INP n'existe même pas dans un test Lighthouse.

CrUX indique une réussite ou un échec par groupe d'URL. Pour savoir quelle page, quel appareil et quel élément sont à l'origine de l'échec, j'utilise le Real User Monitoring : CoreDash, que j'ai conçu exactement pour cela. Il segmente les données par appareil, pays et gabarit de page, et pointe l'élément LCP ou l'interaction qui est lente.

Comment mesurer les Core Web Vitals

Comparatif des outils de mesure

Données CrUX

Le jeu de données CrUX contient les Core Web Vitals de chaque site disposant d'un trafic Chrome suffisant. C'est le jeu de données officiel du programme Web Vitals. Vous pouvez y accéder de plusieurs manières :

1. CrUX Vis montre l'évolution des scores d'une origine ou d'une URL sur les derniers mois. Il remplace l'ancien CrUX Dashboard sous Looker Studio, fermé par Google fin 2025.
2. CrUX sur BigQuery contient les données au niveau origine de tous les sites présents dans CrUX, avec des histogrammes complets par métrique, mis à jour chaque mois. Idéal pour comparer un site à ses concurrents.
3. L'API CrUX fournit les données par page ou par origine, filtrées par type d'appareil et par métrique, pour intégrer les chiffres dans vos propres outils.
4. PageSpeed Insights affiche les données CrUX d'une URL au-dessus d'un rapport Lighthouse. Il s'ouvre sur l'onglet mobile. Restez-y : l'onglet desktop est souvent vert et fait croire à tort que le site est validé.

Le suivi avec le RUM

Les données RUM proviennent d'un petit script installé sur votre site qui mesure chaque visite. Il mesure les mêmes Core Web Vitals que CrUX, avec les détails que CrUX laisse de côté. CrUX est anonymisé, s'arrête au niveau de l'URL et porte toujours sur les 28 derniers jours. Le RUM vous montre les chiffres d'hier, par page, appareil, pays et navigateur, et il indique quel élément cause le LCP lent ou le décalage de mise en page. C'est pour cela que la plupart des professionnels qui optimisent les Core Web Vitals utilisent le RUM aux côtés de CrUX.

Lighthouse

Lighthouse ne mesure pas les Core Web Vitals. Il charge une page, une seule fois, sur un téléphone simulé avec une connexion bridée. Il démarre avec un cache vide, ne navigue jamais vers une deuxième page et ne clique sur rien.

Cela reste le moyen le plus rapide de voir ce qui bloque le rendu, quelle image correspond à l'élément LCP et quels scripts saturent le main thread. Ignorez cependant la moitié de la liste. Minifier le CSS fait gagner quelques kilo-octets et aucun visiteur ne s'en rendra compte.

Lancez-le dans PageSpeed Insights, dans les Chrome DevTools ou avec l'outil en ligne de commande Lighthouse.

Combien de sites valident les Core Web Vitals ?

L'équipe de Chrome publie les chiffres CrUX chaque mois, le deuxième mardi, dans les notes de version CrUX. Voici la proportion d'origines qui obtiennent un bon score, tous appareils confondus :

Comparez le même mois d'une année sur l'autre. Décembre fluctue chaque année (l'équipe Chrome le constate depuis le lancement de CrUX) ; un mauvais mois ne veut donc pas dire grand-chose. Pour le TTFB et le FCP, qui ne figurent pas dans les notes de version, consultez le guide du Time to First Byte et le guide du First Contentful Paint.

Comment améliorer les Core Web Vitals

Par où je commence : le p75 de chaque métrique sur mobile, puis le groupe d'URL signalé par Search Console, puis la tendance. Une chute brutale pointe généralement vers un deploy. Une dégradation lente trahit des scripts tiers qui s'accumulent, tag après tag.

Chaque mise en ligne peut casser quelque chose, continuez donc de surveiller vos field data après le déploiement du fix. De plus, les métriques interagissent entre elles. font-display: swap affiche le texte plus tôt à l'écran, ce qui peut aider le LCP, mais quand la police web a des dimensions différentes du fallback, le swap entraîne un layout shift. Voici un guide par métrique :

• Améliorer le Largest Contentful Paint
• Améliorer l'Interaction to Next Paint
• Améliorer le Cumulative Layout Shift

Deux métriques de diagnostic freinent le LCP :

• Time to First Byte (TTFB) : le navigateur ne peut pas commencer à traiter la page avant la réception du HTML. Avec un TTFB lent, un bon LCP est presque impossible. Mettre le HTML en cache sur votre CDN est généralement le gain le plus rapide.
• First Contentful Paint (FCP) : le tout premier affichage de contenu. Jusque-là, le visiteur regarde un écran blanc.

Pour une méthode pas à pas, consultez la Checklist des Core Web Vitals.

Les Core Web Vitals dans Search Console

Google regroupait auparavant les Core Web Vitals avec le HTTPS, l'ergonomie mobile et les interstitiels intrusifs sous l'appellation « page experience ». Google a retiré le rapport Page Experience de Search Console en novembre 2024. Le rapport Core Web Vitals est toujours présent, sous « Expérience ».

Ce rapport regroupe vos URL par gabarit et montre quels groupes valident le test. Il couvre les 28 derniers jours ; ainsi, deux semaines après la mise en ligne d'un fix, la moitié des données affichées correspond encore à l'ancien site.