Google Core Web Vitals : seuils, mesure et correctifs

Un site affiche 96 sur 100 dans PageSpeed Insights. Le même mois, la Search Console classe 1 400 de ses URL en « Médiocre » sur les Signaux Web essentiels. Les deux constats sont exacts en même temps, et c’est là que la plupart des chantiers de performance se perdent : on optimise un score de laboratoire pendant que Google regarde le comportement de vrais utilisateurs sur 28 jours glissants.

Sur les Core Web Vitals, la documentation officielle est stable, publique et précise. Les contenus francophones, eux, traînent encore des métriques supprimées depuis plus de deux ans.

Core Web Vitals : les trois signaux officiels et leurs seuils en 2026

Les Web Vitals regroupent l’ensemble des indicateurs de qualité d’expérience définis par Google. Les Core Web Vitals en sont le sous-ensemble restreint : les signaux qui s’appliquent à toutes les pages web et que Google intègre à ses systèmes de classement. Ils sont trois, et trois seulement.

Trois précisions changent la lecture de ce tableau (Google, web.dev, 2026). Un seuil ne s’évalue jamais sur un chargement isolé : Google retient la valeur au 75e percentile des chargements observés, segmentée entre mobile et ordinateur, soit deux verdicts distincts. Et Google s’engage sur une cadence de changement d’un an maximum, avec préavis et changelog public. Ce dernier point filtre le bruit : les contenus qui annoncent un seuil LCP abaissé à 2,0 secondes, une métrique surprise pour 2026 ou une évaluation au niveau du site entier inventent.

Il faut aussi savoir ce qui n’est pas un Core Web Vital. Le FCP, le TTFB, le TBT et le Speed Index sont des métriques de diagnostic : elles expliquent pourquoi le LCP ou l’INP dérape, elles n’entrent dans aucun système de classement.

Les définitions normatives font foi dans la documentation Web Vitals de Google, à opposer à toute affirmation contradictoire lors d’un audit technique SEO.

Le FID n’existe plus depuis le 12 mars 2024

Le First Input Delay a été retiré des Core Web Vitals le 12 mars 2024, remplacé par l’INP (Google, web.dev, 2024). Il a disparu du rapport Signaux Web essentiels ce jour-là, puis des autres outils Google après six mois de dépréciation.

Le remplacement n’est pas cosmétique. Le FID ne mesurait que le délai d’entrée de la toute première interaction, entre le clic et le démarrage du gestionnaire d’événement, en ignorant l’exécution du code et l’affichage du résultat : une page pouvait afficher un excellent FID et rester insupportable à l’usage. L’INP mesure la latence complète (délai d’entrée, exécution, rendu) et retient la pire interaction de la visite.

Plusieurs pages françaises encore bien positionnées le présentent pourtant comme un signal actif. Ce n’est pas un détail sémantique : un plan d’action calé sur le FID vise le délai avant exécution, alors que la réactivité réelle se joue dans l’exécution des gestionnaires et le rendu de la frame suivante.

Ce que mesure exactement chaque métrique

La mécanique de calcul dicte le correctif : un LCP dégradé par le temps de réponse serveur et un LCP dégradé par une image découverte trop tard n’appellent ni les mêmes leviers ni les mêmes équipes.

LCP : le rendu du plus grand élément visible

Le LCP mesure le temps de rendu du plus grand élément de contenu visible dans la fenêtre d’affichage, depuis le début de la navigation. Les candidats sont limitativement définis : balises img, images dans un svg, éléments video (poster ou première frame), éléments porteurs d’une background-image en url(), blocs de texte (Google, web.dev, 2026).

Point rarement expliqué : le navigateur cesse de reporter de nouvelles entrées LCP dès la première interaction, tap, scroll ou frappe clavier. Sur une page où l’internaute scrolle immédiatement, l’élément retenu n’est donc pas forcément celui que l’on croit.

Google décompose le LCP en quatre sous-parties, avec une répartition cible : TTFB environ 40 %, resource load delay (entre le TTFB et le début du chargement de la ressource) moins de 10 %, resource load duration environ 40 %, element render delay moins de 10 %.

Garde-fou explicite de Google : ces pourcentages ne se convertissent pas en objectifs en millisecondes. Ils ne valent que les uns par rapport aux autres, et si le LCP tient déjà sous 2,5 secondes, la répartition n’a aucune importance.

INP : la latence de la pire interaction, pas de la première

L’INP observe la latence de toutes les interactions de la visite et retient la pire. Le périmètre est précis : clics, taps et interactions clavier. Ni le scroll, ni le survol, ni le zoom (Google, web.dev, 2026). Chaque interaction se décompose en trois phases :

