Tu lances PageSpeed Insights une fois, tu lis le chiffre, et tu en tires une conclusion sur la vitesse de ton site. C'est ce que fait presque tout le monde, et c'est presque toujours faux. Pas parce que l'outil ment, mais parce qu'un seul run dans des conditions de laboratoire ne ressemble en rien à ce que vivent tes visiteurs.
Un test de performance qui ne reproduit pas les conditions réelles de ton public n'est pas un test, c'est une mise en scène. Il te donne un chiffre rassurant ou inquiétant, déconnecté de la réalité, sur la base duquel tu prends de mauvaises décisions. Voici la différence entre un test de façade et un vrai test, et le protocole pour mesurer ce qui compte vraiment.
Le mécanisme : le labo est un environnement, le terrain en est mille
Un test en laboratoire se fait dans des conditions fixes et contrôlées. Un appareil donné, une connexion donnée, un environnement stable. C'est utile pour comparer deux versions de ta page dans les mêmes conditions, parce que tout est égal par ailleurs. Mais ce n'est qu'un seul point, dans un univers où tes visiteurs sont partout.
Le terrain, lui, c'est mille environnements à la fois. Des téléphones puissants et des téléphones modestes, des connexions rapides et des 4G fluctuantes, des navigateurs à jour et d'autres pas, des appareils proches de ton serveur et d'autres à l'autre bout du monde. La performance que vivent tes visiteurs n'est pas un chiffre, c'est une distribution. Et un test qui ne renvoie qu'un seul point ne te dit rien de cette distribution.
C'est pour ça que la métrique qui compte se lit au 75e centile sur des données de terrain, pas au centre d'un test de labo. Le 75e centile te dit ce que vivent la grande majorité de tes visiteurs, y compris ceux qui sont mal lotis. Le run de labo, lui, te dit ce que vit une machine idéale qui n'existe pas dans ta base d'utilisateurs.
La prise de position : un test à vide, une seule fois, ne prouve rien
Je vais être tranchant. Lancer un test de performance une seule fois, à vide, sur ta machine, ne prouve rien. Ça te donne une impression, pas une mesure. Et une impression sur laquelle tu engages du travail de correction est plus dangereuse qu'une absence de mesure, parce qu'elle t'oriente avec une fausse confiance.
Un vrai test obéit à trois exigences. Il regarde le terrain avant le labo, parce que c'est le terrain qui décide de ta conversion. Il se répète, parce qu'un seul run est sujet au hasard et que seule la médiane sur plusieurs runs est fiable. Et il teste sous les conditions de tes vrais visiteurs, processeur bridé, réseau ralenti, pas le confort de ton bureau. Tout ce qui s'écarte de ces trois exigences est une mise en scène qui te rassure à bon compte.
La répétition n'est pas une précaution de maniaque, c'est une nécessité. Deux runs successifs de la même page, sur la même machine, peuvent donner des résultats sensiblement différents, parce qu'une foule de facteurs varient d'un instant à l'autre, la charge réseau, les processus en arrière plan, la mise en cache. Si tu décides sur un seul run, tu décides peut être sur le run le plus favorable ou le plus défavorable du lot, sans le savoir. La médiane sur cinq runs lisse ce bruit et te donne une mesure sur laquelle tu peux raisonner. Un chiffre unique sans répétition n'est pas une donnée, c'est un tirage.
Teardown : le test qui ne se révèle que sous charge
Le cas qui m'a marqué, c'est Zovalide, et il illustre pourquoi tester à vide trompe.
- Ce qui ne se voyait pas. À vide, sans trafic, le temps de réponse paraissait correct. Rien n'alertait. Si je m'étais arrêté à un test au repos, j'aurais conclu que tout allait bien.
- Ce que le test sous charge a révélé. En simulant un vrai trafic avec k6, le 95e centile du temps de réponse montait à 32 secondes. Le problème ne se déclenchait que sous pression, parce qu'il venait de requêtes de base de données non indexées qui s'effondraient quand les demandes s'accumulaient. Une fois les index posés, ce même p95 sous charge est tombé à 1,2 seconde.
La leçon est nette. Un test qui ne reproduit pas les conditions réelles, ici la charge, t'aurait laissé croire que tout allait bien jusqu'au jour où le trafic réel aurait fait exploser le temps de réponse devant tes vrais visiteurs. Le test n'a de valeur que s'il reproduit la pression du réel, pas le calme du labo.
L'artefact : le protocole d'un test de performance réel
Suis cet ordre.
- Commence par le terrain. Regarde tes données de terrain au 75e centile, segmentées mobile et desktop. C'est la vérité de ce que vivent tes visiteurs, avant tout test de labo.
- Reproduis les conditions du réel. Quand tu testes en labo, bride le processeur d'un facteur quatre à six et ralentis le réseau à une 4G moyenne. Le confort de ta machine n'est pas une condition de test valable.
- Répète et prends la médiane. Jamais un seul run. Lance plusieurs fois et garde la médiane, parce qu'un run isolé est trop sensible au hasard pour décider quoi que ce soit.
- Teste sous charge, et les vrais parcours. Si ton produit sert du dynamique, mesure le temps de réponse sous un trafic simulé, pas à vide. Et teste les pages qui comptent pour ta conversion, pas seulement l'accueil.
Où tu mesures sérieusement : le terrain dit la réalité vécue, le labo répété et bridé dit la cause, le test sous charge dit la résistance. Les trois ensemble font un vrai test. Un seul des trois, pris isolément, ne fait qu'une mise en scène.
Ce qu'il faut retenir
Un seul run de labo, à vide, sur ta machine, n'est pas un test de performance, c'est une mise en scène qui te rassure ou t'inquiète à tort. La performance vécue par tes visiteurs est une distribution, pas un chiffre, et elle se lit au 75e centile sur le terrain. Commence par le terrain, reproduis les conditions réelles, répète et prends la médiane, teste sous charge et sur les vrais parcours. Sur Zovalide, seul le test sous charge a révélé un p95 à 32 secondes invisible au repos. Refais ton dernier test de performance avec le processeur bridé et plusieurs runs, et compare au chiffre qui t'avait rassuré. Si tu veux un test mené sur tes vraies conditions, du terrain à la charge, c'est exactement ce que couvre le diagnostic performance.