Évitez les requêtes en cascade côté client pour accélérer votre application

Ce qu'est une requête en cascade et pourquoi elle ralentit votre application

Une « requête en cascade » survient quand votre application lance une requête réseau, attend sa fin, puis démarre la suivante. Chaque requête ajoute son propre délai, si bien que le temps total devient la somme des délais au lieu d'être à peu près égal au plus long d'entre eux.

Ceci nuit au temps avant interactivité parce que l'écran ne peut souvent rien afficher d'utile tant que la dernière requête n'est pas revenue. Les utilisateurs le perçoivent comme une page blanche, un spinner qui traîne, ou une interface qui apparaît mais reste à moitié vide et continue de bouger.

Les cascades se manifestent souvent selon quelques schémas récurrents :

• Des fetchs chaînés où la requête B ne démarre que dans le handler de succès de la requête A.
• Un rendu lié à l'arrivée des données, de sorte que les parties profondes de la page ne montent pas avant que les données précédentes ne soient de retour.
• Des composants imbriqués qui chacun « fetchent au montage », ce qui force les requêtes enfants à attendre les parents.
• Du code « confort » qui transforme un écran en cinq endpoints, alors que les données sont toujours nécessaires ensemble.

C'est particulièrement courant dans les prototypes générés par l'IA. Ils semblent souvent corrects sur une machine locale rapide, puis deviennent lents en production parce que les appels séquentiels s'accumulent.

La bonne nouvelle : vous pouvez généralement éviter les requêtes en cascade côté client sans tout réécrire. Beaucoup de correctifs sont simples : exécuter les requêtes indépendantes en parallèle, commencer le chargement plus tôt et déplacer la coordination côté serveur quand le client fait trop de travail.

Comment repérer rapidement une cascade côté client

Commencez par regarder l'écran comme le ferait un utilisateur. Les cascades donnent souvent une impression d'activité sans réactivité.

Un indice fort est l'expérience de chargement. Si un spinner apparaît, disparaît puis réapparaît, l'app attend probablement une chaîne. Un autre signe est une UI qui arrive par étapes : l'en-tête d'abord, puis la barre latérale, puis le tableau, puis les filtres. Cette sensation d'étagement signifie généralement que les données arrivent une requête à la fois.

Concentrez-vous sur les écrans qui reçoivent le plus de plaintes. Les cascades adorent les dashboards, les pages de paramètres et toute vue avec beaucoup de petites données.

Ce qu'il faut chercher dans le navigateur

Ouvrez DevTools et allez dans l'onglet Network. Rechargez la page et repérez :

• Une longue chaîne où chaque requête ne démarre qu'après la fin de la précédente
• Des écarts d'inactivité entre les requêtes (rien ne se passe pendant que l'UI attend)
• Beaucoup d'appels similaires ne différant que légèrement
• Des requêtes qui bloquent le premier contenu significatif
• Un « fan-out » tardif (un appel revient, puis en déclenche plusieurs autres)

Après avoir repéré une chaîne suspecte, cliquez sur la première requête et vérifiez ce qui l'a déclenchée (Initiator ou stack trace selon le navigateur). Si un fetch dans un composant déclenche un autre fetch dans un composant enfant, vous avez trouvé la forme d'une cascade.

Vérifiez aussi vos logs backend

Une cascade peut aussi apparaître comme des appels répétés pour la même donnée. Un dashboard peut récupérer l'utilisateur courant dans trois composants différents parce que chacun « joue la sécurité » et le demande à nouveau.

Dans les codebases générées par l'IA, c'est fréquent : les composants copient-collent la logique de fetch, créant par accident des chaînes et des duplications.

Exemple : un écran de dashboard qui attend cinq endpoints

Une cascade courante en production est un dashboard issu d'un prototype qui charge les données une étape à la fois. Chaque requête attend la précédente, si bien que la page ne peut pas se stabiliser.

Imaginez que la page fasse ceci au montage : fetcher l'utilisateur, puis l'équipe, puis les permissions, puis la liste de widgets, puis les données de chaque widget. Si chaque appel prend 200–400 ms, les utilisateurs peuvent facilement attendre 1,5–3 secondes avant que l'écran soit utilisable, même avec une connexion correcte.

