Latence dans les applications web : les fondamentaux que chaque équipe doit comprendre

La vitesse est l'une des rares caractéristiques du produit que l'utilisateur ressent avant de pouvoir l'expliquer. Personne n’ouvre un site Web et pense que « la latence ici est élevée ». Les gens ont juste l’impression que quelque chose est lent, ils s’impatientent et s’en vont. La latence est invisible jusqu'à ce qu'elle devienne abandon.

Pour ceux qui commencent à s'intéresser aux performances Web, la première confusion est de considérer la latence comme synonyme d'« Internet lent ». Ce n'est pas. La latence est le temps entre une action et la réponse à cette action, et elle est construite par une chaîne de facteurs qui vont bien au-delà de la connexion de l'utilisateur. Comprendre cette chaîne est ce qui différencie ceux qui lancent les optimisations de ceux qui résolvent le problème à la source.

Ce texte est une base. Le but n’est pas de vous livrer des recettes, mais de vous donner le vocabulaire et le modèle mental pour raisonner clairement sur la latence, car sans comprendre d’où elle vient, toute optimisation devient un essai et une erreur.

Qu'est-ce que la latence, en fait

La latence est le temps d'attente. Lorsque quelqu'un clique sur un bouton et que quelque chose doit se produire sur le serveur, il y a un délai entre le clic et la réponse visible. Cet intervalle est la latence perçue, et c'est la somme de plusieurs temps plus petits.

Il est utile de séparer la latence du débit, deux concepts souvent confondus. La latence correspond à la durée d'une seule requête. Le débit correspond au nombre de requêtes que le système peut traiter par seconde. Vous pouvez avoir un système à haut débit et à haute latence en même temps, il sert beaucoup de monde, mais tout le monde attend. Pour l’utilisateur individuel, ce qui compte, c’est la latence. Pour l’opération, les deux sont importants.

La thèse centrale de ce texte : la latence est une somme d'étapes, et vous n'améliorez que ce que vous pouvez voir. Quiconque traite la latence comme un nombre unique et opaque se retrouve coincé avec des optimisations génériques. Celui qui brise la chaîne découvre où le temps est réellement perdu.

D'où vient la latence

Imaginez le cheminement d'une requête typique, du clic de l'utilisateur à la réponse à l'écran. Chaque tronçon de ce chemin ajoute du temps.

Il y a une distance physique. Les informations circulent sur le réseau à une vitesse limitée et la distance entre l'utilisateur et le serveur est importante. Un serveur sur un autre continent ajoute des dizaines de millisecondes rien que pour l'aller-retour, avant tout traitement. Pour un public brésilien desservi par des infrastructures distantes, cela constitue une véritable partie du problème.

Il y a l'établissement de la connexion. L'ouverture d'une connexion sécurisée implique une négociation initiale entre le client et le serveur qui coûte des allers-retours à travers le réseau. Les connexions réutilisées paient ce coût une fois ; les nouvelles connexions sont payantes à chaque fois.

Il y a un traitement sur le serveur. Le temps nécessaire à l'application pour comprendre la requête, interroger les bases de données, exécuter la logique métier et assembler la réponse. C’est là que réside une grande partie de la latence que les équipes peuvent directement contrôler.

Il y a une interrogation de données. La base de données est souvent le plus grand méchant caché. Une requête mal indexée, un appel qui déclenche des dizaines d'autres requêtes à la suite, un service externe lent dans la chaîne, tout cela transforme une réponse rapide en attente.

Et il y a un rendu dans le navigateur. Même une fois la réponse arrivée, le navigateur doit la traiter et dessiner l'écran. Du JavaScript lourd, des ressources bloquantes et des images volumineuses ajoutent du temps dans la dernière section, là où l'utilisateur regarde.

Pourquoi c'est important pour les entreprises

Il est tentant de considérer la latence uniquement comme un problème d’ingénierie. C'est une erreur de gestion. La latence a un effet direct sur la conversion, la rétention et la perception de la qualité. Les applications lentes sont abandonnées et l'abandon ne demande pas d'autorisation.

Pensez à un portail de services publics. Le citoyen qui tente de délivrer un duplicata, de prendre rendez-vous ou de consulter une prestation n'a pas une patience infinie et y accède souvent à partir d'un téléphone portable doté d'une connexion modeste. Si chaque étape prend du temps, le taux d'achèvement diminue, le service en face-à-face se développe et la perception selon laquelle « le système gouvernemental ne fonctionne pas » est renforcée. La latence, dans ce cas, est une barrière pour accéder à un droit.

Dans les produits privés, la logique est la même sous un autre nom : chaque seconde d’attente est de l’argent qui sort. C'est pourquoi la latence ne devrait pas être un problème qui n'apparaît que lorsque l'utilisateur se plaint. Il devrait s’agir d’un indicateur surveillé comme on surveillerait les revenus.

Mesurer avant d'optimiser

L’erreur la plus courante commise par ceux qui étudient la latence est de commencer à optimiser avant de mesurer. Vous ajoutez du cache ici, réécrivez une fonction là, tout cela par intuition, et le résultat est un effort dispersé sans impact clair.

La bonne discipline est le contraire. Mesurez d’abord le temps perdu, puis attaquez-vous au plus gros goulot d’étranglement. La latence suit généralement une répartition inégale : une seule étape peut représenter la majeure partie du temps total. Optimiser les autres est un gaspillage.

Il convient également d’examiner non seulement la moyenne, mais aussi les pires cas. La latence moyenne peut sembler élevée alors qu’une fraction importante des utilisateurs connaît de longues attentes. Ce sont précisément ces utilisateurs, ceux du mauvais centile, qui abandonnent et se plaignent. Une bonne moyenne peut cacher une expérience épouvantable pour de nombreuses personnes.

Le piège de l'optimisation de l'invisible

Il existe un risque de l’autre côté de l’enthousiasme pour la performance : optimiser ce qui n’a pas d’importance. Des équipes enthousiastes passent des semaines à gagner des millisecondes sur une pièce que l'utilisateur ne remarque jamais, tandis que la plus grande attente reste intacte.

La performance est toujours une question de proportion. Réduire une étape qui représente peu du temps total ne change pas l’expérience. La maturité consiste à résister à la tentation de l’optimisation élégante et à se demander avant tout si elle fait évoluer le nombre ressenti par l’utilisateur.

Un autre écueil consiste à considérer la latence comme un problème résolu après une série d’améliorations. Les systèmes évoluent, les données augmentent, de nouvelles fonctionnalités ajoutent des appels. La latence augmente à nouveau si personne ne regarde. Il s'agit d'un indicateur à surveiller en permanence, et non d'une tâche à rayer de la liste.

Clôture

La latence est la taxe invisible que paie toute application web, et c’est l’utilisateur qui en ressent la facture. Comprendre ses fondamentaux, qu'il s'agit d'une somme d'étapes, qu'il se mesure avant d'être optimisé, qu'il est important pour le business autant que pour l'ingénierie, est la première étape pour construire des produits que les gens n'abandonnent pas par impatience.

La vitesse n'est ni un luxe ni un détail technique. Cela fait partie de la promesse que fait votre produit. Ceux qui considèrent la performance comme une décision produit, et non comme un ajustement de dernière minute, proposent des expériences qui respectent le temps de ceux qui se trouvent de l’autre côté de l’écran.

Si vous commencez à examiner plus sérieusement les performances de votre application, cela vaut la peine de le faire avec des mesures en main dès le début. Il existe d'autres articles ici sur le blog sur l'architecture et l'évolutivité qui approfondissent le sujet.