Core Web Vitals en échec ? Comment corriger LCP, INP et CLS

Par SEOgrinder · Publié le 4 novembre 2026 · 10 min de lecture

Réponse courte : Une évaluation des Core Web Vitals en échec signifie qu’au moins une de trois mesures dépasse son seuil chez les visiteurs réels : le LCP (chargement) doit être de 2,5 secondes ou moins, l’INP (réactivité) de 200 millisecondes ou moins et le CLS (stabilité visuelle) de 0,1 ou moins, chacun mesuré au 75e centile. Repérez la mesure en échec dans les données de terrain, celles des visiteurs réels, et non dans le score de laboratoire, et corrigez d’abord celle-là. Google dit que ses systèmes de classement utilisent les Core Web Vitals, mais de bonnes valeurs ne garantissent pas une place en tête.

Que signifie « Core Web Vitals en échec » ?

Les Core Web Vitals sont la partie de l’initiative Web Vitals de Google qui s’applique à toutes les pages web. web.dev nomme trois mesures, une pour chaque aspect de l’expérience :

Mesure	Ce qu’elle mesure	Bonne valeur
LCP, Largest Contentful Paint	Chargement : moment où apparaît la plus grande image, le plus grand bloc de texte ou la plus grande vidéo de la zone visible	2,5 secondes ou moins
INP, Interaction to Next Paint	Réactivité : rapidité avec laquelle la page réagit visiblement à un clic, un toucher ou une touche	200 millisecondes ou moins
CLS, Cumulative Layout Shift	Stabilité visuelle : degré auquel le contenu visible bouge pendant que vous utilisez la page	0,1 ou moins

Les valeurs sont jugées au 75e centile des chargements de page, séparément pour mobile et pour ordinateur. En clair : pour trois visites sur quatre, la valeur doit être bonne, et le mobile et l’ordinateur reçoivent chacun leur verdict. web.dev indique aux outils de considérer une page comme réussie si elle atteint les objectifs au 75e centile pour les trois mesures. Une seule mesure dans le rouge suffit donc pour échouer.

Un détail à la limite : web.dev dit que l’INP et le CLS doivent être « ou moins », alors que la documentation de Google sur la recherche dit « moins de 200 millisecondes » et « moins de 0,1 ». Visez nettement sous la limite et la différence n’a plus d’importance.

Un changement à connaître : l’INP a remplacé le First Input Delay (FID) comme Core Web Vital en mars 2024, comme l’indique l’annonce de web.dev. Un guide qui cite encore le FID est dépassé. Nous avons lu toutes les pages citées dans cet article le 4 novembre 2026 ; la vue d’ensemble de web.dev a été mise à jour pour la dernière fois le 31 octobre 2024.

Les Core Web Vitals influencent-ils le classement dans Google ?

Oui, selon Google, mais sans donner de poids. La page de Google sur l’expérience de page dit : « Core Web Vitals are used by our ranking systems. » Elle recommande de bonnes valeurs pour réussir dans la recherche, et ajoute qu’il n’existe pas de signal unique d’expérience de page.

La même page est tout aussi claire sur les limites. De bons résultats dans le rapport Core Web Vitals de la Search Console ou dans des outils tiers « doesn’t guarantee that your pages will rank at the top of Google Search results ». Elle dit aussi que viser un score parfait uniquement pour le SEO n’est peut-être pas le meilleur usage de votre temps. Google cherche toujours à montrer le contenu le plus pertinent, même quand l’expérience de page est médiocre.

Google ne publie pas le poids de ces mesures, et nous n’avançons donc aucun chiffre non plus. Notre lecture, qui n’est pas une information de Google : voyez les seuils comme un niveau de qualité pour vos visiteurs, amenez les trois mesures dans le vert, puis réinvestissez votre temps dans le contenu. Les systèmes de classement principaux de Google évaluent en général le contenu page par page : vérifiez donc chaque type de page important.

Données de laboratoire ou de terrain : lesquelles comptent pour les Core Web Vitals ?

L’évaluation repose sur les données de terrain : des mesures de visites réelles. Le Chrome User Experience Report (CrUX) de Google les collecte auprès d’utilisateurs réels de Chrome ; PageSpeed Insights et le rapport Core Web Vitals de la Search Console les affichent. D’après web.dev, un rapport CrUX couvre une période de 28 jours.

Les données de laboratoire viennent d’un chargement unique de la page dans un cadre contrôlé : un appareil, un réseau, un lieu. C’est idéal pour trouver des causes et tester une correction avant sa mise en ligne, mais le guide du LCP prévient : « lab tests alone may not be entirely representative ». Quand les deux divergent, le guide du LCP dit de se concentrer d’abord sur les données des utilisateurs réels. Elles diffèrent pour de bonnes raisons :