Voici un ensemble typique d'endpoints (les noms varient, c'est le comportement qui compte) :

• GET /api/me (infos de profil basiques comme nom, avatar)
• GET /api/team (id d'équipe, nom d'équipe)
• GET /api/permissions?teamId=... (rôles, feature flags)
• GET /api/widgets?teamId=... (quelles cartes afficher)
• GET /api/widgets/:id/data (chiffres, graphiques, éléments récents)

Ce qui en fait une cascade n'est pas le nombre de requêtes mais l'ordre forcé.

Souvent la page attend /api/me avant de démarrer /api/team, alors que ces appels pourraient s'exécuter ensemble. Ensuite elle attend les permissions avant de rendre les cartes, donc les utilisateurs regardent une coquille vide. Plus tard, les cartes apparaissent une par une et bougent au fur et à mesure que les données arrivent.

Pour éviter les requêtes en cascade côté client, séparez ce qui est vraiment dépendant de ce qui est simplement codé ainsi.

Certaines requêtes peuvent généralement s'exécuter en parallèle (comme /api/me et /api/team, et parfois /api/widgets). D'autres sont vraiment dépendantes (comme /api/permissions, qui a besoin d'un teamId, et les appels de données des widgets qui ont besoin d'IDs de widgets).

L'idée principale : vous avez souvent seulement besoin d'un petit jeu de champs en amont pour rendre une première vue stable (en-tête, mise en page, placeholders). Tout le reste peut être parallélisé ou regroupé.

Gains rapides avant une grosse refactorisation

Vous n'avez pas toujours besoin d'une réécriture complète pour éviter les cascades côté client. Quelques changements ciblés peuvent enlever des secondes au temps avant interactivité et réduire la sensation de « sautillement ».

Commencez par confirmer ce qui est réellement lent. Dans le panneau Network, triez par Duration et trouvez l'endpoint qui domine la timeline. Il est facile de refactorer trois appels « évidents » et de rater le vrai problème, comme un check de permissions lent.

Ensuite, rendez le premier écran utilisable plus tôt. Si des données ne sont pas nécessaires pour la première vue significative (par exemple « éléments recommandés », « activité récente » ou un graphique lourd), chargez-les après que l'utilisateur puisse déjà cliquer. Les gens tolèrent beaucoup mieux un chargement en arrière-plan qu'une page blanche.

Quelques gains rapides qui paient généralement :

• Démarrez les requêtes plus tôt (sur la navigation ou le changement de route), pas après le montage de composants profonds.
• Évitez les fetchs dupliqués en récupérant les données partagées une seule fois et en les réutilisant.
• Mettez les résultats en cache en mémoire pour un court instant afin qu'une navigation aller-retour ne répète pas les mêmes appels.
• Préchargez l'écran suivant probable quand l'app est idle, mais seulement si c'est sûr et non sensible.
• Déplacez les appels non critiques « après le paint », pour que la page devienne interactive en priorité.

Exemple : les dashboards refetchent souvent "/me" dans chaque tuile parce que chaque widget demande l'utilisateur séparément. Une correction simple consiste à fetcher l'utilisateur une fois au niveau de l'écran et à le passer en props.

Étape par étape : refactoriser des requêtes séquentielles en appels parallèles

Commencez par lister chaque requête qu'un écran effectue et pourquoi il en a besoin. Marquez chacune comme indépendante (peut charger tout de suite) ou dépendante (a besoin d'un ID ou d'une valeur d'une autre réponse).

Une chaîne commune est : charger l'utilisateur, puis charger l'équipe avec user.teamId, puis charger les projets avec team.id. Seuls les appels team et projects sont réellement dépendants. Tout le reste qui n'a pas besoin de ces IDs ne devrait pas rester coincé dans la chaîne.

1) Cartographiez ce qui peut s'exécuter ensemble

Regroupez les requêtes en deux bacs : « peut fetcher maintenant » et « doit attendre X ». Planifiez deux vagues :

• Vague 1 : démarrez en même temps tout ce qui est indépendant.
• Vague 2 : une fois les IDs disponibles, lancez les appels dépendants en parallèle aussi.

