Les Core Web Vitals expliqués simplement

Derrière le nom un peu technique de « Core Web Vitals » se cachent trois indicateurs que Google utilise pour juger l'expérience de vos visiteurs. Les comprendre en profondeur, c'est savoir non seulement si votre site est à la hauteur, mais surtout quoi corriger en priorité. Ce guide détaille ce que mesure chaque métrique, son seuil officiel, ses causes de dégradation et son correctif.

Que sont les Core Web Vitals ?

Ce sont trois mesures de la qualité de l'expérience de chargement, de réactivité et de stabilité d'une page. Google les considère comme des signaux de classement, intégrés à l'ensemble plus large des « signaux d'expérience de page ». Chacune isole une dimension distincte du ressenti utilisateur : la vitesse d'affichage (LCP), la réactivité aux interactions (INP) et la stabilité visuelle (CLS). Une page validée doit atteindre le seuil « bon » sur les trois à la fois, mesurés au 75e centile des visites réelles (autrement dit, l'expérience doit être bonne pour au moins trois visiteurs sur quatre).

LCP : la vitesse d'affichage du contenu principal

Largest Contentful Paint mesure le temps nécessaire pour afficher le plus gros élément visible dans la fenêtre au chargement : le plus souvent une image de bannière, une vidéo poster ou un bloc de texte principal. En clair : combien de temps s'écoule avant que le visiteur voie vraiment le contenu qui compte.

• 🟢 Bon : de 0 à 2,5 secondes
• 🟠 À améliorer : de 2,5 à 4 secondes
• 🔴 Médiocre : au-delà de 4 secondes

Causes fréquentes de dégradation. Un serveur lent à répondre (temps de réponse initial, le TTFB, élevé), une image LCP trop lourde ou non dimensionnée, des ressources qui bloquent le rendu (feuilles de style et scripts chargés avant l'affichage), ou une police web qui retarde l'apparition du texte.

Comment corriger. Compressez et servez l'image principale dans un format moderne, en la dimensionnant à sa taille d'affichage réelle. Préchargez la ressource LCP pour signaler sa priorité au navigateur. Réduisez le TTFB via la mise en cache ou la génération statique des pages. Enfin, différez ou allégez le CSS et le JavaScript qui bloquent le premier rendu. La documentation officielle détaille la démarche dans le guide Optimize LCP.

INP : la réactivité aux interactions

Interaction to Next Paint mesure le délai entre une action de l'utilisateur (clic, appui, saisie au clavier) et le moment où le navigateur peut afficher la réponse visuelle correspondante. INP observe l'ensemble des interactions d'une visite et retient la plus lente : la question posée est « quand je clique, l'interface répond-elle au quart de tour, ou marque-t-elle un temps mort ? ». Depuis mars 2024, INP a remplacé l'ancien FID (First Input Delay) comme Core Web Vital officiel, avec une exigence plus stricte.

• 🟢 Bon : de 0 à 200 millisecondes
• 🟠 À améliorer : de 200 à 500 ms
• 🔴 Médiocre : au-delà de 500 ms

Causes fréquentes de dégradation. Un fil d'exécution principal monopolisé par de longues tâches JavaScript, des scripts tiers lourds (widgets de chat, traqueurs, tests A/B), un travail de rendu excessif déclenché à chaque interaction, ou un DOM très volumineux qui alourdit chaque mise à jour de l'affichage.

Comment corriger. Découpez les longues tâches JavaScript en unités plus courtes pour laisser le navigateur respirer entre deux interactions. Reportez le travail non essentiel après le rendu, supprimez ou différez les scripts tiers superflus, et allégez le poids global de code exécuté au chargement. Le guide officiel Optimize INP décrit ces techniques en détail.

CLS : la stabilité visuelle

Cumulative Layout Shift mesure les décalages inattendus de la mise en page pendant le chargement. Vous connaissez cette situation agaçante : vous allez cliquer sur un bouton, une image ou une bannière se charge au-dessus, tout se décale et vous cliquez au mauvais endroit. Le CLS quantifie ce phénomène, non pas en secondes mais en score, calculé à partir de l'ampleur des éléments déplacés et de la distance de leur déplacement.

• 🟢 Bon : de 0 à 0,1
• 🟠 À améliorer : de 0,1 à 0,25
• 🔴 Médiocre : au-delà de 0,25

Causes fréquentes de dégradation. Des images ou vidéos sans dimensions déclarées, des publicités ou encarts insérés dynamiquement sans espace réservé, des polices web qui provoquent un changement de rendu du texte (le FOUT), ou des contenus injectés en haut de page après le premier affichage.

Comment corriger. Réservez systématiquement l'espace des médias en déclarant leurs attributs de largeur et hauteur (ou via des rapports d'aspect en CSS). Prévoyez un emplacement fixe pour les bannières et modules chargés après coup. Chargez les polices avec une stratégie qui évite le saut de texte. La règle générale : tout élément dont l'arrivée est différée doit avoir sa place réservée d'avance.

Un tableau de synthèse