L’élément LCP peut différer. Un test en laboratoire trouve toujours le même élément. Les visites réelles ont d’autres tailles d’écran, du contenu réservé aux utilisateurs connectés ou des tests A/B.
L’INP a besoin de vraies personnes. Lighthouse et les autres outils de laboratoire chargent une page sans que personne ne clique : ils ne peuvent donc pas mesurer l’INP. Le Total Blocking Time (TBT) en est le substitut en laboratoire ; améliorer le TBT peut améliorer l’INP.
Le CLS continue de compter après le chargement. Les tests en laboratoire ne voient surtout que le chargement lui-même. Sur le terrain, un contenu qui apparaît pendant que les visiteurs font défiler la page peut aussi décaler la mise en page.
Les caches aident les visiteurs réels. Les tests en laboratoire partent en général d’un cache vide, alors que les visiteurs qui reviennent et le cache de navigation avant/arrière (bfcache) chargent les pages plus vite.

Comment lire vos chiffres en quatre étapes :

Testez votre adresse dans PageSpeed Insights. Dans l’interface en anglais, la section « Discover what your real users are experiencing » contient les données de terrain ; « Diagnose performance issues » contient le test en laboratoire.
Vérifiez ce que vous regardez. Basculez entre mobile et ordinateur, et entre l’URL seule et l’ensemble de l’origine. Si une URL a trop peu de données, PageSpeed Insights affiche à la place les données de l’origine.
Trouvez la mesure qui dépasse sa limite au 75e centile. C’est votre mesure en échec. Avec trop peu de trafic, il n’y a pas de données de terrain ; utilisez alors les valeurs de laboratoire et mesurez vos propres visiteurs avec la petite bibliothèque web-vitals de web.dev.
Ouvrez le diagnostic de laboratoire de cette mesure pour voir la cause, et corrigez d’abord cette seule chose.

Comment corriger le LCP : le plus grand élément apparaît trop tard

Le LCP indique quand la plus grande image, le plus grand bloc de texte ou la plus grande vidéo de la zone visible est affiché. Le guide du LCP de web.dev répartit le temps en quatre parties dont la somme donne le LCP : la réponse du serveur (TTFB), le délai avant que le navigateur commence à charger la ressource LCP, le temps de chargement de cette ressource, et le délai avant l’affichage de l’élément. Cherchez la plus grosse partie avant de rien changer : réduire une partie peut simplement déplacer le temps vers une autre. Une image compressée n’aide pas si l’élément reste caché tant qu’un script n’est pas chargé.

La liste des correctifs les plus efficaces de l’équipe Chrome comprend ceux-ci :

Rendez l’image LCP facile à trouver et donnez-lui la priorité. Utilisez un <img> normal avec src ou srcset, pas un data-src qui exige du JavaScript. Préférez le rendu côté serveur à une page construite uniquement dans le navigateur. Ajoutez fetchpriority="high" et retirez loading="lazy" de cette seule image.
Raccourcissez la réponse du serveur. Servez et mettez en cache le contenu près de vos visiteurs, en général avec un CDN.

La même balise traite le LCP et, par sa taille, le CLS :

<!-- Image principale : dans le HTML, priorité haute, pas en lazy, avec ses dimensions -->
<img src="/img/hero.webp" width="1200" height="630" alt="Courte description" fetchpriority="high">

<!-- Images plus bas dans la page : le chargement différé convient ici -->
<img src="/img/equipe.webp" width="600" height="400" alt="Courte description" loading="lazy">

Comment corriger l’INP : la page réagit trop lentement

L’INP observe chaque clic, chaque toucher et chaque pression de touche pendant une visite, et rapporte à peu près le plus lent (pour les pages comptant énormément d’interactions, les valeurs aberrantes sont écartées). Le survol à la souris et le défilement ne comptent pas. D’après le guide de l’INP, chaque interaction comporte trois parties : le délai d’entrée, la durée d’exécution des gestionnaires d’événements, et le délai avant l’affichage de l’image suivante. Le coupable habituel est du JavaScript qui occupe le thread principal. Les principaux correctifs de l’équipe Chrome :

Découpez les tâches longues. Une tâche de plus de 50 millisecondes bloque le thread principal. Rendez souvent la main : scheduler.yield() là où le navigateur le prend en charge, setTimeout à l’ancienne.
Livrez moins de JavaScript. Repérez le code inutilisé avec l’outil de couverture des Chrome DevTools, découpez le code qui n’est pas nécessaire au départ et nettoyez les anciennes balises de votre gestionnaire de balises.
Évitez les grosses mises à jour du rendu. Gardez le DOM petit, évitez les mises en page forcées et utilisez le confinement CSS (CSS containment) pour le contenu hors écran.