2) Remplacez les await chaînés par des appels parallèles

Si vous voyez await après await pour des appels sans rapport, c'est votre première cible de refactor.

async function loadScreenData() {
  const [me, flags, notifications] = await Promise.all([
    api.get("/me"),
    api.get("/feature-flags"),
    api.get("/notifications"),
  ]);

  const [team, projects] = await Promise.all([
    api.get(`/teams/${me.teamId}`),
    api.get(`/teams/${me.teamId}/projects`),
  ]);

  return { me, flags, notifications, team, projects };
}

Gardez les groupes parallèles petits et pertinents. Si un appel est optionnel (comme « tips » ou « news »), chargez-le après le premier paint.

3) Centralisez le chargement de données par écran

Au lieu d'éparpiller les fetchs dans les widgets, créez une fonction « load screen data » (ou un hook au niveau de la route) qui possède les données de l'écran.

Cela rend les dépendances plus faciles à raisonner. Ça rend aussi les retries et le cache plus prévisibles, et ça aide à éviter « cinq spinners » partout.

Visez un état de chargement par écran quand c'est possible. Les utilisateurs préfèrent souvent « le dashboard charge » plutôt que cinq spinners séparés qui se terminent à des moments différents.

Mesurez avant et après. Suivez le temps jusqu'au premier contenu (quand quelque chose d'utile apparaît) et le temps avant interactivité (quand les contrôles répondent).

Quand agréger côté serveur plutôt que côté client

L'aggregation serveur signifie qu'une requête renvoie tout ce dont un écran a besoin, au lieu que le navigateur fasse beaucoup de petits appels.

Si vous voulez éviter les cascades côté client, cela peut être la correction la plus propre car le client n'a plus à coordonner une chaîne de requêtes dépendantes.

L'agrégation aide surtout quand :

