La mise en production s’est bien passée : le laboratoire confirme un LCP divisé par deux, le monitoring interne montre des pages beaucoup plus rapides. Et pourtant, le lendemain, PageSpeed Insights affiche toujours dans la section des utilisateurs réels les mêmes chiffres rouges que la semaine précédente. Ce n’est pas un bug et cela ne veut pas dire que la modification n’a pas fonctionné : c’est l’effet de la fenêtre de 28 jours sur laquelle le Chrome UX Report agrège les données des utilisateurs. Comprendre son fonctionnement évite les mauvaises décisions, les attentes irréalistes et plus d’une discussion inutile avec les clients et les collègues.
Ce qu’est le Chrome UX Report
Le Chrome UX Report, CrUX pour tout le monde, est le jeu de données public que Google utilise pour collecter la performance vécue par les utilisateurs réels de Chrome. Y contribuent les navigateurs des personnes qui ont activé la synchronisation de l’historique et l’envoi des statistiques d’utilisation, sur ordinateur et sur Android. Les données sont agrégées par origine, c’est-à-dire pour l’ensemble du site, et par URL individuelle lorsque la page a assez de trafic, en distinguant les appareils mobiles, ordinateurs et tablettes.
Pour chaque métrique, comme le LCP, l’INP, le CLS ou le TTFB, CrUX fournit la distribution des expériences et la valeur au 75e percentile : une page réussit l’évaluation seulement si au moins trois visites sur quatre respectent le seuil « bon ». Ce sont les données qui apparaissent dans la section « Découvrez l’expérience de vos utilisateurs réels » de PageSpeed Insights et dans le rapport Core Web Vitals de la Search Console, et que Google utilise comme signal d’expérience de page.
Deux limites sont à garder à l’esprit dès le départ. La première : tous les utilisateurs ne sont pas représentés. Chrome sur iOS ne contribue pas, les autres navigateurs non plus : le public iPhone d’un site e-commerce de mode ou d’un éditeur de presse est donc en pratique absent de l’échantillon. La seconde : en dessous d’un certain seuil de trafic, CrUX ne publie pas de données pour l’URL, et PageSpeed Insights se rabat sur les valeurs de l’ensemble de l’origine ou indique que les données sont insuffisantes.
Comment fonctionne la fenêtre glissante
Les données CrUX affichées par PageSpeed Insights et renvoyées par l’API CrUX ne décrivent pas une seule journée, mais les 28 derniers jours. Chaque jour, la fenêtre avance : le jour le plus récent entre, celui d’il y a quatre semaines sort, et les percentiles et les distributions sont recalculés sur l’ensemble. C’est une moyenne mobile et, comme toutes les moyennes mobiles, elle a une force et une faiblesse.
La force, c’est la stabilité : un pic de trafic lent sur une seule journée, un problème temporaire chez un fournisseur externe ou un week-end avec un public différent ne bouleversent pas l’évaluation. La faiblesse, c’est l’inertie : toute modification, en bien ou en mal, met des semaines à apparaître pleinement.
Il existe d’autres vues des mêmes données, avec des délais différents. Le jeu de données publié sur BigQuery est mensuel et couvre le mois civil précédent. L’API CrUX History renvoie en revanche une série temporelle de fenêtres de 28 jours échantillonnées chaque semaine, utile pour observer la tendance dans le temps. La Search Console, enfin, utilise les mêmes données en regroupant les URL similaires.
Le niveau auquel on lit les données compte aussi. La valeur de l’origine additionne toutes les pages du site en proportion de leur trafic : sur un site e-commerce, elle sera dominée par la page d’accueil, les catégories et les fiches produit, sur un éditeur de presse par les articles du jour. Une modification sur un modèle de page peu visité peut donc améliorer beaucoup l’URL individuelle et à peine faire bouger le chiffre global. À l’inverse, un ralentissement du seul modèle de page le plus visité déplace toute l’origine. Avant de juger un résultat, il vaut toujours la peine de se demander quelle part du trafic cette modification a réellement touchée.
Pourquoi les améliorations arrivent progressivement
Imaginez une modification qui fait passer le LCP des visites mobiles de 3,8 à 2,0 secondes au 75e percentile, mise en production en une seule journée avec un trafic constant. Le lendemain de la mise en ligne, la fenêtre ne contient qu’un jour « nouveau » et vingt-sept « anciens ». Au bout d’une semaine, le rapport est d’un quart pour trois quarts. Ce n’est qu’au vingt-huitième jour que la fenêtre contient exclusivement des visites postérieures à la modification.
Le 75e percentile d’une distribution mixte ne baisse pas de façon intuitive. Avec des distributions réalistes, l’évolution ressemble à ceci :
| Jours depuis la mise en ligne | Nouvelles visites dans la fenêtre | LCP p75 affiché |
|---|---|---|
| 0 | 0 % | 3,8 s |
| 7 | 25 % | 3,4 s |
| 14 | 50 % | 3,0 s |
| 21 | 75 % | 2,4 s |
| 28 | 100 % | 2,0 s |
La donnée la plus importante est dans la troisième colonne : le seuil « bon » de 2,5 secondes n’est franchi que vers la troisième semaine, alors que dès le premier jour chaque visite est déjà rapide. Pendant deux bonnes semaines, le rapport continuera d’afficher une page « à améliorer ». Qui ne connaît pas le mécanisme risque de conclure que la modification n’a eu aucun effet, de chercher des causes inexistantes ou, pire, d’annuler une modification correcte.
Les régressions suivent la même règle
L’inertie joue dans les deux sens, et c’est là que la fenêtre devient dangereuse. Un nouveau plugin, un script marketing ajouté à la hâte ou une mise à jour du thème qui dégrade l’INP n’apparaît pas dans les données CrUX le lendemain. L’évaluation reste verte pendant des jours alors qu’une part croissante des utilisateurs vit un site plus lent. Quand la régression devient évidente dans le rapport, le problème est en production depuis deux ou trois semaines, et sa correction demandera encore quatre semaines pour être pleinement visible.
En termes business, cela représente jusqu’à deux mois pendant lesquels les conversions et la visibilité peuvent être pénalisées par un problème né en un seul après-midi. C’est pourquoi CrUX ne peut pas être le seul outil de contrôle : c’est le juge final, mais il arrive toujours en retard.
Quand les chiffres changent sans toucher au code
Il y a un autre effet qui surprend souvent : les valeurs CrUX peuvent se dégrader ou s’améliorer sans aucune mise en production. La raison est que la fenêtre mesure les expériences du public réel, et que le public change. Une campagne sur les réseaux sociaux qui amène beaucoup de visites depuis des smartphones d’entrée de gamme, une période de soldes avec des pics de charge sur le serveur, du trafic en provenance d’un pays éloigné du data center ou une saisonnalité particulière modifient toutes la distribution, même si le site reste le même.
Lire les données sans connaître le calendrier commercial conduit à de fausses conclusions. Un LCP qui se dégrade en même temps qu’une campagne auprès d’un nouveau public n’est pas forcément un problème technique ; une amélioration pendant un mois de trafic surtout desktop n’est pas forcément due à une modification que vous avez faite.
Search Console et validation de la correction
Le rapport Core Web Vitals de la Search Console hérite de la même logique. Il regroupe les URL aux expériences similaires et attribue à chaque groupe le statut « bon », « à améliorer » ou « médiocre ». Quand vous corrigez un problème, vous pouvez lancer la validation de la correction : à partir de ce moment, la Search Console observe les données pendant 28 jours et ne confirme, ou ne rejette, la résolution qu’à la fin.
Le conseil pratique est de ne lancer la validation que lorsque la correction est vraiment terminée et vérifiée, car une nouvelle mise en production pendant la période d’observation peut remettre le résultat en question. Et, dans l’intervalle, il faut éviter d’interpréter comme un échec les semaines où le statut reste inchangé.
Comment travailler avec la fenêtre, et non contre elle
La fenêtre de 28 jours n’est pas un obstacle à contourner, mais une contrainte dont il faut tenir compte dans la façon de travailler. En pratique, nous utilisons trois niveaux d’observation, chacun avec son temps de réponse :
- Le laboratoire, avant la mise en production. Lighthouse et les tests synthétiques vérifient en quelques minutes que la modification produit l’effet attendu et n’introduit pas de régressions évidentes. Ils ne disent rien des utilisateurs réels, mais c’est le filtre le plus rapide.
- Le monitoring des utilisateurs réels, dès le jour même. Un système de RUM, même basé sur la bibliothèque open source
web-vitals, collecte les métriques dans les navigateurs des visiteurs, y compris ceux que CrUX ne voit pas, et permet de comparer les visites avant et après une mise en production dès les premières heures. C’est le niveau qui détecte les régressions avant qu’elles ne deviennent un problème pour l’entreprise. - CrUX, comme vérification finale. Les données officielles confirment le résultat une fois la fenêtre renouvelée. L’API CrUX History permet de suivre la tendance semaine après semaine et de comparer des fenêtres équivalentes, sans s’appuyer sur une seule lecture de PageSpeed Insights.
À ces trois niveaux, nous ajoutons une habitude simple mais précieuse : noter les dates de chaque mise en production, de chaque nouveau script tiers et des principales campagnes. Quand une courbe change de pente, savoir ce qui s’est passé trois semaines plus tôt fait gagner des heures d’investigation.
Comment l’expliquer aux décideurs
Une bonne part des frictions dans les projets de performance vient d’une attente erronée : « nous avons livré, alors pourquoi PageSpeed est-il encore rouge ? ». Clarifier à l’avance le calendrier de la fenêtre transforme un moment de tension en une étape attendue du projet. Dans nos plans de travail, nous indiquons toujours trois dates : la mise en production, les premiers retours sur les données RUM et, au moins quatre semaines plus tard, la date à laquelle nous présenterons la comparaison officielle sur CrUX.
Il en va de même pour les résultats : une comparaison correcte place côte à côte deux fenêtres complètes, l’une entièrement avant et l’autre entièrement après la modification, sur le même type d’appareil. Comparer une capture de PageSpeed Insights de la veille avec celle du lendemain, dans un sens comme dans l’autre, ne prouve rien.
En résumé
Les données de terrain CrUX sont la mesure la plus fiable de l’expérience réelle, mais elles décrivent toujours les 28 derniers jours. Une amélioration n’apparaît pleinement qu’au bout de quatre semaines et franchit souvent le seuil vers la troisième ; une régression reste cachée pendant des jours et pèse sur les résultats pendant des semaines. Le public, en outre, change même quand le code ne change pas, et certains utilisateurs, à commencer par ceux sur iPhone, n’apparaissent pas du tout.
Bien travailler avec cette fenêtre, c’est combiner le laboratoire, le monitoring des utilisateurs réels et CrUX, chacun avec son rôle, et donner aux décideurs des attentes claires sur les délais. Le résultat arrive bel et bien : il suffit de savoir quand le regarder.
