Core Web Vitals en 2026 : le jeu de métriques actuel
Les Core Web Vitals actuels sont LCP, INP et CLS. LCP mesure le chargement, INP la réactivité des interactions et CLS la stabilité visuelle. Google les présente comme trois dimensions centrales de l'expérience réelle. [1][3]
FID ne fait plus partie du jeu actuel. INP l'a remplacé en mars 2024 et FID a ensuite été retiré des outils CrUX. [7][14]
Seuils et 75e percentile
| Métrique | Bon | À améliorer | Mauvais | Mesure |
|---|---|---|---|---|
| LCP | ≤ 2.5 s | 2.5 s - 4.0 s | > 4.0 s | Chargement du contenu principal |
| INP | ≤ 200 ms | 200 ms - 500 ms | > 500 ms | Réactivité des interactions |
| CLS | ≤ 0.1 | 0.1 - 0.25 | > 0.25 | Stabilité visuelle |
Les valeurs correctes sont LCP ≤ 2,5 s, INP ≤ 200 ms et CLS ≤ 0,1. La zone à améliorer est 2,5 à 4,0 s, 200 à 500 ms et 0,1 à 0,25. Au-delà, le résultat est mauvais. [3][4]
Google utilise le 75e percentile, pas la moyenne. Au moins 75% des expériences doivent atteindre le seuil ou mieux. Mobile et desktop sont évalués séparément. [3][4]
Les trois métriques doivent être bonnes pour réussir l'évaluation globale. [3]
Core Web Vitals et SEO
Google confirme l'utilisation des Core Web Vitals dans ses systèmes de classement, comme partie de l'expérience de page. De bons scores ne garantissent toutefois pas une haute position, car pertinence et qualité du contenu restent essentielles. [1][2]
L'objectif est donc double : améliorer l'expérience réelle et éliminer une faiblesse technique potentiellement défavorable au référencement.
LCP : ce qui est réellement mesuré
Largest Contentful Paint mesure le temps entre le début de la navigation et le rendu du plus grand élément de contenu éligible dans le viewport. En terrain, LCP peut inclure redirections, établissement de connexion et TTFB. [5]
LCP n'est donc pas simplement le temps de téléchargement de la plus grande image. Le problème peut apparaître bien avant le transfert de la ressource. [5][6]
LCP en pratique : quatre sous-parties
web.dev décompose LCP en TTFB, délai de chargement de ressource, durée de chargement et délai de rendu de l'élément. [6]
Si la ressource LCP est découverte tard, la compression seule peut ne rien changer. Elle doit être détectable tôt dans le HTML initial et une image LCP ne doit pas être chargée en lazy loading. Priorité ou preload peuvent aider. [6]
Diagnostiquez dans cet ordre : TTFB, découverte de la ressource, durée de transfert, puis délai avant rendu final. [6]
- Réduire TTFB avec cache, CDN, moins de redirections et un backend plus rapide.
- Rendre la ressource LCP visible dans le HTML initial.
- Ne pas utiliser `loading="lazy"` pour l'image LCP.
- Utiliser une priorité adaptée ou preload si nécessaire.
- Optimiser taille et format seulement si le transfert est réellement limitant.
- Réduire JavaScript ou CSS qui bloque le rendu final.
INP : réactivité pendant toute la visite
Interaction to Next Paint observe clics, taps et clavier durant toute la visite. Pour la plupart des pages, l'interaction la plus lente devient l'INP. Pour les pages très interactives, une interaction maximale est ignorée toutes les 50 interactions afin de limiter les anomalies. [7]
INP diffère de FID car il inclut le délai d'entrée, le traitement et le délai jusqu'au prochain paint. [7][8]
Sans clic, tap ou clavier, une visite peut ne pas avoir de valeur INP. Scroll et hover ne comptent pas. [7]
INP en pratique : trois sources de latence
La latence totale comprend input delay, processing duration et presentation delay. Un INP élevé peut venir d'un thread principal occupé, de handlers trop longs ou d'un layout et rendu coûteux. [8]
Les corrections fréquentes sont des tâches plus courtes, du travail fractionné, moins de JavaScript lourd, un layout plus simple, des Web Workers adaptés et un retour visuel rapide. [8]
Commencez idéalement par des données RUM qui identifient l'interaction lente, puis reproduisez-la dans DevTools. Lighthouse seul ne représente pas l'INP réel complet. [8][11][12]
CLS : stabilité pendant toute la vie de la page
Cumulative Layout Shift mesure les déplacements inattendus des éléments visibles. Il utilise la plus grande fenêtre de session où les déplacements successifs sont espacés de moins d'une seconde et où la fenêtre dure au maximum cinq secondes. [9]
CLS est sans unité et combine impact et distance du déplacement. Certains changements directement liés à une interaction peuvent être exclus. [9]
Les problèmes arrivent souvent après le chargement à cause de publicités, bannières, widgets ou polices. Un simple test de chargement peut les manquer. [10][11]
CLS en pratique : causes courantes
web.dev cite les images sans dimensions, publicités, embeds et iframes sans espace réservé, contenu injecté et web fonts. [10]
Réservez la place avant l'arrivée du contenu. Utilisez `width` et `height` ou un `aspect-ratio` stable, dimensionnez les emplacements publicitaires et évitez d'insérer du contenu au-dessus de ce que l'utilisateur lit déjà. [10]
Pour les polices, réduisez les différences métriques avec la police de secours et testez l'effet réel. `font-display` seul ne résout pas tous les cas. [10]
Données terrain contre laboratoire
Les Core Web Vitals sont d'abord des métriques terrain. CrUX et RUM reflètent de vrais utilisateurs, alors que Lighthouse aide à reproduire et diagnostiquer dans un environnement contrôlé. [11][12]
Lighthouse ne mesure pas l'INP complet d'une visite naturelle et utilise notamment TBT comme indicateur de laboratoire. Le CLS de laboratoire peut aussi être plus faible si les déplacements apparaissent après interaction. [11][12]
Utilisez le terrain pour savoir si le problème existe et le laboratoire pour comprendre sa cause.
Quel outil utiliser
| Outil | Type de données | Meilleur usage |
|---|---|---|
| PageSpeed Insights | CrUX + Lighthouse | Évaluation rapide d'une URL et d'un origin |
| Search Console | CrUX, groupes d'URL | Repérer les groupes de pages en difficulté SEO |
| Chrome DevTools | Laboratoire + contexte CrUX | Diagnostic détaillé de LCP, INP et CLS |
| Lighthouse | Laboratoire | Audits automatiques et régressions CI |
| RUM / web-vitals | Données de vos utilisateurs | Monitoring et diagnostic les plus précis après release |
PageSpeed Insights combine CrUX et Lighthouse. Search Console regroupe des URL similaires. DevTools fournit des métriques en direct et des traces détaillées. [12][13]
CrUX API et PageSpeed Insights reposent sur une fenêtre glissante d'environ 28 jours. Une correction récente n'affecte donc pas immédiatement le p75 public. Un RUM propre réagit plus vite. [12][13]
Le flux recommandé est RUM pour surveiller, Search Console pour les groupes SEO, PSI pour contrôler rapidement et DevTools pour diagnostiquer.
CrUX en 2026 : état récent du Web
| Métrique | Origins avec un bon score, juillet 2026 |
|---|---|
| LCP | 68,3% |
| INP | 85,7% |
| CLS | 81,6% |
| Tous les Core Web Vitals | 55,7% |
Le dernier jeu mensuel publié avant le 4 septembre 2026 couvre juillet 2026 et a été publié le 11 août. Il contient 18 059 068 origins. 68,3% avaient un bon LCP, 81,6% un bon CLS, 85,7% un bon INP et 55,7% réussissaient les trois métriques. [14]
Ces chiffres agrègent le Web représenté dans CrUX et ne sont pas des objectifs individuels. CrUX exige notamment une page publiquement découvrable et suffisamment populaire. [13][14]
L'absence de données CrUX ne signifie donc ni rapide ni lent, seulement un manque de données éligibles.
SPA et soft navigations : changement important en 2026
Historiquement, les Core Web Vitals étaient surtout liés aux navigations complètes. Chrome 151 a introduit en 2026 de nouvelles API pour mesurer les soft navigations, et la documentation a été mise à jour le 2 septembre 2026. [15]
Chrome DevTools 152, publié le 25 août 2026, affiche ces métriques dans Live Metrics par défaut grâce à `web-vitals` 6.0.0. [16]
C'est important pour React, Angular, Vue et autres SPA. Il ne faut toutefois pas supposer que tous les rapports publics CrUX utilisent déjà exactement cette logique.
Monitoring en production avec contexte
Un p75 public indique souvent le problème sans sa cause. Un RUM propre peut envoyer élément et sous-parties LCP, interaction INP, route, appareil et version de l'application. web.dev recommande RUM en complément de CrUX. [3][8][12]
Versionnez les déploiements et comparez les distributions avant et après. Une moyenne peut masquer des régressions sur les appareils lents.
CI protège contre des régressions de laboratoire évidentes, mais ne remplace pas le monitoring production. [11][12]
Plan pratique d'amélioration
Identifiez d'abord la métrique qui échoue au p75 et les types de pages concernés. Réduisez ensuite le problème avec RUM ou CrUX, reproduisez-le dans DevTools, corrigez la cause précise puis surveillez après déploiement. [12]
Pour LCP, trouvez la sous-partie dominante. Pour INP, l'interaction réellement lente. Pour CLS, les déplacements et éléments précis.
Vérifiez ensuite laboratoire et terrain. CrUX public réagit avec retard, donc RUM est utile pour valider rapidement une correction.
- Identifier le problème dans les données terrain.
- Séparer mobile et desktop.
- Pour LCP, analyser TTFB, découverte, transfert et délai de rendu.
- Pour INP, analyser l'interaction et ses trois phases.
- Pour CLS, enregistrer les déplacements sur toute la session.
- Déployer une correction mesurable et comparer avant et après.
- Conserver RUM et alertes de régression après chaque release.
