Core Web Vitals

Ce que sont les Core Web Vitals

Les Core Web Vitals sont un ensemble de trois indicateurs définis par Google pour mesurer l'expérience réelle d'une page web : la vitesse d'affichage du contenu, sa stabilité pendant le chargement, et sa rapidité de réaction aux interactions. Ils forment un sous-ensemble de l'initiative plus large des Web Vitals, l'effort de Google pour transformer la notion floue d'expérience de page en chiffres qu'une équipe peut suivre et améliorer.

Les trois métriques sont le Largest Contentful Paint (LCP), le Cumulative Layout Shift (CLS) et l'Interaction to Next Paint (INP). Chacune cible une frustration distincte que peut ressentir un visiteur : attendre le contenu, voir la page sauter sous un doigt qui tape, ou cliquer sans obtenir de réponse. Ensemble, ils font partie des signaux d'expérience de page pris en compte par Google dans le classement de recherche, ce qui les place à la croisée de l'expérience utilisateur et du SEO.

Les trois métriques en détail

Chaque métrique a une cible claire qui sépare un bon score d'un mauvais.

• Le LCP (Largest Contentful Paint) mesure le temps avant l'affichage du plus gros élément visible, en général une image de couverture, une vignette de vidéo ou un grand bloc de texte. On vise moins de 2,5 secondes. Un LCP lent vient souvent d'images trop lourdes, de serveurs lents ou de ressources qui bloquent le rendu.
• Le CLS (Cumulative Layout Shift) mesure l'ampleur des sauts de mise en page pendant le chargement. On vise moins de 0,1. Un CLS élevé provient d'images sans dimensions fixées, de polices qui basculent tard, ou de bannières et publicités injectées au-dessus du contenu existant.
• L'INP (Interaction to Next Paint) mesure la réactivité globale aux interactions sur toute la visite, donc la vitesse à laquelle la page réagit quand l'utilisateur tape, clique ou saisit du texte. On vise moins de 200 millisecondes. L'INP a remplacé l'ancien First Input Delay (FID) en 2024, passant d'une mesure de la première interaction à une vue plus complète de la réactivité.

Une page n'est jugée bonne que lorsque les trois indicateurs tiennent dans leurs seuils au 75e centile des visites réelles, c'est-à-dire pour au moins trois quarts des utilisateurs.

À quoi servent les Core Web Vitals

Ces indicateurs traduisent en chiffres ce que ressent un visiteur : une page qui s'affiche vite, ne bouge pas sous le doigt et répond sans latence. Ils servent deux causes à la fois. Côté utilisateur, une expérience plus fluide réduit le taux de rebond et soutient la conversion, car les gens abandonnent les pages lentes ou instables. Côté SEO, ils comptent parmi les signaux d'expérience de page utilisés par Google.

Il faut être précis sur ce poids SEO. Les Core Web Vitals sont un vrai facteur de classement, mais modeste : un critère de départage plutôt qu'un levier qui l'emporte sur la qualité du contenu. Une page aux excellents indicateurs mais au contenu faible ne gagnera pas, mais entre deux pages comparables, la plus rapide et la plus stable prend l'avantage. Le gain le plus important est souvent la conversion : gagner une seconde de chargement ou supprimer les sauts de mise en page fait souvent plus pour le chiffre d'affaires que le petit bonus de classement.

Données de terrain contre données de laboratoire

Une source fréquente de confusion : les Core Web Vitals se mesurent de deux façons, qui divergent souvent.

Les données de laboratoire proviennent d'un outil comme Lighthouse qui simule un chargement unique dans des conditions fixes, un appareil et une vitesse réseau donnés. Elles sont reproductibles et parfaites pour debugger, car on peut changer un paramètre et relancer. Mais c'est une simulation, pas la réalité. Notamment, les outils de laboratoire ne peuvent pas mesurer l'INP directement, puisqu'aucun utilisateur réel n'interagit.

Les données de terrain proviennent du Chrome UX Report (CrUX), qui agrège l'expérience des vrais visiteurs Chrome sur une fenêtre glissante de 28 jours. C'est ce que Google utilise réellement pour le classement. La conséquence pratique est importante : un score Lighthouse parfait ne garantit pas de bonnes données de terrain, car votre audience réelle peut être sur des appareils ou des réseaux plus lents que ce que le laboratoire suppose. Quand les deux divergent, faites confiance aux données de terrain, et servez-vous du laboratoire pour comprendre pourquoi.

Erreurs courantes et comment les éviter

Le piège le plus fréquent est d'optimiser pour le chiffre Lighthouse plutôt que pour les vrais utilisateurs, de soigner le score de laboratoire pendant que les données de terrain restent mauvaises. Courir après un 100 vert dans Lighthouse donne un sentiment de productivité, mais peut passer à côté du vrai problème que rencontrent vos visiteurs sur des téléphones de milieu de gamme.

D'autres soucis récurrents ont des correctifs directs. Les images trop lourdes et non compressées sont la première cause d'un mauvais LCP, réglée par des formats modernes, un dimensionnement correct et le lazy loading sous la ligne de flottaison. Les sauts de mise en page viennent en général d'un espace non réservé, donc fixer une largeur et une hauteur explicites sur les images et les intégrations, et stabiliser les polices, réduit vite le CLS. Un mauvais INP tient presque toujours à un JavaScript lourd qui bloque le thread principal, donc alléger ou différer les scripts et balises tierces non essentiels est le remède fiable. Enfin, traiter les indicateurs comme un correctif ponctuel est une erreur : un nouveau contenu, un script ajouté ou une balise marketing peut faire régresser les scores, d'où la nécessité d'un suivi continu.

Les Core Web Vitals chez BeBranded

Webflow gère nativement une partie du travail : hébergement rapide, CDN mondial, compression et lazy loading des images sont inclus, ce qui donne à un projet une bonne longueur d'avance. Pourtant, un site Webflow peut quand même échouer sur ses indicateurs, souvent à cause d'images trop lourdes, de polices mal chargées, d'animations coûteuses ou de scripts tiers ajoutés après la mise en ligne.

Chez BeBranded, en maintenance, on surveille les Core Web Vitals via PageSpeed Insights et le rapport Core Web Vitals de la Google Search Console, en prenant les données de terrain comme source de vérité. On optimise le poids des médias, on réserve l'espace des éléments pour éviter le CLS, on stabilise le chargement des polices et on allège le JavaScript non essentiel pour tenir l'INP sous son seuil. Comme les indicateurs dérivent avec le temps à mesure qu'un site grandit, on traite cela comme un contrôle récurrent plutôt qu'un audit unique, pour qu'une page qui passait à la mise en ligne continue de passer des mois plus tard. Le bénéfice est double : une meilleure expérience pour les visiteurs et une base technique plus propre qui soutient à la fois le SEO et la conversion.