Core Web VitalsSEO techniquePerformance

INP, LCP, CLS : les seuils que Google sanctionne vraiment en 2026

Seuils INP, LCP, CLS en 2026, données CrUX par secteur et ce que Google pénalise vraiment dans son ranking. Où concentrer les efforts en pratique.

Par Anthony Custodio · 15 mai 2026 · 9 min de lecture

Réponse courte. En 2026, Google considère qu’une page passe les Core Web Vitals si 75 % des visites (P75) atteignent simultanément ces seuils, mesurés sur le terrain via le Chrome UX Report : LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1. Au-dessus de ces seuils, la page est marquée “needs improvement” jusqu’à un palier “poor” (LCP > 4 s, INP > 500 ms, CLS > 0,25). Ces métriques ne sont pas le signal de classement le plus fort, mais elles deviennent un facteur tangible sur les SERP concurrentielles et un critère explicite pour les AI Overviews.

Ce qui a changé depuis mars 2024

Le rappel utile : INP (Interaction to Next Paint) a définitivement remplacé FID (First Input Delay) le 12 mars 2024, sur décision de Google et du groupe de travail Web Performance. FID ne mesurait que la latence de la première interaction. INP mesure la latence tout au long de la session, en retenant le pire 98ᵉ percentile des interactions de la page. Concrètement : INP attrape ce que FID ratait — les boutons qui freezent au scroll, les modales lentes, les filtres qui bloquent l’UI 400 ms.

Pour beaucoup de sites, le passage de FID à INP a fait chuter le pourcentage de pages “good” de 90 % à 65–70 % du jour au lendemain. Les sites avec beaucoup de JavaScript côté client (e-commerce SaaS-like, dashboards, applications React/Vue lourdes) ont été les plus touchés.

Les trois seuils 2026, en clair

Métrique	Mesure	Bon	À améliorer	Mauvais
LCP	Temps d’affichage du plus grand élément visible	≤ 2,5 s	2,5 – 4 s	> 4 s
INP	Latence du 98ᵉ percentile des interactions	≤ 200 ms	200 – 500 ms	> 500 ms
CLS	Décalage visuel cumulé sans interaction	≤ 0,1	0,1 – 0,25	> 0,25

Tous les seuils sont évalués au 75ᵉ percentile sur 28 jours glissants par Google, c’est-à-dire que 75 % de vos visites doivent satisfaire le seuil. Une seule métrique en zone “poor” suffit à faire échouer la page.

À noter : le TTFB (Time to First Byte) n’est pas une CWV mais conditionne directement le LCP. Au-dessus de 800 ms de TTFB, viser un bon LCP devient quasiment impossible — on travaille alors d’abord l’hébergement, le CDN et la cache HTML avant de toucher au front-end.

Données réelles : qui passe les CWV en 2026 ?

D’après les dernières analyses publiques du Web Almanac (HTTP Archive) et des rapports CrUX agrégés, l’image est nuancée selon le device et le secteur.

Sur l’ensemble du web mobile (origine la plus représentative pour Google) :

~ 48 % des origines passent les trois CWV simultanément.
LCP est la métrique la plus souvent défaillante sur mobile : médiane autour de 2,8–3,1 s.
INP est devenu le tueur silencieux : 20 à 30 % des sites e-commerce / SaaS échouent uniquement sur INP.
CLS reste la métrique la plus facile à maîtriser : ~ 80 % des origines la passent.

Par secteur (tendance, pas chiffre figé — vérifiez votre origine sur PageSpeed Insights) :

Médias & news : LCP très tendu (vidéos, ads), INP correct sur consultation passive. ~ 40–50 % de pages “good”.
E-commerce : INP catastrophique sur les pages catégorie filtrées en JS, LCP variable. ~ 35–45 %.
SaaS / dashboards : INP le plus mauvais du web (lots de listes virtualisées, formulaires complexes). ~ 30–40 %.
Blog / contenu éditorial bien fait : tous verts à 80–90 %, c’est l’archétype gagnant.
WordPress vanilla : CLS souvent abîmé par les plugins de pub ou les images sans dimensions. ~ 50–60 %.

Si votre origine est en dessous de la moyenne du secteur, vous laissez du ranking sur la table. Si vous êtes au-dessus, vous avez un avantage marginal mais réel sur les requêtes à concurrence élevée.

Ce que Google sanctionne vraiment

Démêlons le mythe et la réalité. Google a clarifié plusieurs fois que les Core Web Vitals sont un signal parmi 200, et que la pertinence d’un contenu reste prioritaire. Mais en 2026, trois faits sont établis :

Sur les SERP très concurrentielles (e-commerce, finance, voyage), les sites avec CWV “poor” perdent en moyenne 1 à 2 positions à pertinence équivalente. C’est confirmé par plusieurs études Backlinko et SISTRIX sur des panels de 5 à 11 millions de SERP.
Pour les AI Overviews et la recherche IA, les pages lentes sont sous-représentées. Google pondère la performance dans ses critères de sélection des sources qu’il “résume”. Une page LCP > 4 s qui répond parfaitement à une requête peut être supplantée par une page concurrente plus rapide qui répond presque aussi bien.
Le rapport CrUX alimente directement le rapport Search Console “Core Web Vitals”, qui est aujourd’hui consulté par les éditeurs avant chaque sortie de version. Une régression visible y est désormais traitée comme un blocker, pas comme une nice-to-have.