1. Input delay : entre le geste et le démarrage des gestionnaires d’événements, allongé quand le thread principal est occupé.
2. Processing duration : l’exécution des callbacks.
3. Presentation delay : jusqu’à l’affichage de la frame suivante, recalcul de mise en page inclus.

Conséquence directe : un INP dégradé ne se corrige pas en compressant des images. Il se corrige dans le JavaScript, dans la taille du DOM et dans la façon dont le rendu est déclenché. Les seuils restent 200 ms et 500 ms, au 75e percentile.

CLS : la pire fenêtre de 5 secondes, pas la somme de la page

Le CLS n’est pas une durée mais un score sans unité. Chaque décalage vaut impact fraction × distance fraction (Google, web.dev, 2026) : la surface cumulée des éléments instables sur deux frames consécutives rapportée au viewport, multipliée par le plus grand déplacement, horizontal ou vertical, rapporté à la plus grande dimension de ce viewport.

L’agrégation est le point que presque personne n’explique. Les décalages sont regroupés en fenêtres de session : deux décalages appartiennent à la même fenêtre s’ils sont espacés de moins d’une seconde, et une fenêtre dure au maximum 5 secondes. Le CLS retenu est le score de la fenêtre la plus élevée, pas le cumul de la page : des micro-décalages espacés ne font pas échouer une page, une seule salve de 3 secondes suffit.

Une exclusion complète le calcul : les décalages survenant dans les 500 ms suivant une interaction discrète portent le drapeau hadRecentInput et sont écartés, ce qui ne vaut pas pour les actions continues comme le scroll. Concrètement, un bandeau injecté tardivement suffit à faire échouer un gabarit entier.

Données terrain contre données labo : la confusion qui coûte le plus cher

Une seule règle : les données terrain sont les seules qui comptent pour Google, les données labo servent à trouver la cause, jamais à décider si c’est corrigé. Presque toutes les erreurs de pilotage viennent de l’inversion de ces deux rôles.

CrUX : 28 jours glissants, 75e percentile, Chrome uniquement

Le Chrome UX Report (CrUX) est la source de vérité. Il agrège les mesures collectées chez de vrais utilisateurs et les restitue en moyenne glissante sur 28 jours, au 75e percentile. Rafraîchissement quotidien vers 4h UTC, avec environ deux jours de décalage (Google, Chrome for Developers, 2026).

L’éligibilité est doublement conditionnée. Côté utilisateur : statistiques d’usage activées, historique de navigation synchronisé, absence de phrase secrète de synchronisation, plateforme supportée. Côté page : l’URL doit être publiquement découvrable, donc répondre en HTTP 200 après redirections, sans noindex ni en-tête X-Robots-Tag: noindex, et être suffisamment populaire, seuil non communiqué par Google.

D’où deux conséquences. Une page à faible trafic n’a aucune donnée au niveau page : elle n’hérite que de données au niveau origine, agrégées sur tout le site, ce qui rend son statut individuel illisible. Beaucoup de sites en concluent à tort qu’ils n’ont pas de problème, alors qu’ils n’ont surtout pas de données. Et le CrUX ne voit que Chrome, ni Safari ni Firefox, ce qui compte sur une audience à forte part iOS.

Lighthouse et le score PageSpeed : un labo qui ne classe rien

Lighthouse simule un chargement dans un environnement contrôlé, appareil et réseau bridés, et produit un score sur 100. Ce score n’est pas un Core Web Vital et n’entre dans aucun système de classement. PageSpeed Insights juxtapose les deux mondes : en haut les données terrain issues du CrUX, en bas le diagnostic Lighthouse simulé. Les deux blocs peuvent se contredire, et c’est normal.

Le cas classique est un score labo à 95 sur 100 avec un statut Core Web Vitals en échec. Deux raisons techniques. Lighthouse ne peut pas mesurer l’INP puisqu’aucune interaction réelle n’a lieu pendant le test : une page peut être parfaite au chargement et catastrophique au clic. Et il estime le CLS sur un chargement unique, sans parcours ni scroll, donc sans les injections tardives que subissent de vrais visiteurs. La situation inverse existe aussi, sur une audience équipée mieux que le profil bridé du test.

Règle d’arbitrage : le labo identifie la cause, le terrain valide la correction. Un ticket ne se ferme pas sur un score Lighthouse.

Lire le rapport Signaux Web essentiels de la Search Console

Le rapport s’appuie sur le CrUX. Quatre points de lecture évitent la quasi-totalité des contresens (Google, aide Search Console, 2026).

1. Deux onglets, deux chantiers. Mobile et Ordinateur n’ont ni les mêmes défauts ni les mêmes priorités. En 2025, 62 % des sites ont un bon LCP sur mobile contre 74 % sur ordinateur, mais 81 % ont un bon CLS sur mobile contre seulement 72 % sur ordinateur (HTTP Archive, Web Almanac 2025).

