Les Core Web Vitals sont trois métriques de Google qui mesurent l’expérience réelle d’une page : le LCP (vitesse d’affichage, seuil 2,5 s), l’INP (réactivité aux interactions, seuil 200 ms) et le CLS (stabilité visuelle, seuil 0,1). Une page passe si ses trois indicateurs sont dans le vert au 75e percentile des visites.
Votre page met trois secondes à afficher son contenu principal. Un bouton qui répond avec un temps de retard. Un bandeau cookies qui fait sauter le texte au moment où le visiteur allait cliquer. Ces détails ont un nom chez Google : les Core Web Vitals.
La plupart des dirigeants les découvrent dans un rapport Google Search Console, en rouge, sans savoir quoi en faire. Le mot fait peur. La réalité est plus simple. Ce sont trois mesures concrètes du confort de navigation, et elles pèsent sur votre positionnement Google autant que sur votre taux de conversion.
Ce guide donne les seuils exacts à jour. Il sépare les données qui comptent vraiment de celles qui trompent. Et il détaille les leviers qui bougent l’aiguille. Vous pourrez aussi tester vos scores avec l’évaluateur plus bas. Objectif : comprendre ce qui bloque et savoir par où commencer.
Vos pages sont lentes et vous ne savez pas par où commencer ?
Demander un audit techniqueCore Web Vitals : de quoi parle-t-on vraiment
Un chargement, trois moments mesurés
Chaque métrique capte un instant précis de la visite, du clic dans Google jusqu’à la première interaction.
La requête part
t = 0Page vide, le navigateur attend le serveur.
Le contenu principal s’affiche
LCP ≤ 2,5 sLe plus gros élément visible est enfin là.
Un bloc pousse le texte
CLS ≤ 0,1Tout ce qui bouge sans prévenir s’additionne.
Le visiteur tape un bouton
INP ≤ 200 msCombien de temps avant que l’écran réagisse.
Le CLS se cumule sur toute la visite et l’INP observe toutes les interactions, pas seulement la première. C’est la grande différence avec le FID, retiré en mars 2024, qui ne mesurait que le premier clic.
Le nom intimide, l’idée est simple. Google a longtemps jugé une page sur son temps de chargement total. Mauvais indicateur. Une page peut charger vite en apparence et rester pénible à utiliser. Les Core Web Vitals corrigent ça en mesurant le ressenti réel de l’internaute, pas une moyenne technique.
Le terme français officiel est signaux web essentiels. Chacun répond à une question que le visiteur se pose sans la formuler. Est-ce que ça s’affiche, est-ce que ça réagit, est-ce que ça tient en place. Le schéma ci-dessus situe les trois dans le temps d’une visite.
Ces signaux s’intègrent au cadre plus large que Google appelle Page Experience, aux côtés du HTTPS et de la compatibilité mobile. Mais ce sont les seuls indicateurs d’expérience utilisateur branchés directement sur l’algorithme de classement. C’est ce qui les rend incontournables.
Attention à une confusion encore fréquente. Beaucoup d’articles citent toujours le FID, First Input Delay, comme troisième métrique. C’est faux depuis mars 2024 : l’INP l’a remplacé. Le FID ne mesurait que le délai de la première interaction, l’INP évalue toutes celles de la visite.
Les seuils officiels Core Web Vitals en 2026
Les seuils officiels, et combien de sites les passent vraiment
Part des sites sur mobile, données terrain de Chrome relevées en juillet 2025.
LCP
bon ≤ 2,5 s
mauvais > 4 s
62 % bon, 25 % à améliorer, 13 % mauvaisLe maillon faible
INP
bon ≤ 200 ms
mauvais > 500 ms
77 % bon, 21 % à améliorer, 3 % mauvais
CLS
bon ≤ 0,1
mauvais > 0,25
81 % bon, 10 % à améliorer, 9 % mauvais
- Bon
- À améliorer
- Mauvais
48 %
des sites mobiles passent les trois seuils en même temps.
56 %
sur desktop, avec la même règle.
Un site passe une métrique quand 75 % de ses visites réelles atteignent le seuil. Il passe l’évaluation quand les trois y sont.
Source, HTTP Archive, Web Almanac 2025, chapitre Performance
Google découpe chaque métrique en trois zones : bonne, à améliorer, mauvaise. Pour passer l'évaluation globale, vos trois métriques doivent être dans le vert. Une seule au rouge et la page échoue.
Les bornes sont précises. Le LCP devient mauvais au-delà de 4 secondes, l'INP au-delà de 500 ms, le CLS au-delà de 0,25. Entre le seuil vert et ces bornes, Google parle de zone à améliorer.
Un point que la plupart des guides oublient. Google note votre page au 75e percentile des visites réelles, sur une fenêtre glissante de 28 jours. Autrement dit, au moins 75 % de vos visiteurs doivent vivre une bonne expérience. Une moyenne ne suffit pas. Si un quart de vos utilisateurs rament, la page échoue.
Combien de sites y arrivent vraiment ? HTTP Archive a mesuré les données Chrome de juillet 2025 dans son Web Almanac 2025. Résultat : 48 % des sites mobiles passent les trois seuils, contre 56 % sur desktop. Le détail mobile est parlant. Le LCP est bon sur 62 % des sites, à améliorer sur 25 % et mauvais sur 13 %. L'INP affiche 77 %, 21 % et 3 %. Le CLS, 81 %, 10 % et 9 %. Plus d'un site mobile sur deux échoue, et c'est le LCP qui en fait tomber le plus.
HTTP Archive, Web Almanac 2025, chapitre Performance
Évaluez vos Core Web Vitals en 30 secondes
Avant d'entrer dans le détail de chaque métrique, testez vos propres scores. Récupérez vos valeurs LCP, INP et CLS dans PageSpeed Insights ou dans la Search Console. Saisissez-les ci-dessous. L'outil vous dit où vous en êtes selon les seuils officiels de Google.
Évaluateur de conformité Core Web Vitals
Saisissez vos trois valeurs de terrain, celles de la section « Données de champ ».
Barème : seuils officiels Google. Bon si LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1. Mauvais au-delà de 4 s, 500 ms et 0,25. Les jauges sont bornées à 6 s, 800 ms et 0,4 pour rester lisibles. L'outil compare vos valeurs à ces seuils, rien de plus.
Un score dans le rouge n'est pas une fatalité. Chaque métrique a ses causes connues et ses corrections précises. On les détaille maintenant, une par une.
LCP : la métrique qui fait échouer le plus de sites
Où se perdent les secondes du LCP
Quatre phases s'enchaînent avant l'affichage. Chacune a son frein et son levier.
Phase 1
Réponse du serveur
Frein : serveur lent
Levier : rendu côté serveur, cache
Phase 2
Découverte de l'image
Frein : repérée tard, priorité basse
Levier : préchargement, fetchpriority
Phase 3
Téléchargement
Frein : image trop lourde
Levier : compresser, redimensionner
Phase 4
Rendu à l'écran
Frein : CSS et JavaScript bloquants
Levier : CSS critique dans le HTML
2,5 s
l'élément principal doit être affiché
Levierrendu côté serveur, cache
Levierpréchargement, fetchpriority
Leviercompresser, redimensionner, format moderne
LevierCSS critique dans le HTML
Phase 2, un seul attribut
2,6 s → 1,9 s
LCP d'une page Google Flights après ajout de fetchpriority="high" sur l'image d'en-tête. Test documenté par Google sur web.dev.
Pourquoi les images d'abord
76 %
des pages mobiles ont une image comme élément LCP, selon le Web Almanac 2025.
Le LCP se joue sur le plus gros élément visible au chargement. Sur la plupart des sites, c'est une image d'en-tête ou un grand titre. D'après le même Web Almanac 2025, l'élément LCP est une image sur 76 % des pages mobiles. Si cet élément met plus de 2,5 secondes à apparaître, le visiteur a déjà l'impression d'un site lent.
Les causes d'un mauvais LCP sont bien connues. Un serveur qui répond trop lentement. Des images trop lourdes ou mal dimensionnées. Du CSS et du JavaScript qui bloquent le rendu avant que le contenu ne s'affiche.
Google découpe d'ailleurs le LCP en quatre phases successives. La réponse du serveur, le délai avant que le navigateur découvre la ressource, son téléchargement, puis le rendu. Chaque cause ci-dessus freine une phase précise, d'où l'intérêt de savoir laquelle coince avant d'agir.
Les corrections à fort impact
Quatre leviers sortent du lot. Optimiser et redimensionner l'image d'en-tête, souvent le coupable numéro un. Précharger l'élément LCP pour que le navigateur le télécharge en priorité. Injecter le CSS critique directement dans le HTML. Servir le rendu côté serveur quand c'est possible.
Un test documenté par Google sur web.dev le montre bien. Sur une page Google Flights, ajouter fetchpriority="high" à l'image d'en-tête a fait passer le LCP de 2,6 à 1,9 seconde. Un seul attribut HTML, 700 millisecondes gagnées.
Google web.dev, Optimize resource loading with the Fetch Priority API
INP : la réactivité, le chantier le plus technique
Anatomie d'une interaction
Entre le tap et l'écran mis à jour, trois temps s'additionnent.
Délai d'entrée
Le navigateur finit une tâche longue avant de vous écouter.
Traitement
Votre code répond à l'action.
Présentation
L'écran se redessine.
Total visé : ≤ 200 ms
Sites avec un INP bon
Desktop97 %
Mobile77 %
20 points d'écart. Sur ordinateur, l'INP est presque réglé. Sur mobile, c'est encore un sujet. Source : HTTP Archive, Web Almanac 2025.
L'INP est la métrique la plus exigeante à corriger. Elle mesure la réactivité de votre page à chaque interaction. Un clic, une saisie, un tap sur mobile : combien de temps avant que la page réagisse visuellement.
Chaque interaction se décompose en trois temps. Le délai d'entrée, quand le navigateur est encore occupé ailleurs. Le traitement, quand votre code répond à l'action. Puis la présentation, quand l'écran se redessine. C'est souvent le premier temps qui fait exploser le compteur.
Sur desktop, la question est presque réglée. D'après HTTP Archive (Web Almanac 2025), 97 % des sites ont un INP bon sur ordinateur, contre 77 % sur mobile. Soit 20 points d'écart, précisément sur l'écran que vos visiteurs tiennent en main.
HTTP Archive, Web Almanac 2025, chapitre Performance
La raison est structurelle. L'INP dépend de la façon dont votre JavaScript est architecturé. Un site chargé de scripts lourds, de tags marketing et de widgets tiers accumule des tâches longues qui monopolisent le fil d'exécution principal du navigateur. Pendant ce temps, la page ne peut pas répondre.
Comment reprendre la main sur l'INP
La logique change par rapport au LCP. Ici, il faut découper les tâches longues en morceaux plus courts, différer le travail non critique, et rendre la main au navigateur pendant les interactions. Réduire la complexité du DOM aide aussi.
Sur beaucoup de sites en croissance, le vrai problème n'est pas le contenu. C'est l'empilement de scripts installés au fil des ans, chacun ajoutant sa couche de latence. Un audit d'INP commence toujours par une question simple : de quels scripts peut-on réellement se passer.
Trop de scripts, une page qui rame ?
L'audit identifie ce qui pèse vraiment sur votre INP et par quoi commencer.
CLS : arrêter de faire sauter la page
Même page, même image, deux comportements
La seule différence : l'espace de l'image est-il réservé avant son arrivée ?
Sans dimensions déclarées
Le texte saute, le tap tombe à côté. Le bouton a glissé sous le doigt.
Espace réservé à l'avance
Rien ne bouge. Le tap tombe là où le visiteur visait.
62 %
des pages mobiles ont au moins une image sans dimensions déclarées.HTTP Archive, Web Almanac 2025
Le CLS mesure les décalages visuels inattendus. Un bouton qui se déplace au moment où vous alliez cliquer. Une image qui pousse le texte vers le bas en se chargeant. Un bandeau cookies qui repousse tout le contenu.
Ces décalages ont une cause commune. Le navigateur ne connaît pas la taille finale d'un élément avant de l'afficher. Il réorganise donc la page en cours de route. La solution tient en un mot : réserver l'espace à l'avance.
Les corrections de stabilité
Chaque image, vidéo, iframe et emplacement publicitaire doit avoir ses dimensions déclarées, largeur et hauteur explicites. Les polices web doivent utiliser font-display: swap pour éviter le saut de texte au chargement. Les bandeaux de consentement doivent se superposer au contenu, pas le repousser vers le bas.
Le problème reste massif. D'après HTTP Archive (Web Almanac 2025), 62 % des pages mobiles ont au moins une image sans dimensions déclarées. La correction la plus simple du CLS reste donc la moins appliquée.
HTTP Archive, Web Almanac 2025, chapitre Performance
Le bandeau cookies qui décale le contenu est l'une des sources de CLS les plus fréquentes. Une position fixe ou un overlay règle le problème en quelques lignes de code.
Données terrain contre données labo : le piège à éviter
Deux mesures, une seule qui compte pour Google
Le même site peut réussir l'une et échouer l'autre.
| Données laboLighthouse, diagnostic PageSpeed | Données terrainCrUX, vos vrais visiteurs | |
|---|---|---|
| Origine | Un test simulé, dans des conditions standardisées | Les visites réelles, sur vrais appareils et vrais réseaux |
| Mise à jour | À chaque test lancé | Fenêtre glissante de 28 jours |
| Où la voir | Section « Diagnostic de performances » | Search Console, « Données de champ » de PageSpeed |
| Pour Google | Ne compte pas, sert au débogage | C'est elle qui classe |
Optimisez avec le labo, jugez avec le terrain.Le labo dit pourquoi une page est lente. Le terrain dit si Google la considère lente.
Voici le point que la plupart des articles survolent, et qui explique pourquoi tant de dirigeants sont perdus. Il existe deux façons de mesurer les Core Web Vitals, et elles ne racontent pas la même histoire.
Les données terrain, celles qui comptent pour Google
Google vous note sur les données CrUX, le Chrome User Experience Report. Ce sont les mesures collectées auprès de vos vrais visiteurs, dans leurs vraies conditions : connexions mobiles moyennes, appareils d'entrée de gamme, réseaux saturés. C'est cette donnée, et elle seule, qui influence votre classement.
Vous la trouvez dans deux outils. La Google Search Console, rubrique Signaux web essentiels, qui regroupe vos URL par statut. Et PageSpeed Insights, dans sa section « Données de champ ».
Les données labo, utiles mais trompeuses
Lighthouse et la section « Diagnostic de performances » de PageSpeed simulent un chargement dans des conditions standardisées. Utile pour déboguer, dangereux comme référence. On voit souvent ce schéma : un score labo quasi parfait, et une page qui échoue pourtant en données CrUX. L'écart vient de l'audience mobile réelle, plus lente que le test simulé.
La règle : optimisez avec les données labo, jugez avec les données terrain. Confondre les deux fait perdre des mois.
Quel poids réel dans le classement Google
Le contenu classe, la vitesse départage
Une page de résultats, vue de l'intérieur.
Contenu de qualité comparable
Ce qui décide d'abord
La pertinence du contenu fixe l'ordre général.
Ce que font les Core Web Vitals
Ils tranchent entre deux pages qui se valent sur le fond.
Facteur de classement confirmé par Google depuis juin 2021, avec un poids volontairement mesuré.
Soyons honnêtes, c'est là que le marketing exagère souvent. Les Core Web Vitals sont un facteur de classement confirmé depuis juin 2021. Mais leur poids reste mesuré.
Google le dit lui-même : la pertinence du contenu domine. Les Core Web Vitals agissent comme un départage entre deux pages de qualité comparable. Sur une requête concurrentielle où plusieurs pages se valent sur le fond, la plus rapide et la plus stable passe devant.
La formule juste : un bon score ne fait pas remonter seul une page. Mais un mauvais score plafonne une bonne page. Vous ne gagnez pas la course grâce à la vitesse, vous vous interdisez de la perdre à cause d'elle.
C'est pour ça qu'on ne traite jamais les Core Web Vitals isolément. Ils font partie d'un chantier plus large. Sur le dossier la50cc.fr, le travail structurel a produit 4 210 clics organiques sur trois mois, mesurés dans les captures Search Console publiées au 30 août 2026. La performance technique n'était qu'un maillon, mais un maillon sans lequel le reste ne tenait pas.
Ce que la vitesse change pour votre chiffre d'affaires
Une cause, trois effets mesurés
Test A/B de Vodafone Italie. Les barres sont à la même échelle, en pourcentage de variation.
LCP amélioré de 31 %
+15 % visiteurs devenus prospects
+11 % visites du panier
+8 % de ventes
Chaque barre est proportionnelle à sa valeur, sur une échelle commune aux quatre.
Le protocole
Version A
optimisée
Version B
d'origine
Même design, même contenu, même offre. Seule la performance change. C'est ce qui rend le résultat solide : pas une corrélation, un test contrôlé.
Source, Google web.dev, étude de cas Vodafone
Au-delà du SEO, l'impact business est direct et documenté. C'est même l'argument le plus fort pour prioriser ce chantier.
L'exemple de référence vient de Vodafone Italie. Le test compare deux pages identiques, sauf sur la performance. La version au LCP amélioré de 31 % a généré 8 % de ventes en plus. Elle a aussi amélioré de 15 % la part des visiteurs devenus prospects, et de 11 % celle des visites du panier. Pas une corrélation, un test A/B contrôlé, documenté par Google sur web.dev.
Google web.dev, étude de cas Vodafone
La logique est simple. Une page rapide et stable retient le visiteur. Une page lente le fait fuir avant même qu'il ait lu votre offre. Chaque décalage visuel, chaque seconde d'attente, chaque clic sans réponse est une fuite de conversion.
Pour un site de services ou de génération de leads, l'équation est encore plus nette. Vous ne captez pas des milliers de visiteurs par jour, chaque visite compte double. Une page qui répond mal transforme un prospect chaud en visiteur perdu.
Trois erreurs qui plombent les Core Web Vitals
Le réflexe
« PageSpeed affiche 92, mon site est rapide. »
En réalitéCe score est une simulation. Google ne regarde que la donnée terrain.
Le zèle
« Il faut viser 100 partout. »
En réalitéLe vert suffit. Au-delà du seuil, l'effort ne rapporte plus rien en SEO.
Le raccourci
« Mon LCP est bon, je suis tranquille. »
En réalitéLes trois métriques doivent passer ensemble. Une seule au rouge suffit à échouer.
Sur les dossiers qu'on reprend, les mêmes pièges reviennent. Les connaître évite de perdre du temps.
Erreur 1 : juger son site sur le score labo
Le réflexe le plus courant. On lance PageSpeed, on voit 92, on se rassure. Sauf que ce chiffre est une simulation. Le seul qui compte pour Google est la donnée terrain CrUX. Un dirigeant en premier appel nous cite presque toujours son score labo, jamais son statut Search Console. C'est le premier redressement à faire.
Erreur 2 : viser 100 partout
Chercher le score parfait est une perte d'énergie. Google demande le vert, pas la perfection. Un LCP à 2,3 secondes passe aussi bien qu'un LCP à 1,1 seconde. Au-delà du seuil, l'effort supplémentaire ne rapporte plus rien en SEO. Mieux vaut réinvestir ce temps dans le contenu.
Erreur 3 : optimiser une seule métrique
On voit souvent ce schéma sur les sites e-commerce : un LCP impeccable, un CLS catastrophique à cause des slots publicitaires. Or Google exige les trois au vert simultanément. Optimiser le LCP en ignorant l'INP ou le CLS, c'est faire la moitié du travail pour zéro résultat au classement.
Par où commencer concrètement
Trois marches, du plus simple au plus technique
Chaque marche indique les métriques qu'elle fait bouger.
1
Diagnostiquer
Search Console d'abord, pour savoir quelle métrique coince et sur quel gabarit.
2
Images et dimensions
Compresser, redimensionner, déclarer largeur et hauteur.
3
Alléger le JavaScript
Supprimer les tags inutiles, différer le non-critique. Le plus rentable sur l'INP.
Trois leviers actionnables tout de suite, du plus simple au plus technique.
Levier 1 : diagnostiquer avant de toucher au code
Ouvrez la Search Console, rubrique Signaux web essentiels. Repérez vos groupes de pages en rouge et la métrique fautive. Croisez avec PageSpeed sur une URL type. Vous savez alors quelle métrique traiter et sur quel gabarit de page. On ne corrige pas à l'aveugle.
Levier 2 : traiter les images et les dimensions
Deux gestes couvrent une large part des problèmes de LCP et de CLS. Compresser et redimensionner les images, en format moderne. Déclarer largeur et hauteur sur chaque média. Sur un site WordPress, un plugin de cache et d'optimisation bien réglé fait déjà une différence visible.
Le cache ne fait pas tout. Il accélère la réponse du serveur, mais une image de plusieurs mégaoctets reste lourde, cache ou pas. Les deux gestes se complètent.
Levier 3 : alléger le JavaScript
Le plus technique, mais souvent le plus rentable sur l'INP. Faire l'inventaire des scripts tiers, supprimer les tags inutiles, différer ce qui n'est pas critique au premier affichage. C'est là qu'un regard extérieur aide, parce qu'on hésite à toucher ce qu'on ne comprend pas.
Ce travail s'inscrit rarement seul. Il fait partie d'un audit technique complet, où la performance croise l'indexation, la structure et le contenu. C'est cette cohérence qui produit des résultats durables. Sur le dossier festival-art-de-rien.fr, l'accompagnement dans la durée a généré 7 690 clics organiques sur seize mois, mesurés dans Google Search Console au 24 août 2026.
Vos questions les plus fréquentes sur les Core Web Vitals
Combien de temps pour améliorer ses Core Web Vitals ?
Les Core Web Vitals suffisent-ils à bien se positionner ?
Faut-il un développeur pour les optimiser ?
PageSpeed affiche 95 mais Google me pénalise, pourquoi ?
Le CLS concerne-t-il aussi les sites vitrines ?
Passer au vert, sans y laisser vos semaines
La fiche d'une page qui passe
Les trois en même temps, pour 75 % des visites réelles, sur 28 jours.
Page conformedonnées terrain
Ce que vous sécurisez : plus aucun départage perdu à cause de la vitesse, et des visites qui ne fuient plus.
Les Core Web Vitals ne sont pas une case technique à cocher. Ce sont trois mesures du confort réel que vous offrez à vos visiteurs, et Google les lit comme un signal de sérieux.
Retenez l'essentiel. Trois métriques, trois seuils, le vert obligatoire sur les trois. La donnée terrain qui compte, pas le score labo qui rassure. Et un impact double, sur le classement comme sur la conversion.
Le piège serait d'y passer des semaines seul, à corriger à l'aveugle une métrique après l'autre. La bonne approche part d'un diagnostic clair, hiérarchise les corrections par impact, et branche la performance sur le reste de votre stratégie. Si vous voulez avancer vite et bien, un devis SEO est le point de départ le plus simple.
Un plan d'action précis, pas une liste de bonnes intentions
On regarde vos vrais scores terrain ensemble, on classe les corrections par impact, et on branche la performance sur le reste de votre stratégie SEO.
Sans engagement, réponse sous 24 h.
Sources
- Google web.dev , définition et seuils officiels des Core Web Vitals
- Google web.dev , Largest Contentful Paint (LCP), mesure et optimisation
- Google web.dev , Interaction to Next Paint (INP), la métrique de réactivité
- Google web.dev , Cumulative Layout Shift (CLS), stabilité visuelle
- HTTP Archive , Web Almanac, chapitre Performance, taux de réussite par métrique
- Google web.dev , Fetch Priority API, test Google Flights
- Google web.dev , étude de cas Vodafone, 31 % de LCP pour 8 % de ventes
- Google Search Central , introduction de l'INP en remplacement du FID
- Google Search Central , documentation Page Experience et classement
- Google Search Console , rapport Signaux web essentiels
- Google PageSpeed Insights , outil de mesure terrain et laboratoire
- Google web.dev , impact business des Core Web Vitals
