Core Web Vitals : seuils, mesure et leviers

Que mesurent les Core Web Vitals ?

La Search Console les appelle « Signaux Web essentiels ». Ce sont les Web Vitals que Google applique à toutes les pages. Chacun couvre une facette de l’expérience : chargement, réactivité, stabilité visuelle (web.dev, Web Vitals, 31/10/2024).

Le seuil se lit au 75e centile des chargements de page, en séparant mobile et ordinateur (même source). Concrètement, trois visites sur quatre doivent se situer sous la limite pour que la métrique passe au vert. La documentation Search Central sur les Core Web Vitals (10/12/2025) reprend ces cibles pour la recherche Google.

Deux autres indicateurs apparaissent souvent à côté. Le FCP mesure le premier affichage (bon sous 1,8 s). Le TTFB mesure le temps de réponse du serveur (bon sous 0,8 s). Ce sont des métriques de diagnostic. Elles aident à comprendre un mauvais LCP, mais elles ne font pas partie du trio officiel.

Les Core Web Vitals sont-ils un facteur de classement ?

Oui, mais un facteur parmi d’autres. Google l’écrit dans sa page sur l’expérience de page : « Core Web Vitals are used by our ranking systems » (Google Search Central, 22/09/2026). La même page précise que de bons résultats dans la Search Console ne garantissent pas la première place.

Google ajoute que la recherche montre toujours le contenu le plus pertinent, même si l’expérience de page est médiocre. En pratique, ces signaux départagent des pages de pertinence proche. Ils ne rattrapent pas un contenu qui répond mal à la requête.

L’argument le plus solide reste souvent l’expérience utilisateur. Une page qui se décale sous le doigt ou qui fige au clic fait perdre des visiteurs, quel que soit son classement. Mesurez ce lien avec la conversion sur vos propres données, dans une démarche d’optimisation de la conversion. Les moyennes de marché ne le diront pas.

Comment mesurer les Core Web Vitals : terrain ou laboratoire ?

Deux familles d’outils coexistent, et elles ne répondent pas à la même question.

Les données de terrain font foi pour le classement. La note Lighthouse sur 100 sert au diagnostic. Une page peut afficher 95 en laboratoire et échouer sur le terrain, ou l’inverse (web.dev, section sur les outils de mesure).

Que signifie « Évaluation des Core Web Vitals : échec » ?

PageSpeed Insights affiche ce message quand une des trois métriques au moins n’est pas bonne. Le calcul se fait au 75e centile, sur les données de terrain. Le verdict porte sur l’URL si elle a assez de trafic, sinon sur l’origine (le site entier). Il ne dépend pas de la note Lighthouse affichée plus bas.

Lire le rapport de la Search Console

Le rapport Signaux Web essentiels regroupe les URL qui se ressemblent. Il leur attribue un statut commun : bon, à améliorer ou médiocre. Il sert à repérer un gabarit défaillant, pas une page isolée. Pour prendre en main les autres rapports, voir notre guide Google Search Console.

Comment améliorer le LCP, l’INP et le CLS ?

LCP : afficher plus vite l’élément principal

Google découpe le LCP en quatre temps (web.dev, LCP, 04/09/2025). Viennent la réponse du serveur, le délai avant le chargement de la ressource, la durée de ce chargement, puis le délai de rendu. Mesurez d’abord lequel domine, puis traitez-le :

• serveur lent : cache de page, CDN, requêtes base de données allégées ;
• image principale découverte tard : la placer dans le HTML initial, la précharger, ne jamais la charger en différé ;
• image lourde : format WebP ou AVIF, dimensions égales à l’affichage ;
• rendu bloqué : CSS critique en ligne, polices et scripts qui ne retardent pas l’affichage.

INP : répondre vite à chaque interaction

Un mauvais INP vient presque toujours du JavaScript qui occupe le fil principal du navigateur (web.dev, INP, 02/09/2025). Découpez les tâches longues et retirez les scripts inutiles. Différez les scripts tiers (chat, tags, widgets) et limitez la taille du DOM. Sur un site construit avec un framework, le sujet rejoint celui du SEO JavaScript.

CLS : stabiliser la mise en page

Les décalages viennent d’éléments qui arrivent sans place réservée (web.dev, CLS). Indiquez largeur et hauteur sur les images et les vidéos. Réservez l’espace des encarts publicitaires et des contenus intégrés. N’insérez pas de bannière au-dessus d’un contenu déjà affiché, et choisissez des polices de secours aux dimensions proches.

Par où commencer sur un site existant ?

La méthode suivie en audit tient en cinq étapes. Elle évite de corriger au hasard la page d’accueil pendant que les fiches produits échouent.

1. Relever le terrain : rapport Signaux Web essentiels de la Search Console, mobile d’abord, puis ordinateur.
2. Grouper par gabarit : accueil, catégorie, fiche, article. Un défaut de gabarit touche des centaines d’URL à la fois.
3. Diagnostiquer en laboratoire : une URL représentative par gabarit dans PageSpeed Insights, pour identifier la ressource ou le script en cause.
4. Traiter dans l’ordre de rentabilité : images, cache navigateur, minification CSS et JS, CDN, temps serveur, chargement différé sous la ligne de flottaison.
5. Valider sur 28 jours : le terrain met environ un mois à refléter une correction. Lancer la validation dans la Search Console une fois le correctif en ligne.

Ces métriques ne sont qu’un bloc d’un audit SEO technique. Si Google n’explore pas ou n’indexe pas vos pages, leur vitesse ne sert à rien. Le temps de réponse du serveur pèse aussi sur l’exploration. Sur les grands sites, il entre dans le budget de crawl.

Pour situer ce sujet parmi les autres chantiers d’exploration, d’indexation et de performance, voir le guide du SEO technique.