2. Les URL sont regroupées en pages à expérience similaire, ce qui correspond en pratique aux gabarits : on ne corrige jamais une URL, on corrige un gabarit. Quand les données d’un groupe sont insuffisantes, le rapport bascule sur un groupe origine couvrant toutes les URL de même protocole, hôte et port, ce qui dilue le diagnostic.

3. Le statut d’une URL est celui de sa pire métrique. Un LCP et un CLS irréprochables ne sauvent pas une page dont l’INP dépasse 200 ms.

4. Le bouton « Valider la correction » ouvre une session d’observation de 28 jours, qui s’ajoute à la fenêtre glissante de 28 jours du CrUX. Un correctif déployé aujourd’hui ne peut pas être jugé avant environ un mois, et n’est pleinement reflété qu’au bout de deux cycles.

La conséquence est organisationnelle avant d’être technique : un chantier Core Web Vitals se cadence par cycles de quatre semaines, avec un correctif significatif à la fois par gabarit. Cinq changements le même jour rendent tout gain inattribuable, donc non reproductible.

Ce que les Core Web Vitals pèsent réellement dans le classement

Mieux vaut citer Google que le paraphraser. La documentation Page experience de Search Central est explicite. « There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience. » Il n’existe pas de facteur unique « expérience de page » que l’on pourrait activer. « Google Search always seeks to show the most relevant content, even if the page experience is sub-par. » La pertinence prime, toujours.

Et surtout, la phrase que personne ne relève : « Beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher in search results. » Autrement dit, parmi tous les critères d’expérience de page, les Core Web Vitals sont les seuls à aider directement au classement. La version française dit la même chose : de bons Core Web Vitals, « combinée à d’autres aspects de l’expérience sur la page, est en adéquation avec ce que nos principaux systèmes de classement cherchent à récompenser » (Google Search Central, 2026).

Conclusion sans ambiguïté : les Core Web Vitals ne font pas remonter un contenu faible, ils départagent des contenus équivalents sur des SERP concurrentielles. Une brique parmi d’autres dans un chantier d’optimisation technique SEO, pas un levier de croissance autonome.

Le terrain de jeu est chiffré. D’après le Web Almanac 2025 de HTTP Archive (données CrUX de juillet 2025), 48 % des sites passent les trois métriques sur mobile et 56 % sur ordinateur, contre 32 % sur mobile en 2021 : la progression est réelle, mais plus d’un site mobile sur deux échoue encore. Et ce ne sont pas les gros sites qui s’en sortent le mieux : 51 % du top 1 000 passent sur mobile, contre 37 % du top 100 000.

Là où l’impact se chiffre vraiment, c’est côté business (Google, web.dev, études de cas, 2026) :

• Vodafone Italie : LCP amélioré de 31 %, 8 % de ventes supplémentaires.
• Nykaa : LCP amélioré de 40 %, 28 % de trafic organique supplémentaire.
• Cdiscount : les trois métriques améliorées, 6 % de chiffre d’affaires supplémentaire sur son Black Friday.
• Agrofy Market : LCP amélioré de 70 %, 76 % d’abandons de chargement en moins.

Le point commun de ces quatre cas n’est pas le gain SEO, c’est la conversion et l’abandon évité. C’est en général l’argument qui débloque le budget.

Du diagnostic au correctif : la méthode métrique par métrique

Pas de liste générique de leviers de vitesse ici (formats d’image, cache, minification, hébergement, CDN, HTTP/3) : ce plan d’action est traité dans notre diagnostic de vitesse de chargement. L’apport est en amont : qualifier la sous-partie ou la phase fautive avant de choisir un correctif.

LCP : qualifier la sous-partie avant de toucher aux images

1. Relever la sous-partie dominante. Le panneau Performance de Chrome DevTools, ou l’attribution de la bibliothèque web-vitals, donne la répartition entre TTFB, load delay, load duration et render delay. Tant qu’elle n’est pas connue, tout correctif est un pari.

2. Si le load delay domine, le problème est la découvrabilité de la ressource. 73 % des pages mobiles ont une image comme élément LCP, et 35 % de ces images ont une URL source non découvrable dans le HTML initial parce qu’elles sont déclarées en CSS ou injectées en JavaScript (Google, web.dev, 2026). Le navigateur ne peut pas précharger ce qu’il ne voit pas. Correctif : une balise img avec un src présent dans le HTML servi, ou un link rel="preload" combiné à fetchpriority="high". Le gisement est massif : 16 % des pages chargent encore leur image LCP en lazy loading, et fetchpriority="high" n’est présent que sur 17 % des pages mobiles à image LCP, contre 15 % en 2024 (HTTP Archive, Web Almanac 2025).

3. Si le TTFB domine, le sujet est infrastructure, pas front. Réponse serveur, cache côté edge, distribution géographique. Seules 33 % des requêtes de document HTML sont servies depuis un CDN (Google, web.dev, 2026).

