La fiabilité du frontend est souvent évoquée en termes de pannes. Les équipes se préparent aux échecs d’appels d’API, aux temps d’arrêt et aux plantages visibles, car ces échecs sont faciles à reconnaître et à mesurer. Cependant, dans de nombreuses applications modernes, le plus grand défi n’est pas l’échec complet mais la latence. Les systèmes sont rarement complètement hors ligne. Au lieu de cela, ils deviennent suffisamment lents pour que les utilisateurs perdent confiance dans l’interface bien avant que quelque chose ne se brise techniquement.
La plupart des ingénieurs front-end en ont fait l’expérience en production. Une page finit par se charger, mais seulement après plusieurs secondes d’attente. Une action de sauvegarde réussit dans le backend, mais l’interface reste inchangée suffisamment longtemps pour que l’utilisateur clique à nouveau sur le bouton. Un tableau de bord s’affiche immédiatement, mais les données critiques apparaissent si tard que l’application semble instable. Dans la pratique, les utilisateurs font rarement la distinction entre « lent » et « en panne ». Si une interaction semble incertaine ou retardée, la confiance diminue rapidement.
À mesure que les systèmes frontaux dépendent de plus en plus de l’infrastructure cloud distribuée, la latence devient une condition de fonctionnement normale plutôt qu’une exception occasionnelle. Les API peuvent dépendre de plusieurs services en aval, les systèmes sans serveur peuvent introduire des retards de démarrage et les mises à jour d’état peuvent se propager de manière asynchrone à travers les régions ou les caches. La fiabilité du frontend ne peut donc plus être définie uniquement par la disponibilité. Cela dépend également de la clarté avec laquelle l’interface se comporte en attendant des dépendances lentes au cloud.
