Core Web Vitals en 2026 : seuils et ce qui a bougé

Trois métriques, et les mêmes trois depuis 2024. Le Largest Contentful Paint doit se situer à 2,5 secondes ou moins, l'Interaction to Next Paint à 200 millisecondes ou moins, et le Cumulative Layout Shift à 0,1 ou moins. Chacune est jugée au 75e centile des chargements de page réels, séparément sur mobile et sur ordinateur.

Quels sont les seuils des Core Web Vitals en 2026 ?

Ces valeurs viennent directement des pages de métriques de web.dev, où Google publie les définitions. Tout est mesuré au 75e centile des chargements de page : vous passez quand trois quarts de vos visiteurs réels obtiennent un bon résultat, pas quand votre ordinateur portable y arrive.

Les Core Web Vitals ont-ils vraiment changé en 2026 ?

Non. Ni le jeu de métriques, ni un seul seuil. Le dernier changement structurel remonte au 12 mars 2024 : l'Interaction to Next Paint est devenue une Core Web Vital stable et le First Input Delay a été retiré, comme l'a annoncé web.dev dans son billet INP becomes a Core Web Vital. Depuis, l'ensemble se limite à trois métriques stables, sans remplaçante expérimentale ni annoncée. La règle que Google s'impose est que les Core Web Vitals stables ne changent pas plus d'une fois par an, et 2025 comme 2026 sont passées sans changement.

Ce qui a bougé, c'est la couche de mesure. Les notes de version du Chrome UX Report, publiées sur Chrome for Developers, indiquent que les sous-parties de l'image LCP et les types de ressources LCP sont arrivés dans l'API CrUX en janvier 2025, que la dimension ECT a été retirée de BigQuery dans la même livraison, et que l'ancien CrUX Dashboard a été déprécié fin novembre 2025. Par ailleurs, les travaux sur les soft navigations ont atteint Chrome 151 : les applications monopages peuvent rattacher LCP, INP et CLS à chaque changement de route, au lieu d'une seule vue de page interminable. Cette documentation précise explicitement que la façon dont les soft navigations seront remontées dans CrUX n'est pas encore tranchée, donc cela ne change rien à vos chiffres dans la Search Console pour l'instant.

Si l'on vous annonce qu'une nouvelle métrique est arrivée cette année, demandez laquelle. Il n'y en a pas.

Comment corriger un LCP trop lent

Presque tous les mauvais LCP sont un problème de découvrabilité. Le guide des correctifs prioritaires de web.dev place trois choses en tête : s'assurer que la ressource LCP est visible dans le code source HTML plutôt qu'injectée par un script, la marquer fetchpriority="high", et réduire le Time to First Byte avec un CDN qui met en cache le document lui-même. Au-delà, visez des navigations instantanées grâce au cache de navigation arrière et avant (bfcache) ou aux règles de spéculation, pour que la page suivante soit déjà là au moment du clic.

Comment corriger un INP trop élevé

L'INP se décompose en trois parties : le délai d'entrée avant l'exécution de votre gestionnaire, la durée de traitement de ce gestionnaire, et le délai de présentation avant l'affichage de l'image suivante. Le score remonté correspond en gros à la pire interaction de la page, une valeur aberrante étant ignorée toutes les cinquante interactions. Les correctifs recommandés : rendre la main souvent pour que les tâches longues cessent de bloquer le fil principal, embarquer moins de JavaScript dès le départ, et garder des mises à jour de rendu légères avec un DOM sobre et le confinement CSS. Auditez votre gestionnaire de balises. C'est en général là que ça se joue.

Comment corriger les décalages de mise en page

Le CLS retient la pire rafale de décalages, définie comme des décalages espacés de moins d'une seconde à l'intérieur d'une fenêtre de cinq secondes au maximum. Fixez une largeur et une hauteur explicites, ou un ratio d'affichage, sur chaque image et chaque contenu embarqué, réservez la place de tout ce qui est injecté tardivement, bannières et barres de consentement en tête, gardez la page éligible au cache de navigation arrière et avant, et animez avec transform plutôt qu'avec des propriétés qui forcent un recalcul de la mise en page.

Où mesurer les Core Web Vitals ?

Les données de terrain d'abord, toujours. Les outils de laboratoire servent à repérer les régressions avant la mise en production, et web.dev le dit sans détour : ils ne remplacent pas de vrais utilisateurs sur de vrais appareils. Le Chrome User Experience Report est le jeu de données de terrain. PageSpeed Insights et le rapport Core Web Vitals de la Search Console y puisent tous les deux, et la bibliothèque JavaScript web-vitals vous donne vos propres chiffres avec bien moins de retard qu'une fenêtre glissante de 28 jours. Chrome DevTools et Lighthouse couvrent le versant laboratoire. Utilisez les deux, mais seules les données de terrain décident si vous passez.

Les Core Web Vitals pèsent-ils encore sur le classement Google ?

Google Search Central documente toujours les Core Web Vitals comme un élément de l'expérience sur la page : des métriques qui mesurent l'expérience réelle des utilisateurs et qui, dit Google, vont dans le sens de ce que ses systèmes de classement principaux cherchent à récompenser. C'est volontairement plus tiède qu'un facteur de classement. Voyez-y un critère de départage entre des pages par ailleurs comparables, et un levier qui agit de toute façon sur vos conversions, quoi que fasse la recherche. La même logique vaut pour le reste de vos fondations techniques, que passe en revue notre vérificateur de préparation à l'IA.

Une remarque pour qui court après le score parfait : passer les trois seuils au 75e centile, c'est la ligne d'arrivée. Il n'existe aucun palier bonus au-dessus. Une fois au vert, l'heure suivante est mieux employée à vérifier que les robots peuvent seulement atteindre la page, ce qui prend cinq minutes dans votre robots.txt.