Core Web Vitals en 2026 : ce qui a changéCore Web Vitals en 2026 : ce qui a changé

Une page peut sembler rapide sur l’ordinateur du développeur et rester pénible pour une partie de ses visiteurs. Un téléphone peu puissant, une connexion instable ou un script tiers suffisent à transformer une navigation fluide en succession d’attentes et de décalages.

Les Core Web Vitals servent à objectiver cette expérience. Ils prennent tout leur sens dans le diagnostic qui transforme des constats en priorités concrètes, car un score isolé ne dit ni quelle page corriger en premier, ni quelle intervention produira un bénéfice réel.

En 2026, il faut surtout écarter une idée trompeuse : Google n’a pas publié une nouvelle série de seuils annuels. Les trois métriques de référence restent LCP, INP et CLS. Ce qui évolue concerne davantage leur maturité, leur disponibilité dans les navigateurs et les moyens de les diagnostiquer.

Ce qui a réellement changé avant 2026

Les seuils officiels n’ont pas été durcis

Les valeurs utilisées pour qualifier l’expérience restent les mêmes :

• LCP est bon jusqu’à 2,5 secondes, à améliorer au-delà de 2,5 secondes et mauvais au-delà de 4 secondes.
• INP est bon jusqu’à 200 millisecondes, à améliorer au-delà de 200 millisecondes et mauvais au-delà de 500 millisecondes.
• CLS est bon jusqu’à 0,1, à améliorer au-delà de 0,1 et mauvais au-delà de 0,25.

Ces limites ne sont pas calculées sur une visite idéale. L’évaluation s’effectue au 75e percentile, séparément pour les expériences mobiles et celles sur ordinateur. Autrement dit, une page est considérée comme bonne pour une métrique lorsque la grande majorité des visites reste dans la zone recommandée.

Il n’existe donc pas de « nouveaux seuils 2026 » à appliquer. Une présentation qui annoncerait, sans source officielle, un LCP désormais exigé sous deux secondes ou un INP ramené à 100 millisecondes confondrait un objectif interne ambitieux avec la classification de Google.

INP a remplacé FID, mais ce changement date de 2024

Le changement le plus important de ces dernières années reste le remplacement de First Input Delay par Interaction to Next Paint en mars 2024. FID observait seulement le délai avant le traitement de la première interaction. INP examine les interactions réalisées pendant la visite et représente beaucoup mieux la réactivité générale de la page.

Prenons une fiche produit. Son premier bouton peut répondre immédiatement, tandis que l’ouverture du sélecteur de variantes devient lente après le chargement de plusieurs scripts. FID pouvait passer à côté de cette dégradation. INP tient compte du clic tardif et du délai nécessaire avant l’affichage de la réponse visuelle.

En 2026, conserver FID dans un tableau de bord principal constitue donc une erreur de méthode. Il faut suivre INP et rechercher l’interaction précise qui explique la mauvaise valeur.

LCP et INP sont devenus mesurables dans davantage de navigateurs

Depuis décembre 2025, les interfaces nécessaires à la mesure de LCP et d’INP sont disponibles dans les versions récentes des trois grands moteurs de navigateur. Cette avancée permet aux solutions de suivi côté site de mieux observer les expériences vécues hors de l’écosystème Chromium.

Cela ne signifie pas que les données CrUX intègrent soudainement Safari ou Firefox. Le Chrome User Experience Report reste fondé sur des expériences éligibles provenant de Chrome. Un outil de suivi réel installé sur le site peut donc présenter un périmètre différent de celui de CrUX, avec des écarts légitimes entre les résultats.

CrUX Vis a remplacé l’ancien tableau de bord historique

Le tableau de bord CrUX construit dans Looker Studio a été abandonné à la fin de 2025. CrUX Vis prend le relais pour visualiser les tendances historiques, avec des périodes glissantes de 28 jours et un historique hebdomadaire.

Cette évolution ne modifie pas les seuils, mais elle change les habitudes de suivi. Une capture mensuelle manuelle devient moins utile qu’une lecture de tendance par appareil, par métrique et, lorsque les données sont disponibles, par URL.

Ce que mesurent vraiment LCP, INP et CLS

LCP mesure l’arrivée du contenu principal

