Core Web Vitals 2026 : comprendre LCP, INP et CLS

En bref : quelles valeurs viser ?

Au 75e centile des visites réelles, visez un LCP de 2,5 secondes ou moins, un INP de 200 millisecondes ou moins et un CLS de 0,1 ou moins, en contrôlant mobile et ordinateur séparément. Un bon score Lighthouse aide à trouver les causes d’un problème ; elle ne prouve pas que vos visiteurs obtiennent ces valeurs.

Les trois métriques et leurs seuils

Chaque métrique a une limite « bonne » et une limite « mauvaise » ; entre les deux, la valeur est à améliorer. Une page est conforme quand les trois métriques sont bonnes au 75e centile, c’est-à-dire pour au moins trois visites sur quatre.

Largest Contentful Paint (LCP) : bon jusqu’à 2,5 s, mauvais au-delà de 4 s. Il marque l’affichage du plus grand bloc d’image ou de texte visible à l’écran.
Interaction to Next Paint (INP) : bon jusqu’à 200 ms, mauvais au-delà de 500 ms. Il mesure le délai entre un clic, un appui ou une touche et la mise à jour suivante de l’affichage, sur toute la durée de la visite.
Cumulative Layout Shift (CLS) : bon jusqu’à 0,1, mauvais au-delà de 0,25. Il additionne les déplacements inattendus, comme un texte qui saute quand une image ou un bandeau se charge en retard.

Les seuils sont ceux que Google publie sur web.dev. L’INP est devenu une Core Web Vital stable en 2024, à la place du First Input Delay (FID) : un outil ou un rapport qui vous note encore sur le FID n’est plus à jour. Dans sa documentation en français, Google emploie le terme anglais, mais aussi « signaux Web essentiels » (Google Search Central) : c’est la même chose.

Données de terrain et données de laboratoire

Les données de terrain viennent d’utilisateurs réels de Chrome, via le Chrome UX Report (CrUX), agrégées sur les 28 derniers jours. Ce sont elles que Google utilise. Un petit site n’en a souvent pas, faute de trafic suffisant pour les publier ; PageSpeed se rabat alors sur l’ensemble du domaine, puis n’affiche rien si le domaine manque lui aussi de données (documentation PageSpeed Insights).

Les données de laboratoire viennent d’un chargement simulé par Lighthouse, en général sur un téléphone de milieu de gamme bridé. Elles sont reproductibles et parfaites pour chercher une cause, mais elles ne peuvent pas mesurer l’INP, puisque personne n’interagit avec la page. Lighthouse affiche à la place le Total Blocking Time (TBT), qui révèle les mêmes problèmes de scripts.

Servez-vous du laboratoire pour trouver la cause et du terrain pour vérifier que la correction profite aux vrais visiteurs. Les chiffres de terrain évoluent lentement : la fenêtre de 28 jours doit d’abord se renouveler.

Diagnostiquer une page lente en cinq minutes

Testez l’URL exacte sur mobile. Notez l’élément LCP, les requêtes qui bloquent l’affichage et les images lourdes.
Regardez les données de terrain à part. Si CrUX n’en a pas, notez-le comme un manque de trafic, ni réussite ni échec.
Repérez le retard principal. Une grande image d’en-tête ne se corrige pas comme un serveur lent ou un script qui bloque les interactions.
Corrigez une cause, puis testez de nouveau la même URL, en notant ce qui a changé.
Suivez la tendance. Les scores de laboratoire bougent tout de suite ; les Core Web Vitals de terrain changent progressivement.

Testez la vitesse de votre page gratuitement : l’analyse lance Google PageSpeed sur mobile et ordinateur pour une URL. La page test de vitesse de site web explique comment les deux résultats forment un seul score.

Améliorer le LCP

Un LCP lent vient presque toujours de l’un de ces quatre points : un serveur qui répond tard, une feuille de style ou un script qui bloque l’affichage, une image principale découverte trop tard, ou une image simplement trop lourde.

Gardez un temps de réponse serveur (TTFB) bas grâce au cache de pages et, si vos visiteurs sont loin du serveur, à un CDN.
Ne chargez pas l’image principale en différé. Donnez-lui fetchpriority="high" et, si elle est définie en CSS, préchargez-la.
Servez-la en AVIF ou WebP, à la taille où elle s’affiche, avec srcset pour les différents écrans.
Intégrez le CSS critique ou gardez la feuille de style principale légère, et différez les scripts inutiles au premier affichage.
Remplacez les carrousels d’en-tête et les vidéos en lecture automatique par une seule image forte quand c’est possible.