4. Si le render delay domine, ce sont les ressources bloquantes et les polices web. CSS bloquant le rendu, scripts synchrones dans le head, polices chargées sans stratégie d’affichage.

Le LCP reste le vrai goulot d’étranglement : 40 % des sites du CrUX n’atteignent pas le seuil recommandé, loin devant le CLS et l’INP (Google, web.dev, 2026).

INP : trouver l’interaction coupable, pas la page lente

L’INP ne se diagnostique pas sur un chargement mais sur un parcours : enregistrer une session réelle dans le panneau Performance de DevTools en cliquant sur les éléments interactifs du gabarit, ou exploiter l’API Long Animation Frames via la bibliothèque web-vitals, pour isoler l’interaction la plus lente et la phase responsable. Les correctifs se choisissent ensuite par phase :

• Input delay élevé : des tâches longues monopolisent le thread principal. Découper toute tâche dépassant 50 ms et rendre la main au navigateur avec scheduler.yield() (Google, web.dev, 2026).
• Processing duration élevée : gestionnaires d’événements trop lourds. Ne garder dans le chemin de l’interaction que ce qui produit le retour visuel immédiat, différer le reste (analytics, journalisation, calculs secondaires).
• Presentation delay élevé : mise à jour de rendu trop large. Éviter les layouts forcés en regroupant les lectures puis les écritures du DOM, limiter la taille du DOM, appliquer la containment CSS aux blocs hors écran.

Levier de fond recommandé par Google dans les trois cas : réduire le volume de JavaScript envoyé, en repérant le code inutilisé avec l’outil de couverture et en découpant les bundles non critiques.

CLS : dimensionner avant d’optimiser

Trois causes couvrent l’essentiel. Les médias sans dimensions : 66 % des pages ont au moins une image sans width ni height déclarés (Google, web.dev, 2026), première cause de décalage et premier correctif à passer. Le contenu injecté au-dessus de la ligne de flottaison (bandeaux, publicités, consentement, notifications) : réserver son espace en amont, avec une hauteur minimale déclarée dans le gabarit, plutôt que le laisser pousser le contenu. Les animations qui déclenchent un recalcul de mise en page : animer transform et opacity, jamais margin, top ou left.

S’y ajoute le levier que Google désigne comme celui ayant produit le plus gros gain de CLS observé : l’éligibilité au bfcache, souvent cassée par un gestionnaire unload résiduel ou des en-têtes Cache-Control: no-store. Un quart des sites environ n’atteignent pas le seuil CLS, et le score retenu étant la pire fenêtre de 5 secondes, la chasse se fait à l’unité, pas en moyenne.

Les quatre erreurs qui font échouer un chantier Core Web Vitals

1. Piloter sur le score PageSpeed au lieu du terrain. Le score sur 100 n’est pas un signal, il n’entre dans aucun système de classement et il ne mesure pas l’INP.

2. Corriger la page d’accueil et oublier les gabarits qui portent le trafic. Sur mobile, 45 % des pages d’accueil ont de bons Core Web Vitals contre 56 % des pages secondaires, et sur l’INP le rapport s’inverse : 80 % contre 69 % (HTTP Archive, Web Almanac 2025).

3. Traiter mobile et ordinateur comme un seul chantier. 62 % de bons LCP sur mobile contre 74 % sur ordinateur, 77 % de bons INP sur mobile contre 97 % sur ordinateur (HTTP Archive, Web Almanac 2025) : sur ordinateur, l’INP est un non-sujet dans la quasi-totalité des cas.

4. Déployer cinq correctifs le même jour et regarder le lendemain. La fenêtre CrUX de 28 jours rend toute évaluation impossible avant un mois, et un correctif par cycle reste la seule façon d’attribuer un gain à une action.

Passer des signaux au plan de correction

La hiérarchie utile tient en trois temps. Savoir d’abord sur quelle métrique et quel groupe d’URL le site échoue, dans le rapport Signaux Web essentiels, sur le bon onglet. Qualifier ensuite la sous-partie du LCP, la phase de l’interaction ou la fenêtre de décalage en cause, en laboratoire. Choisir enfin un correctif, un seul, et lui laisser un cycle complet de 28 jours.

Les Core Web Vitals sont moins un problème technique qu’un problème de séquence. La plupart des chantiers échouent parce qu’ils commencent par les correctifs et jamais par la qualification : on compresse des images quand c’est le serveur qui répond mal, on allège le CSS quand c’est un gestionnaire d’événement qui bloque le clic, et trois mois plus tard personne ne sait ce qui a produit quoi.

Pour identifier sur quels gabarits et quelles métriques votre site perd réellement, et dans quel ordre les traiter, parlons de votre audit technique.