Un paradoxe circule parmi ceux qui travaillent sur la performance web. D’un côté, on reconnaît à juste titre que ce sont les données d’utilisateurs réels qui comptent. De l’autre, on en tire souvent une conclusion hâtive : si seules les données réelles comptent, les tests de laboratoire peuvent être ignorés. Si le Chrome UX Report est vert, qu’importe que Lighthouse signale un LCP lent, un Total Blocking Time élevé ou un score médiocre ?
Cela importe, et beaucoup. CrUX et les données de laboratoire, que par commodité nous appellerons LABS, ne mesurent pas la même chose et, surtout, ne servent pas au même usage. Les premières disent ce qui est arrivé aux utilisateurs qui ont visité le site. Les secondes montrent comment la page se comporte dans des conditions contrôlées, reproductibles et, si l’on veut, plus dures que d’habitude. Renoncer à l’une des deux, c’est travailler avec la moitié de l’information.
Le faux mythe : CrUX au vert, site rapide
Le raisonnement est bien connu : Google évalue les Core Web Vitals avec des données réelles, donc le seul objectif est de réussir l’évaluation CrUX, et la section de laboratoire de PageSpeed Insights devient un détail. Le problème, c’est que l’on confond deux questions différentes : ce qui s’est passé, et ce qui pourrait se passer.
CrUX collecte les expériences réelles des utilisateurs Chrome éligibles et les agrège par URL ou par origine. Il ne calcule pas une moyenne, mais évalue le 75e percentile : une métrique est « bonne » si au moins trois expériences sur quatre respectent le seuil. Les seuils actuels sont de 2,5 secondes pour le LCP, de 200 millisecondes pour l’INP et de 0,1 pour le CLS. Le percentile limite l’effet des cas extrêmes et est bien plus significatif qu’une moyenne, mais, précisément parce qu’il décrit une distribution, il ne garantit pas que chaque utilisateur navigue rapidement : il dit seulement que la majorité le fait.
Qui mesurez-vous vraiment
Prenez un site dont le public vient en grande partie des grandes villes, avec des smartphones récents connectés en fibre, en Wi-Fi rapide ou en 5G à faible latence. C’est cette population qui domine les expériences collectées par CrUX. Si neuf utilisateurs sur dix naviguent dans des conditions favorables, la page peut obtenir d’excellentes valeurs même si, en valeur absolue, elle est tout sauf légère.
Ouvrez maintenant le même site depuis une zone à faible couverture mobile, sur un réseau 4G saturé et avec un smartphone milieu de gamme. Une image principale de 800 Ko, quatre polices provenant de domaines externes, 700 Ko de JavaScript, un script publicitaire, le bandeau de consentement et quelques widgets tiers étaient presque invisibles en fibre ; ici, ils se transforment en secondes d’attente. Le site n’est pas devenu plus lourd : il l’était déjà. C’est le réseau et les appareils du public habituel qui amortissaient le poids.
La géographie n’est que l’exemple le plus intuitif. L’appareil, la puissance du processeur, le type de réseau, la latence, le cache du navigateur, le comportement du visiteur et bien d’autres facteurs comptent tous. Une partie du public, de plus, n’apparaît pas du tout dans les données : Chrome sur iPhone et les autres navigateurs ne contribuent pas à CrUX.
CrUX décrit correctement le public que vous avez aujourd’hui. Pas tous les utilisateurs que vous pourriez avoir demain.
Ce que les données de terrain disent, et ce qu’elles ne disent pas
Les données CrUX sont représentatives des expériences effectivement collectées pour ce site, pas de toutes les conditions de navigation possibles. Et c’est normal : le rôle des données de terrain est de dire le monde réel. L’erreur apparaît quand on transforme cette caractéristique en conclusion absolue. « CrUX est vert, donc le site est rapide » est une affirmation différente de la bonne : « au moins 75 % des expériences collectées au cours des 28 derniers jours respectent aujourd’hui les seuils de la catégorie bon ».
Il y a ensuite le facteur temps. Les données de PageSpeed Insights couvrent une fenêtre glissante de 28 jours : une modification qui dégrade la page aujourd’hui apparaît immédiatement dans un test de laboratoire, alors que dans les données réelles elle émerge progressivement, à mesure que les nouvelles expériences remplacent les anciennes. Ce n’est pas un défaut de CrUX, mais la conséquence naturelle d’une mesure agrégée dans le temps.
À quoi servent les données de laboratoire
Le laboratoire répond à une autre question. Non pas « comment nos visiteurs ont-ils navigué ? », mais « comment cette page se comporte-t-elle si l’on retire les variables externes et qu’on la soumet à un scénario reproductible ? ». Lighthouse, le même moteur que PageSpeed Insights utilise pour la section de laboratoire, charge la page avec un appareil, un réseau et un processeur simulés et décompose le chargement.
C’est ainsi qu’émergent des problèmes difficiles à voir dans les données agrégées : ressources qui bloquent le rendu, JavaScript excessif, tâches longues sur le thread principal, images surdimensionnées, chaîne de requêtes trop longue avant l’élément LCP, CSS inutilisé, scripts tiers. Et le laboratoire a un avantage que les données réelles ne peuvent pas offrir : la répétabilité. Avant et après une modification, on peut comparer des conditions équivalentes, en quelques minutes.
Dire que les données de laboratoire sont « fausses » parce qu’elles sont synthétiques est une erreur de perspective. Un crash test ne reproduit pas tous les accidents possibles, mais personne ne le juge inutile : il place le véhicule dans une condition connue et observe comment il réagit. De la même façon, un site qui garde un LCP bas, un JavaScript léger et un thread principal libre, même dans des conditions plus dures que celles de son public habituel, a quelque chose en plus.
La marge de performance
Ce quelque chose en plus, c’est la marge. Imaginez deux sites avec le même LCP de 2 secondes dans les données réelles. Le premier est bien construit : HTML généré rapidement, cache efficace, images compressées, peu de ressources critiques, peu de JavaScript, un serveur qui répond en quelques millisecondes. Le second atteint les 2 secondes surtout parce que son public utilise du matériel récent et des connexions très rapides, alors que la page pèse plusieurs mégaoctets et embarque beaucoup de JavaScript.
En ne regardant que CrUX, ils semblent équivalents. Du point de vue de l’ingénierie de la performance, ils ne le sont pas du tout : le premier continue de bien fonctionner quand les conditions se dégradent, le second se dégrade vite dès que la latence, la congestion du réseau ou la charge du processeur augmentent. Le laboratoire est l’outil qui rend cette différence visible.
LABS au rouge et CrUX au vert
C’est la situation qui suscite le plus de débats : le site réussit les Core Web Vitals sur le terrain, mais Lighthouse signale des performances médiocres. Faut-il agir sur chaque avertissement ? Non, et certainement pas en courant après le 100 : le score n’est pas un objectif en soi. Mais ignorer le rapport serait tout aussi faux. Un laboratoire nettement négatif indique souvent un site avec peu de marge, dont les bonnes performances dans le monde réel dépendent en partie des conditions favorables du public. Si le test montre 2 Mo de JavaScript, des images énormes ou un LCP qui arrive après une longue chaîne de requêtes, le fait que les utilisateurs d’aujourd’hui parviennent à compenser ne transforme pas ces problèmes en bonnes pratiques.
LABS au vert et CrUX au rouge
L’inverse se produit aussi : Lighthouse est excellent, mais les données réelles montrent un LCP, un INP ou un CLS insuffisant. Le laboratoire dit que, dans le scénario de test, la page se comporte bien ; CrUX dit que, dans le monde réel, quelque chose ne va pas. Des facteurs entrent en jeu qu’un seul chargement synthétique ne représente pas : interactions successives, contenus personnalisés, bandeaux de consentement, publicité, scripts chargés seulement dans certaines conditions, appareils très lents. L’INP, en particulier, dépend d’interactions réelles, qu’un test automatisé n’effectue pas : c’est pourquoi des techniques comme retarder le JavaScript jusqu’au premier clic peuvent améliorer le laboratoire et dégrader le terrain. Et il ne faut pas oublier qu’il existe des configurations capables de servir au test une page différente de celle que reçoivent les utilisateurs. Dans ces cas, CrUX est le point de départ : il indique le problème que le laboratoire devra reproduire et expliquer.
Le flux de travail : CrUX, LABS, modification, CrUX
Se demander lequel des deux jeux de données est « le bon » est une mauvaise question : les deux le sont, car ils répondent à des questions différentes. Un processus d’optimisation sensé utilise les données de terrain pour identifier les problèmes et en mesurer l’impact, et le laboratoire pour en comprendre les causes.
- Observer les données CrUX pour comprendre comment les utilisateurs naviguent réellement et quelles pages et quelles métriques sont critiques.
- Analyser les pages en laboratoire, en essayant de reproduire les conditions problématiques.
- Identifier le goulot d’étranglement technique dans le waterfall, dans le thread principal ou sur le serveur.
- Appliquer la modification.
- Vérifier tout de suite en laboratoire qu’aucune régression n’a été introduite.
- Surveiller les données réelles dans les semaines suivantes pour mesurer l’effet sur les utilisateurs.
C’est une approche bien plus rationnelle que d’attendre passivement que la case des données réelles passe au vert ou de courir compulsivement après le 100 de Lighthouse sans se demander si les utilisateurs percevront vraiment la différence.
N’oubliez pas le serveur
Les bonnes performances viennent de toute la pile, pas seulement du front-end. Le navigateur ne peut pas construire une page que le serveur n’a pas encore commencé à envoyer : requêtes lentes, PHP surchargé, absence de cache de page, cache d’objets mal configuré ou ressources sous-dimensionnées allongent le temps de réponse. Le TTFB n’est pas un Core Web Vital, mais il se propage à toute la chaîne de chargement et pèse surtout sur le LCP. Avec des utilisateurs proches du data center et bien connectés, certaines de ces inefficacités restent cachées ; des tests contrôlés, avec des waterfalls et des conditions réseau différentes, permettent de séparer les responsabilités du back-end de celles du front-end.
Quand le public change soudainement
Un dernier aspect montre combien il est risqué de se fier uniquement aux conditions moyennes de son public : la composition du trafic peut changer rapidement. Une campagne internationale, un contenu qui devient viral, la croissance sur un nouveau marché amènent des utilisateurs plus éloignés du serveur, avec des réseaux plus lents et des appareils moins puissants. En théorie, le même effet pourrait être provoqué volontairement, en achetant du trafic bon marché dans des zones à la connectivité moins bonne pour nuire aux données d’un concurrent. Rien ne garantit qu’une telle opération fonctionnerait, et les Core Web Vitals ne sont qu’un des nombreux signaux que Google utilise, mais le scénario aide à illustrer le propos.
CrUX n’utilise pas toutes les visites et ne calcule pas de moyenne : il ne considère que les utilisateurs éligibles et évalue le 75e percentile. Il n’existe donc pas de règle du type « tant de visites lentes coûtent tant de points ». Mais si une part suffisante de nouvelles expériences, plus lentes, entre dans l’échantillon, la distribution change. Un site qui a déjà peu de marge en laboratoire, avec un LCP proche du seuil, des centaines de requêtes et des images lourdes, dépasse vite les limites dès que les conditions favorables disparaissent. Un site optimisé aussi pour les scénarios difficiles dispose au contraire d’une réserve : quelques centaines de millisecondes de latence en plus ne le font pas sortir des seuils. Prendre soin des données de laboratoire devient ainsi une forme de durcissement, non pas contre un algorithme, mais contre l’idée d’un site rapide seulement tant que rien ne change.
En résumé
Il ne faut pas choisir entre CrUX et LABS, mais en connaître les limites et les avantages. CrUX dit ce qui est arrivé aux utilisateurs réels, sur les réseaux et les appareils qu’ils ont effectivement utilisés : c’est la référence pour l’évaluation des Core Web Vitals. Le laboratoire permet de créer des conditions contrôlées, de comparer avant et après, de trouver les goulots d’étranglement et de mesurer la marge d’une page. Si votre public navigue presque uniquement en fibre et avec des smartphones de dernière génération, CrUX peut être excellent même avec des inefficacités importantes : il n’a pas tort, il décrit le public d’aujourd’hui. Le laboratoire aide à comprendre ce qui se passera demain, ou ce qui arrive déjà aux utilisateurs moins bien lotis.
Et puis il y a le test le plus simple de tous : utiliser le site comme les gens l’utilisent. Ouvrez-le sur votre smartphone dans un café bondé, dans un immeuble mal couvert, en vacances là où le signal va et vient. C’est là qu’apparaissent les images qui arrivent en retard, les éléments qui bougent et les boutons qui ne répondent pas. Le throttling réseau dans DevTools reste précieux, mais il ne remplace pas l’expérience directe : si le site vous semble lent, en conditions réelles, il l’est aussi pour une partie de vos utilisateurs. Un site vraiment rapide n’est pas celui qui affiche trois indicateurs verts aujourd’hui, mais celui qui reste rapide quand le réseau ralentit, que l’appareil est moins puissant et que le public change.
