Un site lent frustre les visiteurs et déçoit Google. Les Core Web Vitals sont la façon dont Google mesure cette qualité, en trois notes précises. Ce guide explique ce qu'elles sont, comment les lire, comment les améliorer, et pourquoi elles en disent long sur la qualité de la création de votre site.
Core Web Vitals, c'est quoi ?
Les Core Web Vitals (ou signaux web essentiels) sont un ensemble de trois métriques définies par Google pour mesurer l'expérience réelle d'un utilisateur sur une page. Elles évaluent trois choses : la vitesse de chargement, la réactivité aux interactions et la stabilité visuelle. Chacune a un seuil à ne pas dépasser pour être jugée bonne.
Leur intérêt : elles traduisent en chiffres une impression jusque-là floue, la sensation qu'un site est rapide et agréable, ou lent et agaçant. Google les mesure sur les vrais visiteurs, pas en laboratoire, ce qui en fait un reflet fidèle du ressenti.
Les trois métriques : LCP, INP et CLS
Chaque métrique répond à une question simple que se pose le visiteur.
- LCP (Largest Contentful Paint) : le contenu principal s'affiche-t-il vite ? Elle mesure le temps d'apparition du plus gros élément visible (image ou bloc de texte).
- INP (Interaction to Next Paint) : la page réagit-elle vite quand je clique ? Elle mesure le délai de réponse aux interactions. Elle a remplacé l'ancien FID en mars 2024.
- CLS (Cumulative Layout Shift) : la page bouge-t-elle sous mes yeux ? Elle mesure les décalages inattendus de mise en page pendant le chargement.
| Métrique | Ce qu'elle mesure | Bon | À améliorer | Mauvais |
|---|---|---|---|---|
| LCP | Vitesse d'affichage du contenu principal | <= 2,5 s | 2,5 à 4 s | > 4 s |
| INP | Réactivité aux interactions | <= 200 ms | 200 à 500 ms | > 500 ms |
| CLS | Stabilité visuelle de la page | <= 0,1 | 0,1 à 0,25 | > 0,25 |
Un détail important : Google évalue ces seuils au 75e centile de vos visites, séparément sur mobile et sur ordinateur, sur une fenêtre glissante de 28 jours. Autrement dit, il faut que l'expérience soit bonne pour au moins trois visiteurs sur quatre. Et les trois métriques doivent passer en même temps : une seule dans le rouge fait basculer toute la page.
En pratique, c'est presque toujours le mobile qui échoue, freiné par des processeurs plus lents et des connexions plus faibles. Or c'est justement l'expérience mobile que Google retient pour le classement.
Comment mesurer ses Core Web Vitals ?
Deux outils gratuits de Google suffisent, et il faut comprendre la différence entre leurs deux types de données.
- PageSpeed Insights : entrez une URL, obtenez les trois scores. Il affiche à la fois les données de terrain et de laboratoire.
- Search Console : le rapport Signaux web essentiels regroupe vos pages en bon, à améliorer et mauvais, sur tout le site. C'est le point de départ d'un audit SEO complet.
La distinction clé : les données de terrain (issues des vrais utilisateurs de Chrome, via le rapport CrUX) sont celles que Google utilise pour le classement. Les données de laboratoire (mesurées en conditions simulées par Lighthouse) servent à diagnostiquer et reproduire un problème, mais ne comptent pas directement pour le SEO.
Concrètement, dans PageSpeed Insights, l'encadré du haut affiche vos données de terrain (les vrais visiteurs) : c'est celui qui compte pour Google. Le score Lighthouse en dessous n'est qu'un diagnostic. Un site peut afficher un beau 95 en laboratoire et rester dans le rouge sur le terrain, ce qui explique bien des incompréhensions.
Comment améliorer ses Core Web Vitals ?
Chaque métrique a ses leviers. On traite d'abord celle qui est dans le rouge.
Améliorer le LCP
Le LCP échoue surtout à cause d'une image principale trop lourde, d'un serveur lent à répondre ou de scripts qui retardent l'affichage.
- Optimiser les images : formats modernes (WebP, AVIF), compression et dimensions déclarées ; précharger (preload) l'image principale. C'est souvent le frein numéro un.
- Accélérer le serveur : un bon hébergement, un CDN et la mise en cache réduisent le temps de réponse (TTFB).
- Lever les ressources bloquantes : différer le JavaScript non essentiel et intégrer le CSS critique en ligne pour afficher le contenu plus tôt.
Améliorer l'INP
L'INP se dégrade quand le fil principal du navigateur est occupé par du JavaScript au moment où l'utilisateur clique. Les extensions et scripts tiers en sont les grands responsables.
- Alléger le JavaScript : moins de code, découpé et chargé à la demande (code splitting). Auditer les scripts tiers (chat, tracking, tests A/B) qui bloquent le fil principal.
- Découper les tâches longues : fractionner les traitements lourds, voire les déporter dans un Web Worker, pour que la page réponde sans attendre.
Améliorer le CLS
Le CLS vient d'éléments qui s'insèrent ou changent de taille après coup : images sans dimensions, polices qui chargent tard, encarts injectés.
- Réserver la place : déclarer les dimensions des images, vidéos et encarts pour que rien ne pousse le contenu une fois affiché.
- Soigner les polices : les précharger et utiliser font-display: swap pour éviter le saut de texte au chargement.
Core Web Vitals et SEO : quel impact ?
Les Core Web Vitals sont un facteur de classement, au sein de ce que Google appelle l'expérience sur la page. Mais c'est un facteur secondaire : à contenu égal, de bons signaux peuvent départager deux pages, sans jamais compenser un contenu faible.
Le vrai gain est ailleurs, et double. Une page rapide retient mieux les visiteurs et convertit davantage ; et elle envoie à Google un signal de qualité. Optimiser ses Core Web Vitals, c'est donc autant pour l'utilisateur que pour le référencement.
Le vrai levier : la qualité du build
La plupart des sites se battent contre leurs Core Web Vitals après coup, à coups d'extensions d'optimisation. C'est traiter le symptôme. La cause tient à la façon dont le site est construit, et elle se lit métrique par métrique.
| Cause (site lourd) | Conséquence sur les Core Web Vitals | Ce qu'un build moderne change |
|---|---|---|
| Thème et empilement d'extensions | JavaScript bloquant, INP dégradé au clic | Peu ou pas de scripts au chargement |
| Pages assemblées à la volée à chaque visite | Serveur lent, LCP qui s'allonge | Pages pré-rendues, servies statiques et en cache |
| Modules qui injectent du contenu tardif | Décalages de mise en page, CLS en hausse | Mise en page fixée à la construction |
C'est pourquoi une base moderne et légère, comme un CMS headless couplé à un rendu statique, passe les Core Web Vitals presque par défaut. C'est le principe d'une création de site pensée pour la performance : la vitesse se conçoit, elle ne se rattrape pas.
Un exemple parlant : une même page passe souvent d'un LCP de 4 secondes sur un thème chargé de douze extensions à moins de 2 secondes une fois reconstruite en statique, sans rien changer au contenu. Le gain vient de l'architecture, pas d'un réglage.
Core Web Vitals et IA : la même exigence
Une page rapide et légère ne sert pas que l'humain et Google. Les robots des moteurs et des assistants IA parcourent des millions de pages, et la performance décide de leur coût de traitement. Le soin porté à la vitesse profite donc aussi à un site prêt pour les agents IA.
Le mécanisme est concret : une page de plusieurs mégaoctets, rendue par JavaScript côté navigateur, oblige chaque robot à exécuter ce rendu pour lire le contenu. Une page statique et légère se lit directement, plus vite et à moindre coût. Un code propre et léger sert ainsi le visiteur pressé, le robot de Google et l'agent IA d'un même geste ; les Core Web Vitals sont un bon indicateur de cette hygiène technique de fond.
En résumé
Les Core Web Vitals mesurent l'expérience réelle d'une page en trois notes : LCP pour la vitesse d'affichage, INP pour la réactivité, CLS pour la stabilité. On les lit dans PageSpeed Insights et Search Console, on les améliore métrique par métrique, et elles pèsent sur le SEO comme facteur secondaire. Mais leur meilleur allié reste un site bien construit dès le départ, rapide par conception plutôt que par rustines.
Vos Core Web Vitals sont dans le rouge et les extensions n'y changent rien ? Réservez un échange avec In Soo : on regarde d'où vient le poids et ce qu'un build propre changerait, sans engagement.
