Pour de nombreux propriétaires de sites, le rapport sur les Core Web Vitals de Google Search Console est le premier contact, et souvent le seul, avec les métriques de performance. C’est là qu’apparaissent les URL « médiocres » ou « à améliorer », les e-mails d’alerte de Google et les graphiques qui montent ou descendent. C’est aussi l’un des rapports les plus mal compris : des chiffres qui ne correspondent pas à PageSpeed Insights, des pages signalées qui semblent ultra-rapides, des corrections qui ne produisent aucun effet visible pendant des semaines.
Presque tous ces malentendus s’expliquent par la manière dont le rapport est construit. Dans cet article, nous voyons d’où viennent les données, comment fonctionnent les groupes d’URL, comment lire les statuts et les comptages, pourquoi les corrections apparaissent en retard, et comment utiliser le rapport pour décider où agir.
D’où viennent les données
Le rapport, situé dans la section Expérience de la Search Console, repose exclusivement sur les données de terrain du Chrome UX Report : des mesures collectées depuis les navigateurs Chrome des utilisateurs réels qui visitent le site. Il ne contient aucun test de laboratoire, n’utilise pas Lighthouse et ne dépend pas du nombre de fois où l’on analyse une page avec PageSpeed Insights. Chaque valeur est le 75e percentile des expériences des utilisateurs sur les 28 derniers jours, comme l’explique l’article sur la fenêtre de 28 jours.
Le rapport est divisé en deux sections, mobile et ordinateur, qui doivent se lire séparément : les expériences sont très différentes, et un site peut être bon sur ordinateur et médiocre sur mobile. Les seuils sont les seuils officiels des trois métriques : LCP inférieur ou égal à 2,5 secondes, INP inférieur ou égal à 200 millisecondes et CLS inférieur ou égal à 0,1 pour le statut « bon » ; au-delà de 4 secondes, 500 millisecondes et 0,25 pour le statut « médiocre ».
Les groupes d’URL
Le concept le plus important, et le moins intuitif, est le groupe. La Search Console n’évalue pas chaque URL avec ses propres données : elle regroupe les URL qu’elle juge similaires, par structure et par contenu, et évalue le groupe dans son ensemble. Chaque URL du groupe hérite du statut du groupe. C’est pourquoi une page précise, peut-être ultra-rapide quand on la teste, peut ressortir comme « médiocre » : elle appartient à un groupe qui, globalement, ne respecte pas les seuils.
Le regroupement a sa logique : la plupart des pages d’un site n’ont pas assez de trafic pour avoir des données propres, alors que les pages construites sur le même modèle ont tendance à se comporter de façon similaire. En pratique, les groupes correspondent souvent aux modèles de page : fiches produit, articles, catégories, pages institutionnelles. Quand on ouvre un problème signalé, le rapport affiche quelques URL d’exemple avec la valeur du groupe ; c’est par là qu’il faut commencer pour comprendre quel modèle de page est concerné.
Le statut global d’un groupe, donc de ses URL, est déterminé par la pire métrique. Un groupe avec un bon LCP et un bon CLS mais un INP à améliorer est « à améliorer ». C’est pourquoi, dans le rapport, une même URL peut apparaître dans plusieurs problèmes, un pour chaque métrique hors seuil, mais n’est comptée qu’une seule fois dans le total, avec le pire statut.
Lire les comptages
Le graphique principal montre, jour après jour, le nombre d’URL dans chaque statut. Deux précisions évitent de nombreuses mauvaises interprétations. La première : les URL comptées ne sont pas toutes les pages du site, mais seulement celles pour lesquelles des données existent, directement ou par le groupe. Un site de dix mille pages peut n’en afficher que quelques centaines, et le nombre peut changer sans que rien n’ait changé sur le site, simplement parce que le trafic change et, avec lui, la disponibilité des données.
La seconde : le nombre d’URL n’indique pas l’importance d’un problème. Un groupe de quatre mille fiches produit rarement visitées pèse sur le graphique bien plus qu’une page d’accueil comptant des milliers de visites par jour, mais celle-ci peut compter beaucoup plus pour l’activité. Le comptage doit toujours se lire avec le trafic des pages concernées, que l’on trouve dans le rapport sur les performances de la Search Console elle-même ou dans son outil d’analytics.
Les sauts soudains du graphique, dans un sens comme dans l’autre, ont souvent des causes extérieures au site. Google peut recalculer les groupes, et des URL auparavant jugées similaires peuvent être séparées ou fusionnées. Le passage du FID à l’INP en mars 2024 a fait basculer de nombreux sites de « bon » à « à améliorer » sans aucun changement, parce que la nouvelle métrique est plus exigeante. Et une variation du trafic, comme des visiteurs arrivant d’une campagne avec des appareils ou des connexions différents, peut déplacer le 75e percentile même si les pages n’ont pas changé.
Pourquoi cela ne correspond pas à PageSpeed Insights
L’une des questions les plus fréquentes concerne les écarts avec PageSpeed Insights. La partie haute de PageSpeed Insights affiche elle aussi des données de terrain du Chrome UX Report, mais pour l’URL individuelle quand elle a assez de trafic, et pour toute l’origine sinon. La Search Console affiche en revanche la valeur du groupe. Trois niveaux différents, URL, groupe et origine, peuvent donner trois valeurs différentes, toutes correctes. La partie basse de PageSpeed Insights, le test Lighthouse, est un test de laboratoire et ne joue aucun rôle dans le rapport, comme l’explique l’article sur les différences entre PageSpeed Insights et Lighthouse.
Valider les corrections
Après avoir corrigé un problème, la Search Console permet de lancer la validation. Le bouton n’accélère pas la mise à jour des données : il démarre une période de surveillance de 28 jours pendant laquelle Google vérifie si les URL du groupe respectent les seuils. Si le groupe est dans le statut « bon » à la fin, la validation est réussie ; sinon elle échoue, et doit être relancée.
Le retard est inhérent à la manière dont les données sont calculées. Le lendemain d’une correction, 27 des 28 jours de la fenêtre contiennent encore les expériences antérieures. La valeur du rapport s’améliore progressivement, et ne franchit le seuil que lorsqu’il y a assez de données nouvelles pour déplacer le 75e percentile. À cela s’ajoutent quelques jours de délai de traitement. En pratique, entre une correction efficace et sa pleine répercussion dans le rapport, il s’écoule souvent de trois à six semaines.
Pour ne pas rester dans le noir pendant cette période, il vaut la peine de suivre les effets avec des outils plus réactifs : le Real User Monitoring, qui montre les données jour par jour, ou les séries hebdomadaires de la CrUX History API, qui permettent de voir la tendance à une granularité plus fine. Quand le rapport se met enfin à jour, il ne devrait que confirmer ce que ces données montraient déjà.
Les pages sans données
Un site récent, ou à faible trafic, peut afficher un rapport vide, ou avec des données pour une seule des deux sections. Cela ne signifie pas que la performance est bonne ou mauvaise, seulement qu’il n’y a pas assez de visites depuis Chrome pour calculer des statistiques fiables. Dans ces cas, les Core Web Vitals ne sont pas utilisés comme signal pour ces pages, et le moyen le plus utile de les évaluer reste les tests de laboratoire et, si le trafic le permet, un système de mesure propre.
Utiliser le rapport pour décider
Lu de la bonne façon, le rapport est un outil pour fixer des priorités plus que pour établir un diagnostic. Une méthode pratique suit quelques étapes.
- Commencer par le mobile. C’est là que se concentre la plupart des problèmes et, pour beaucoup de sites, la plus grande partie du trafic.
- Identifier les groupes. Pour chaque problème, ouvrir les URL d’exemple et comprendre à quel modèle de page elles correspondent.
- Pondérer par le trafic. Donner la priorité aux groupes qui reçoivent le plus de visites organiques ou qui comptent le plus pour les conversions.
- Diagnostiquer ailleurs. Utiliser PageSpeed Insights et les DevTools sur quelques URL représentatives du groupe pour trouver la cause, et le RUM, s’il est disponible, pour l’attribution.
- Annoter et valider. Noter la date de chaque modification, lancer la validation et suivre la tendance avec des outils plus rapides au cours des semaines suivantes.
Noter les dates est un détail qui fait gagner beaucoup de temps. La Search Console n’enregistre pas les mises en production du site, et des semaines plus tard, il est difficile de se rappeler ce qui a changé et quand. Un simple journal avec la date, les pages concernées et le type de modification permet de relier chaque variation du graphique à sa cause, et de distinguer les effets de ses propres changements de ceux de facteurs externes.
Un exemple de lecture
Imaginons une boutique en ligne qui reçoit une alerte : sur mobile, plus de quatre mille URL sont passées au statut « médiocre » pour le LCP. À première vue, cela ressemble à un désastre. En ouvrant le problème, les URL d’exemple sont toutes des fiches produit, et la valeur du groupe est de 3,4 secondes. Le rapport sur les performances montre cependant que ces pages, prises une à une, reçoivent peu de trafic organique, alors que les catégories, qui apportent la plus grande partie des visites depuis Google, sont dans le statut « bon ».
Le problème est réel, car les fiches produit sont l’endroit où l’achat se décide, mais son urgence doit être relativisée par rapport à l’alarme initiale. Un test sur quelques fiches produit représentatives montre que l’image principale est chargée en lazy loading par un plugin d’optimisation récemment mis à jour : la date de la dégradation coïncide avec celle de la mise à jour. Une fois le réglage corrigé, le RUM montre un LCP mobile de 2,1 secondes dès le lendemain ; le rapport de la Search Console fera repasser le groupe au statut « bon » au bout de quatre semaines environ, et la validation se clôturera en conséquence.
Exporter et intégrer les données
Le rapport permet d’exporter les données du graphique et les listes d’URL d’exemple, utiles pour archiver la situation avant et après une modification. Pour une analyse plus poussée, les mêmes données sources sont disponibles via la CrUX API, qui renvoie des valeurs par URL ou par origine, et la CrUX History API, qui fournit des séries hebdomadaires couvrant plusieurs mois. Avec des outils de visualisation comme Looker Studio, on peut construire des tableaux de bord qui réunissent les données CrUX, le trafic organique et les conversions : une vue unique qui facilite beaucoup l’explication aux décideurs de ce qui justifie le coût d’un projet de performance.
Les e-mails d’alerte
La Search Console envoie un e-mail quand elle détecte un nouveau problème ou une augmentation du nombre d’URL dans un statut moins bon. Ces alertes sont utiles, mais il faut les recevoir sans affolement. Le rapport n’est pas un système de pénalités : il signale une situation qui, comme l’explique l’article sur les Core Web Vitals et le SEO, pèse sur le classement surtout à pertinence égale. Avant d’agir, il vaut la peine de vérifier si la dégradation touche des pages importantes, si elle coïncide avec une mise en production ou une variation du trafic, et si d’autres données la confirment.
En bref
Le rapport Core Web Vitals de la Search Console présente les données de terrain du Chrome UX Report, au 75e percentile sur 28 jours, séparées entre mobile et ordinateur et organisées en groupes d’URL similaires. Chaque URL hérite du statut du groupe, et le statut est celui de la pire métrique. Les comptages ne couvrent que les pages disposant de données et n’indiquent pas l’importance des problèmes, qui doit être jugée avec le trafic.
Les corrections apparaissent avec des semaines de retard, parce que la fenêtre de 28 jours doit se renouveler ; la validation lance une période de surveillance, pas une mise à jour immédiate. Utilisé comme outil de priorisation, avec les tests de laboratoire pour le diagnostic et des données plus réactives pour vérifier les modifications, c’est le moyen le plus direct de savoir comment Google voit l’expérience qu’offre votre site.
