Relier correctement les durées navigateur, API et base de données

Un écran lent ne montre pas où le temps se perd. Pour une analyse ciblée, développement et exploitation doivent considérer la même tâche, la même requête et des limites de mesure clairement nommées.

L’exemple suivant est entièrement hypothétique. L’identifiant req-17, toutes les durées et la structure des requêtes sont inventés. Aucun système client n’a été mesuré.

Délimiter une requête concrète

Ici, un portail charge une liste de commandes de 20 lignes. Les mesures supposées suivantes correspondent à la requête :

La durée de la base est incluse dans celle du serveur, elle-même incluse dans le chargement. Les additionner compte plusieurs fois le même temps. Pour des appels parallèles, la somme peut aussi dépasser le temps écoulé.

Les heures absolues de début du navigateur et du serveur ne peuvent être simplement soustraites sans référence temporelle adaptée. Utilisez des durées définies et un rattachement traçable à la même requête.

Examiner la partie qui attire l’attention

Le parcours inventé produit 21 appels à la base : une requête de liste, puis une de détail par ligne. Cet accès répété devient une piste concrète. Un nombre élevé de requêtes ne prouverait pas, seul, cette structure ; elle fait ici partie de l’exemple.

Examinez les informations réellement nécessaires. Un accès groupé délimité peut être une modification possible. Il doit retourner les mêmes enregistrements autorisés. Cela ne justifie pas de tout charger dans une requête énorme.

La durée navigateur du tableau s’arrête à la réception de la ressource. Elle ne prouve pas que l’écran soit alors utilisable. S’il reste bloqué, traitement, affichage et autres ressources doivent être examinés séparément.

Vérifier dans des conditions comparables

Notez version logicielle, tâche, volume de données, filtres et périmètre des droits. Charge simultanée et état du cache comptent aussi. Un cache vide et un cache déjà rempli peuvent donner des résultats différents.

Répétez le parcours avant et après modification dans des conditions adaptées. Vérifiez résultat et limites d’accès autant que durée. Une requête exceptionnellement rapide ne suffit pas à démontrer une amélioration générale.

L’accès aux mesures techniques doit être maîtrisé ; aucun contenu client n’est nécessaire à cette note. L’analyse doit déboucher sur une modification justifiée et délimitée, pas un jugement global sur la vitesse de toute l’application.

Sources

• MDN — Server timing

• MDN — PerformanceResourceTiming: responseEnd

• Microsoft — Chatty I/O antipattern