Améliorer l’INP

Un INP médiocre signifie que le fil principal du navigateur est occupé au moment où l’utilisateur agit. Le JavaScript lourd en est la cause habituelle, et les scripts tiers en représentent souvent une grande part.

Supprimez les scripts qui ne servent plus : restes d’anciennes extensions, de modules désactivés ou de tests dans le gestionnaire de balises.
Chargez le chat, les cartes de chaleur et les widgets d’avis après que la page est devenue interactive, ou seulement quand l’utilisateur les ouvre.
Découpez les tâches longues et gardez les gestionnaires de clic légers, pour que le navigateur puisse redessiner vite après chaque action.
Évitez les DOM gigantesques : un très grand menu ou une grille de produits interminable ralentit chaque mise à jour.

Améliorer le CLS

La mise en page bouge quand le navigateur ne sait pas, avant le chargement, quelle place un élément va prendre.

Indiquez width et height (ou aspect-ratio) sur chaque image, vidéo et iframe.
Réservez la place des emplacements publicitaires, des vidéos intégrées et de la bannière de consentement aux cookies, au lieu de pousser le contenu vers le bas quand ils apparaissent.
Utilisez font-display: swap avec une police de secours de taille proche, ou préchargez la police principale, pour limiter le recalage du texte.
N’insérez jamais de contenu au-dessus du contenu existant, sauf à la demande de l’utilisateur.

Ce que montre le rapport Sitequiry

Sitequiry lance Google PageSpeed Insights sur mobile et ordinateur et affiche le LCP, le FCP, le TBT et le CLS sur des échelles qui reprennent les seuils ci-dessus, avec la bande d’images du chargement et le poids de la page par type de ressource. Quand Google dispose de données de terrain CrUX pour l’URL ou pour le domaine, le rapport les utilise aussi. Si PageSpeed ne répond pas, le rapport le dit et présente le score de vitesse comme une estimation, sans inventer de chiffres.

Questions fréquentes

Les Core Web Vitals sont-elles un facteur de classement ?

Google indique qu’elles sont utilisées par ses systèmes de classement, mais qu’il montre toujours le contenu le plus pertinent, même quand l’expérience sur la page est décevante (Google Search Central). De bonnes valeurs comptent surtout quand plusieurs résultats se valent, et elles changent l’expérience de chaque visiteur.

Pourquoi mon score PageSpeed change-t-il d’un test à l’autre ?

Un test de laboratoire dépend du réseau, de la charge du serveur et des scripts tiers au moment du passage. Quelques points d’écart sont normaux : suivez la tendance et les métriques une par une plutôt qu’un score isolé.

Mon site n’a pas de données de terrain. Est-ce un problème ?

Non. Cela signifie seulement que le trafic Chrome est insuffisant pour que CrUX publie des chiffres. Les mesures de laboratoire suffisent pour trouver et corriger les problèmes ; les données de terrain apparaîtront d’elles-mêmes avec le trafic.

Faut-il optimiser d’abord le mobile ou l’ordinateur ?

En général le mobile : Google utilise la version mobile du contenu pour l’indexation et le classement, et les téléphones sont plus lents. Vérifiez quand même la répartition dans vos statistiques : si la plupart de vos visiteurs sont sur ordinateur, leurs données de terrain comptent autant.

Pourquoi Lighthouse est-il bon alors que CrUX échoue ?

Lighthouse simule un chargement sur un appareil, alors que CrUX reflète 28 jours de visites réelles sur toutes sortes d’appareils et de réseaux. Les téléphones lents, les scripts tiers chargés plus tard et les interactions sur des pages chargées n’apparaissent que sur le terrain.

Pourquoi l’INP manque-t-il dans un rapport de laboratoire ?

L’INP a besoin de vraies interactions, et un test de laboratoire ne clique ni ne tape. Lighthouse affiche à la place le Total Blocking Time, qui pointe vers les mêmes problèmes de fil principal.

Quelle Core Web Vital corriger en premier ?

Celle qui échoue sur le terrain, mobile d’abord. Sans données de terrain, commencez par le LCP : c’est l’échec le plus fréquent, et sa cause est souvent claire, comme une grande image d’en-tête ou un serveur lent.

Core Web Vitals en 2026 : LCP, INP et CLS expliqués