Core Web Vitals : définition, seuils et optimisation

Les Core Web Vitals mesurent la vitesse d'affichage, la réactivité et la stabilité visuelle de vos pages auprès de vrais visiteurs. Seuils, mesure, poids réel dans le classement Google et corrections efficaces, y compris sur WordPress.

Les Core Web Vitals sont trois indicateurs définis par Google pour mesurer l’expérience réelle des visiteurs sur une page : le LCP (vitesse d’affichage du contenu principal), l’INP (réactivité aux clics et à la saisie) et le CLS (stabilité visuelle). Une page est jugée bonne si, sur 75 % des visites, le LCP reste sous 2,5 secondes, l’INP sous 200 millisecondes et le CLS sous 0,1. Google les utilise dans ses systèmes de classement, mais ils ne remplacent jamais un contenu pertinent.

On explique ce que mesure chaque indicateur, les seuils à viser, leur poids réel dans le référencement, les outils pour les mesurer gratuitement et les corrections qui font vraiment bouger les chiffres, y compris sur WordPress.

Que sont les Core Web Vitals ?
Quels sont les seuils à atteindre ?
Les Core Web Vitals influencent-ils le classement Google ?
Comment mesurer vos Core Web Vitals ?
Comment améliorer chaque indicateur ?
Et sur un site WordPress ?
Quelles erreurs éviter ?
Questions fréquentes
Sources

Que sont les Core Web Vitals ?

Les Core Web Vitals (ou « signaux Web essentiels ») font partie du programme Web Vitals de Google, lancé pour donner aux propriétaires de sites des repères simples sur la qualité de l’expérience utilisateur. Ils répondent à trois questions que se pose, sans le formuler, chaque visiteur :

La page s’affiche-t-elle vite ? C’est le rôle du Largest Contentful Paint (LCP).
La page réagit-elle quand j’agis ? C’est le rôle de l’Interaction to Next Paint (INP).
La page reste-t-elle stable pendant que je lis ? C’est le rôle du Cumulative Layout Shift (CLS).

Leur particularité : ils se mesurent d’abord sur de vrais visiteurs (on parle de données de terrain), et non uniquement en laboratoire. C’est ce qui les distingue d’un simple score de performance calculé par un outil.

Largest Contentful Paint (LCP) : le chargement

Le LCP mesure le temps nécessaire pour afficher le plus grand élément visible dans la fenêtre au chargement : souvent une image de bannière, une vidéo en couverture ou un gros bloc de texte. C’est le moment où le visiteur a le sentiment que « la page est là ». Nous avons consacré un article complet à cet indicateur : comprendre et optimiser le Largest Contentful Paint.

Interaction to Next Paint (INP) : la réactivité

L’INP mesure le délai entre une action de l’utilisateur (clic de souris, appui sur un écran tactile, frappe au clavier) et le moment où la page affiche une réponse visible. Le survol, le défilement et le zoom ne sont pas pris en compte. L’indicateur observe toutes les interactions de la visite et retient l’une des plus lentes (il ignore une valeur extrême toutes les 50 interactions pour écarter les accidents).

L’INP a remplacé le First Input Delay (FID) le 12 mars 2024. Le FID ne mesurait que le délai avant le traitement de la toute première interaction, ce qui laissait passer beaucoup de lenteurs. Si vous lisez encore « FID » dans un tableau de bord ou un article, l’information date d’avant 2024.

Cumulative Layout Shift (CLS) : la stabilité visuelle

Vous avez déjà voulu cliquer sur un bouton, et une bannière chargée au dernier moment l’a poussé vers le bas, si bien que vous avez cliqué sur autre chose ? C’est exactement ce que mesure le CLS : les décalages de mise en page inattendus. Contrairement aux deux autres, ce n’est pas un temps mais un score sans unité. Google retient la plus grosse « rafale » de décalages survenue pendant la visite (des décalages espacés de moins d’une seconde, sur cinq secondes au maximum). Les mouvements qui suivent de moins de 500 millisecondes un clic ou une frappe de l’utilisateur ne comptent pas, puisqu’ils sont attendus.

Quels sont les seuils à atteindre ?

Google classe chaque indicateur en trois états. Pour qu’une page ou un groupe de pages soit jugé « bon », il faut que 75 % des visites (le 75e centile) passent sous le seuil, séparément sur mobile et sur ordinateur. Ce choix du 75e centile permet de refléter l’expérience de la majorité des visiteurs sans qu’une poignée de connexions très lentes fausse le résultat.

Indicateur	Bon	À améliorer	Médiocre
LCP (chargement)	2,5 s ou moins	entre 2,5 s et 4 s	plus de 4 s
INP (réactivité)	200 ms ou moins	entre 200 ms et 500 ms	plus de 500 ms
CLS (stabilité)	0,1 ou moins	entre 0,1 et 0,25	plus de 0,25

