Réduire la latence dans les applications Web : un guide rapide pour éliminer les bons goulots d'étranglement

Si vous êtes arrivé ici, vous savez probablement déjà ce qu'est la latence et souhaitez agir. Ce texte ne vous fera pas perdre de temps à redéfinir le concept. C'est un guide pratique pour tous ceux qui ont besoin de créer une application Web plus rapidement et qui souhaitent le faire dans le bon ordre, sans passer des semaines sur des optimisations qui ne font pas bouger les choses.

La règle qui organise tout ce qui suit n’en est qu’une : s’attaquer en premier au plus gros goulot d’étranglement. La latence se concentre. Dans une application typique, une ou deux étapes représentent la majeure partie de l’attente. Les trouver et les résoudre vaut plus que des dizaines de petits ajustements éparpillés.

Passons de la partie qui fait habituellement le plus mal à celle qui fait habituellement le moins mal. Adaptez la commande à votre réalité, mais seulement après avoir mesuré.

Commencez toujours par mesurer

Sauter cette étape est l’erreur la plus coûteuse. Sans mesure, vous optimisez dans le noir et le risque de vous tromper au mauvais endroit est élevé.

Avant de toucher un code, instrumentez la requête. Vous devez savoir combien de temps est passé sur le serveur, combien de temps est consacré à l'interrogation des données, combien de temps est consacré au réseau et combien de temps est consacré au rendu du navigateur. Les outils d'observabilité du backend et les outils de développement du navigateur donnent une image suffisante pour commencer.

Regardez également la répartition, pas seulement la moyenne. La latence des cas les plus défavorables, c'est-à-dire les utilisateurs du mauvais centile, est ce qui génère des plaintes et des abandons. Un délai moyen acceptable peut cacher une longue série de souffrances. Optimisez en gardant cette queue à l'esprit.

La base de données est souvent la méchante

Dans la plupart des applications qui ralentissent avec le temps, le goulot d'étranglement réside dans les requêtes. Cela vaut la peine de commencer ici.

Le suspect classique est la requête sans index approprié. À mesure que la table s'agrandit, une recherche instantanée avec un millier d'enregistrements devient un problème avec des millions. Identifier les requêtes lentes et ajouter les bons index constituent souvent l'optimisation la plus rentable qui soit.

Le deuxième suspect est le modèle de nombreuses requêtes en séquence : l'application recherche dans une liste et, pour chaque élément, déclenche une nouvelle requête. Dix articles ont donné lieu à onze voyages à la banque ; cent éléments deviennent cent un. Résoudre ce problème en récupérant les données d'un seul coup transforme une page lente en une page rapide sans rien changer d'autre.

La troisième est la requête qui apporte trop de données. Demander toutes les colonnes lorsque vous en utilisez trois, ou introduire des milliers de lignes pour en afficher vingt, fait perdre du temps sur chaque couche. Commandez uniquement ce que vous utiliserez.

Cache : le raccourci le plus puissant et le plus dangereux

Le cache est l’outil qui réduit le plus la latence et introduit les bugs les plus subtils. Utiliser avec intention.

L’idée est simple : sauvegarder le résultat d’une opération coûteuse pour ne pas la répéter. Des données qui changent peu et sont beaucoup lues, un catalogue, une configuration, une page publique, sont de parfaits candidats. Le service à partir du cache élimine la recherche dans la base de données et la majeure partie du traitement.

Le danger réside dans l'invalidation : garantir que le cache est mis à jour lorsque les données changent. Le cache qui sert d'anciennes informations génère des problèmes difficiles à diagnostiquer, car le système "fonctionne", c'est tout simplement faux. Avant d'ajouter du cache, décidez comment il sera invalidé. Si vous ne savez pas comment répondre à cette question, vous n’êtes pas encore prêt à le faire.

Cache en couches

