Core Web Vitals : les seuils Google (LCP, INP, CLS) et comment les passer

Sommaire

• Les Core Web Vitals, c’est quoi ? Les trois métriques de Google
• Pourquoi Google utilise les Core Web Vitals dans son classement
• LCP : la vitesse d’affichage, la mesure la plus souvent échouée
• INP : la réactivité, la métrique qui a remplacé FID
• CLS : la stabilité visuelle, la mesure la plus simple à corriger
• Comment mesurer ses Core Web Vitals avec les outils Google
• FAQ

Quand un site est lent, la réponse se trouve presque toujours dans les mêmes trois chiffres. Google mesure la performance réelle de chaque page avec trois métriques, les Core Web Vitals : le temps d’affichage du contenu principal (LCP), la réactivité aux clics (INP) et la stabilité de la mise en page (CLS). Voici comment les lire, pourquoi elles comptent pour votre référencement et comment les passer.

Les Core Web Vitals, c’est quoi ? Les trois métriques de Google

Les Core Web Vitals sont un ensemble de métriques qui évaluent l’expérience utilisateur réelle en fonction des performances de chargement, de l’interactivité et de la stabilité visuelle de la page, explique la documentation officielle de Google Search Central. Concrètement, Google mesure ce que vivent vos vrais visiteurs, pas un test de laboratoire : la valeur retenue pour chaque métrique est le 75e percentile des visites, calculé séparément sur mobile et sur desktop.

Le tableau ci-dessous reprend les seuils officiels publiés dans l’aide de la Search Console.

À retenir : une page n’est considérée comme bonne que si elle passe les trois seuils au 75e percentile des visites. Passer le LCP mais échouer l’INP, c’est une page classée « amélioration nécessaire ».

Pourquoi Google utilise les Core Web Vitals dans son classement

Google a intégré l’expérience de page à ses systèmes de classement à partir de la mi-juin 2021, avec un déploiement progressif jusqu’à la fin du mois d’août, précise le blog Search Central. Les Core Web Vitals en sont le socle mesurable, aux côtés d’autres critères comme le HTTPS ou l’absence d’interstitiels intrusifs.

La documentation actuelle est claire : Google recommande d’atteindre de bons Core Web Vitals « pour réussir dans la recherche » et note que ces métriques s’alignent avec ce que recherchent ses systèmes de classement de base. Cela ne veut pas dire que la vitesse prime sur le contenu. Un site rapide avec du contenu pauvre perdra toujours contre un site plus lent qui répond vraiment à la question posée. La performance est un signal de qualité parmi d’autres, comme le maillage interne ou la structure des pages.

Le constat de fond reste parlant : selon le Web Almanac 2025 de HTTP Archive, seuls 48 % des sites mobiles et 56 % des sites desktop passaient les trois seuils. La progression est réelle (32 % sur mobile en 2021, 44 % en 2024), mais plus de la moitié du web mobile reste sous les seuils.

LCP : la vitesse de chargement, la mesure la plus souvent échouée

Le LCP (Largest Contentful Paint) mesure la vitesse de chargement : le temps nécessaire pour afficher le plus grand élément visible de la page, généralement une image ou un bloc de texte. L’objectif fixé par Google : 2,5 secondes maximum, pour au moins 75 % des visites.

Les causes d’échec les plus fréquentes, détaillées par Google dans son guide d’optimisation du LCP :

• un temps de réponse serveur (TTFB) trop élevé : redirections, hébergement éloigné, cache non configuré ;
• des fichiers CSS et JavaScript qui bloquent le rendu du contenu ;
• une image principale difficile à découvrir dans le HTML initial, ou chargée en lazy-load. Google est explicite : ne jamais mettre l’image LCP en lazy-load, car elle part toujours en retard.

Les correctifs qui fonctionnent : améliorer le temps de réponse serveur (hébergement adapté, cache, CDN), réduire les scripts tiers sur le chemin critique, précharger l’image principale et différer le reste.

Un détail intéressant du Web Almanac 2025 : les pages d’accueil échouent nettement plus que les pages secondaires. Les pages intérieures passent les Core Web Vitals à 61 % sur desktop et 56 % sur mobile, soit 14 et 11 points de plus que les pages d’accueil, plus lourdes. Si votre page d’accueil est votre seule page en échec, vous savez où regarder en premier. C’est un symptôme classique qu’on retrouve aussi lors d’une refonte de site.