• L'écran a besoin de beaucoup de petits endpoints.
• La latence est sensible (utilisateurs mobiles, régions éloignées).
• Chaque endpoint répète le même travail (vérifs d'auth, checks de permission, requêtes DB).

Cinq requêtes qui prennent chacune 150–300 ms peuvent vite se transformer en plus d'une seconde avant que l'UI se stabilise.

Un contrat simple le rend prévisible. Par exemple, un dashboard pourrait appeler un seul endpoint et obtenir les bases en une réponse :

• GET /dashboard -> { profile, team, widgets }

Surveillez la portée. Évitez l'agrégation quand elle crée un payload énorme, ramène des données rarement utilisées « au cas où », ou mélange des données avec des règles de confidentialité différentes. Un autre signe d'alerte est que la réponse devienne si large qu'un petit changement casse beaucoup de parties non liées de l'UI.

Un plan de migration sûr consiste à ajouter l'endpoint agrégé tout en gardant les anciens endpoints opérationnels. Publiez le changement client derrière un feature flag, comparez les résultats, puis basculez progressivement le trafic. Une fois la nouvelle voie stable, retirez les anciens appels.

Réduire la taille des payloads et les appels redondants

Ne regardez pas seulement l'ordre des requêtes. Vérifiez la taille de chaque réponse et la fréquence à laquelle vous demandez la même chose. Même des requêtes parfaitement parallèles peuvent sembler lentes si chaque réponse est lourde ou répétée.

Allégez les réponses API pour ne renvoyer que ce que l'écran utilise. Si une carte a besoin de name, status et updatedAt, n'envoyez pas l'enregistrement complet avec logs, commentaires et longues descriptions.

Regroupez des requêtes similaires quand vous le pouvez. Un motif fréquent est de fetcher une liste, puis de fetcher les détails de chaque élément un par un. Ce comportement N+1 ajoute des délais cachés et une charge serveur supplémentaire. Préférez un endpoint qui accepte des IDs et renvoie les éléments correspondants en une seule réponse.

Les appels redondants viennent souvent de plusieurs composants demandant la même chose indépendamment. Un header, une sidebar et un panneau principal peuvent chacun fetcher l'utilisateur courant, le plan et les feature flags. Placez les données partagées derrière une seule couche de requête (ou un store) pour qu'elles soient récupérées une fois et réutilisées.

Vérifications pratiques qui paient souvent :

• Ajoutez pagination ou limites pour que le premier chargement reste léger.
• Demandez seulement les champs nécessaires (évitez les expansions « include everything »).
• Batcher les appels « fetch by ID » en un seul « fetch by IDs ».
• Dédupliquez les requêtes en cours pour qu'un composant ne déclenche pas deux appels identiques.
• Surveillez les patterns N+1 côté backend aussi (un appel API causant beaucoup de requêtes DB).

Exemple : si votre dashboard charge 200 projets au premier rendu mais n'en affiche que 20, demandez 20 puis chargez-en plus au scroll ou via recherche.

États de chargement, erreurs et cache sans nouveaux bugs

Après avoir refactorisé pour éviter les cascades côté client, le risque suivant est des bugs UX : écrans vides, spinners sans fin et données qui clignotent ou changent de façon inattendue.

Décidez ce qui bloque vraiment l'interaction et ce qui peut arriver plus tard.

Scindez les données en deux groupes :

• Données bloquantes : nécessaires pour afficher la structure de la page ou permettre la première action significative.
• Données non bloquantes : agréables à avoir, mais sûres à charger après que la page soit utilisable.

Afficher l'UI partielle sans tromper

Les skeletons fonctionnent mieux quand ils correspondent à la mise en page finale. Utilisez-les pour réserver l'espace et montrer la structure, puis remplissez avec les vraies valeurs.

Pour les widgets lourds (graphiques, éditeurs, cartes), rendez un placeholder léger et chargez le widget après le contenu principal prêt.

Un pattern simple :

• Rendre la mise en page immédiatement avec des valeurs par défaut sûres
• Afficher des skeletons uniquement là où les données apparaîtront
• Charger les widgets lourds après le contenu principal
• Désactiver les boutons seulement s'ils ont vraiment besoin de données manquantes
• Préférer un texte « dernière mise à jour » plutôt qu'un spinner infini

Erreurs : échouer petit, pas fort

Les appels parallèles font que certaines requêtes peuvent réussir tandis qu'une échoue. Gérez les échecs par section, pas comme « la page entière est cassée ». Affichez un petit message d'erreur avec un retry pour cette partie, et gardez le reste interactif.

Évitez le retry automatique en boucle serrée. Utilisez un backoff et un nombre max de tentatives pour ne pas créer de tempêtes de retry.

Le cache aide, mais seulement avec des règles claires. Décidez combien de temps les données sont « fraîches » (par exemple 30 secondes pour les notifications, 5 minutes pour le profil). Quand c'est périmé, vous pouvez afficher les données en cache instantanément et rafraîchir en arrière-plan, mais signalez-le si l'exactitude est importante.

Enfin, protégez-vous contre les conditions de course quand les utilisateurs vont vite. Si un utilisateur navigue ailleurs, annulez les requêtes en cours et ignorez les réponses tardives. Sinon, une vieille réponse peut écraser un état plus récent.

Erreurs courantes qui réintroduisent les cascades

Les cascades reviennent souvent après un refactor « réussi » parce que le fetch est autorisé dans trop d'endroits. L'objectif n'est pas seulement d'avoir des appels parallèles une fois. C'est de garder l'application structurée pour qu'elle reste parallèle dans le temps.

1) Fetchs cachés dans des composants imbriqués

Un piège fréquent est d'avoir rendu le screen principal parallèle, mais de laisser des composants enfants qui fetchent toujours au montage. La page semble correcte en local, puis un nouveau widget est ajouté et le client commence silencieusement à attendre.

Une règle simple aide : fetcher à un seul niveau (route ou écran), puis passer les données en bas. Si un composant doit vraiment posséder ses données, prenez la décision explicitement et mesurez-la.

2) Requêtes “dépendantes” qui ne le sont pas vraiment

Les équipes enchaînent parfois des appels par sécurité. Mais souvent la requête B a seulement besoin d'un petit morceau de A (comme un ID) que vous avez déjà, ou que vous pourriez obtenir plus tôt.