Ces seuils sont ceux publiés par Google sur web.dev en 2026. Une page doit être « bonne » sur les trois indicateurs pour réussir l’évaluation globale des Core Web Vitals.

Les Core Web Vitals influencent-ils le classement Google ?

Oui, mais modestement. Google l’écrit clairement dans sa documentation : « Les Core Web Vitals sont utilisées par nos systèmes de classement ». Il précise aussi qu’il n’existe pas un signal unique d’expérience de page, et qu’obtenir de bons résultats dans le rapport Search Console ou dans un outil tiers « ne garantit pas » que vos pages se classeront en tête. Surtout : Google cherche toujours à afficher le contenu le plus pertinent, même si son expérience de page est moyenne.

Un peu d’histoire pour remettre les choses à leur place. L’intégration de l’expérience de page dans le classement a été déployée progressivement à partir de mi-juin 2021, pour un effet complet fin août 2021. Cette mise à jour avait fait beaucoup de bruit, mais son impact est resté limité. Elle a aussi mis fin à une obligation : depuis 2021, le format AMP n’est plus nécessaire pour apparaître dans le carrousel « À la une » de Google, et aucun score minimal de Core Web Vitals n’est exigé pour y figurer (il faut respecter les règles de Google Actualités).

En pratique, les Core Web Vitals départagent surtout des pages de pertinence comparable. Leur vrai intérêt est ailleurs : sur vos visiteurs. En 2020, en analysant des millions d’affichages de pages, l’équipe Chrome a constaté que les utilisateurs sont 24 % moins susceptibles d’abandonner le chargement d’une page lorsque le site respecte les seuils. Une page lente ou instable coûte d’abord des contacts et des ventes, avant de coûter des positions. Nous détaillons ces conséquences dans l’impact d’un site internet lent sur votre entreprise.

Comment mesurer vos Core Web Vitals ?

Il existe deux familles de mesures, à ne pas confondre :

Les données de terrain : collectées auprès de vrais utilisateurs de Chrome et publiées dans le Chrome UX Report (CrUX). Ce sont elles que Google utilise pour évaluer vos pages.
Les données de laboratoire : un outil charge la page dans un environnement simulé. Elles servent à diagnostiquer et à tester une correction avant sa mise en ligne.

Le rapport Core Web Vitals de la Search Console

C’est le point de départ. Dans Google Search Console, le rapport « Core Web Vitals » classe vos URL en « Médiocre », « Amélioration nécessaire » ou « Bon », par indicateur (LCP, INP, CLS), par appareil (mobile, ordinateur) et par groupes de pages similaires. Il s’appuie uniquement sur des données de terrain. Son grand avantage : il vous dit où concentrer vos efforts, en commençant par les groupes de pages « médiocres » qui reçoivent le plus de visites.

Si votre site est récent ou peu visité, le rapport peut afficher « Aucune donnée disponible » : le CrUX ne contient pas assez de visites pour être représentatif. Il faut alors passer par les outils de laboratoire.

PageSpeed Insights, Lighthouse et les outils de Chrome

PageSpeed Insights (pagespeed.web.dev) : gratuit, il affiche pour une URL les données de terrain CrUX quand elles existent, puis un diagnostic de laboratoire Lighthouse avec des pistes de correction.
Lighthouse, intégré aux outils de développement de Chrome : il simule un chargement sans utilisateur, donc il ne peut pas mesurer l’INP. Il affiche à la place le Total Blocking Time (TBT), un indicateur de laboratoire qui sert d’approximation : améliorer le TBT améliore souvent l’INP réel.
Le panneau Performance de Chrome DevTools : il mesure les trois indicateurs pendant que vous naviguez réellement sur la page, ce qui permet de reproduire une interaction lente.

Gardez en tête qu’un score Lighthouse de 100 sur votre ordinateur, avec une bonne connexion, ne dit rien de l’expérience d’un visiteur sur un téléphone d’entrée de gamme en 4G. Ce sont les données de terrain qui comptent.

Comment améliorer chaque indicateur ?

Améliorer le LCP

Accélérer la réponse du serveur : un hébergement correctement dimensionné et une mise en cache des pages réduisent le temps avant le premier octet.
Faire découvrir l’image principale tôt : elle doit figurer dans le HTML (pas injectée en JavaScript ni cachée dans une image de fond CSS), avec l’attribut fetchpriority="high".
Ne jamais différer l’image principale : le chargement différé (loading="lazy") est utile pour les images plus bas dans la page, pas pour celle du haut.
Alléger les fichiers : images redimensionnées à la taille d’affichage, formats modernes (WebP, AVIF), polices limitées au strict nécessaire.
Supprimer ce qui bloque l’affichage : feuilles de style et scripts inutiles chargés dans l’en-tête.

Améliorer l’INP