Métrique	Ce qu'elle mesure	Seuil « bon »	Cause fréquente	Correctif principal
LCP	Vitesse d'affichage du contenu principal	moins de 2,5 s	Image lourde, serveur lent	Compresser l'image, précharger, mettre en cache
INP	Réactivité aux interactions	moins de 200 ms	Excès de JavaScript	Découper les tâches, différer les scripts tiers
CLS	Stabilité visuelle de la mise en page	moins de 0,1	Éléments sans dimensions	Réserver l'espace des médias et bannières

💡 Traitez les métriques dans l'ordre du ressenti. Un visiteur perçoit d'abord la vitesse d'affichage (LCP), puis la stabilité au moment où il agit (CLS), puis la réactivité de ses interactions (INP). En pratique, LCP et CLS se corrigent souvent avec les mêmes leviers (images bien gérées, rendu non bloqué), tandis qu'INP relève d'un travail spécifique sur le JavaScript. Commencer par les images règle fréquemment deux problèmes d'un coup.

Données de laboratoire ou données terrain ?

C'est la distinction la plus importante à saisir, car elle explique pourquoi deux outils affichent parfois des scores différents pour la même page.

Les données de laboratoire proviennent d'un test unique, exécuté dans un environnement contrôlé (un appareil et une connexion simulés). Elles sont reproductibles et parfaites pour diagnostiquer et vérifier un correctif immédiatement. À noter : INP ne se mesure pas en laboratoire, faute d'interactions réelles ; on y observe un indicateur de substitution, le TBT (Total Blocking Time).

Les données terrain sont collectées auprès de vos vrais visiteurs, sur leurs appareils et leurs connexions, et agrégées dans le rapport CrUX (Chrome User Experience Report). Ce sont elles, et elles seules, qui déterminent si votre page est validée aux yeux de Google. Un excellent score de laboratoire ne garantit rien si vos utilisateurs réels, sur mobile et connexion moyenne, vivent une autre expérience.

⚠️ Ne vous fiez pas au seul score de laboratoire. Optimiser jusqu'à obtenir un « 100 » sur un test ponctuel donne une fausse assurance : c'est le 75e centile des visites réelles qui compte pour le classement. Suivez toujours les données terrain sur la durée, et testez une page de chaque gabarit (accueil, catégorie, article, contact) plutôt qu'une seule, car une lenteur de gabarit se répercute sur des dizaines de pages.

Les outils pour mesurer et suivre

Trois outils officiels et gratuits couvrent l'essentiel des besoins :

• PageSpeed Insights : analyse une URL, croise données de laboratoire et données terrain, et liste des recommandations concrètes hiérarchisées. C'est l'outil de diagnostic page par page.
• Le rapport « Signaux web essentiels » de la Google Search Console : offre la vue d'ensemble à l'échelle du site, regroupe les URL par état (bon, à améliorer, médiocre) et par type de problème. C'est le tableau de bord de suivi.
• CrUX : la source de données terrain sous-jacente, consultable directement pour des analyses plus poussées.

Pour un diagnostic durant le développement, l'onglet Lighthouse intégré au navigateur Chrome complète ces outils en local.

Par où commencer

Face à trois métriques et une longue liste de recommandations, la paralysie guette. Voici un ordre de marche pragmatique :

1. Mesurez d'abord le terrain. Ouvrez le rapport de la Search Console et identifiez quel indicateur est dans le rouge, et sur quels gabarits de pages. Inutile d'optimiser ce qui est déjà bon.
2. Diagnostiquez la page représentative. Passez le gabarit fautif dans PageSpeed Insights et lisez les recommandations dans l'ordre où elles apparaissent : elles sont classées par gain potentiel.
3. Traitez les images en premier. Dans la majorité des cas, elles pèsent sur le LCP et parfois sur le CLS. C'est le levier au meilleur rapport effort/gain.
4. Attaquez ensuite le JavaScript si l'INP est en cause : réduisez, différez, supprimez le superflu.
5. Vérifiez en laboratoire, confirmez sur le terrain. Le correctif se voit tout de suite dans PageSpeed Insights ; attendez quelques semaines pour que la Search Console reflète l'amélioration réelle.

Au-delà de la note dans un outil, ces trois indicateurs décrivent une expérience concrète, celle qui retient un visiteur et le convertit. C'est là qu'un site développé sans WordPress part avec un avantage : une base technique légère atteint de bons Core Web Vitals par défaut, au lieu de courir après eux une fois le site en ligne. Pour un diagnostic précis de vos scores et un plan d'action chiffré, un audit SEO technique reste le point de départ, et il s'inscrit dans la logique plus large de pourquoi mener un audit avant d'investir.

En résumé

Les Core Web Vitals se résument à trois questions simples : la page s'affiche-t-elle vite (LCP, seuil de 2,5 secondes), répond-elle vite aux actions (INP, seuil de 200 ms), reste-t-elle stable au chargement (CLS, seuil de 0,1) ? Chacune a ses causes typiques et ses correctifs propres, mais le juge de paix reste le même : les données terrain de vos vrais visiteurs, pas un test isolé. Mesurez avec la Search Console, diagnostiquez avec PageSpeed Insights, traitez les images puis le JavaScript, et confirmez sur la durée. La vitesse étant aussi un levier de conversion à part entière, ces corrections rapportent bien au-delà du seul référencement.