Core Web Vitals en 2026 : seuils officiels, outils de mesure et priorités d’optimisation

Trois métriques conditionnent toujours l’évaluation de l’expérience utilisateur par Google : le LCP, l’INP et le CLS. Leurs seuils « good », « needs improvement » et « poor » n’ont pas changé depuis la dernière mise à jour de la documentation officielle de web.dev, malgré des rumeurs persistantes de durcissement courant 2026. Ce qui change, en revanche, c’est la facilité avec laquelle un audit mal mené produit un diagnostic faux — et une priorisation d’optimisation qui part dans la mauvaise direction.

#Les trois métriques et leurs seuils officiels

Chaque métrique est évaluée au 75e centile des chargements de page, en distinguant mobile et ordinateur. Un site n’est « bon » sur une métrique que si 75 % de ses visites réelles passent sous le seuil « good », pas seulement sa moyenne.

L’INP a remplacé le FID (First Input Delay) comme métrique officielle de réactivité en mars 2024. Contrairement au FID, qui ne mesurait que le délai avant le premier traitement d’une interaction, l’INP observe l’ensemble des interactions d’une session et retient la pire valeur représentative — un calcul nettement plus exigeant pour les interfaces riches en JavaScript.

#Mesurer : données de terrain contre données de laboratoire

La confusion la plus fréquente consiste à auditer un site uniquement avec Lighthouse ou PageSpeed Insights en mode « lab », puis à annoncer un score alors que Google classe les pages sur des données de terrain (field data), issues du Chrome User Experience Report (CrUX) et des utilisateurs réels qui ont consenti à la remontée télémétrique.

• Données de laboratoire (Lighthouse, WebPageTest) : simulation reproductible sur une machine et un réseau standardisés. Utile pour déboguer, pas pour évaluer le classement.
• Données de terrain (rapport Search Console « Signaux web essentiels », PageSpeed Insights onglet « Expérience utilisateur réelle », CrUX directement) : seules celles-ci reflètent ce que Google utilise pour le classement.

Un site peut afficher un excellent score Lighthouse en local tout en restant « mauvais » sur l’INP en production, simplement parce que ses visiteurs réels utilisent des terminaux d’entrée de gamme ou une connexion mobile dégradée que le test en laboratoire ne reproduit pas.

#Réduire le LCP

Le LCP mesure le temps d’affichage du plus grand élément visible dans la zone visible initiale — le plus souvent une image héro, un titre ou un bloc de texte. Les leviers les plus efficaces, par ordre d’impact généralement observé :

• Précharger la ressource critique avec <link rel="preload"> plutôt que de la laisser découverte tardivement par le navigateur.
• Servir des images déjà dimensionnées et compressées au format AVIF ou WebP, avec fetchpriority="high" sur l’élément LCP.
• Réduire le temps de réponse du serveur (TTFB), souvent négligé alors qu’il conditionne le point de départ de toute la chronologie.
• Éliminer les ressources bloquant le rendu (CSS et JavaScript synchrones) au-dessus de la ligne de flottaison.

#Réduire l’INP

L’INP se dégrade quand le thread principal reste occupé trop longtemps après une interaction — clic, frappe clavier, tap tactile — avant que le navigateur puisse peindre le résultat. Le correctif ne consiste presque jamais à « accélérer » une fonction isolée, mais à découper le travail pour laisser le thread principal respirer :

import {onINP} from 'web-vitals';

onINP((metric) => {
  // Loggue chaque interaction mesurée, avec le détail de l'entrée fautive
  console.log('INP:', metric.value, metric.attribution.interactionTarget);
  navigator.sendBeacon('/analytics/web-vitals', JSON.stringify(metric));
});

La bibliothèque officielle web-vitals expose un champ attribution qui identifie l’élément DOM responsable de l’interaction la plus lente — souvent plus utile en débogage réel qu’un score Lighthouse isolé. Les correctifs courants incluent le découpage des longues tâches avec scheduler.yield(), le report du JavaScript non critique après l’interaction utilisateur, et la réduction du travail de rendu déclenché par chaque mise à jour d’état.

#Stabiliser le CLS

Le CLS pénalise les décalages de mise en page inattendus après le premier rendu : une image sans dimensions réservées, une police qui bascule tardivement, une bannière publicitaire injectée au-dessus du contenu déjà lu. Réserver l’espace avant chargement, via des attributs width/height explicites ou une grille CSS Subgrid aux pistes dimensionnées à l’avance, évite l’essentiel des régressions. Pour les animations, privilégier les propriétés transform et opacity, qui ne déclenchent pas de recalcul de mise en page — un principe au cœur des bonnes pratiques détaillées dans le guide sur les animations CSS pilotées par le défilement, où le moindre décalage de disposition casse l’effet autant que le score.

Un site peut afficher un excellent score Lighthouse en local tout en restant classé « mauvais » en production : seules les données de terrain comptent pour le classement.

#Prioriser les chantiers avec les données CrUX

Avant de lancer une refonte, il vaut mieux savoir si le problème touche l’ensemble du site ou un seul gabarit. Le jeu de données public CrUX, interrogeable gratuitement via BigQuery ou via l’API CrUX History, permet de suivre l’évolution mensuelle des trois métriques par origine ou par URL, segmentée par type de connexion effective (4G, 3G) et par facteur de forme. Comparer sa propre tendance à celle d’un concurrent direct, sur la même période, aide à distinguer une régression spécifique au site d’un effet saisonnier plus large (changement de comportement des terminaux, montée en charge d’un CDN partagé, etc.).

Pour éviter qu’une régression ne revienne inaperçue entre deux audits mensuels, un budget de performance posé directement en intégration continue reste la méthode la plus fiable : le build échoue si le LCP simulé dépasse un seuil fixé, avant même la mise en production.

{
  "ci": {
    "assert": {
      "assertions": {
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}],
        "total-blocking-time": ["warn", {"maxNumericValue": 300}]
      }
    }
  }
}

Cette configuration Lighthouse CI ne remplace pas la mesure de terrain — elle reste un garde-fou en laboratoire — mais elle évite qu’une régression grossière (image non compressée oubliée dans un commit, script tiers ajouté sans async) n’atteigne la production avant d’être repérée.

#Ce qu’il faut retenir

Les seuils eux-mêmes sont stables et documentés ; ce qui fait la différence, c’est la discipline de mesure. Auditer sur des données de terrain, isoler le gabarit de page réellement concerné avant d’agir, et traiter le LCP, l’INP et le CLS comme trois problèmes distincts, avec des leviers techniques distincts, plutôt que comme un score unique à faire remonter.

Pour aller plus loin : la documentation officielle et la méthodologie complète sont disponibles sur web.dev.