Largest Contentful Paint correspond au moment où le plus grand élément visible dans la fenêtre initiale est affiché. Il s’agit souvent d’une image principale, d’une bannière ou d’un grand bloc de texte.

Un LCP lent n’est pas automatiquement un problème d’image trop lourde. Le délai peut venir de plusieurs étapes :

• le serveur met du temps à produire le document HTML ;
• le navigateur découvre tardivement la ressource principale ;
• le téléchargement de cette ressource est lent ;
• des feuilles de style, des polices ou du JavaScript retardent son rendu.

La bonne question n’est donc pas « comment compresser toutes les images ? », mais « quelle portion du délai LCP domine sur ce modèle de page ? ».

INP mesure la réponse visible aux interactions

Interaction to Next Paint couvre les clics, les pressions tactiles et les saisies au clavier. Son délai réunit trois composantes : l’attente avant le traitement, l’exécution du code associé et le temps nécessaire au navigateur pour présenter l’image suivante.

Sur un site e-commerce, un mauvais INP peut apparaître lorsque l’ajout au panier déclenche trop de calculs, lorsqu’un gestionnaire d’événement parcourt un document complexe ou lorsqu’un script publicitaire monopolise le thread principal. La correction dépend de la composante responsable, pas seulement du volume total de JavaScript téléchargé.

CLS mesure les mouvements inattendus

Cumulative Layout Shift quantifie les déplacements visuels qui ne résultent pas d’une action attendue de l’utilisateur. L’exemple classique est un bouton qui descend au moment où une bannière se charge, provoquant un clic sur le mauvais élément.

Les causes courantes comprennent les images sans espace réservé, les publicités injectées dans une zone de hauteur inconnue, les bandeaux ajoutés au-dessus du contenu et les changements tardifs de police. Une page peut charger rapidement tout en conservant un mauvais CLS : vitesse et stabilité sont deux problèmes distincts.

Données réelles et tests de laboratoire ne répondent pas à la même question

Un audit sérieux commence par séparer deux familles de mesures.

Les données de terrain décrivent des visites réelles agrégées. Dans PageSpeed Insights, elles proviennent de CrUX lorsqu’un volume suffisant est disponible. Elles couvrent une fenêtre glissante de 28 jours, ce qui explique pourquoi une correction déployée ce matin ne transforme pas immédiatement la classification affichée.

Les données de laboratoire proviennent d’un test contrôlé. Elles sont reproductibles et riches en détails, ce qui les rend très utiles pour isoler une ressource bloquante, une tâche JavaScript longue ou un déplacement de mise en page. Elles ne représentent cependant qu’un scénario, sur un appareil et un réseau simulés.

Une page peut donc réussir le test de laboratoire et rester mauvaise sur le terrain. Les visiteurs réels utilisent peut-être des appareils plus lents, acceptent davantage de traceurs ou déclenchent des interactions absentes du test automatisé. L’inverse existe également : une exécution de laboratoire ponctuellement lente ne suffit pas à conclure que tous les visiteurs rencontrent le même problème.

Pour superviser un ensemble de modèles, Google Search Console regroupe les URL qui présentent des expériences similaires. Ce regroupement aide à repérer un défaut commun à toutes les fiches produits ou à toutes les pages locales, mais il ne remplace pas l’analyse détaillée d’une URL représentative.

Comment améliorer chaque métrique sans corriger au hasard

Pour le LCP, suivre la chaîne de chargement

Commencez par identifier l’élément LCP réel sur mobile et sur ordinateur. S’il s’agit d’une image principale, vérifiez qu’elle est présente dans le HTML initial, correctement dimensionnée et chargée avec une priorité adaptée. Le lazy loading est utile sous la ligne de flottaison, mais contre-productif sur une image LCP immédiatement visible.

Si la ressource est découverte rapidement mais arrive tard, examinez son poids, le format, le cache et la distance réseau. Si le document HTML lui-même tarde, l’hébergement, les traitements serveur ou les appels applicatifs deviennent prioritaires. Enfin, si la ressource est disponible mais ne s’affiche pas, cherchez du côté des styles bloquants, des polices et du rendu côté client.

Pour l’INP, retrouver l’interaction lente

