Guide technique 2 350 mots · 11 minutes Mis à jour

Core Web Vitals : LCP, INP, CLS, les 3 métriques qui décident du SEO en 2026.

Depuis le 12 mars 2024, INP a remplacé FID. Trois métriques en tout, trois seuils définis par Google, et un rapport dédié dans la Search Console. Ce guide pose les définitions officielles, donne les seuils à viser, montre comment mesurer correctement, et liste les dix leviers techniques qui font vraiment bouger l'aiguille. Sources web.dev et Google Search Central, vérifiables.

Voir le tableau des seuils
YS
Yonel Sasson
Fondateur Getknown · 10 ans SEO + 4 ans GEO
Section 01 · Définition

Qu'est-ce que les Core Web Vitals ?

Les Core Web Vitals sont un ensemble de trois métriques, définies par Google, qui mesurent la qualité de l'expérience utilisateur réelle sur une page web. Chargement perçu, réactivité aux interactions, stabilité visuelle. Trois axes, trois indicateurs, trois seuils chiffrés.

Définition officielle Google

Les signaux web essentiels sont un sous-ensemble des Web Vitals qui s'appliquent à toutes les pages web. Ils évaluent l'expérience utilisateur réelle en fonction des performances de chargement, de l'interactivité et de la stabilité visuelle de la page. Source : web.dev/articles/vitals et developers.google.com.

Trois précisions valent la peine d'être posées d'entrée. Premièrement, ces signaux évoluent. Le programme a démarré en mai 2020 avec LCP, FID et CLS. FID a été remplacé par INP le 12 mars 2024, après vingt-deux mois de phase pending. Deuxièmement, la mesure officielle se fait sur le terrain, pas en laboratoire. Google calcule au 75e percentile des chargements de page observés via le Chrome User Experience Report sur une fenêtre glissante de 28 jours. Troisièmement, mobile et desktop sont évalués séparément. Une page peut être good en desktop et poor en mobile, et c'est la version mobile qui sert au classement depuis le mobile-first indexing.

Le rapport dédié dans la Search Console agrège vos URLs en trois catégories : good, needs improvement, poor. Pour qu'un groupe d'URLs soit qualifié good, il doit valider les trois métriques simultanément au 75e percentile. Un seul indicateur dans le rouge bascule l'ensemble dans la catégorie correspondante.

Section 02 · LCP

LCP — Largest Contentful Paint, ce qui ralentit votre page.

Le LCP mesure le temps écoulé entre le début du chargement de la page et le moment où le plus grand élément de contenu visible dans la fenêtre est rendu. Image héros, vidéo, bloc de titre, image de fond CSS. Cet élément varie d'une page à l'autre, et l'identifier précisément est la première étape de tout audit.

Métrique LCP

Largest Contentful Paint

Vitesse de chargement perçue · 75e percentile
Good≤ 2,5 secondes
À améliorer2,5 – 4,0 secondes
Poor> 4,0 secondes

Le LCP a quatre composants additifs : temps avant le premier octet (TTFB), délai de chargement de la ressource LCP, temps de chargement de la ressource elle-même, délai de rendu. Optimiser un LCP sans savoir lequel des quatre est le coupable revient à tirer dans le brouillard.

Causes fréquentes d'un LCP dégradé :

  • Image héros lourde, non compressée, sans format moderne (AVIF, WebP)
  • Police web bloquante chargée sans font-display: swap
  • JavaScript critique placé en tête de page sans defer ou async
  • Hébergement lent ou absence de CDN sur les ressources statiques
  • Rendu côté serveur absent sur un site React, Vue ou Angular pur SPA

Le LCP est la métrique qui montre la corrélation la plus forte avec la position de classement selon l'étude Advanced Web Ranking sur 3 millions de pages : les pages classées entre les positions 1 et 3 affichent un LCP mesurablement plus bas que celles classées entre 8 et 10. Source détaillée en bas de page.

Section 03 · INP

INP — Interaction to Next Paint, la métrique qui a remplacé FID.

