Ce que mesurent habituellement les tests de performance UI
Le chargement initial : temps jusqu'au premier rendu, délai avant interactivité, poids du bundle. Réellement important pour une première visite, bien couvert par les outils existants, et pour l'essentiel un coût unique par session.
Ce que les utilisateurs remarquent vraiment
Latence d'interaction
L'écart entre le clic et le moment où quelque chose se produit visiblement.
Se produit des centaines de fois par session, contrairement au chargement.
Réactivité perçue
Savoir si l'interface a seulement accusé réception de l'action.
Un indicateur de chargement affiché en moins de 100 ms paraît plus rapide que 400 ms de silence, même si c'est en réalité plus lent.
Dégradation avec les données
Correct avec dix lignes, inutilisable avec deux mille.
Invisible sur un environnement de test vierge.
C'est la troisième qui atteint le plus souvent la production, parce que les environnements de test sont petits et que les comptes clients ne le sont pas.
La mesure qui compte et qui manque le plus souvent
Exécutez le même parcours sur un jeu de données de taille réaliste. Pas un test de charge : un seul utilisateur, sur un compte contenant le volume de données d'un vrai client. Une liste qui s'affiche en 80 millisecondes avec dix lignes et en quatre secondes avec deux mille est un défaut, et aucun test de charge sur un environnement vierge ne le révélera.
Pourquoi le bon fonctionnement passe d'abord, ici aussi
Une interface qui s'affiche instantanément parce que la requête a échoué en silence n'est pas rapide. Avant toute mesure, vérifiez que le parcours fait ce qu'il doit faire, puis mesurez le temps qu'il met à le faire. Dans l'ordre inverse, vous obtenez des chiffres rassurants sur un écran cassé.
Le compte pré-rempli que personne n'entretient
L'essentiel de ce que recommande cette page suppose un environnement contenant des données réalistes, et les raisons pour lesquelles les équipes n'en ont pas méritent d'être abordées franchement.
Le remplir est facile. Le garder réaliste ne l'est pas : le schéma évolue, le script d'alimentation se dégrade, et au bout de deux trimestres il produit un compte qui ne ressemble plus à rien. À ce stade, on cesse de lui faire confiance et on revient à des tests sur dix lignes.
La version qui survit est générée à partir de la forme de la production plutôt qu'à partir d'un script figé : prenez la distribution du nombre d'enregistrements que possèdent les comptes réels, et construisez un compte de test au quatre-vingt-dixième centile. Il demande une régénération occasionnelle plutôt qu'une maintenance continue, et il reste honnête parce qu'il découle de ce que vos clients ont réellement.
La régression plutôt que les valeurs absolues
Les objectifs absolus empruntés à des benchmarks se transposent rarement. Suivez vos propres chiffres sur le même environnement et surveillez les variations. L'alerte utile, c'est qu'un parcours est devenu plus lent cette semaine, pas qu'il a dépassé un seuil choisi par quelqu'un.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Le tableau de bord couvre le même périmètre pour qui ne souhaite pas d'installation locale, et l'ensemble des commandes est détaillé dans le dépôt CLI.
Si le pipeline appartient à une autre équipe, la GitHub App est la solution la plus simple : c'est un webhook, elle ne change rien dans votre dépôt, et elle se déclenche lorsque votre build signale la mise en ligne de la nouvelle version. Si vous préférez rendre la vérification visible dans le dépôt, une étape GitHub Actions fait la même chose.
Ce que TestSprite vérifie en premier
Le bon fonctionnement, condition préalable pour qu'un chiffre de performance ait un sens. Une interface qui s'affiche instantanément parce que la requête a échoué en silence obtiendra d'excellents résultats : c'est précisément cet échec-là qui est détecté ici.
La couverture est générée à partir de votre produit et s'exécute sur l'application déployée à chaque changement, y compris sur un compte pré-rempli avec des volumes de données réalistes — c'est là qu'apparaît réellement la dégradation qui atteint la production.
La mesure des temps et le profilage restent du ressort d'outils dédiés. Ce que vous obtenez ici, c'est l'assurance que le parcours mesuré est un parcours qui fonctionne, et un signal précoce lorsqu'une liste cesse de passer à l'échelle, parce que c'est le comportement qui change, et pas seulement le temps.
TestSprite mesure-t-il la performance UI ?
Il vérifie que les parcours se comportent correctement, ce qui en est le préalable. La mesure des temps et le profilage relèvent d'un autre instrument.
Quelle métrique suivre en premier ?
La latence d'interaction sur vos trois actions les plus utilisées, sur un compte de taille réaliste. Elle est plus proche de la plainte que le temps de chargement.
Comment obtenir des volumes de données réalistes ?
Alimentez un compte de test jusqu'à la taille d'un gros client, et conservez-le. L'effort est rentabilisé dès la première fois qu'il révèle une liste qui a cessé de passer à l'échelle.
Vaut-il la peine de travailler la performance perçue ?
Oui, et cela coûte peu. Accuser réception d'une action immédiatement change davantage l'expérience que de grappiller des millisecondes réelles.
La performance doit-elle bloquer une mise en production ?
Une forte régression sur une interaction courante, oui. Une faible variation, non, sinon vous passerez votre temps à ajuster des seuils.
Les utilisateurs se plaignent de l'interaction, pas du chargement.
Les tests de performance UI mesurent en général le chargement des pages et passent à côté de la latence d'interaction et de la dégradation avec des volumes de données réels. Vérifiez d'abord le bon fonctionnement, mesurez sur un compte de taille réaliste, et suivez votre propre tendance plutôt que des objectifs empruntés.