Core Web Vitals : les trois mesures qui comptent et les seuils à tenir

Les Core Web Vitals sont les trois mesures que Google retient pour juger l’expérience d’une page. Leur particularité est capitale et souvent mal comprise : elles ne sont pas relevées en laboratoire mais chez vos visiteurs réels, avec leurs téléphones, leurs connexions et leur position géographique. Un site rapide sur votre ordinateur de bureau relié à la fibre peut être médiocre dans ces données.

Pourquoi ces trois-là

Elles ne sont pas choisies au hasard. Chacune correspond à un moment de frustration identifiable dans une visite : l’attente devant une page blanche, l’impression que le site ne répond pas au doigt, et le contenu qui bouge au moment où l’on veut cliquer. Ce sont les trois reproches les plus fréquents des utilisateurs, traduits en chiffres mesurables.

Google en a fait un critère de classement en 2021. Il faut cependant garder le sens des proportions : la pertinence du contenu passe devant. Ces mesures départagent des pages de qualité comparable — situation extrêmement courante sur les requêtes concurrentielles, où dix résultats répondent correctement à la même question.

LCP — le temps d’affichage du contenu principal

Le Largest Contentful Paint mesure le moment où le plus gros élément visible devient visible : en général l’image de bannière ou le titre du haut de page. C’est la traduction chiffrée de « la page s’affiche ».

Seuil à tenir : 2,5 secondes. Au-delà de 4 secondes, la page est classée mauvaise.

Ce qui le dégrade

• L’image de bannière. Une photo de 3 Mo en JPEG là où 150 Ko en WebP suffiraient. C’est la première cause, de loin.
• Les polices web. Une police chargée sans précaution bloque l’affichage du texte le temps de son téléchargement. Le correctif tient en deux lignes : précharger le fichier et autoriser l’affichage immédiat avec une police de substitution.
• Le temps de réponse du serveur. Sur un hébergement mutualisé saturé, la première réponse arrive après une seconde. Ce retard est irrattrapable : tout le reste s’empile derrière.
• Les scripts tiers chargés trop tôt. Une bannière de consentement ou un outil de statistiques placé avant le contenu retarde mécaniquement l’affichage.

Par où commencer

Redimensionner et convertir l’image de bannière donne, à lui seul, l’essentiel du gain dans la majorité des cas. C’est une heure de travail pour un effet immédiat et durable.

INP — la réactivité aux interactions

L’Interaction to Next Paint mesure le délai entre l’action d’un visiteur — un clic, une tape, une touche du clavier — et le moment où l’écran répond visiblement. Il a remplacé l’ancien FID en mars 2024, et il est nettement plus sévère : là où le FID n’observait que la première interaction et seulement son délai de prise en compte, l’INP observe toutes les interactions de la visite et va jusqu’à l’affichage du résultat.

Seuil à tenir : 200 millisecondes. Au-delà de 500 ms, la page est classée mauvaise.

Ce qui le dégrade

C’est la mesure qui punit le JavaScript excessif. Un menu qui met une demi-seconde à s’ouvrir, un accordéon qui hésite, un filtre de catalogue qui fige la page : autant de points perdus.

• Les constructeurs de pages, qui exécutent beaucoup de code pour afficher peu de choses.
• Les scripts publicitaires et de suivi, qui monopolisent le fil d’exécution au moment précis où le visiteur essaie de cliquer.
• Les gestionnaires de consentement mal intégrés, souvent les pires contrevenants — ils s’exécutent tôt, surveillent le document entier, et le premier geste du visiteur est justement de cliquer sur leur bannière.
• Les transitions de page animées, qui retiennent l’affichage pendant que la page suivante se télécharge. Le délai réseau est alors imputé au clic.

Un piège fréquent

L’INP ne se mesure pas sur une page qu’on regarde sans y toucher. Un site peut afficher un INP excellent simplement parce que personne n’interagit avec lui — et se dégrader brutalement le jour où un menu mobile est ajouté. La mesure ne devient significative qu’avec du trafic réel qui clique.

CLS — la stabilité visuelle

Le Cumulative Layout Shift mesure les déplacements involontaires du contenu pendant le chargement. C’est le bouton qui saute au moment où on le vise, le paragraphe qu’on était en train de lire et qui descend de trois lignes.

Seuil à tenir : 0,1. Au-delà de 0,25, la page est classée mauvaise.

Ce qui le dégrade

Presque toujours la même cause : des images, des vidéos ou des cadres publiés sans dimensions déclarées. Le navigateur ne sait pas quelle place réserver, affiche le texte, puis décale tout quand l’élément arrive.