FID, le First Input Delay, mesurait la latence de la première interaction utilisateur uniquement. L'industrie a documenté pendant des années que cette mesure était trop indulgente. La majorité des sites validaient FID sans pour autant être réactifs au quotidien. Google a donc introduit INP, qui observe toutes les interactions sur la durée de vie d'une page, et retient la plus mauvaise en valeur 98e percentile.

Métrique INP

Interaction to Next Paint

Réactivité · stable depuis le 12 mars 2024
Good≤ 200 millisecondes
À améliorer200 – 500 millisecondes
Poor> 500 millisecondes

INP additionne trois durées pour chaque interaction observée : input delay, processing duration, presentation delay. Une interaction lente signifie qu'au moins un de ces trois segments dépasse son budget temporel.

Causes fréquentes d'un INP dégradé :

  • Longues tâches JavaScript bloquant le main thread plus de 50 ms
  • DOM trop volumineux qui ralentit les recalculs de mise en page
  • Event handlers synchrones lourds, sans découpage en chunks via setTimeout ou scheduler.yield()
  • Scripts tiers (analytics, A/B testing, chat) qui se déclenchent sur chaque interaction
  • Hydratation React ou Vue trop volumineuse au premier rendu

INP est la métrique qui demande le plus de travail aux équipes techniques, car elle révèle des problèmes que LCP et CLS masquent. Selon les données CrUX publiées par DebugBear, INP est en 2025-2026 le signal le plus discriminant sur les marchés concurrentiels en français, notamment dans l'e-commerce et la finance.

Section 04 · CLS

CLS — Cumulative Layout Shift, éviter les sauts visuels.

Le CLS est un score sans unité, cumulé sur la durée de vie d'une page, qui mesure les décalages inattendus d'éléments affichés. Une bannière publicitaire qui pousse le contenu vers le bas après quelques secondes. Une image dont la hauteur n'est définie qu'après chargement. Une police web qui change la taille du texte une fois téléchargée. Chaque décalage est un point CLS qui s'additionne.

Métrique CLS

Cumulative Layout Shift

Stabilité visuelle · score cumulé sans unité
Good≤ 0,1
À améliorer0,1 – 0,25
Poor> 0,25

Le CLS prend en compte les fenêtres glissantes de 5 secondes maximum, séparées d'au moins une seconde, et retient la pire de toutes. Le scroll utilisateur ne compte pas comme un layout shift. Seuls les décalages inattendus sont mesurés.

Causes fréquentes d'un CLS dégradé :

  • Images sans attribut width et height ou sans aspect-ratio CSS
  • Bannières publicitaires injectées sans réservation d'espace
  • Polices web qui produisent un FOUT (flash of unstyled text) avec un swap brutal
  • Carrousels et widgets tiers chargés en JavaScript avec du contenu de hauteur variable
  • Boutons « accepter cookies » qui poussent du contenu en bas de viewport

Le CLS est la métrique la plus facile à corriger des trois. Quelques lignes de CSS — déclarer la taille des médias, réserver les zones d'annonce, gérer les fontes proprement — suffisent dans la majorité des cas. C'est aussi la métrique que les équipes intègrent rarement dans leur chaîne d'intégration continue, et le poste où une régression silencieuse fait le plus de dégâts.

Section 05 · Seuils

Seuils Google officiels en un tableau.

Pour qu'une page soit considérée good par Google, les trois métriques doivent valider simultanément le seuil good au 75e percentile des chargements sur les 28 derniers jours. Une métrique poor isolée suffit à basculer l'ensemble de la page dans la catégorie poor.

Métrique Good À améliorer Poor Source officielle
LCP ≤ 2,5 s 2,5 – 4 s > 4 s web.dev/lcp
INP ≤ 200 ms 200 – 500 ms > 500 ms web.dev/inp
CLS ≤ 0,1 0,1 – 0,25 > 0,25 web.dev/cls
Source : web.dev (Google). Mesure au 75e percentile sur 28 jours glissants. Mobile et desktop séparés.
« Avoir une page good sur les trois Core Web Vitals ne fait pas ranker un mauvais contenu. Mais avoir une page poor sur INP en e-commerce concurrentiel, c'est laisser le concurrent ramasser le clic. »
— Yonel Sasson · 4 ans à mesurer du CrUX sur des sites B2B
Section 06 · Mesure

