Core Web Vitals sur plusieurs sites : quoi mesurer d’abord
Les seuils, pourquoi terrain et labo divergent, que faire quand un petit site n’a pas de données, et suivre de nombreux sites gratuitement avec l’API CrUX.
Les Core Web Vitals sont simples pour une page et épuisants pour vingt sites. Chaque rapport est par propriété, chaque outil affiche un autre chiffre, et la moitié de vos petits sites n’ont aucune donnée. Voici comment se faire une idée utile sans une semaine d’onglets.
Les seuils
Trois indicateurs, mesurés au 75e centile des chargements, séparément sur mobile et sur ordinateur. Une page passe quand les trois sont bons. Les plages ci-dessous viennent de la documentation de PageSpeed Insights.
| Indicateur | Mesure | Bon | Mauvais |
|---|---|---|---|
| LCP, Largest Contentful Paint | Chargement | Jusqu’à 2,5 s | Plus de 4 s |
| INP, Interaction to Next Paint | Réactivité | Jusqu’à 200 ms | Plus de 500 ms |
| CLS, Cumulative Layout Shift | Stabilité visuelle | Jusqu’à 0,1 | Plus de 0,25 |
Entre les deux, c’est « à améliorer ». L’INP a remplacé le First Input Delay en mars 2024 : les guides qui parlent encore de FID sont dépassés.
Gardez la question du classement en proportion. Google recommande vivement de bons Core Web Vitals et dit qu’ils vont dans le sens de ce que ses systèmes de classement cherchent à récompenser. Il ne dit pas qu’ils feront passer une page devant un meilleur contenu, et nous ne le promettrions pas non plus.
Pourquoi deux outils donnent deux chiffres
L’essentiel de la confusion vient du mélange entre terrain et labo.
Les données de terrain sont ce que de vrais visiteurs ont vécu. Elles viennent du Chrome UX Report (CrUX), en moyenne glissante sur 28 jours, et seulement d’utilisateurs ayant donné leur accord, sur les plateformes prises en charge : Chrome sur iOS et les autres navigateurs Chromium n’y sont pas. Une correction livrée aujourd’hui met des semaines à se voir en entier.
Les données de labo sont un seul chargement simulé, comme Lighthouse. Immédiates et reproductibles, elles ne peuvent pas mesurer l’INP, faute de savoir quand quelqu’un va interagir. Elles utilisent le Total Blocking Time à la place. Le score de 0 à 100 de PageSpeed Insights est un score de labo : de bonnes données de labo ne veulent pas forcément dire une bonne expérience pour de vrais utilisateurs.
La règle est courte : le terrain pour décider quoi corriger, le labo pour le déboguer.
Comment le rapport de Search Console vous juge
Le rapport Core Web Vitals regroupe les pages à l’expérience similaire au lieu de juger chaque URL. Trois détails comptent :
- Le plus faible décide. Un seul indicateur mauvais rend tout le groupe mauvais.
- Chaque appareil a son état. Un groupe peut passer sur mobile et échouer sur ordinateur.
- Sans assez de données, il se rabat. Un groupe qui manque de données prend les chiffres de l’origine : un modèle lent peut déteindre sur des pages qui vont bien.
Après une correction, la validation surveille pendant 28 jours avant de la déclarer réussie.
Quand un petit site n’a pas de données
Beaucoup de sites n’ont rien dans CrUX. Une page ou une origine doit être publiquement détectable et suffisamment populaire, et Google ne publie pas le seuil. « Aucune donnée disponible » ne signale pas un problème, et ne veut pas dire que tout va bien.
Il reste deux options. Lancer Lighthouse sur vos modèles principaux, qui renseigne sur le chargement et la mise en page, pas sur l’interaction. Ou collecter vos propres données de terrain avec un outil de mesure sur utilisateurs réels, même un petit script qui remonte les mêmes indicateurs. Pour un site à faible trafic, la première suffit en général.
Suivre de nombreux sites sans une semaine d’onglets
Utilisez l’API CrUX. Elle est gratuite avec une clé d’API Google Cloud, limitée à 150 requêtes par minute par projet, mise à jour chaque jour vers 04:00 UTC, et accepte une origine ou une URL. Vous pouvez boucler sur toutes vos origines en quelques secondes et stocker le résultat. Un site qui répond sans données n’est simplement pas encore assez populaire : notez-le aussi.
Commencez par les origines, puis descendez. Récupérez les trois indicateurs de chaque origine sur mobile. Triez par l’indicateur le plus loin de son seuil, pondéré par le trafic du site. Un mauvais LCP sur votre site principal passe avant un mauvais CLS sur un projet annexe.
Corrigez les modèles, pas les pages. Les sites bâtis sur la même pile partagent leurs problèmes. Si quatre sites utilisent une même mise en page, le décalage de l’en-tête est une seule correction pour les quatre. C’est ce qui rend l’exercice rentable à l’échelle de plusieurs sites.
Commencez par ce qui fait bouger le chiffre. Les guides de Google découpent chaque indicateur : le LCP en réponse du serveur, chargement de la ressource et délai de rendu, l’INP en délai d’entrée, traitement et présentation, le CLS en ce qui bouge et pourquoi. Pour le LCP de la plupart des sites vitrines, regardez d’abord l’image principale : son poids, son format, et si elle est chargée en différé alors qu’elle ne devrait pas. Pour le CLS, cherchez les images sans dimensions et tout ce qui s’insère au-dessus du contenu existant. Pour l’INP, les longues tâches des scripts tiers.
N’oubliez pas le délai. Après une livraison, les outils de labo montrent le changement tout de suite. Le terrain met jusqu’à 28 jours à le refléter en entier : ne jugez pas une correction au bout d’une semaine, et notez la date de livraison.
Ce qu’Owlseen fera, et quand
PageSpeed et Core Web Vitals sont sur la liste d’Owlseen pour après la première version, à partir des mêmes sources que celles décrites ici. Il n’est pas sorti, et rien de tout cela n’en dépend : l’API CrUX et un tableur vous mèneront déjà loin.
Et si votre vitesse va bien mais que votre trafic baisse, la cause est ailleurs : voir les pages qui perdent du trafic et ce que Search Console retient.