Viennent ensuite les bannières insérées en haut de page après coup, les polices de substitution dont les proportions diffèrent trop de la police finale, et les contenus injectés dynamiquement au-dessus de ce que le visiteur est en train de lire.

C’est la mesure la plus facile à corriger des trois : déclarer une largeur et une hauteur sur chaque image règle l’essentiel.

Récapitulatif

Où lire ses vrais chiffres

Trois sources, qui ne disent pas la même chose.

1. PageSpeed Insights. Le bloc du haut vient de vos visiteurs réels sur les vingt-huit derniers jours : c’est celui qui compte pour le référencement. Le bloc du bas est une simulation instantanée, utile pour diagnostiquer, sans aucun poids dans le classement.
2. La Search Console, rapport « Signaux web essentiels ». Mêmes données réelles, groupées par type de page, avec l’historique. C’est le tableau de bord de suivi.
3. Les outils du navigateur. Ils mesurent votre machine, pas vos visiteurs. Indispensables pour comprendre une cause, inutiles pour juger un résultat.

Le piège du délai de vingt-huit jours

Les données terrain sont une moyenne glissante sur vingt-huit jours. Conséquence pratique : après une correction, il faut près d’un mois pour en voir l’effet complet, et les premiers jours ne montrent presque rien.

C’est la source d’une erreur classique — conclure qu’un correctif n’a rien donné et le défaire, alors que la mesure regardait encore derrière elle. La bonne méthode consiste à vérifier l’effet immédiatement avec la simulation et les outils du navigateur, puis à attendre les données terrain pour confirmer.

Par quoi commencer

1. Relever les trois chiffres actuels dans la Search Console, pour savoir d’où l’on part.
2. Traiter les images : effet sur le LCP et le CLS à la fois, pour le moins d’effort.
3. Déclarer les dimensions de tout ce qui s’affiche : le CLS se règle presque entièrement là.
4. Faire l’inventaire des scripts tiers et supprimer ceux que personne ne consulte.
5. Mesurer le temps de réponse du serveur seul ; au-delà de 600 ms de façon répétée, changer d’hébergement avant toute autre optimisation.
6. Reprendre l’INP en dernier : c’est le plus technique, et souvent le plus rentable une fois le reste assaini.

Trois idées fausses qui coûtent cher

« J’ai 100 sur PageSpeed, donc tout va bien »

Le score sur cent n’est pas une Core Web Vital. C’est une note composite calculée à partir d’une simulation en laboratoire, avec ses propres pondérations. On peut afficher 100 en simulation et être classé « mauvais » sur les données terrain — il suffit que vos visiteurs réels utilisent des téléphones plus lents que la machine de test, ce qui est la norme.

Le score sert à diagnostiquer et à comparer deux versions d’une même page. Il ne mesure pas ce que vivent vos visiteurs.

« Mon site est rapide, je l’ai vérifié »

Vous le vérifiez depuis une connexion que vous connaissez, sur un appareil récent, avec vos fichiers déjà en cache après plusieurs visites. C’est le scénario le plus favorable qui existe, et il ne ressemble à aucune première visite.

Le test honnête se fait sur un téléphone de milieu de gamme, en navigation privée, sur le réseau mobile plutôt que sur le Wi-Fi de bureau. La différence surprend presque toujours.

« Ces mesures ne concernent que les gros sites »

C’est l’inverse. Sur une requête très concurrentielle, les grands sites compensent par leur autorité et leurs liens. Sur une requête locale disputée entre cinq entreprises de taille comparable, l’expérience de page fait partie des rares critères qui départagent.

Un piège technique fréquent

Les données terrain ne sont disponibles que si votre site reçoit assez de trafic pour constituer un échantillon. En dessous d’un certain seuil, PageSpeed Insights n’affiche que la simulation, et la Search Console reste vide.

Ce n’est pas un problème en soi, mais cela change la méthode : sur un site à faible trafic, il faut se fier à la simulation et aux mesures faites soi-même sur un vrai téléphone, en gardant à l’esprit qu’elles sont plus optimistes que la réalité. Et vérifier au niveau de l’ensemble du domaine plutôt que page par page, ce que la Search Console permet en regroupant les URL similaires.

Ce qu’il faut retenir

Trois seuils, une source de vérité — les données terrain — et un délai d’un mois pour constater un effet. Le reste est du diagnostic.

Et une hiérarchie utile quand le temps manque : le LCP se corrige presque toujours par les images et l’hébergement, le CLS par les dimensions déclarées, l’INP par la réduction du JavaScript. Dans cet ordre, on traite l’essentiel du problème avec les deux premiers, qui sont aussi les moins techniques.