Une interaction se décompose en trois temps : le délai avant que le navigateur commence à traiter l’action, le temps d’exécution du code qui y répond, puis le délai avant l’affichage de l’image suivante. Les causes les plus fréquentes sont les « tâches longues », c’est-à-dire du JavaScript qui occupe le processeur plus de 50 millisecondes d’affilée.

Faire l’inventaire des scripts tiers (chat, pixels publicitaires, widgets, outils d’A/B testing) et retirer ceux qui ne servent plus.
Découper les traitements lourds en petites tâches, pour que le navigateur puisse répondre entre deux.
Afficher un retour visuel immédiat (bouton enfoncé, indicateur de chargement) avant de lancer le traitement.
Limiter la taille de la page : un DOM de plusieurs milliers d’éléments ralentit chaque mise à jour de l’affichage.

Améliorer le CLS

Indiquer la largeur et la hauteur (attributs width et height) de chaque image et vidéo, pour que le navigateur réserve la place.
Réserver un emplacement de taille fixe aux publicités, vidéos intégrées et widgets tiers.
Ne pas insérer de bandeau au-dessus du contenu déjà affiché (bandeau cookies, promotion) : préférez une position qui ne pousse rien.
Soigner le chargement des polices web, dont la taille diffère souvent de la police de secours.

Et sur un site WordPress ?

WordPress fait une partie du travail tout seul : depuis la version 6.3 (2023), il ajoute automatiquement fetchpriority="high" à l’image qu’il estime être celle du LCP et évite de différer son chargement. Les problèmes viennent le plus souvent d’ailleurs :

Les extensions accumulées : chacune peut ajouter ses propres scripts et styles sur toutes les pages, même là où elle ne sert pas.
Les constructeurs de pages et thèmes « tout-en-un » : ils génèrent beaucoup de code et d’éléments imbriqués, ce qui pèse sur l’INP.
Les sliders en haut de page : ils retardent l’élément principal et provoquent souvent des décalages.
Un hébergement sous-dimensionné et l’absence de cache : le serveur met trop de temps à répondre, et tout le reste en pâtit.

Avant d’installer une énième extension d’optimisation, commencez par retirer ce qui est inutile. Un site entretenu régulièrement (mises à jour, ménage dans les extensions, cache et hébergement adaptés) garde de bons Core Web Vitals dans la durée : c’est l’objet de notre offre d’hébergement et maintenance WordPress, avec un budget mensuel qui dépend du niveau de suivi (voir nos tarifs indicatifs).

Quelles erreurs éviter ?

Courir après le score de 100 sur PageSpeed Insights : le score de laboratoire n’est pas ce que Google utilise. Visez le vert sur les données de terrain.
Tester uniquement la page d’accueil : ce sont souvent les fiches produits ou les articles de blog, plus nombreux, qui plombent le rapport.
Oublier le mobile : les seuils sont évalués séparément sur mobile et sur ordinateur, et le mobile est presque toujours le plus lent.
Sacrifier le contenu à la vitesse : une page ultra-rapide qui ne répond pas à la question du visiteur ne se classera pas mieux.
Corriger sans vérifier : après une correction, les données de terrain mettent plusieurs semaines à se mettre à jour. Validez d’abord en laboratoire, puis suivez l’évolution dans la Search Console.

Si le rapport de la Search Console affiche beaucoup de rouge et que vous ne savez pas par où commencer, un audit SEO technique (le budget dépend du site, voir nos tarifs indicatifs) permet de hiérarchiser les corrections selon leur effet sur vos pages les plus importantes.

Questions fréquentes

Le FID fait-il encore partie des Core Web Vitals ?

Non. Depuis le 12 mars 2024, l’INP a remplacé le FID. Le FID a été retiré de la Search Console le jour même, puis des autres outils de Google dans les mois qui ont suivi.

De bons Core Web Vitals suffisent-ils pour être premier sur Google ?

Non. Google indique qu’un bon rapport Core Web Vitals ne garantit pas un bon classement. La pertinence et la qualité du contenu restent déterminantes.

Pourquoi la Search Console n’affiche-t-elle aucune donnée pour mon site ?

Le rapport s’appuie sur le Chrome UX Report, qui a besoin d’un volume minimal de visites réelles. Un site récent ou peu fréquenté n’y figure pas encore. Utilisez PageSpeed Insights ou Lighthouse en attendant.

Pourquoi mon score PageSpeed change-t-il à chaque test ?

La partie laboratoire dépend des conditions du test (charge du serveur, réseau, scripts tiers). Des écarts de quelques points sont normaux. Les données de terrain, calculées sur de nombreuses visites, sont bien plus stables.

Combien de temps faut-il pour voir l’effet d’une correction ?

Le laboratoire montre l’effet immédiatement. Les données de terrain étant agrégées sur une période glissante de plusieurs semaines, comptez plusieurs semaines avant de voir le rapport de la Search Console évoluer.

Core Web Vitals : définition, seuils et comment les améliorer