Que montre ce rapport Core Web Vitals ?
Entrez un domaine ou une URL, choisissez mobile ou desktop, et le rapport extrait 25 semaines de field data depuis l'API CrUX History de Google. Vous obtenez un graphique hebdomadaire pour le LCP, l'INP et le CLS, plus le TTFB et le FCP. Le LCP ne peut jamais être plus rapide que l'un ou l'autre. Cela fonctionne pour n'importe quel site avec assez de trafic Chrome, même celui d'un concurrent.
Sous les graphiques de chargement, le LCP est décomposé en quatre parties. Plus bas, vous trouvez le CLS et l'INP dans le temps, puis les appareils et les types de navigation. Ces deux derniers, ainsi que la part d'image ou de texte du LCP, concernent tous les appareils confondus, quel que soit le mode sélectionné.
Comment lire les graphiques hebdomadaires CrUX
Une barre représente une semaine. Survolez-la pour voir le p75 de cette semaine et la part des chargements bons, à améliorer et médiocres.
Le p75 est la valeur sur laquelle Google vous juge : trois chargements de page sur quatre étaient au moins aussi bons.
- Le LCP est bon jusqu'à 2,5 s et médiocre au-delà de 4 s
- L'INP est bon jusqu'à 200 ms et médiocre au-delà de 500 ms
- Le CLS est bon jusqu'à 0,1 et médiocre au-delà de 0,25
Vous validez les Core Web Vitals quand les trois sont bonnes au p75.
Le badge sur chaque carte de métrique indique la direction d'une droite tracée sur l'ensemble des semaines. Le résumé en haut compare le p75 moyen de la moitié la plus ancienne des semaines à celui de la plus récente. Le score UX happiness à côté est mon propre calcul : la part de chargements bons sur la dernière semaine, en moyenne sur le LCP, l'INP, le CLS, le FCP et le TTFB. Google ne l'utilise pas, et il n'y a de toute façon aucun score officiel pour les Core Web Vitals.
D'où viennent les données CrUX ?
De Chrome sur Android et desktop, pour les utilisateurs qui synchronisent leur historique et partagent leurs statistiques d'utilisation avec Google. Chrome sur iPhone n'y figure pas. Edge non plus.
Chaque point hebdomadaire couvre les 28 jours précédents, donc les points se chevauchent. Un fix mis en production un mardi met environ quatre points à se refléter pleinement.
Google ajoute un nouveau point chaque lundi avec les données allant jusqu'au samedi précédent ; le lundi, le point le plus récent a donc deux jours. Ces 28 jours correspondent à la taille de chaque fenêtre, voilà pourquoi le délai de 28 jours est un mythe.
C'est ce que les visiteurs ont réellement obtenu sur leurs propres appareils. PageSpeed Insights exécute Lighthouse une seule fois, depuis un serveur Google, en simulant un téléphone et un réseau lents. Lighthouse ne clique sur rien, il n'a donc aucun INP. Un 98 dans Lighthouse et une courbe INP rouge ici peuvent parfaitement être vrais tous les deux.
En quoi ce rapport diffère-t-il de celui de Search Console ?
Search Console lit les mêmes données CrUX, uniquement pour vos propres sites. Elle regroupe les URL au comportement similaire et étiquette chaque groupe selon sa pire métrique sur les 28 derniers jours.
Search Console vous indique quel groupe de pages échoue. Les barres hebdomadaires ici vous aident à trouver la semaine où le problème a commencé, et donc la release en cause.
Que vérifier quand une métrique se dégrade
Restez d'abord sur mobile (le rapport s'ouvre dessus) : c'est presque toujours le pire des deux. Regardez ensuite la forme de la courbe.
Un deploy se traduit par une hausse sur environ quatre semaines qui se stabilise ensuite : un nouveau thème, un tag ajouté dans Tag Manager, une image hero passée en loading="lazy". Regardez ce qui a été mis en production la semaine où la hausse commence.
Une courbe qui grimpe régulièrement pendant des mois provient généralement de scripts tiers qui s'accumulent.
Pour le LCP, ouvrez le graphique de décomposition et regardez quelle partie a augmenté. Il ne prend en compte que les chargements où l'élément LCP est une image. Un TTFB plus élevé pointe vers le serveur ou le cache. Un load delay plus long signifie que le navigateur découvre l'image LCP trop tard. Une load duration plus longue correspond à une image plus lourde ou à une connexion lente vers son hébergement. Un render delay en hausse indique que le CSS ou le JavaScript retarde l'affichage.
Ce que l'historique CrUX ne peut pas vous dire
Les petits sites n'ont aucune donnée. Google a besoin de beaucoup de visites Chrome et ne précise pas combien. Les pages avec un noindex ou un statut différent de 200 sont également exclues. L'URL ne donne rien ? Essayez tout le domaine. Le rapport teste avec et sans www pour vous.
Même avec des données, vous n'obtenez qu'un seul p75 par métrique et par semaine pour tout le domaine ou pour une URL populaire. CrUX ne dit pas quel template est lent, quel élément bouge ou quel script bloque le clic.
Pour cela, il faut du real user monitoring sur votre propre site. J'ai créé CoreDash pour cela : les chargements sur votre propre site, avec l'élément LCP et l'interaction lente associés, pour voir l'effet d'un fix en quelques heures.