Un test rapide : « Si A échoue, est-ce que B peut quand même s'exécuter ? » Si oui, elles ne sont pas vraiment dépendantes.

3) Trop de parallélisme et surcharge du backend

Le parallèle est bon jusqu'à devenir un pic. Lancer 20 requêtes en même temps peut déclencher des limites de taux, ralentir la base de données ou provoquer des retries qui ajoutent encore du délai.

Contrôlez le parallélisme :

• Limitez la concurrence (par exemple 4–6 à la fois)
• Dédupliquez les appels identiques entre composants
• Cachez les données stables (comme l'utilisateur courant)
• Ajoutez un backoff pour les retries

4) Le méga-endpoint qui renvoie trop de choses

L'agrégation serveur peut aider, mais un endpoint unique qui renvoie « tout » a tendance à grossir jusqu'à devenir le nouveau goulot d'étranglement. Le client fait un seul appel, mais cet appel devient lourd, lent à calculer et difficile à mettre en cache.

5) Tours supplémentaires dus aux vérifs d'auth

Si l'auth est vérifiée tard, vous pouvez finir avec : charger la page, recevoir un 401, rafraîchir le token, relancer toutes les requêtes.

Rendez l'état d'auth disponible tôt et évitez de lancer les requêtes tant que vous ne savez pas que la session est valide.

Checklist rapide avant de déployer le refactor

Faites une dernière passe en vous concentrant sur le temps utilisateur, pas seulement sur un code plus propre. Les cascades peuvent revenir via de petites modifications comme un nouvel appel de feature flag ou un fetch « au cas où ».

Parcourez l'écran principal comme un nouvel utilisateur en cold load (cache vide). Si la page ne peut rien afficher d'utile tant que beaucoup d'appels ne sont pas terminés, vous avez probablement encore une chaîne cachée.

Une courte checklist pré-livraison :

• Démarrez avec une ou deux requêtes « must-have », puis chargez le reste après que le premier contenu soit visible.
• Démarrez les appels indépendants au même instant (même tick), pas après la résolution d'une autre promesse.
• Désignez un seul propriétaire clair pour le chargement des données de l'écran (une fonction ou un hook).
• Supprimez les duplications par conception (cache client partagé, loaders mémoïsés, ou une réponse agrégée).
• Re-vérifiez le timing réseau et le temps avant interactivité après le refactor en utilisant le même throttling.

Un contrôle de réalité : si votre dashboard lance profile, permissions et workspace en parallèle, puis affiche rapidement header et nav, il devrait rester ainsi. Si plus tard un nouveau badge « billing status » attend que permissions soient résolues avant de commencer à charger, vous avez introduit une mini-cascade.

Étapes suivantes : rendre votre app rapide et fiable

Si votre app semble encore lente après le refactor, supposez qu'il reste d'autres cascades cachées. C'est courant dans les bases de code générées par des outils IA, où un composant écran paraît propre mais un hook dessous enchaîne des requêtes, répète des appels à chaque rendu ou refetch la même donnée par ligne.

Choisissez un écran concret que les utilisateurs utilisent (souvent un dashboard ou la vue d'accueil) et mesurez une chose : combien de temps avant que l'écran utilisable apparaisse. Puis planifiez le plus petit changement qui fait baisser ce délai.

Un audit ciblé vous aide à éviter des « corrections de vitesse » qui créent de nouveaux bugs. Cherchez :

• Fetchs chaînés déclenchés par des mises à jour d'état (fetch A met l'état, ce qui déclenche fetch B)
• Requêtes N+1 (une requête liste puis une requête par élément)
• Appels répétés causés par l'absence de mémoïsation ou des dépendances instables
• Endpoints serveur qui renvoient trop de données, forçant un parsing et rendu lents
• Raccourcis risqués introduits pendant des refactors (comme des secrets dans le client ou une construction de requête non sécurisée)

Si vous avez hérité d'un code généré par l'IA et voulez un second avis, FixMyMess (fixmymess.ai) propose un diagnostic et des réparations pour les apps construites par IA, y compris le démêlage des chaînes de fetch séquentielles et l'optimisation des appels API pour que les écrans se chargent de façon prévisible en production.