Suivre l’historique des Core Web Vitals d’un site

Comment utiliser l’outil

Saisissez l’adresse d’un site ou d’une page, avec ou sans « https:// », choisissez la portée et l’appareil, puis lancez. Avec « site entier », l’outil interroge l’origine, c’est-à-dire l’ensemble des pages du domaine. Avec « page seule », il interroge l’adresse exacte que vous avez saisie.¹

Le résultat comporte trois blocs, un par mesure. Chacun donne la dernière valeur au 75e centile avec sa pastille, une courbe sur 25 semaines tracée contre le seuil « bon », la répartition des visites en trois classes pour la dernière période, et un tableau des valeurs semaine par semaine.

Ce que contient l’historique

L’API CrUX History renvoie, pour chaque mesure, une série de périodes. Chaque période couvre une fenêtre de 28 jours, et les périodes sont espacées d’une semaine : elles se chevauchent, un peu comme une moyenne mobile.¹ Une correction mise en ligne n’apparaît donc entièrement dans la courbe qu’au bout de quatre semaines, le temps que les anciennes visites sortent de la fenêtre.

La série par défaut compte 25 périodes, et l’API en accepte jusqu’à 40 par requête. Google la met à jour le lundi, vers 4 h UTC, avec les données jusqu’au samedi précédent, sans engagement de délai.¹ L’outil demande les 25 périodes, du plus ancien au plus récent.

Les trois mesures et leurs seuils

Les Core Web Vitals sont au nombre de trois. Le Largest Contentful Paint (LCP) mesure le moment où le plus grand élément visible s’affiche, avec un seuil « bon » de 2,5 secondes. L’Interaction to Next Paint (INP) mesure la réactivité aux clics, touches et appuis, avec un seuil de 200 millisecondes. Le Cumulative Layout Shift (CLS) mesure les déplacements inattendus du contenu, avec un seuil de 0,1.²

Google recommande de regarder le 75e centile des chargements de page, séparément sur mobile et sur ordinateur.² C’est pourquoi l’outil vous fait choisir l’appareil : une moyenne des deux mélangerait deux expériences différentes. La ligne verte en pointillés de chaque courbe marque le seuil « bon ». Les limites des classes « à améliorer » et « mauvais » (4 secondes, 500 millisecondes et 0,25) sont celles de l’histogramme renvoyé par l’API.¹

Lire les courbes et la répartition

La courbe suit le 75e centile semaine après semaine : quand elle passe sous la ligne verte, les trois quarts des visites font mieux que le seuil. Google précise que ces valeurs sont calculées sur l’ensemble des données disponibles et non sur les classes de l’histogramme.¹ Chaque point est coloré selon sa classe, ce qui permet de repérer d’un coup d’œil les semaines où le site a décroché.

La barre de répartition montre, pour la dernière période, la part des visites bonnes, à améliorer et mauvaises. Elle complète le centile : un site qui passe sous le seuil compte au moins 75 % de bonnes visites, et jusqu’à un quart de visites moyennes ou mauvaises. Quand une semaine n’a pas assez de données, Google renvoie une valeur vide, et l’outil laisse alors un trou dans la courbe au lieu de relier les points voisins.¹

Pourquoi Google n’a parfois aucune donnée

Les données du CrUX viennent de vrais utilisateurs de Chrome sur ordinateur et sur Android, à condition qu’ils aient activé l’envoi des statistiques d’usage et synchronisé leur historique. Chrome sur iOS, les WebView Android et les autres navigateurs, Edge compris, ne contribuent pas.³

Une page ou un site doit aussi être public et assez visité. Les pages en erreur ou en noindex sont exclues, et Google ne publie pas le seuil de visites exigé.³ Un petit site local n’a donc souvent aucune donnée, et l’outil l’écrit. Dans ce cas, le test de vitesse en laboratoire reste le seul repère, et il se fait avec le test de vitesse PageSpeed.

La vitesse compte-t-elle pour le classement ?

Google écrit que les Core Web Vitals sont utilisés par ses systèmes de classement, et qu’il n’existe pas de signal unique : plusieurs signaux d’expérience sur la page entrent en jeu. De bons scores ne garantissent pas une première place.⁴

Google ajoute que la recherche cherche toujours à montrer le contenu le plus pertinent, même quand l’expérience de la page est médiocre. L’expérience pèse surtout quand beaucoup de pages utiles répondent à la même requête.⁴ Pour un site vitrine, la courbe sert d’abord les visiteurs : suivre l’historique permet de vérifier qu’une correction a tenu et qu’une mise à jour n’a rien dégradé.

Ce que l’outil fait, et ses limites

L’outil interroge la méthode queryHistoryRecord de l’API CrUX avec les trois mesures, 25 périodes et le type d’appareil choisi. Un site sous le seuil de visites n’est pas dans le jeu de données : l’API répond alors qu’elle n’a pas de données, et l’outil le dit.³ Il n’analyse que le LCP, l’INP et le CLS ; les autres mesures du CrUX, comme le First Contentful Paint, ne sont pas affichées.

Les adresses locales, privées ou à identifiants sont refusées. Aucune adresse saisie n’est conservée au-delà des 6 heures de cache, qui ne contient que des mesures publiques de Google. Les données ne portent pas sur votre page seule quand vous choisissez le site entier : elles agrègent toutes les pages de l’origine.

Après l’historique

Une courbe qui décroche appelle un diagnostic. Le test de vitesse PageSpeed donne les mesures de laboratoire et les pistes pour corriger, et l’audit SEO on-page contrôle le reste de la page. La vitesse est aussi un des points de la checklist pour auditer son site. Quand les corrections demandent un travail technique, c’est le cadre de l’accompagnement SEO que je mène pour mes clients.

Questions fréquentes