Comment mesurer ses Core Web Vitals correctement.

Distinction critique avant d'ouvrir un outil. Il existe deux types de données. Les données de terrain (field data), collectées sur de vrais utilisateurs et anonymisées par Chrome dans le Chrome User Experience Report, sont les métriques officielles utilisées par Google Search. Les données de laboratoire (lab data), produites par Lighthouse dans des conditions standardisées, sont utiles pour le debug mais ne reflètent pas l'expérience réelle.

Trois outils suffisent pour couvrir 95 % des besoins d'un audit performance sérieux.

Outil 01

Search Console

Rapport « Signaux web essentiels » natif, données de terrain agrégées par groupe d'URLs similaires. Vue mobile et desktop séparée. C'est le seul rapport qui reflète exactement ce que Google utilise pour ses systèmes de classement.

Field data · gratuit
Outil 02

PageSpeed Insights

Croise les données CrUX réelles (28 jours) et un audit Lighthouse instantané, URL par URL. Identifie l'élément LCP, signale les longues tâches INP et liste les éléments responsables du CLS. L'outil de debug par excellence.

Field + lab data · gratuit
Outil 03

web-vitals.js + RUM

La bibliothèque officielle distribuée par Google sur GitHub permet de mesurer LCP, INP et CLS en RUM (Real User Monitoring) sur ses propres utilisateurs, puis d'envoyer les métriques vers son outil d'analytics ou un produit comme DebugBear, SpeedCurve ou Calibre.

Field data custom · open source

Erreur classique : lancer un Lighthouse, voir un score 95/100 en LCP, conclure que tout va bien. Le score Lighthouse simule un seul chargement en laboratoire, sur une connexion 4G simulée, depuis un data center précis. Vos utilisateurs réels, sur un Samsung Galaxy A23 en zone 3G en région PACA, n'auront jamais ce résultat. Toujours croiser avec les données CrUX dans Search Console ou PageSpeed Insights.

Erreur classique numéro deux : oublier la fenêtre glissante de 28 jours. Une optimisation déployée aujourd'hui ne montre son effet plein dans la Search Console que trois à quatre semaines plus tard, le temps que les anciennes mesures sortent de la fenêtre. Compter une lecture intermédiaire après 7 jours et une lecture finale après 30 jours.

Section 07 · Leviers

Dix leviers techniques pour améliorer ses Core Web Vitals.

Tous les leviers ne se valent pas. La hiérarchie ci-dessous suit le ratio impact-effort observé sur les audits que nous avons menés depuis 2022. Démarrer par le haut de la liste, puis descendre, donne plus de résultats qu'attaquer toutes les optimisations en parallèle.

01
LCP

Précharger l'élément LCP

Identifier l'élément LCP via PageSpeed Insights et ajouter <link rel="preload" as="image"> dans le head pour qu'il soit téléchargé en priorité, avant les CSS et JS non critiques.

02
LCP

Servir les images en AVIF ou WebP

Les formats modernes réduisent de 30 à 50 % le poids des images vs JPEG. La balise <picture> permet un fallback automatique pour les navigateurs anciens.

03
INP

Découper les longues tâches JS

Toute tâche supérieure à 50 ms bloque le main thread. Découper via scheduler.yield(), setTimeout ou requestIdleCallback pour rendre la main au navigateur.

04
CLS

Déclarer width et height sur toutes les images

Sans dimensions explicites ou aspect-ratio CSS, le navigateur ne réserve pas l'espace. Le contenu sous l'image saute au moment du chargement.

05
LCP

Activer un CDN sur les statiques

