Aller au contenu
Antoine Le LouetDéveloppeur senior indépendant
← Tous les articles

Conseils3 min de lecture

Comprendre une page lente avant de l’optimiser

Une page semble lente : comment retrouver l’attente qui gêne l’utilisateur et mesurer l’effet d’une correction dans les mêmes conditions ?

Un parcours est découpé en trois phases : requête, réponse et affichage.
Distinguer les phases d’attente aide à choisir ce qu’il faut mesurer.

Décrire ce qui semble lent

« La page est lente » peut décrire plusieurs situations. Après un clic sur un filtre, la liste reste par exemple inchangée pendant quelques secondes. Est-ce la réponse du serveur qui tarde ou le navigateur qui peine à afficher les données reçues ? Je commence par noter ce que l’utilisateur attend et le moment où il peut continuer.

Le contexte compte aussi : première visite ou navigation suivante, volume de données, appareil et connexion. Une mesure réalisée sur un ordinateur de développement ne suffit pas à représenter tous les usages. Elle peut néanmoins servir de point de comparaison si ses conditions sont conservées pendant l’analyse.

Construire un cas reproductible

  • Choisir une URL et une action précises.
  • Utiliser un jeu de données que l’on peut retrouver.
  • Noter les conditions : navigateur, cache, connexion et environnement.
  • Observer plusieurs exécutions pour repérer la variabilité.
  • Conserver une mesure de référence avant de changer le code.

Une première exécution peut inclure une compilation ou remplir un cache dont profiteront les suivantes. Répéter le parcours permet de repérer cet écart. Si l’attente ne se produit qu’à la première visite, cette condition doit faire partie du cas étudié.

Séparer la donnée de son affichage

Le navigateur permet d’examiner les requêtes réseau et le travail effectué pour afficher leur résultat. Si la réponse arrive tard, il faut comprendre le chemin côté serveur ou les dépendances externes. Si les données sont déjà présentes mais que l’interface tarde à réagir, le travail de rendu ou de traitement côté client mérite d’être étudié.

Ces pistes sont des hypothèses à confirmer. Ajouter du cache mérite par exemple d’être essayé si l’attente vient d’un travail répété côté serveur. Une intervention limitée permet de comparer son effet à la mesure de référence et de revenir en arrière si elle n’apporte rien.

Comparer le résultat et les compromis

Après le changement, je propose de reprendre les mêmes conditions et le même parcours. L’amélioration concerne-t-elle l’attente observée ? Introduit-elle des données moins fraîches, un comportement différent ou un coût de maintenance supplémentaire ? La mesure doit rester liée à l’expérience que l’on cherchait à améliorer.

Cette méthode ne garantit pas qu’une cause sera simple à trouver. Elle évite en revanche de multiplier les changements simultanés sans savoir lequel explique le résultat. Chaque étape laisse une trace utile pour la prochaine investigation.

Poursuivre la lecture
Tous les articles de la catégorie →