Mesurer : terrain, laboratoire, 75ᵉ percentile, budget

Mesurer : laboratoire, terrain, et pourquoi la moyenne trompe

1. Laboratoire contre terrain : deux questions différentes

   La distinction est la première chose à installer, parce qu'elle change tout le reste. Tout le monde prend le même chiffre et le prend pour la même chose.

   La mesure de laboratoire : « est-ce que ça pourrait être lent ? »

   Un environnement simulé, souvent sur un ordinateur puissant, avec un réseau dégradé artificiel. C'est un excellent outil de diagnostic : il montre quelles ressources sont lentes, quelles tâches bloquent, ce qui décale la mise en page. Il est reproductible, donc deux mesures successives sont comparables.

   Ce qu'il ne dit pas : ce que vivent vos utilisateurs. Un score de 100 sur un simulateur peut correspondre à un INP médiocre sur un téléphone d'entrée de gamme en 4G.

   La mesure de terrain : « qu'est-ce qu'ils vivent vraiment ? »

   Les rapports Core Web Vitals de Search Console agrègent des mesures réalisées par les navigateurs eux-mêmes, sur des appareils et des connexions réels, dans une fenêtre glissante de 28 jours. C'est la donnée que Google utilise, et la seule qui décide.

   Le problème de la fenêtre de 28 jours

   Une correction publiée hier n'apparaît pas dans les chiffres avant plusieurs semaines. Et une correction ancienne reste dans la fenêtre pendant un mois après être revenue en arrière. Conséquence pratique : une donnée de terrain ne se lit pas au jour le jour, et deux équipes qui regardent le même rapport le même jour peuvent en tirer des conclusions opposées selon ce qu'elles ont changé la veille.

   La règle du seuil minimal de données

   Search Console n'affiche un groupe d'URL que s'il dispose d'un nombre suffisant de données. À défaut, le groupe est omis du rapport. Le piège : une page disproportionnellement populaire aura toujours des données, tandis qu'un template secondaire peut n'en avoir pas assez pour apparaître — et l'absence dans le rapport n'est pas un bon résultat, c'est une absence de mesure.

2. Le 75ᵉ percentile, et pourquoi la moyenne est un piège

   Google évalue une page au 75ᵉ percentile : la valeur telle qu'elle est vécue par 75 % des visites. Ce n'est pas un détail technique, c'est une décision de conception du produit, et elle change tout.

   Ce que le P75 dit sur l'utilisateur

   Il dit : « votre page est bonne pour 75 % de vos visiteurs ». Le quart restant vit une expérience médiocre. La question de gestion est alors : acceptez-vous de laisser un quart de vos utilisateurs subir une page lente ? Selon le produit, la réponse est non — et le P75 est précisément l'indicateur qui rend cette question visible.

   Ce que la moyenne cache

   Un site dont 80 % des visites sont immédiates et 20 % tardives peut avoir une moyenne flatteuse tout en étant catastrophique pour une part réelle de ses utilisateurs. Pire : sur les pages de catalogue, la moyenne est dominée par le trafic des robots, qui est rapide et n'a aucun problème. Les tableaux de performance « agrégés » sont donc souvent des mensonges — ils décrivent des robots, pas des gens.

   Les deux découpages obligatoires

   1. Mobile et desktop séparément. Un même groupe d'URL peut être « bon » sur mobile et « mauvais » sur desktop. Sur un site à trafic majoritairement mobile, un rapport agrégé masque le problème principal.
   2. Par groupe d'URL, pas page par page. Toutes les pages qui partagent un gabarit partagent une évaluation. C'est utile : corriger un gabarit corrige dix mille pages.

   La conséquence sur les rapports internes

   Si votre propre outil d'analyse affiche une moyenne, il affiche autre chose que ce que Google utilise. Le module d'outil n'a pas à être remplacé — il a à être lu avec ses limites, et à être complété par le rapport officiel pour les trois métriques.