Cloudflare, Bunny CDN ou Vercel Edge. Le temps de récupération chute pour les utilisateurs éloignés du serveur d'origine. Gain typique : 200 à 600 ms sur TTFB.

06
INP

Charger les scripts tiers en deferred

Tags marketing, analytics, chat. Charger après l'événement load ou sur première interaction. Outils comme Partytown peuvent isoler ces scripts dans un web worker.

07
CLS

Réserver l'espace des bandeaux ad et cookies

Min-height CSS sur l'emplacement, même avant le chargement asynchrone. Le bandeau cookies en bas de viewport plutôt qu'en haut limite les décalages perçus.

08
LCP

Auto-host les fontes en woff2

Google Fonts hébergé en externe coûte une connexion TLS. Self-host en woff2 avec font-display: swap et préchargement réduit de 100 à 300 ms le rendu du texte.

09
INP

Réduire la taille du DOM

Au-delà de 1 500 nœuds, le navigateur ralentit sur chaque interaction. Découper les longues pages en composants chargés à la demande, supprimer les wrappers inutiles.

10
LCP

Activer le rendu côté serveur

Sites React, Vue, Angular en SPA pur. Passer à Next.js, Nuxt, Astro ou SvelteKit avec SSR ou SSG divise par deux à quatre le LCP sur la page d'entrée.

Section 08 · Impact SEO

Core Web Vitals et SEO : impact réel, données sourcées.

La question revient sans cesse en conférence client. Ces métriques font-elles ranker ? La réponse honnête tient en deux phrases. Oui, elles sont un signal de classement intégré au signal Page Experience depuis 2021. Non, elles ne sont pas un signal majeur isolé qui surclasserait la pertinence éditoriale.

Google a été explicite sur ce point dans sa documentation Search Central. Le trio LCP, INP, CLS intervient surtout en départage entre pages dont la pertinence est comparable. Une page lente avec un contenu unique et exhaustif peut largement rester devant une page rapide au contenu pauvre. Pour qu'une amélioration de performance produise un gain de positionnement, il faut être déjà compétitif sur le fond.

Les données publiques disponibles le confirment. L'étude Backlinko publiée sur 208 085 pages n'a pas trouvé de corrélation directe entre CLS, LCP ou FID isolés et les indicateurs UX comme le taux de rebond ou le temps passé. En revanche, l'étude Advanced Web Ranking sur 3 millions de pages a observé que les pages classées en positions 1 à 3 présentent un LCP mesurablement plus bas que celles classées entre les positions 8 à 10. Corrélation, pas causalité, le rappel s'impose.

Côté terrain, l'enjeu n'est pas tant de gagner trois positions grâce à un LCP qui passe de 3 à 2 secondes. C'est de ne pas perdre des positions parce qu'un INP poor laisse penser à Google que la page est inadaptée au public mobile. Sur un e-commerce concurrentiel, un INP qui dépasse 500 ms en mobile constitue un signal négatif qui se cumule avec d'autres alertes.

Sources externes citées dans ce guide

  1. web.dev — « Web Vitals », article officiel. Source de référence Google pour les définitions et seuils LCP, INP, CLS.
  2. Google Search Central — « Comprendre les métriques Core Web Vitals », documentation officielle. Position officielle de Google sur le rôle des Core Web Vitals dans le classement.
  3. web.dev — « Interaction to Next Paint becomes a Core Web Vital on March 12, 2024 ». Annonce officielle du remplacement de FID par INP.
  4. Backlinko — étude sur 208 085 pages, Core Web Vitals benchmark. Référence indépendante sur la distribution des scores CWV à l'échelle du web.
  5. Advanced Web Ranking — étude de corrélation Core Web Vitals et positions. Étude sur 3 millions de pages mesurant la corrélation entre LCP et position de classement.
  6. Chrome User Experience Report — documentation officielle Google. Méthodologie de collecte des données de terrain utilisées par Search Console et PageSpeed Insights.
  7. GoogleChrome/web-vitals sur GitHub — bibliothèque officielle. Outil open source pour mesurer LCP, INP, CLS en RUM.
