Tu lances un test, tu obtiens un beau score vert, tu te dis que ta vitesse est réglée. Et pourtant, tes utilisateurs se plaignent, ton taux de rebond mobile reste haut, tes conversions ne bougent pas. Le score te rassure, la réalité te contredit. C'est le piège le plus courant de la performance web, et il fait perdre un temps fou à corriger des chiffres qui n'existent que dans un laboratoire.
Cet article te montre pourquoi le score de labo ment souvent, ce qu'il faut mesurer à la place, et comment voir la vitesse que vivent vraiment tes visiteurs.
Le labo n'est pas la rue
Pourquoi mon score Lighthouse est bon alors que mes utilisateurs se plaignent de la lenteur ?
Parce que Lighthouse mesure une seule visite, sur une seule machine, dans des conditions simulées et stables. Tes vrais visiteurs arrivent avec mille appareils différents, des connexions instables, des heures de forte charge sur ton serveur. Le score de labo décrit un instant idéal, pas la distribution complète de ce que vivent réellement tes utilisateurs.
Voici la distinction que personne ne t'explique clairement. Un outil comme Lighthouse mesure ta page dans des conditions de laboratoire. Une seule machine, un seul réseau simulé, une seule visite, à un instant donné. C'est utile pour diagnostiquer, mais ça ne décrit pas ce que vivent tes vrais utilisateurs.
Tes visiteurs, eux, arrivent avec mille appareils différents, des téléphones d'entrée de gamme, des connexions instables, des navigateurs chargés d'extensions, à des heures où ton serveur est plus ou moins sollicité. La vitesse réelle, c'est la distribution de toutes ces expériences, pas le résultat propre d'un test unique sur une machine de développeur.
Le piège du 4x, même le labo simule mal la réalité
Ce que peu de gens savent, c'est que Lighthouse essaie déjà de compenser en simulant un mobile. Par défaut, l'outil applique un facteur de ralentissement CPU de 4x, pour transposer les performances d'une machine de développeur haut de gamme vers celles d'un mobile milieu de gamme, comme le documente le dépôt officiel de Lighthouse. C'est déjà un progrès sur un test lancé sans throttling du tout, qui ne dirait rien de l'expérience mobile. Le problème, c'est que ce facteur est calibré sur un appareil moyen, à vide, sans les dix autres onglets ouverts ni la 4G qui décroche dans le métro, ni la batterie à 12% qui pousse le téléphone à brider lui même son propre processeur pour économiser l'énergie. Même le labo le plus honnête reste une approximation d'une approximation. C'est un point de départ pour comprendre, jamais une preuve de ce que vit un visiteur précis sur un appareil précis, à un moment précis de sa journée.
Pourquoi la moyenne ment sur la vitesse de mon site ?
Parce qu'une moyenne peut rester flatteuse même quand une partie de tes visiteurs vit un enfer. Imagine une page qui charge en une seconde pour la plupart des gens, mais en vingt secondes pour un visiteur sur dix : la moyenne reste bonne, alors qu'un visiteur sur dix part. C'est pour ça qu'on lit la vitesse en centiles, pas en moyenne.
Et il y a un piège dans le piège, la façon dont on résume la distribution des temps réels. Le réflexe est de regarder la moyenne, or la moyenne est l'indicateur le plus menteur qui soit en performance. C'est pour ça qu'on raisonne en centiles plutôt qu'en moyenne. Le p75 te dit ce que vivent les trois quarts les mieux servis, le p95 ce que subissent les plus mal lotis. Google lui même a tranché la question pour les Core Web Vitals : les moyennes sont trompeuses parce qu'elles ne représentent la session d'aucun visiteur réel, alors qu'un centile "décrit mieux l'éventail complet des expériences vécues sur ton site", comme l'explique web.dev dans son guide des bonnes pratiques de mesure de terrain. La performance se juge sur la queue de la distribution, pas sur son milieu, parce que c'est dans la queue que se trouvent les visiteurs qui renoncent.
Un score vert ne prouve rien tout seul
Je vais prendre une position tranchée. Un score Lighthouse à 90 ne prouve rien sur l'expérience de tes utilisateurs. Le labo est un point de départ pour diagnostiquer, jamais une preuve que ta vitesse est bonne. Se fier au seul score de labo, c'est juger un restaurant sur la photo du menu. Ce n'est pas que Lighthouse soit inutile, au contraire, c'est un excellent outil pour comprendre ce qui ralentit une page et obtenir des pistes. Mais il répond à la question "qu'est-ce qui pourrait être lent ici", pas à la question "qu'est-ce que mes utilisateurs vivent vraiment". Je démonte ce mythe en détail dans le mythe du score Lighthouse à 100.
Mon propre reçu, le labo qui ne voyait rien
Le p95 qui n'existait pas dans mon labo
Le cas le plus parlant, je l'ai vécu sur Zovalide. Le score en conditions calmes était correct, rien n'alertait. J'aurais pu m'arrêter là, satisfait, et croire ma vitesse réglée.
Sauf que j'ai testé la page sous charge, avec plusieurs utilisateurs simultanés, avec un outil de test de montée en charge. Et là, le verdict tombait. Le p95, le temps vécu par les 5% d'utilisateurs les plus mal servis, atteignait 32 secondes. Le score de labo, lui, n'avait jamais vu cette charge, donc ne l'avait jamais signalée. Le problème venait de requêtes en base non indexées qui s'effondraient à plusieurs. En posant les index, ce p95 est tombé à 1,2 seconde.
Pourquoi une requête non indexée explose sous charge
Pourquoi une requête non indexée explose sous charge, et pas seule, vaut l'explication. Seul, le serveur a tout le temps de parcourir la table entière pour trouver ta ligne, ça reste tolérable. À plusieurs en même temps, ces parcours complets se cumulent, chacun monopolise les ressources, et la base passe son temps à relire les mêmes données pour tout le monde à la fois. L'index change la nature du travail, au lieu de feuilleter toute la table, le serveur va droit à la bonne ligne. C'est la différence entre chercher un mot en lisant un livre de la première à la dernière page, et le trouver par l'index de la fin. Seul, la lecture intégrale passe. En heure de pointe, elle s'effondre.
La leçon est nette. Mon labo me disait que tout allait bien, pendant que mes utilisateurs sous charge attendaient trente secondes, un temps d'attente qui aurait fait fuir n'importe qui, y compris moi. Si je m'étais fié au seul score, je n'aurais jamais trouvé la fuite.
Les trois mesures qui comptent vraiment
Pour voir ta vitesse réelle, regarde au-delà du score unique. Voici les trois mesures à suivre, ton artefact à garder.
| Instrument | Ce qu'il capture | Demande du trafic réel | Où le lancer en premier |
|---|---|---|---|
| Lighthouse, en labo | Un diagnostic technique, sur une visite simulée | Non | Pour comprendre une fuite déjà repérée |
| Données de terrain, p75 | Ce que vivent réellement les trois quarts de tes visiteurs les mieux servis | Oui, du trafic significatif | En premier, pour savoir si tu as un problème |
| Test de montée en charge, p95 | Ce qui casse quand plusieurs visiteurs arrivent en même temps | Non, se simule avec des utilisateurs virtuels | Après un signal du terrain, ou en prévention |
| Test sur appareil modeste | La vitesse vécue sur un téléphone d'entrée de gamme | Non, un seul téléphone suffit | Pour vérifier qu'un correctif tient dans la vraie vie |
Les données de terrain, ta mesure reine
Ce sont les temps réellement mesurés chez tes vrais visiteurs, agrégés, souvent exprimés en p75. Si ton p75 est mauvais, un quart de tes visiteurs vit pire encore. C'est la mesure reine, parce qu'elle vient de la vraie vie, pas du labo. Tu les obtiens via les rapports d'expérience de Chrome ou un petit outil de mesure posé sur ta page, sans rien simuler.
L'intérêt des données de terrain ne s'arrête pas à un chiffre global. Segmentées par appareil, par pays, par type de connexion, elles te disent où chercher en premier. Un p75 correct en moyenne peut cacher un p75 catastrophique sur mobile en 4G, pendant que le desktop en fibre tire la moyenne vers le haut. C'est le terrain qui te dit aussi lequel des trois signaux, le LCP, le CLS ou l'INP, pèse le plus chez toi : je détaille les trois dans Core Web Vitals expliqués, trois sensations, pas trois chiffres.
Le comportement sous charge, ton p95
Teste ta page avec plusieurs utilisateurs simultanés, pas seul. C'est ce qui m'a sauvé sur Zovalide, et c'est probablement le test le plus négligé des trois, parce qu'il demande un outil dédié plutôt qu'un onglet déjà ouvert. La moyenne ment, le p95 dit la vérité sur tes utilisateurs les plus mal lotis. Un outil de test de montée en charge suffit, tu n'as besoin d'aucun vrai visiteur pour le déclencher. Je détaille la méthode complète, y compris pourquoi un seul run ne prouve jamais rien, dans test de performance réel, un seul run en labo n'est pas un test.
La vitesse sur de vrais appareils modestes
Teste sur un téléphone d'entrée de gamme en données mobiles, pas sur ton ordinateur en fibre. C'est l'appareil d'une grande partie de tes visiteurs, et c'est là que la lourdeur se paie au prix fort. Le mode bridé de ton navigateur dépanne pour un premier repérage rapide, mais rien ne remplace un vrai téléphone bon marché dans la main, sur un vrai réseau mobile, avec les autres applications qui tournent déjà en arrière-plan et se disputent la même mémoire limitée. Et attention à un biais courant, une page peut sembler rapide sans l'être, ou lente en l'étant : je détaille cette nuance dans la vitesse perçue, pourquoi un site peut sembler rapide sans l'être.
Avec ces trois mesures, tu passes d'un chiffre rassurant et faux à une image fidèle de ce que vivent les gens qui décident d'acheter ou de partir.
Et si tu n'as pas encore de données de terrain
Je n'ai pas encore de trafic, comment je mesure ma vitesse réelle ?
Deux des trois mesures ne dépendent pas de ton volume de visiteurs. Le test sous charge se déclenche avec un outil qui simule des utilisateurs virtuels, tu peux en lancer mille sur une page que personne ne visite encore. Le test sur appareil modeste ne demande qu'un téléphone bon marché et ta page. Les données de terrain viendront avec le trafic.
Objection fréquente quand on démarre. Je n'ai pas assez de trafic pour des données de terrain fiables. C'est vrai, et ce n'est pas bloquant, parce que deux des trois mesures ne dépendent pas du tout de ton volume de visiteurs. Ces deux mesures te donnent déjà l'essentiel des fuites techniques, sans une seule visite réelle. Les données de terrain viendront avec le trafic, et tu les brancheras le jour où elles deviennent significatives, sans avoir attendu les bras croisés d'ici là. En attendant, tu n'es pas aveugle, tu changes juste d'instrument.
La hiérarchie à respecter
Pour t'éviter de tout regarder en même temps, voici l'ordre. Tu commences par les données de terrain, parce qu'elles te disent si tu as un problème réel, et à quelle échelle. Si elles sont mauvaises, tu ouvres le labo pour comprendre pourquoi et obtenir des pistes, avec par exemple un budget de performance qui fixe une limite claire à ne pas dépasser plutôt qu'une cible vague à atteindre un jour. Puis tu testes sous charge et sur appareil modeste pour vérifier que ton correctif tient dans la vraie vie, pas seulement dans le rapport que tu viens de lancer sur ta machine de développeur.
Le labo sert au milieu, à diagnostiquer, jamais au début comme alarme ni à la fin comme preuve. Utilisé au début, il te fait courir après des chiffres qui n'inquiètent que lui. Utilisé à la fin comme seule validation, il te fait croire qu'un correctif fonctionne alors qu'il n'a jamais été mis à l'épreuve d'une vraie charge ni d'un vrai téléphone. Et si tu es sur le point de tout reconstruire, mesure d'abord : reconstruire sans savoir ce qui est réellement cassé, c'est reproduire les mêmes fuites avec un design neuf. Je détaille pourquoi dans audit de vitesse avant refonte, ne reconstruis pas sur des fondations cassées.
Applique-le maintenant
Avant ton prochain chantier de performance, va chercher tes données de terrain, pas seulement ton score de labo. Si tu n'en as pas encore, mets en place une mesure chez tes vrais utilisateurs, et teste au moins une fois ta page sous charge, même sommairement. Tu découvriras peut-être, comme moi, une fuite que ton beau score vert n'avait jamais vue, et qui attend patiemment ton prochain pic de trafic pour se révéler au pire moment possible.
Pour replacer ce sujet dans l'ensemble de ta friction technique, lis le guide performance web et conversion. Pour ce que la lenteur te coûte concrètement, vois l'impact réel du temps de chargement sur tes conversions, et pour comprendre pourquoi un site soigné peut ramer, pourquoi un beau site peut quand même être lent.
Si tu veux qu'on mesure ensemble la vitesse réelle de ton site, celle que vivent tes visiteurs et pas celle du labo, c'est le point de départ d'une Radiographie CRO. Le détail est sur le guide pilier.