Il y a plus d’un endroit où jouer au curling, et ils s’additionnent. Dans le navigateur, les ressources statiques peuvent être enregistrées afin qu'elles ne soient pas téléchargées à nouveau. Dans un CDN, le contenu peut être servi à partir d'un point physiquement proche de l'utilisateur. Sur le serveur, les résultats d'opérations coûteuses peuvent rester en mémoire. Chaque couche réduit une partie de la latence totale.

Raccourcissez la distance et réutilisez les connexions

Une partie de la latence est purement physique : la distance entre l’utilisateur et le serveur. Vous ne pouvez pas battre la vitesse de la lumière, mais vous pouvez raccourcir le chemin.

Un CDN place des copies de votre contenu à proximité de quiconque y accède. Pour un public brésilien, servir depuis des points de présence dans le pays, au lieu d'un serveur distant, réduit le temps de trajet qu'aucune optimisation de code ne pourrait récupérer. Pour le contenu et les médias statiques, il s'agit de l'un des meilleurs ratios effort-gagnant.

La réutilisation des connexions permet également d'économiser. L’ouverture d’une nouvelle connexion sécurisée coûte des allers-retours à travers le réseau ; maintenir les connexions actives et utiliser des protocoles modernes réduit ces coûts répétés. C’est un avantage qui apparaît surtout sur les pages qui font de nombreuses requêtes.

Soulager le navigateur

Même avec le serveur rapide, l'écran n'apparaît qu'une fois que le navigateur a traité la réponse. Cette dernière section mérite attention.

Les délinquants courants sont connus. JavaScript excessif qui ralentit le chargement des pages. Images volumineuses diffusées sans compression ou dans une taille incorrecte. Fonctionnalités qui bloquent l'écran pendant le chargement. Réduire et différer ce qui n'est pas essentiel au premier écran donne l'impression que l'application est rapide même lorsqu'elle est encore en train de finir de charger le reste.

La perception compte autant que les chiffres. Afficher tôt un contenu utile, même partiel, donne à l'utilisateur un sentiment de rapidité. Un écran vide pendant deux secondes est pire qu’un écran qui montre immédiatement la structure puis la complète.

Il vaut également la peine d’appliquer ici la même logique de proportion. Avant de réécrire un composant entier au nom de la performance, vérifiez que la section que vous allez attaquer est celle qui apparaît sur le premier écran. Souvent, le plus gros gain vient du report du chargement de quelque chose de secondaire, et non de la réécriture de l'essentiel.

L'erreur d'optimiser ce qui ne fait pas de mal

Cela vaut la peine de mettre en garde tout guide de performance honnête : n'optimisez pas l'invisible. Il est facile de tomber amoureux d'un morceau de code élégant et de passer des journées entières à gagner des millisecondes que personne ne remarque, alors que le véritable goulot d'étranglement reste intact.

Revenez toujours à la mesure. Après chaque optimisation, mesurez à nouveau et confirmez que le chiffre que l'utilisateur estime s'est réellement amélioré. Si cela ne s'est pas amélioré, vous avez mal optimisé. La performance est un jeu de proportions, et l’humilité de mesurer est ce qui évite le gaspillage.

Clôture

Réduire la latence n’est pas de la magie ou de l’héroïsme technique. C'est une méthode : mesurer, trouver le plus gros goulot d'étranglement, le résoudre, mesurer à nouveau. La base de données, le cache, la distance et le navigateur sont les endroits où l'on perd le plus de temps, et presque toujours l'un d'eux concentre le problème.

La vitesse est une décision produit déguisée en tâche d'ingénierie. Les équipes qui le traitent méthodiquement fournissent des applications qui respectent le temps de l'utilisateur et dépensent moins d'énergie pour éteindre les incendies de performances plus tard.

Si vous occupez ce poste maintenant, commencez par mesurer avant toute autre chose. Il existe d'autres articles ici sur le blog sur l'architecture, la mise en cache et l'évolutivité qui approfondissent chacun de ces points.