Quelqu’un teste la vitesse de votre site, obtient un score de 54 et vous dit qu’il est lent. Un autre outil donne 91. Aucun de ces chiffres ne dit ce que vivent vraiment vos visiteurs, et c’est cela que Google utilise.
Les Core Web Vitals sont trois mesures issues de visites réelles sur votre site. Elles valent la peine d’être comprises, car elles décrivent des problèmes que les gens ressentent : attendre la page, toucher un bouton qui ne réagit pas, voir le contenu sauter pendant le chargement.
Les trois mesures
Largest Contentful Paint (LCP) : le temps avant l’affichage du contenu principal, en général la plus grande image ou le plus grand titre. Bon : 2,5 secondes ou moins.
Interaction to Next Paint (INP) : la rapidité de réaction de la page quand on touche, clique ou tape. Bon : 200 millisecondes ou moins. Elle a remplacé First Input Delay en 2024.
Cumulative Layout Shift (CLS) : à quel point la mise en page bouge de façon inattendue pendant l’utilisation. Bon : 0,1 ou moins.
Une page est validée quand au moins 75 % des visites atteignent le seuil « bon » pour les trois mesures, évaluées séparément sur mobile et sur ordinateur. Les seuils viennent desrecommandations Web Vitals de Google.
Scores de laboratoire et visites réelles sont deux choses différentes
Un score donné par un outil comme Lighthouse est un test de laboratoire : une visite simulée, avec un appareil et une connexion. Il aide à trouver les causes, mais varie d’un test à l’autre et ne représente pas votre public.
Les données terrain viennent de vrais utilisateurs de Chrome qui visitent votre site, collectées dans le Chrome UX Report sur une fenêtre glissante de 28 jours. Elles reflètent leurs téléphones, leurs réseaux et leurs lieux. Pour savoir si vos clients subissent un site lent, la réponse est dans les données terrain.
Ce qui explique le plus souvent de mauvais résultats
LCP lent
Des images lourdes non redimensionnées pour mobile, des réponses serveur lentes, des polices ou scripts qui bloquent la page, et des images principales chargées tard parce que JavaScript les ajoute.
INP médiocre
Trop de JavaScript exécuté en même temps, souvent à cause de widgets de chat, de balises de suivi et de constructeurs de pages lourds. La page semble prête mais elle est occupée et ne peut pas réagir à un toucher.
CLS élevé
Des images et contenus intégrés sans espace réservé, des bandeaux qui poussent le contenu vers le bas et des polices web qui changent la taille du texte en se chargeant.
Suivez la tendance, pas une seule journée
Comme les données terrain couvrent 28 jours, une amélioration apparaît progressivement. Une mauvaise semaine peut aussi venir d’une campagne, d’un nouveau plugin ou d’un script tiers. Regarder l’historique semaine par semaine montre si un changement a aidé et repère les dégradations lentes avant qu’elles deviennent un problème.
Monhistorique gratuit de vitesse réelle lit la History API du Chrome UX Report et trace LCP, INP, CLS, FCP et TTFB pour votre site et pour une page précise, par appareil, avec les seuils de Google et la part de bonnes visites chaque semaine. Les sites avec trop peu de trafic Chrome n’ont pas de données publiques, et l’outil le dit au lieu de deviner.
Est-ce que ça vaut la peine de corriger ?
Les Core Web Vitals sont un signal parmi beaucoup d’autres dans la recherche Google et pèsent rarement plus qu’un contenu pertinent. La meilleure raison de les corriger, ce sont vos clients : un paiement qui réagit tout de suite et une page qui ne saute pas sous le pouce sont tout simplement plus faciles à utiliser.
Si une mesure est dans le rouge, commencez par les pages qui rapportent de l’argent ou des contacts. Mesurez, corrigez une cause, puis suivez la tendance les semaines suivantes.
Se faire aider
Les problèmes de vitesse ont généralement deux ou trois causes principales, pas des dizaines. Si votre historique montre de mauvais résultats,envoyez-moi le site et les pages qui comptent. Je peux trouver les causes, vous dire lesquelles valent la peine d’être corrigées et faire les changements.