Section 09 · FAQ

Core Web Vitals : les questions qui reviennent.

Les signaux web essentiels sont un ensemble de trois métriques définies par Google pour mesurer la qualité de l'expérience utilisateur réelle d'une page web : LCP pour la vitesse de chargement, INP pour la réactivité aux interactions et CLS pour la stabilité visuelle. Elles sont évaluées au 75e percentile des chargements de page, mobile et desktop séparément, sur des données de terrain issues du Chrome User Experience Report.
Selon Google, une page est considérée good lorsque LCP est inférieur ou égal à 2,5 secondes, INP inférieur ou égal à 200 millisecondes et CLS inférieur ou égal à 0,1. Ces seuils s'évaluent au 75e percentile des chargements observés sur les 28 derniers jours. Une page doit valider les trois métriques simultanément pour être qualifiée good dans la Search Console.
INP, pour Interaction to Next Paint, est devenu une Core Web Vital stable le 12 mars 2024, en remplacement officiel de FID (First Input Delay). FID a été retiré de la Search Console à cette date. Une période de dépréciation jusqu'au 9 septembre 2024 a été laissée pour les autres outils comme PageSpeed Insights et la bibliothèque CrUX, le temps que les équipes techniques mettent à jour leur instrumentation.
Oui, mais avec une nuance. Ces trois métriques font partie du signal Page Experience que Google intègre dans ses systèmes de classement depuis 2021. Elles ne sont pas un facteur isolé qui déciderait à elles seules d'un positionnement. Google précise qu'elles interviennent en départage entre pages à pertinence éditoriale comparable. Une page lente avec un contenu très pertinent peut rester devant une page rapide au contenu faible.
Trois outils suffisent. La Search Console affiche le rapport « Signaux web essentiels » avec les données de terrain agrégées par groupe d'URLs. PageSpeed Insights croise les données CrUX réelles et un audit Lighthouse en laboratoire, URL par URL. La bibliothèque web-vitals.js, distribuée par Google sur GitHub, permet de collecter ses propres métriques en RUM dans un outil d'analyse maison ou un produit comme DebugBear, SpeedCurve ou Calibre.
La modification technique peut être déployée en quelques jours à quelques semaines selon la complexité du stack. La Search Console et le Chrome User Experience Report s'appuient en revanche sur une fenêtre glissante de 28 jours de données réelles utilisateurs. Une amélioration déployée aujourd'hui n'apparaît donc pleinement dans les rapports que trois à quatre semaines plus tard, le temps que les anciennes mesures sortent de la fenêtre.
Les données de terrain, ou field data, proviennent de mesures collectées sur des vrais utilisateurs, anonymisées par Chrome dans le Chrome User Experience Report. Ce sont les métriques officielles utilisées par Google Search. Les données de laboratoire, ou lab data, sont produites par un outil comme Lighthouse qui simule un chargement dans des conditions standardisées. Elles sont utiles pour le debug mais ne reflètent pas l'expérience réelle de vos utilisateurs.
Pour aller plus loin

Trois pages à lire ensuite.

01

Audit SEO complet

Diagnostic technique, on-page, contenu, autorité et performances. La mesure LCP, INP et CLS intégrée à un audit Getknown nominal.

Découvrir l'audit
02

Guide SEO technique

Crawlabilité, indexation, rendering, performance. Le guide pilier dans lequel s'inscrivent ces métriques comme sous-thème.

Lire le guide
03

Notre pilier SEO

Audit, refonte, international, local. Le socle technique et sémantique sur lequel se construit la performance perçue d'un site.

Découvrir

Vos Core Web Vitals, mesurés et arbitrés en 30 minutes.

Un appel de diagnostic gratuit. Nous regardons votre rapport Search Console, l'élément LCP réel de votre page d'entrée, l'INP en mobile, et nous vous disons honnêtement par où ouvrir le chantier. Si la marge est faible, nous vous le disons. Si elle est forte, nous chiffrons. Voir nos modalités d'intervention.

Réserver 30 minutes