Une seconde disparaît facilement dans un rapport. Entre un bouton pressé et l’action attendue dans un jeu, elle paraît interminable. Le joueur ressent le trajet complet entre l’entrée, la simulation et l’image affichée.

Une boucle de jeu lit les commandes, met à jour le monde, prépare le rendu et présente l’image. À 60 images par seconde, le budget total est 16,7 ms; à 30, 33,3 ms.

manette -> lecture entrée -> simulation -> commandes GPU -> rendu -> écran
               1 ms            5 ms          2 ms       8 ms

Ce budget de 16 ms est déjà plein. Une pointe de simulation à 20 ms rate la prochaine présentation et produit une image de 33 ms. La moyenne peut rester belle alors que les pointes cassent régulièrement la fluidité.

Les consoles rendent la discipline visible : le matériel reste stable pendant des années. Le moteur prépare les textures avant leur usage, simplifie la géométrie lointaine et libère les ressources qui ne servent plus. Charger au moment exact où l’objet apparaît bloque la boucle sur le disque. Précharger tout remplit la mémoire. Il faut prévoir une fenêtre et un budget.

Appliquer le même traçage à une application Web

Un clic dans une application de travail traverse aussi plusieurs étapes :

navigateur 80 ms -> réseau 120 ms -> serveur Web 50 ms
-> service 200 ms -> SQL 700 ms -> réponse/rendu 150 ms
total = 1 300 ms

Chaque équipe peut annoncer « moins d’une seconde » pour son composant. L’utilisateur reçoit la somme. Un identifiant de corrélation et des horodatages à chaque frontière permettent de suivre une requête précise. Les horloges doivent être synchronisées, sinon les durées entre serveurs deviennent douteuses.

Je mesurerais médiane, 95e et 99e percentiles. La moyenne cache le petit groupe qui tombe toujours sur une requête sans index ou un lien lent. Je séparerais aussi temps serveur et temps perçu dans le navigateur; un HTML reçu rapidement peut encore attendre du JavaScript et des images.

Le test de charge doit garder le même mélange d’actions que le vrai trafic. Mille lectures faciles ne révèlent pas le verrou créé par dix écritures concurrentes. Je monterais progressivement le volume, observerais le point de saturation, puis vérifierais que les files et timeouts se résorbent lorsque la charge retombe au lieu de laisser le service coincé.

Le feedback traite la perception, pas la cause. Dès le clic, le bouton change d’état et empêche un second envoi. Au-delà de quelques centaines de millisecondes, un indicateur montre que le travail continue. Pour une opération longue, le serveur crée une tâche, retourne son identifiant et laisse l’interface suivre le progrès. Une barre inventée qui reste à 99 % détruit la confiance.

Les timeouts doivent être coordonnés. Si le navigateur abandonne après 30 secondes mais que le serveur continue et enregistre la commande à 35, l’utilisateur recommence et crée un doublon. Un identifiant d’opération et une lecture du statut permettent de reprendre sans rejouer aveuglément.

Comme chef d’équipe, je donnerais un budget à chaque segment et profilerais d’abord le pire parcours fréquent. Une application de paie n’a pas besoin d’explosions. Elle mérite tout de même une boucle mesurée, des ressources préparées et une reprise claire. Le bon résultat reste simple : j’ai cliqué, le système a confirmé, et je sais quoi faire si l’attente dépasse le budget.