INP : la réactivité, la métrique qui a remplacé FID

Le INP (Interaction to Next Paint) mesure la réactivité de la page à toutes les interactions de l’utilisateur : clics, appuis, saisies clavier. L’objectif est de répondre en moins de 200 millisecondes.

Cette métrique a remplacé le FID (First Input Delay) en mars 2024, et ce n’est pas un simple changement de nom. Le FID ne mesurait que le délai avant traitement de la première interaction, ce qui laissait passer tous les ralentissements survenant ensuite. L’INP observe toutes les interactions pendant toute la visite et retient la plus longue, en ignorant une anomalie sur cinquante, puis applique le 75e percentile, détaille Google dans sa documentation sur l’INP.

Les causes d’un mauvais INP sont presque toujours les mêmes : un JavaScript trop lourd qui bloque le thread principal du navigateur (les long tasks), des scripts tiers qui s’exécutent au mauvais moment, ou des calculs de mise en page trop complexes. Les correctifs passent par la réduction du JavaScript (supprimer, différer, charger en async), le report des scripts non essentiels après l’interaction et, pour les cas lourds, le déchargement des traitements vers des web workers.

CLS : la stabilité visuelle, la mesure la plus simple à corriger

Le CLS (Cumulative Layout Shift) mesure les décalages inattendus de mise en page : un bouton qui bouge au moment où vous cliquez, une image qui pousse le texte pendant le chargement, une bannière qui s’insère au mauvais moment. Le score doit rester sous 0,1.

Google liste les causes principales dans son guide d’optimisation du CLS : les images sans dimensions déclarées, les publicités, encarts et iframes sans espace réservé, le contenu injecté dynamiquement et les polices web qui se chargent tard. Les correctifs sont mécaniques : déclarer la largeur et la hauteur sur chaque image, réserver l’espace des encarts publicitaires, charger les polices critiques tôt avec un bon système de repli, et viser l’éligibilité au bfcache pour que le retour arrière ne provoque aucun décalage.

C’est la métrique la plus facile à corriger du trio, car elle ne demande pas de refonte technique : une passe de développement sur les dimensions et les polices règle l’essentiel. Pour le reste de la qualité perçue, la vitesse ne fait pas tout : l’accessibilité pèse tout autant dans l’expérience réelle.

Comment mesurer ses Core Web Vitals avec les outils Google

Trois outils gratuits de Google suffisent pour suivre vos mesures :

• le rapport Core Web Vitals dans la Search Console : il classe vos URLs par groupe, mobile et desktop séparés, avec les statuts Bon, Amélioration nécessaire, Médiocre, à partir des données réelles collectées par Chrome ;
• PageSpeed Insights : il combine données de terrain et audit de laboratoire pour une seule page ;
• le jeu de données CrUX, accessible publiquement, si vous voulez comparer votre origine à la concurrence.

La distinction entre données de terrain et données de laboratoire est essentielle. Les données de terrain viennent de vrais utilisateurs Chrome (le dataset CrUX) : c’est ce que Google regarde pour le classement. Les données de laboratoire simulent un chargement sur une machine de test : utiles pour diagnostiquer, elles ne reflètent pas vos visiteurs. Détail technique : l’INP ne se mesure pas en laboratoire, les outils utilisent un proxy, le Total Blocking Time, en attendant.

Concrètement : ouvrez le rapport Core Web Vitals de la Search Console, regardez quelles URLs sont en échec sur mobile, puis lancez PageSpeed Insights sur la page d’accueil pour voir le diagnostic détaillé.

FAQ

Sources et références

• Google Search Central : comprendre les métriques Core Web Vitals et les résultats de recherche Google
• Google web.dev : Web Vitals
• Google web.dev : Optimize INP
• Google web.dev : Optimize Largest Contentful Paint
• Google web.dev : Optimize Cumulative Layout Shift
• Aide Search Console : rapport Core Web Vitals
• HTTP Archive : Web Almanac 2025, chapitre Performance
• Abondance : Core Web Vitals, qu’est-ce que c’est ?