Comment corriger le CLS : la mise en page saute

Le CLS n’a pas d’unité. Il combine la quantité de contenu visible qui a bougé et la distance parcourue. Sur le terrain, il compte sur toute la visite, mais les décalages survenus dans les 500 millisecondes suivant une interaction de l’utilisateur sont exclus. Le guide du CLS de web.dev énumère les causes courantes : images sans dimensions, publicités, intégrations et iframes sans dimensions, contenu injecté dynamiquement et polices web. Ce qui aide :

Réservez de la place. Donnez à vos images et vidéos width et height, ou utilisez la propriété CSS aspect-ratio. Pour un contenu de taille inconnue, une min-height raisonnable vaut mieux que la valeur par défaut, zéro.
Animez avec transform. Animer top, left ou margin décale la mise en page. Les bannières de cookies qui glissent dans la page en sont un cas typique.
Laissez le cache de navigation avant/arrière travailler. Il restaure des pages entièrement affichées. Les blocages courants sont les directives de cache no-store et les écouteurs d’événement unload.
Maîtrisez les polices web. font-display: optional, des polices de secours adaptées avec size-adjust et le préchargement des polices critiques réduisent les décalages liés aux polices.

Comment SEOgrinder vérifie les Core Web Vitals

SEOgrinder est notre outil ; nous le développons. Saisissez une adresse publique sur SEOgrinder et les chiffres de vitesse viennent de Google PageSpeed Insights, pour mobile et pour ordinateur. La carte « Core Web Vitals » affiche le LCP et le CLS issus du test en laboratoire de Lighthouse et l’INP issu de visiteurs réels, et un encadré distinct montre les données de visiteurs réels des 28 derniers jours. Si Google a trop peu de données pour la page, le rapport le dit au lieu de deviner. Des tâches comme « Les visiteurs réels sur mobile attendent le contenu pendant … » nomment la mesure, la valeur et la correction. Une réponse serveur lente, qui pèse sur le LCP, a sa propre tâche.

Limites : SEOgrinder lit les chiffres de Google et ne remplace pas votre propre suivi des visiteurs réels. Il ne mesure pas les classements. Si le quota quotidien de Google pour la mesure de vitesse est épuisé, le rapport est fourni sans elle.

Erreurs fréquentes

Se fier uniquement au score de laboratoire. Il ne peut pas mesurer l’INP et peut différer de ce que vivent les visiteurs. Commencez par les valeurs des visiteurs réels.
Ne vérifier qu’un seul appareil. Mobile et ordinateur sont jugés séparément.
Charger l’image principale en lazy. loading="lazy" sur l’image LCP ajoute du délai.
Oublier les dimensions des images. Sans width et height, le navigateur ne peut pas réserver de place.
Corriger la mauvaise partie du LCP. Ne compressez les images qu’une fois que la répartition montre que le temps de chargement est le problème.
Attendre un résultat immédiat. Les données de terrain couvrent 28 jours : elles évoluent progressivement. Vérifiez le test en laboratoire juste après une correction, et les chiffres des visiteurs réels dans les semaines qui suivent.

Questions fréquentes

Qu’est-ce qu’un bon score aux Core Web Vitals ?

Il n’y a pas de score unique. Une page réussit quand le LCP est de 2,5 secondes ou moins, l’INP de 200 millisecondes ou moins et le CLS de 0,1 ou moins, au 75e centile. Le nombre de 0 à 100 que vous connaissez peut-être grâce à Lighthouse est une valeur de laboratoire, et c’est autre chose.

Pourquoi PageSpeed Insights n’affiche-t-il aucune donnée de visiteurs réels pour mon site ?

Il y a généralement trop peu de visites pour que CrUX puisse rapporter quoi que ce soit. web.dev suggère alors d’ajouter votre propre mesure des visiteurs réels. D’ici là, travaillez à partir des valeurs de laboratoire.

Faut-il un score parfait ?

Non. Réussir est l’objectif. Google dit lui-même que viser un score parfait uniquement pour des raisons de SEO n’est peut-être pas le meilleur usage de votre temps.

Votre prochaine étape

Faites passer votre page la plus importante dans SEOgrinder, ouvrez la carte « Core Web Vitals » et regardez d’abord les valeurs des visiteurs réels. Corrigez la seule mesure qui échoue, cliquez sur Réanalyser et lisez les valeurs de laboratoire. Pour une vue d’ensemble, consultez notre checklist audit SEO.