3. Les quatre outils, et lequel pour quelle question

   Outil	Données	La question à laquelle il répond
   Search Console	Terrain	Ce que vivent mes utilisateurs, par groupe d'URL et par appareil
   PageSpeed Insights	Terrain si disponible, sinon laboratoire	Quel est l'état de cette URL précise, et le diagnostic associé
   Lighthouse	Laboratoire	Qu'est-ce qui bloque sur cette page, maintenant
   DevTools	Laboratoire, local	Quel élément est le LCP, quelles tâches bloquent, ce qui décale

   Le piège du score unique

   Lighthouse affiche un score global de performance. Ce score n'a aucune signification officielle : il n'entre dans aucun critère de classement, et il est calculé sur une simulation qui ne représente pas vos utilisateurs. Utiliser ce score comme objectif, c'est optimiser la mauvaise métrique — on peut obtenir 100 en laboratory tout en échouant en terrain.

   La documentation le formule implicitement en ne retenant que les trois métriques comme signals de qualité d'expérience. Le reste du rapport est utile comme diagnostic.

   L'attribution, qui est le vrai outil de travail

   Savoir que l'INP est à 400 ms ne sert à rien en soi. L'outil d'attribution indique quelle interaction est responsable, et à quel moment : pendant le chargement ou après, quel type (clic, frappe, toucher). C'est cette information qui transforme une mesure en décision.

   Sans attribution, on optimise au hasard — et le résultat le plus fréquent est de corriger un problème qui n'était pas le pire.

   La séquence de travail

   1. Terrain d'abord : quelle métrique échoue, sur quel groupe d'URL, sur quel appareil.
   2. Attribution : quelle interaction ou quel élément est responsable.
   3. Labo ensuite : DevTools pour comprendre pourquoi.
   4. Une correction, puis retour au terrain.

   Commencer par le laboratoire sans données de terrain est l'erreur de méthode la plus fréquente : on optimise ce qui est facile à mesurer plutôt que ce qui est subi.

4. Budget de performance : décider avant de mesurer

   Un budget de performance est un engagement écrit : « le JavaScript de ce gabarit ne dépassera pas X Ko », « le LCP de la page d'accueil restera sous 2,5 s au 75ᵉ percentile ». Sans cela, chaque livraison ajoute quelques kilo-octets et quelques dizaines de millisecondes, et personne ne s'en aperçoit.

   Les trois formes utiles

   • Par gabarit, pas par page. Un budget par page est impossible à tenir dès qu'on a des dizaines de gabarits. Un budget par gabarit est vérifiable.
   • Sur les poids et les temps, pas sur un score. « 200 Ko de JavaScript » et « LCP < 2,5 s » sont vérifiables ; « score > 90 » ne l'est pas.
   • Plafonné par une alerte, pas bloquant. Une alerte qui prévient l'équipe est utilisable ; un blocage permanent de déploiement est contourné en trois semaines.

   Où le placer pour qu'il tienne

   Le budget ne tient que s'il est vérifié automatiquement et qu'il est visible au moment de la revue. Trois emplacements, du plus simple :

   1. Dans la chaîne de build — le paquet est mesuré à chaque build, l'échec est visible immédiatement.
   2. Dans un test automatisé — un test lit le poids des fichiers générés et échoue au-delà du seuil.
   3. Dans le suivi de production — un rapport périodique compare le réel au prévu.

   Le troisième est le plus utile et le plus rare : il mesure ce qui est réellement servi, y compris ce que personne ne croyait avoir ajouté.

   La question qui rend le budget crédible

   Un budget de performance sans réponse à « qu'est-ce qu'on sacrifie si on le dépasse ? » n'est pas un budget, c'est un souhait. La réponse à cette question est presque toujours : « on décale une fonctionnalité ». C'est cette réponse qui rend la discussion possible au lieu de la rendre théorique.