Core Web Vitals : c'est quoi ?
Ce sont trois métriques choisies par Google pour résumer l'expérience d'une page : charge-t-elle vite son contenu principal, réagit-elle vite quand on clique, reste-t-elle stable pendant qu'on la lit ? La Search Console en français les appelle signaux Web essentiels. Elles se mesurent sur de vraies visites. Selon web.dev, la documentation de Google sur la performance, chaque métrique s'évalue au 75e centile des chargements de page, séparément sur mobile et sur ordinateur : une page est jugée bonne sur une métrique quand au moins les trois quarts des chargements atteignent le seuil. Le jeu de métriques évolue : INP a remplacé FID comme Core Web Vital stable en 2024.
LCP, INP, CLS : les trois métriques et leurs seuils
- LCP (Largest Contentful Paint), le chargement : le temps nécessaire pour afficher le plus grand élément visible à l'ouverture, une image ou un bloc de texte. Bon à 2,5 secondes ou moins.
- INP (Interaction to Next Paint), la réactivité : le délai entre une interaction, clic, toucher ou touche du clavier, et la mise à jour visible de la page, observé sur l'ensemble de la visite. Bon à 200 millisecondes ou moins.
- CLS (Cumulative Layout Shift), la stabilité visuelle : l'ampleur des déplacements inattendus de la mise en page, ceux qui font cliquer à côté. Bon à 0,1 ou moins.
Au-delà de ces seuils, web.dev distingue une zone à améliorer, puis une zone mauvaise. Regardez toujours l'appareil : une page peut être bonne sur ordinateur et mauvaise sur mobile.
Où les mesurer : données de terrain et de laboratoire
Deux sortes de chiffres coexistent. Les données de terrain viennent de visites réelles d'utilisateurs de Chrome, agrégées sur une période glissante : ce sont elles qui reflètent l'expérience évaluée. Les données de laboratoire viennent d'un chargement simulé, sur une machine et un réseau donnés : elles sont reproductibles et servent au diagnostic, mais ce n'est pas ce que vivent vos visiteurs. INP, qui dépend d'interactions réelles, ne se mesure pas en laboratoire ; le test affiche à sa place le temps de blocage total, un indicateur voisin.
Core Web Vitals : les outils de test
- Le rapport Core Web Vitals de la Search Console : des données de terrain, séparées entre mobile et ordinateur, avec des URL regroupées par pages semblables. C'est lui qui montre quel gabarit pose problème. Il reste vide tant que le trafic est insuffisant.
- PageSpeed Insights, pour une URL : en haut, les données de terrain de la page ou, à défaut, de l'origine entière quand elles existent ; en dessous, un test de laboratoire avec ses pistes de correction.
- Les outils de développement du navigateur : pour reproduire un problème précis et vérifier un correctif avant sa mise en ligne.
Quand terrain et laboratoire divergent, ce sont les données de terrain qui comptent. Un excellent score de laboratoire obtenu sur un ordinateur rapide ne dit rien d'un téléphone d'entrée de gamme sur un réseau mobile.
Les causes fréquentes, métrique par métrique
- LCP lent : un serveur lent à répondre, faute de cache ou d'hébergement adapté ; une image principale trop lourde ou dans un format ancien ; cette même image chargée en différé alors qu'elle est visible dès l'ouverture ; une image découverte tard parce qu'elle est placée en arrière-plan CSS ou insérée par JavaScript ; des feuilles de style et des scripts qui bloquent l'affichage ; un contenu entièrement rendu dans le navigateur.
- INP élevé : de longues tâches JavaScript qui occupent le fil principal ; l'accumulation de scripts tiers, gestionnaire de balises, tchat, outils de test, widgets ; des gestionnaires d'événements trop lourds ; une page très volumineuse qui se redessine à chaque clic.
- CLS élevé : des images, vidéos et iframes sans dimensions déclarées ; des emplacements publicitaires ou des contenus intégrés sans espace réservé ; un bandeau inséré en haut de page après le chargement ; des polices web qui changent la taille du texte en arrivant ; du contenu injecté au-dessus de ce que le visiteur lit déjà.
Leur poids réel dans le référencement
Dans son guide sur les fonctionnalités IA de la recherche, Google range l'expérience de page parmi les fondamentaux du référencement, à côté de l'exploration autorisée, du maillage interne, d'un contenu de qualité et de données structurées conformes au texte visible. C'est un fondamental parmi d'autres, pas le facteur décisif. La documentation de Google sur l'expérience de page le dit à sa manière : la recherche cherche à montrer le contenu le plus pertinent, même quand l'expérience de page est médiocre, et de bons résultats dans le rapport Core Web Vitals ne garantissent pas un bon classement. Une page lente qui répond précisément peut donc passer devant une page rapide qui répond mal. Le coût le plus sûr d'une page lente se lit ailleurs : un visiteur qui attend ou clique à côté s'en va, et cela se mesure en conversions plus qu'en positions.
Côté moteurs de réponse, rien de documenté n'indique que ChatGPT ou Perplexity mesurent ces métriques. Ce qui compte pour leurs robots, c'est de recevoir un HTML complet sans dépendre du JavaScript. Le rendu côté serveur, qui améliore souvent le LCP, sert donc les deux à la fois.
L'ordre des corrections
- Partir du rapport de la Search Console, sur mobile d'abord si c'est là que sont vos visiteurs : quelle métrique échoue, sur quel groupe d'URL.
- Corriger par gabarit, pas par URL : des pages semblables partagent presque toujours la même cause, et un correctif sur le gabarit les traite toutes.
- Commencer par les pages qui comptent, celles qui reçoivent le trafic de recherche ou portent les conversions, avant celles que personne ne visite.
- Traiter d'abord les causes simples et sûres, dimensions des images, image principale compressée et non différée, cache serveur, avant les chantiers lourds : découpage du JavaScript, retrait de scripts tiers, changement de mode de rendu.
- Vérifier en laboratoire avant la mise en production, puis attendre les données de terrain : comme elles portent sur une période glissante, une correction met plusieurs semaines à s'y refléter.
- Noter la date de chaque correctif, pour relier plus tard une évolution du rapport à ce qui l'a provoquée.
Ce qui ne sert à rien
- Viser un score parfait dans un test de laboratoire : c'est un outil de diagnostic, pas la mesure retenue.
- Tester uniquement depuis un ordinateur de bureau, sur la connexion du bureau.
- Différer le chargement de toutes les images, y compris celle du haut de page : c'est une cause classique de LCP lent.
- Retirer un contenu utile pour gagner un peu de vitesse : la pertinence passe avant.
- Mesurer une seule fois : un nouveau script marketing, une nouvelle extension ou un nouveau bandeau peuvent tout défaire.
Ce que fait Vandolo
Le module Santé du site & tracking (71 € HT par mois) contrôle le tracking, c'est-à-dire les balises, les doublons et le consentement, réalise un audit SEO technique avec vérification automatique et en tire une feuille de route priorisée, cochable. Les chiffres viennent des comptes connectés, ou sont absents.