Rapport Core Web Vitals

Les données terrain et les données de laboratoire sont deux choses différentes

Un test de laboratoire, comme Lighthouse, charge votre page une fois sur un téléphone milieu de gamme simulé avec une connexion bridée. Vous pouvez le répéter autant que vous voulez et il est plein de détails, mais le visiteur qu’il décrit est imaginaire.

Les données terrain viennent de visites réelles. Les utilisateurs de Chrome qui ont accepté de partager des statistiques d’usage envoient des durées anonymes et Google les agrège sur les 28 derniers jours dans le Chrome UX Report, connu sous le nom de CrUX. Ce sont les données que Google Search lit pour évaluer l’expérience de page. Une page peut obtenir 95 en laboratoire et échouer sur le terrain parce que son vrai public a des téléphones plus anciens. Elle peut aussi réussir sur le terrain avec un score de laboratoire moyen parce que la plupart des visiteurs arrivent avec un cache déjà rempli.

Ce rapport demande d’abord les données terrain, puisque c’est la version qui compte.

Les cinq mesures du tableau

Les trois premières sont les Core Web Vitals. FCP et TTFB sont ajoutées en complément parce qu’elles aident à expliquer un LCP lent. Elles ne comptent pas dans la note.

Comment le rapport est construit

Nous suivons les redirections jusqu’à l’adresse finale, puis interrogeons CrUX deux fois, une pour les mobiles et une pour les ordinateurs. Chaque requête essaie d’abord la page exacte, puis se rabat sur l’ensemble de l’origine quand la page seule a trop peu de trafic. La ligne au-dessus de chaque tableau indique lequel vous lisez.

La valeur affichée pour une mesure est son 75e centile, c’est-à-dire que trois visites sur quatre étaient au moins aussi rapides. La barre colorée à côté donne la part des visites dans les plages bonne, à améliorer et mauvaise.

Pour la note, chaque Core Web Vital rapporte 2 points quand elle est bonne, 1 quand elle est à améliorer et 0 quand elle est mauvaise. Six points sur six donnent un A, cinq un B, quatre un C, trois un D, deux un E et moins un F. Une seule mesure mauvaise plafonne la note à D, même si les deux autres sont excellentes. La note principale est celle du mobile quand des données mobiles existent.

Quand Chrome n’a pas de données

CrUX ne couvre que les pages publiques et assez visitées. Pour tout le reste, le rapport lance un test PageSpeed Insights sur un téléphone simulé et vous dit clairement qu’il l’a fait. Vous obtenez alors le score de performance Lighthouse (A dès 90, B dès 75, C dès 50, D dès 35, E dès 20), des valeurs de laboratoire pour LCP et CLS et le Total Blocking Time à la place de l’INP, puisqu’on ne peut pas mesurer la réactivité aux actions sans une personne pour les faire. Jusqu’à cinq audits aux plus grands gains de temps estimés sont listés en dessous.

Ce qui fait bouger chaque chiffre

LCP

Repérez l’élément LCP dans le panneau Performance des outils de développement de Chrome. C’est généralement l’image principale. Servez-la à la taille affichée en WebP ou AVIF, ajoutez fetchpriority="high" et ne mettez jamais loading="lazy" dessus. Si le TTFB dépasse déjà 0.8 s, corrigez d’abord le serveur avec un cache de pages ou un CDN. Le détail du poids de la page montre les fichiers les plus lourds.

INP

De longues tâches JavaScript empêchent la page de répondre aux actions. Retirez les balises et extensions que vous n’utilisez plus, chargez les scripts tiers avec defer et découpez le travail qui dure plus de 50 ms.

CLS

Donnez à chaque image et vidéo des attributs width et height, réservez de la place pour les publicités et les contenus intégrés avec min-height ou aspect-ratio et n’insérez pas de bannières au-dessus d’un contenu déjà visible.

Les données terrain forment une fenêtre glissante de 28 jours. Après une correction, les chiffres s’améliorent un peu chaque jour et il faut quatre semaines pour voir l’effet complet. Les visites de Safari et de tout navigateur sur iPhone ne font jamais partie de CrUX, donc le rapport ne décrit que votre public sous Chrome.