Réduire un fichier JavaScript au hasard ne suffit pas. Il faut reproduire les actions qui comptent pour le visiteur : ouvrir un menu, modifier une variante, utiliser un filtre, valider un formulaire ou ajouter un produit au panier.

Pour chaque interaction lente :

1. mesurez l’attente avant le démarrage du gestionnaire ;
2. repérez les tâches longues exécutées pendant le traitement ;
3. contrôlez le coût du recalcul de styles et du rendu ;
4. fractionnez les traitements qui peuvent céder la main au navigateur ;
5. différez les scripts tiers non indispensables à l’action immédiate.

Une interface doit aussi fournir un retour rapide. Afficher immédiatement un état de chargement ne corrige pas tout le travail sous-jacent, mais évite de laisser l’utilisateur sans réponse lorsque l’opération ne peut pas être instantanée.

Pour le CLS, réserver l’espace avant le chargement

La prévention est souvent plus efficace que la correction tardive. Définissez les dimensions ou le ratio des images, vidéos et contenus intégrés. Prévoyez une hauteur réaliste pour les emplacements publicitaires et évitez d’insérer un bandeau au-dessus d’un contenu déjà affiché.

Pour les polices, contrôlez la différence de dimensions entre la police de remplacement et la police finale. Pour les animations, privilégiez les propriétés comme transform et opacity, qui ne réorganisent pas toute la mise en page.

Un plan d’action adapté à un audit SEO

L’objectif n’est pas de faire passer chaque URL au vert à n’importe quel coût. Il faut concentrer les efforts là où le problème touche beaucoup d’utilisateurs ou compromet un parcours important.

1. Relevez les groupes d’URL médiocres sur mobile et sur ordinateur.
2. Choisissez une page représentative de chaque modèle, par exemple une fiche produit, une page service et un article.
3. Confirmez la métrique défaillante avec les données de terrain.
4. Utilisez un test de laboratoire et les outils du navigateur pour trouver la cause technique.
5. Corrigez le composant partagé plutôt qu’une seule URL si le défaut vient du gabarit.
6. Validez immédiatement la correction en laboratoire, puis surveillez les données réelles pendant la fenêtre de collecte suivante.

Documentez la date de mise en production, les modèles concernés et les valeurs avant correction. Cette discipline permet ensuite de suivre les indicateurs après un audit SEO sans confondre tendance et fluctuation.

Lorsque plusieurs composants, scripts tiers et modèles sont impliqués, un accompagnement en SEO technique permet de relier la mesure, le diagnostic et les contraintes de développement au lieu d’empiler des recommandations génériques.

Les erreurs d’interprétation à éviter en 2026

La première consiste à traiter le score Lighthouse sur 100 comme un Core Web Vital. Ce score synthétique aide au diagnostic, mais il ne remplace pas les valeurs de terrain de LCP, INP et CLS.

La deuxième consiste à promettre un gain de position automatique. Google recommande de bons Core Web Vitals et ses systèmes cherchent à valoriser une expérience satisfaisante, mais la pertinence du contenu reste déterminante. Faire passer un LCP de 3 à 2 secondes ne rend pas une page hors sujet plus utile.

La troisième consiste à optimiser uniquement la page d’accueil. Les visiteurs arrivent souvent directement sur un article, une fiche produit ou une page service. Les données doivent être étudiées par modèle et par parcours.

Enfin, méfiez-vous des extensions qui annoncent une correction globale en un clic. Une couche de cache peut améliorer certaines étapes du LCP, mais elle ne résout ni un gestionnaire d’événement coûteux, ni une bannière injectée sans espace réservé. Chaque métrique décrit un symptôme différent et réclame un diagnostic correspondant.

Ce qu’il faut retenir

En 2026, les Core Web Vitals n’ont pas changé de seuils. LCP, INP et CLS restent évalués au 75e percentile, avec des données distinctes pour les usages mobiles et ceux sur ordinateur.

Les évolutions utiles concernent surtout la mesure : INP a définitivement succédé à FID, LCP et INP sont observables dans davantage de navigateurs, et CrUX Vis facilite l’étude de l’historique. La méthode reste stable : partir des données réelles, isoler la cause en laboratoire, corriger le composant responsable et vérifier l’effet après déploiement.