Pour passer les Core Web Vitals en 2026, ta page doit afficher un LCP sous 2,5 secondes, un INP sous 200 millisecondes et un CLS sous 0,1 — mesurés au 75e percentile des visites réelles via le CrUX. Ces trois seuils, définis par Google, déterminent le badge « Bon » affiché dans Search Console.
Tu regardes ton score PageSpeed Insights : 95/100, tout au vert. Tu ouvres Search Console, onglet Core Web Vitals : « Mauvais » sur mobile. Les deux outils ne racontent pas la même histoire, et c'est justement là que la plupart des sites se plantent dans leur diagnostic.
Ce n'est pas un détail technique isolé. Après le core update de mars 2026, les pages en position 1 affichaient un taux de passage des Core Web Vitals supérieur de 10 % à celles en position 9, selon les observations de Search Engine Land. Ce n'est pas le facteur qui décide du classement, mais c'est celui qui te fait perdre l'arbitrage face à un concurrent équivalent en contenu.
Voici les seuils exacts, ce qu'ils mesurent vraiment, et comment les corriger sans perdre de temps sur ce qui ne compte pas.
Que mesurent les Core Web Vitals et pourquoi ils comptent en 2026
Les Core Web Vitals sont trois métriques Google qui évaluent l'expérience réelle d'un visiteur sur une page : le LCP (Largest Contentful Paint) mesure la vitesse de chargement du plus gros élément visible, l'INP (Interaction to Next Paint) mesure la réactivité de la page après une interaction, et le CLS (Cumulative Layout Shift) mesure la stabilité visuelle pendant le chargement.
Le point que presque personne ne lit jusqu'au bout dans la documentation Google : ces métriques sont évaluées au 75e percentile des visites réelles, collectées via le Chrome User Experience Report (CrUX). Concrètement, ta page ne passe que si 75 % de tes visiteurs — pas la moyenne, le 3e quartile le moins favorisé — vivent une expérience « Bonne ». Un site rapide sur fibre et lent sur 4G en zone rurale peut très bien échouer alors que son score de laboratoire est excellent.
| Métrique | Bon | À améliorer | Mauvais |
|---|---|---|---|
| LCP (chargement) | ≤ 2,5 s | 2,5 s – 4 s | > 4 s |
| INP (réactivité) | ≤ 200 ms | 200 ms – 500 ms | > 500 ms |
| CLS (stabilité) | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
L'INP a remplacé le FID (First Input Delay) en mars 2024 comme métrique officielle. La différence compte : le FID ne mesurait que le tout premier clic sur la page, l'INP mesure la réactivité sur toutes les interactions pendant toute la session — un calcul bien plus exigeant, qui explique pourquoi des sites jugés rapides avant 2024 se retrouvent en difficulté aujourd'hui. Pour resituer ces seuils dans une évaluation technique plus large, notre article sur les 12 critères d'un bon audit SEO détaille où ils se placent parmi les autres priorités.
Comment améliorer tes Core Web Vitals étape par étape
Corriger dans le désordre fait perdre du temps : mesurer avant d'agir évite de traiter un symptôme qui n'existe pas vraiment sur tes vrais visiteurs.
- Mesurer avec les bonnes données, pas seulement le labo
- Réduire le LCP à la source
- Faire tomber l'INP sous 200 ms
- Stabiliser le CLS dès le premier rendu
- Objectiver le résultat avec un audit complet
Étape 1 — Mesurer avec les bonnes données, pas seulement le labo
Commence toujours par le rapport Core Web Vitals de Search Console : c'est la seule source qui reflète tes vrais visiteurs, groupés par type d'URL. PageSpeed Insights et Lighthouse restent utiles, mais uniquement pour valider une correction en local avant qu'elle ne remonte dans le CrUX — jamais comme diagnostic principal. Segmente aussi par appareil : le mobile échoue presque toujours en premier, et c'est généralement lui qui fait basculer le statut global de la page.
Étape 2 — Réduire le LCP à la source
Le LCP est presque toujours plombé par trois causes : une image héro non optimisée, un temps de réponse serveur trop long (TTFB), ou des ressources bloquantes chargées avant le contenu principal. Compresse et sers tes images en formats modernes (WebP, AVIF), précharge l'élément LCP avec <link rel="preload">, et vérifie ton hébergement : un TTFB supérieur à 600 ms plombe le LCP avant même que le navigateur ne commence à afficher quoi que ce soit.
Étape 3 — Faire tomber l'INP sous 200 ms
L'INP se dégrade quand du JavaScript occupe le thread principal trop longtemps entre le clic de l'utilisateur et la réponse visuelle. Découpe les longues tâches JS, différe le chargement des scripts tiers non essentiels (chat, tracking, pop-ins), et évite les gestionnaires d'événements trop lourds sur les éléments interactifs. C'est la métrique la plus longue à corriger, mais aussi celle qui trahit le plus souvent une accumulation d'outils tiers ajoutés au fil du temps sans jamais être nettoyés.
Étape 4 — Stabiliser le CLS dès le premier rendu
Réserve systématiquement les dimensions de chaque image, vidéo et bloc publicitaire en CSS avant même que la ressource ne charge. Les polices web sont une cause fréquente et sous-estimée : utilise font-display: optional ou précharge la police pour éviter le décalage au moment où elle remplace la police système. N'injecte jamais de contenu au-dessus du contenu déjà affiché, sauf en réponse directe à une action de l'utilisateur.
Étape 5 — Objectiver le résultat avec un audit complet
Une fois les corrections déployées, ne te fie pas qu'à ton impression : l'Audit SEO de GoMySeo mesure les Core Web Vitals aux côtés de tous les autres signaux techniques et on-page, en un seul rapport, sans avoir à jongler entre Search Console, PageSpeed Insights et un crawler séparé. Ça te permet de voir immédiatement si la correction a un effet réel ou si un autre facteur technique masque le résultat.
Les erreurs qui plombent tes Core Web Vitals
- Se fier uniquement au score Lighthouse : un 95/100 en laboratoire ne garantit rien sur le terrain. Seul le rapport CrUX de Search Console reflète tes vrais visiteurs.
- Charger des polices web bloquantes : sans stratégie de préchargement, chaque changement de police après le rendu initial dégrade directement le CLS.
- Ne jamais réserver l'espace des images : une image sans largeur ni hauteur définies pousse le contenu au moment où elle charge — la cause la plus fréquente de mauvais CLS.
- Empiler les scripts tiers sans les auditer : chat en direct, pixels publicitaires, widgets d'avis — chacun ajoute du JavaScript qui bloque le thread principal et dégrade l'INP.
- Injecter des pop-ins après le chargement : une bannière ou une pub qui apparaît sans espace réservé fait immédiatement basculer le CLS dans le rouge.
- Optimiser uniquement le desktop : le 75e percentile mobile est presque toujours pire, et c'est souvent lui qui détermine le statut global affiché dans Search Console.
- Corriger sans remesurer : le rapport Search Console utilise une fenêtre glissante de 28 jours. Une correction qui ne semble « rien changer » après trois jours n'a simplement pas encore eu le temps de remonter.
FAQ : Core Web Vitals et référencement
Les Core Web Vitals sont-ils un facteur de classement Google ?
Oui, mais un facteur d'ajustement plutôt qu'un critère dominant. Google les utilise comme un signal de départage entre pages de qualité éditoriale équivalente : ils comptent pour environ 10 à 15 % des signaux de classement selon les études sectorielles. Un contenu médiocre avec un LCP parfait ne battra jamais un contenu pertinent et bien structuré, même plus lent — le trafic organique se construit d'abord sur la pertinence.
Quelle est la différence entre le score PageSpeed Insights et les Core Web Vitals ?
Le score PageSpeed Insights est une note de laboratoire calculée sur un seul chargement simulé. Les Core Web Vitals affichés dans Search Console viennent du CrUX, les données réelles de millions d'internautes Chrome, mesurées au 75e percentile. Un site peut afficher 95/100 sur Lighthouse et rester « Mauvais » en Core Web Vitals réels.
Pourquoi mon INP est-il mauvais alors que mon site semble rapide au chargement ?
Le LCP mesure le chargement, l'INP mesure la réactivité après coup : un clic sur un menu, un champ de formulaire, un bouton d'ajout au panier. Un site qui charge vite mais exécute beaucoup de JavaScript tiers peut bloquer le thread principal et répondre en retard à chaque interaction, sans que rien ne se voie au premier affichage.
Comment corriger un mauvais CLS causé par des publicités ou des bannières ?
Réserve systématiquement l'espace de chaque élément publicitaire avec une hauteur et largeur fixes en CSS avant même que la ressource ne charge. Le CLS pénalise tout décalage visuel après le premier rendu. Un conteneur dimensionné à l'avance neutralise le problème quasi totalement, sans nuire à la visibilité Google de la page.
Combien de temps avant de voir l'effet d'une correction dans Search Console ?
Compte 28 jours minimum. Le rapport Core Web Vitals de Search Console utilise une fenêtre glissante de 28 jours de données CrUX réelles : une correction déployée aujourd'hui ne remplace complètement l'ancienne donnée qu'au bout de quatre semaines. Si tu prévois une refonte, notre guide sur comment refondre un site sans perdre son référencement détaille comment éviter qu'un nouveau thème ne dégrade ces métriques au pire moment.
Pourquoi mesurer tes Core Web Vitals régulièrement, pas une fois
Le piège classique : corriger une fois, cocher la case, puis oublier. Sauf que chaque script ajouté, chaque plugin installé, chaque image mise en ligne sans compression peut faire repasser une métrique dans le rouge sans que personne ne s'en aperçoive avant la prochaine baisse de trafic.
C'est exactement ce que couvre l'Audit SEO de GoMySeo : un rapport technique et on-page complet, généré en quelques secondes, qui inclut les Core Web Vitals aux côtés des balises, du maillage interne et des points bloquants pour l'indexation. Pas besoin d'ouvrir cinq outils différents pour savoir où tu en es.
Sur GoMySeo, cet audit fonctionne avec le même système de crédits que les autres modules — pas d'abonnement obligatoire, un essai gratuit de 7 jours pour voir exactement où ton site perd des points avant que ça ne se traduise en perte de position. Comparé aux 119 €/mois des suites américaines équivalentes, c'est un contrôle que tu peux te permettre de refaire chaque mois, pas une fois par an.
En résumé : trois seuils, une méthode, un contrôle régulier
LCP sous 2,5 secondes, INP sous 200 millisecondes, CLS sous 0,1 — mesurés au 75e percentile des vrais visiteurs, pas en laboratoire. Corrige dans l'ordre : mesure d'abord avec Search Console, puis LCP, puis INP, puis CLS. Et laisse passer 28 jours avant de juger le résultat.
Ton site charge peut-être vite pour toi, sur ta connexion, sur ton écran. La question qui compte : charge-t-il vite pour le visiteur le moins bien loti, celui qui détermine à lui seul si Google affiche « Bon » ou « Mauvais » sur ta fiche technique ?