En revanche, passer de “needs improvement” à “good” ne fait pas exploser le ranking : l’effet est progressif, et un contenu mauvais ne sera pas sauvé par un LCP de 1,8 s. La règle pratique : viser “good” en priorité sur les pages qui rankent déjà — c’est là que le marginal compte le plus.

Où concentrer les efforts en 2026

Plutôt que d’attaquer tout en même temps, hiérarchiser :

1. Auditer le LCP

Identifier l’élément LCP via PageSpeed Insights ou DevTools (Performance → LCP).
Si c’est une image : width/height posés, format AVIF ou WebP, fetchpriority="high", pas de lazy-loading sur le LCP.
Si c’est du texte : préchargement des polices critiques (<link rel="preload" as="font" crossorigin>), font-display: swap.
Si c’est du serveur lent : viser TTFB < 600 ms — sinon hébergement/CDN/cache HTML avant tout le reste.

2. Optimiser INP

Réduire la taille des bundles JavaScript (code-splitting par route), différer le code non-critique (defer, async, dynamic imports).
Casser les long tasks (> 50 ms) en chunks (scheduler.yield(), setTimeout, requestIdleCallback).
Auditer les handlers d’événements lourds : filtres, recherches, selectors React/Vue. C’est presque toujours là.
Sur WordPress / Shopify, traquer les plugins/apps qui injectent du JS bloquant à DOMContentLoaded.

3. Stabiliser CLS

Toujours dimensionner les images, vidéos, iframes et publicités.
Réserver l’espace des bannières de cookies, modales, contenus dynamiques.
Éviter d’insérer du contenu au-dessus de contenu existant après le chargement.
Tester sur mobile bas de gamme (CrUX rapporte le pire percentile, qui vient souvent de là).

Comment mesurer (et pourquoi pas seulement Lighthouse)

Lighthouse en local donne des données de laboratoire (lab data) : utiles pour debugger, mais pas représentatives. Le seul juge en SEO, c’est le terrain (CrUX field data) — ce que vivent les vraies visites.

Outils à utiliser dans cet ordre :

PageSpeed Insights — combine field (CrUX, 28 jours) et lab. Donne le diagnostic le plus complet en 30 secondes.
Search Console → Expérience → Core Web Vitals — vue d’ensemble par groupe d’URL sur votre origine.
CrUX Dashboard ou BigQuery — pour analyser à l’échelle, par type d’appareil, par géo, par mois.
Web Vitals JS (web-vitals npm) — pour collecter vos propres mesures RUM côté client si vous voulez voir avant que CrUX ne les remonte (28 jours de latence).

FAQ Core Web Vitals 2026

Combien de temps avant que mes améliorations CWV soient prises en compte par Google ?

Le rapport CrUX agrège 28 jours glissants. Comptez 4 à 6 semaines entre une amélioration en production et sa visibilité dans Search Console / PageSpeed Insights. Le ranking, lui, peut bouger plus tard, sur les passages d’index suivants.

Si mon site n’a pas assez de trafic, est-ce un problème ?

Oui, c’est le seuil “data not available” de CrUX. Sous environ 1 000 visites/mois par origine, Google ne dispose pas de données field et utilise des signaux de remplacement (Lighthouse-like). Concentrez-vous alors sur les scores lab, mais sans illusion : ce qui compte, c’est le terrain.

Le score Lighthouse 100/100 est-il un objectif SEO ?

Non. Lighthouse est un outil de diagnostic en lab. Un score de 90+ est confortable, mais un site à 75 avec de bons CrUX field data passera devant un site à 100 mais lent en réalité. La vraie cible : passer les seuils P75 sur le field.

Faut-il s’inquiéter du TTFB ?

Pas en tant que Core Web Vital (il n’en est pas une), mais en tant que cause racine : un TTFB > 800 ms ferme la porte à un bon LCP. Si votre TTFB est mauvais, attaquez d’abord l’hébergement / CDN / cache. Inutile d’optimiser le front si le serveur met une seconde à répondre.

INP est-il déjà stable ou Google va-t-il bouger les seuils ?

INP est en place depuis mars 2024. Aucun changement de seuil annoncé. Google tend à laisser les seuils des CWV stables sur 2–3 ans pour permettre aux éditeurs de s’adapter. Pas d’inquiétude court terme.

Quel est le poids réel des CWV dans le ranking ?

Faible en absolu, significatif en marginal. Sur des SERP de tête où tout le monde a un bon contenu, un site “needs improvement” sur CWV peut perdre 1 ou 2 positions face à un concurrent “good”. Sur des SERP peu concurrentielles ou avec un gros écart de pertinence, l’effet est négligeable.

En résumé

Les Core Web Vitals 2026 ne sont pas un sujet à survoler. Trois métriques (LCP, INP, CLS), trois seuils (2,5 s / 200 ms / 0,1), un percentile (P75), un référent (CrUX field). En pratique : INP est la métrique qui a fait le plus de dégâts depuis 2024 sur les sites lourds en JS, et c’est là que se trouvent les gains de ranking marginaux les plus accessibles aujourd’hui. Avant de s’attaquer à un audit CWV, on regarde toujours le TTFB : s’il est mauvais, tout le reste est de la rustine.

Si on travaillait votre site, c’est par là qu’on commencerait : un audit CrUX par template, un plan de remédiation INP/LCP/CLS, et un suivi sur 6 semaines pour voir l’effet en field.

Sources

Un projet SEO en tête ?

On commence par un audit gratuit pour cadrer l'opportunité et le plan d'action.

Discuter de mon projet