Clientseitige Waterfall-Anfragen vermeiden, um Ihre App zu beschleunigen

Was Waterfall-Fetches sind und warum sie Ihre App bremsen

Eine „Waterfall“-Anfrage entsteht, wenn Ihre App eine Netzwerk-Anfrage startet, auf deren Abschluss wartet und erst dann die nächste startet. Jede Anfrage bringt ihre eigene Verzögerung mit, sodass die Gesamtdauer zur Summe aller Wartezeiten wird, statt ungefähr der längsten Einzelwartezeit zu entsprechen.

Das schadet der Zeit bis zur Interaktivität, weil der Bildschirm oft nichts Nützliches anzeigt, bis die letzte Anfrage zurückkommt. Nutzer erleben das als leere Seite, einen lang anhaltenden Spinner oder eine UI, die zwar erscheint, aber halb leer bleibt und ständig springt.

Waterfalls treten meist in einigen wiederkehrenden Mustern auf:

• Verkettete Fetches, bei denen Anfrage B nur im Erfolgs-Handler von Anfrage A gestartet wird.
• Rendering, das an das Eintreffen von Daten gebunden ist, sodass tiefere Teile der Seite gar nicht gemountet werden, bis frühere Daten zurück sind.
• Verschachtelte Komponenten, die jeweils „on mount“ fetchen, wodurch Kind-Anfragen auf die Eltern warten müssen.
• „Bequemlichkeits“-Code, der einen Bildschirm in fünf Endpunkte aufspaltet, obwohl die Daten immer gemeinsam gebraucht werden.

Das ist besonders häufig in AI-generierten Prototypen. Lokal auf einer schnellen Maschine wirken sie oft in Ordnung, in Produktion werden sie träge, weil sequentielle Aufrufe sich summieren.

Die gute Nachricht: In der Regel lassen sich clientseitige Waterfall-Fetches verhindern, ohne alles neu zu schreiben. Viele Fixes sind unkompliziert: unabhängige Anfragen parallelisieren, früher beginnen zu laden und Koordinationsarbeit vom Client auf den Server verlagern, wenn der Client zu viel macht.

Wie Sie einen clientseitigen Waterfall schnell erkennen

Beginnen Sie, den Bildschirm wie ein Nutzer zu beobachten. Waterfalls sehen oft „beschäftigt“ aus, fühlen sich aber nicht responsiv an.

Ein starkes Indiz ist das Ladeerlebnis. Wenn ein Spinner auftaucht, verschwindet und dann wieder erscheint, wartet die App wahrscheinlich in einer Kette. Ein weiteres Zeichen ist UI, die in Etappen ankommt: zuerst Header, dann Sidebar, dann die Tabelle, dann Filter. Dieses gestaffelte Gefühl bedeutet meist, dass Daten eine Anfrage nach der anderen eintreffen.

Konzentrieren Sie sich auf die Bildschirme, über die sich Nutzer am meisten beschweren. Waterfalls lieben Dashboards, Einstellungsseiten und jede Ansicht mit vielen „kleinen“ Datenanforderungen.

Worauf Sie im Browser achten sollten

Öffnen Sie die DevTools und gehen Sie zum Network-Tab. Laden Sie die Seite neu und achten Sie auf:

• Eine lange Kette, in der jede Anfrage erst startet, nachdem die vorherige fertig ist
• Leerlaufpausen zwischen Anfragen (während der UI nichts passiert)
• Viele ähnliche Calls, die sich nur leicht unterscheiden
• Anfragen, die das erste sinnvolle Rendering blockieren
• Ein späten „Fan-out“ (ein Call kommt zurück und triggert mehrere weitere)

Nachdem Sie eine verdächtige Kette gefunden haben, klicken Sie auf die erste Anfrage und prüfen Sie, was sie ausgelöst hat (Initiator oder Stack-Trace, je nach Browser). Wenn ein Fetch in einer Komponente einen weiteren Fetch in einer Kindkomponente auslöst, haben Sie die Waterfall-Form gefunden.

Abgleich mit Ihren Backend-Logs

Ein Waterfall kann sich auch als wiederholte Calls für dieselben Daten zeigen. Ein Dashboard könnte den aktuellen Nutzer in drei verschiedenen Komponenten anfragen, weil jede „auf Nummer sicher“ geht und erneut anfragt.

In AI-generierten Codebasen ist das häufig: Komponenten kopieren Fetch-Logik und erzeugen so unbeabsichtigt Ketten und Duplikate.

Beispiel: Ein Dashboard, das auf fünf Endpunkte wartet

Ein typischer Waterfall ist ein Dashboard aus einem Prototyp, das Daten Schritt für Schritt lädt. Jede Anfrage wartet auf die vorherige, sodass die Seite nicht zur Ruhe kommt.

Stellen Sie sich vor, die Seite macht beim Mounten Folgendes: GET /api/me, dann GET /api/team, dann GET /api/permissions, dann GET /api/widgets, dann für jedes Widget GET /api/widgets/:id/data. Wenn jeder Call 200–400 ms braucht, müssen Nutzer leicht 1,5–3 Sekunden warten, bis die Seite brauchbar wirkt — selbst bei guter Verbindung.

Hier ein typischer Satz Endpunkte (Namen variieren, wichtig ist das Verhalten):

• GET /api/me (Basisprofil wie Name, Avatar)
• GET /api/team (Team-ID, Teamname)
• GET /api/permissions?teamId=... (Rollen, Feature-Flags)
• GET /api/widgets?teamId=... (welche Karten gezeigt werden)
• GET /api/widgets/:id/data (Zahlen, Diagramme, aktuelle Items)

Wichtig ist nicht die Anzahl der Requests, sondern die erzwungene Reihenfolge.

Oft wartet die Seite auf /api/me, bevor sie /api/team startet, obwohl die Calls zusammen laufen könnten. Dann blockiert sie die Permissions-Abfrage, bevor irgendwelche Karten gerendert werden, sodass Nutzer auf eine leere Hülle starren. Später tauchen Karten nach und nach auf und verschieben das Layout, während Daten eintreffen.

Um clientseitige Waterfall-Fetches zu verhindern, trennen Sie, was wirklich abhängig ist, von dem, was nur so programmiert wurde.

Manche Calls können oft parallel laufen (z. B. /api/me und /api/team, manchmal auch /api/widgets). Andere sind wirklich abhängig (z. B. /api/permissions, das eine teamId braucht, oder Widget-Data-Calls, die Widget-IDs benötigen).

Die Hauptidee: Für die stabile erste Ansicht brauchen Sie meist nur ein kleines Set an Feldern (Header, Layout, Platzhalter). Der Rest kann parallelisiert oder gruppiert werden.

Schnelle Verbesserungen vor einem großen Refactor

Sie müssen nicht immer alles neu schreiben, um clientseitige Waterfalls zu verhindern. Einige gezielte Änderungen können Sekunden von der Time-to-Interactive nehmen und das "springende" Gefühl reduzieren.

Starten Sie damit, festzustellen, was tatsächlich langsam ist. Sortieren Sie im Network-Panel nach Duration und finden Sie den Endpunkt, der die Timeline dominiert. Es ist leicht, drei „offensichtliche“ Calls zu refaktorisieren und das eigentliche Problem zu übersehen, etwa einen langsamen Permissions-Check.

Machen Sie den ersten Bildschirm schneller nutzbar. Wenn Daten für die erste sinnvolle Ansicht nicht nötig sind (z. B. „Empfehlungen“, „letzte Aktivitäten“ oder ein schweres Diagramm), laden Sie sie erst, nachdem der Nutzer interagieren kann. Nutzer tolerieren Hintergrundladen besser als eine leere Seite.

Ein kurzer Satz Quick Wins, der sich oft lohnt:

• Starten Sie Requests früher (bei Navigation oder Routenwechsel), nicht erst nach dem Mounten tiefer Komponenten.
• Stoppen Sie doppelte Fetches, indem Sie gemeinsame Daten einmal holen und wiederverwenden.
• Cachen Sie Ergebnisse kurzzeitig im Speicher, damit ein Hin-und-her nicht dieselben Calls wiederholt.
• Prefetchen Sie den wahrscheinlich nächsten Bildschirm, wenn die App idle ist — nur, wenn es sicher ist.
• Verschieben Sie nicht-kritische Calls auf "after paint", damit die Seite zuerst interaktiv wird.

Beispiel: Dashboards fragen oft "/me" in jedem Tile neu an, weil jede Widget-Komponente den User separat anfragt. Eine einfache Lösung ist, den Nutzer einmal auf Screen-Ebene zu holen und dann weiterzugeben.

Schritt für Schritt: sequentielle Requests in parallele Aufrufe umwandeln

Listen Sie zuerst alle Requests auf, die ein Bildschirm macht, und warum er sie braucht. Markieren Sie jeden als unabhängig (kann sofort laden) oder abhängig (braucht eine ID oder einen Wert aus einer anderen Antwort).

Eine häufige Kette ist: Nutzer laden, dann Team mit user.teamId, dann Projekte mit team.id. Nur Team- und Projekt-Calls sind wirklich abhängig. Alles andere, das diese IDs nicht braucht, sollte nicht in der Kette stecken.

1) Karten, was zusammen laufen kann

Gruppieren Sie Requests in zwei Buckets: „kann jetzt geladen werden“ und „muss auf X warten“. Planen Sie zwei Wellen:

• Welle 1: Starten Sie alles Unabhängige gleichzeitig.
• Welle 2: Sobald die benötigten IDs vorliegen, starten Sie die abhängigen Calls ebenfalls parallel.

2) Verkettete awaits durch parallele Calls ersetzen

Wenn Sie await nach await für unabhängige Calls sehen, ist das Ihr erstes Refactor-Ziel.

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 };
}

Halten Sie parallele Gruppen klein und sinnvoll. Wenn ein Call optional ist (z. B. „Tips“ oder „News“), laden Sie ihn nach dem ersten Paint.

3) Datenlade-Logik pro Bildschirm zentralisieren

Statt Fetches über Widgets zu verteilen, erstellen Sie eine einzige load screen data-Funktion (oder einen Routen-Hook), der die Daten des Bildschirms verwaltet.

Das macht Abhängigkeiten leichter nachvollziehbar. Außerdem werden Retries und Caching vorhersehbarer und Sie vermeiden „fünf Spinner“ überall.

Streben Sie nach einem Ladezustand pro Bildschirm, wenn möglich. Nutzer bevorzugen meist „Das Dashboard lädt“ gegenüber fünf separaten Spinnern, die zu unterschiedlichen Zeiten fertig werden.

Messen Sie vor und nach der Änderung. Tracken Sie Time to First Content (wann etwas Nützliches erscheint) und Time-to-Interactive (wann Controls reagieren).

Wann Sie auf dem Server aggregieren sollten statt auf dem Client

Server-Aggregation bedeutet, dass eine Anfrage alles zurückgibt, was ein Bildschirm braucht, statt dass der Browser viele kleine Calls macht.

Wenn Sie clientseitige Waterfalls verhindern wollen, ist das oft die sauberste Lösung, da der Client die Koordination nicht mehr übernehmen muss.

Aggregation hilft besonders, wenn:

• Der Bildschirm viele kleine Endpunkte braucht.
• Latenz spürbar ist (Mobile, entfernte Regionen).
• Jeder Endpunkt die gleiche Arbeit wiederholt (Auth, Permission-Checks, DB-Lookups).

Fünf Requests mit je 150–300 ms können schnell zu über einer Sekunde führen, bevor die UI sich beruhigt.

Ein einfacher Vertrag hält es vorhersehbar. Ein Dashboard könnte z. B. einen Endpoint haben, der die Basics in einer Antwort liefert:

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

Achten Sie auf den Umfang. Vermeiden Sie Aggregation, wenn dadurch ein riesiges Payload entsteht, selten genutzte Daten „just in case“ gezogen werden oder verschiedene Datenschutzregeln vermischt werden. Ein weiteres Warnsignal ist, wenn die Antwort so breit wird, dass eine kleine Änderung viele UI-Teile bricht.

Ein sicherer Migrationsplan ist, den aggregierten Endpoint hinzuzufügen und die alten Endpunkte weiterlaufen zu lassen. Schalten Sie die Client-Änderung hinter einem Feature-Flag, vergleichen Sie die Ergebnisse und routen Sie dann schrittweise Traffic um. Wenn der neue Pfad stabil ist, retiren Sie die alten Calls.

Payload-Größe und redundante Calls reduzieren

Schauen Sie nicht nur auf die Reihenfolge der Requests. Prüfen Sie, wie groß jede Antwort ist und wie oft dieselben Daten angefragt werden. Selbst perfekt parallele Requests wirken langsam, wenn jede Antwort groß ist oder wiederholt angefragt wird.

Trimmen Sie API-Antworten auf das, was der Bildschirm wirklich nutzt. Wenn eine Karte name, status und updatedAt braucht, liefern Sie nicht den kompletten Datensatz mit Logs, Kommentaren und langen Beschreibungen.

Batchen Sie ähnliche Abfragen, wo möglich. Ein übliches Muster ist, zuerst eine Liste zu laden und dann Details für jedes Element einzeln zu holen. Dieses N+1-Verhalten bringt versteckte Verzögerungen und zusätzliche Serverlast. Bevorzugen Sie einen Endpoint, der IDs akzeptiert und passende Items in einer Antwort zurückgibt.

Redundante Calls entstehen oft, weil mehrere Komponenten unabhängig dasselbe anfragen. Header, Sidebar und Hauptbereich könnten jeweils den aktuellen Nutzer, Plan und Feature-Flags holen. Legen Sie gemeinsame Daten hinter eine einzige Anfrage-Schicht (oder einen Store), sodass sie einmal geladen und wiederverwendet werden.

Praktische Checks, die sich meist lohnen:

• Fügen Sie Pagination oder Limits hinzu, damit das erste Laden klein bleibt.
• Fordern Sie nur benötigte Felder an (vermeiden Sie "alles einschließen").
• Batchen Sie "fetch by ID"-Aufrufe in einen "fetch by IDs"-Call.
• Deduplizieren Sie in-flight Requests, damit zwei Komponenten nicht denselben Aufruf triggern.
• Achten Sie auch im Backend auf N+1-Muster (ein API-Call, der viele DB-Queries auslöst).

Beispiel: Wenn Ihr Dashboard beim ersten Rendern 200 Projekte lädt, aber nur 20 zeigt, fordern Sie zuerst 20 an und laden mehr beim Scrollen oder bei Suche nach.

Ladezustände, Fehler und Caching ohne neue Bugs

Nach dem Refactor, der Waterfalls verhindert, drohen UX-Bugs: leere Bildschirme, Spinner, die nie verschwinden, oder Daten, die aufblitzen oder unerwartet wechseln.

Entscheiden Sie, was wirklich die Interaktion blockiert und was später eintreffen kann.

Teilen Sie Daten in zwei Gruppen:

• Blocking-Daten: nötig, um die Seitenstruktur zu rendern oder die erste sinnvolle Aktion zu erlauben.
• Non-blocking-Daten: nett zu haben, können aber nach der ersten Nutzbarkeit geladen werden.

Teil-UI anzeigen, ohne falsche Erwartungen zu wecken

Skeletons funktionieren am besten, wenn sie dem finalen Layout entsprechen. Nutzen Sie sie, um Platz zu reservieren und Struktur zu zeigen, und füllen Sie anschließend echte Werte nach.

Für schwere Widgets (Charts, Editoren, Karten) rendern Sie einen leichten Platzhalter und laden das Widget, nachdem der Hauptinhalt bereit ist.

Ein einfaches Muster:

• Rendern Sie das Layout sofort mit sicheren Defaults
• Zeigen Sie Skeletons nur dort, wo Daten erscheinen
• Laden Sie schwere Widgets nach dem primären Inhalt
• Deaktivieren Sie Buttons nur, wenn sie wirklich fehlende Daten brauchen
• Bevorzugen Sie "zuletzt aktualisiert" statt endloser Spinner

Fehler: klein fehlschlagen, nicht laut

Parallele Calls bedeuten, dass einige Requests erfolgreich sind, während einer fehlschlägt. Behandeln Sie Fehler pro Sektion, nicht als "die ganze Seite ist kaputt". Zeigen Sie eine kleine Fehlermeldung mit Retry für den betroffenen Teil und halten Sie den Rest interaktiv.

Vermeiden Sie tight-loop Auto-Retries. Nutzen Sie Backoff und eine Max-Retry-Anzahl, damit Sie keine Retry-Stürme erzeugen.

Caching hilft, aber nur mit klaren Regeln. Legen Sie fest, wie lange Daten "frisch" sind (z. B. 30 Sekunden für Notifications, 5 Minuten für Profilinfo). Wenn Daten veraltet sind, können Sie gecachte Werte sofort zeigen und im Hintergrund aktualisieren — aber kennzeichnen Sie das, wenn Genauigkeit wichtig ist.

Schützen Sie sich schließlich vor Race-Conditions, wenn Nutzer schnell navigieren. Wenn ein Nutzer weg navigiert, brechen Sie laufende Requests ab und ignorieren Sie verspätete Antworten. Ansonsten kann eine alte Antwort neuere Zustände überschreiben.

Häufige Fehler, durch die Waterfalls zurückkehren

Waterfalls kommen oft nach einem scheinbar erfolgreichen Refactor zurück, weil Fetch-Logik wieder an zu vielen Stellen zugelassen wird. Das Ziel ist nicht nur einmalige parallele Calls. Es geht darum, die App so zu formen, dass sie dauerhaft parallel bleibt.

1) Versteckte Fetches in verschachtelten Komponenten

Ein häufiger Fall ist, dass die Hauptseite auf parallele Aufrufe umgestellt wurde, aber Kindkomponenten weiterhin beim Mounten fetchen. Lokal wirkt die Seite gut, dann wird ein neues Widget hinzugefügt und der Client wartet plötzlich darauf.

Eine einfache Regel hilft: Fetch auf einer Ebene (Route oder Screen) und geben Sie Daten nach unten weiter. Wenn eine Komponente wirklich ihre eigene Datenhoheit braucht, machen Sie diese Entscheidung explizit und messbar.

2) „Abhängige“ Requests, die gar nicht abhängig sind

Teams ketten manchmal Calls, weil es sich sicherer anfühlt. Oft braucht Anfrage B aber nur ein kleines Feld aus A (z. B. eine ID), das Sie bereits haben oder früher bekommen könnten.

Ein schneller Test: "Wenn A fehlschlägt, kann B trotzdem laufen?" Wenn ja, sind sie nicht wirklich abhängig.

3) Über-Parallelisieren und Backend überlasten

Parallel ist gut — bis es ein Burst wird. 20 Requests auf einmal können Ratenbegrenzungen triggern, die Datenbank verlangsamen oder Retries auslösen, die noch mehr Verzögerung bringen.

Behalten Sie die Parallelität im Griff:

• Begrenzen Sie Concurrency (z. B. 4–6 gleichzeitig)
• Deduplizieren Sie identische Calls über Komponenten hinweg
• Cachen Sie stabile Daten (z. B. den aktuellen Nutzer)
• Fügen Sie Backoff für Retries ein

4) Der Mega-Endpoint, der zu viel zurückgibt

Server-Aggregation kann helfen, aber ein einzelner Endpoint, der "alles" zurückgibt, wächst oft, bis er selbst der neue Flaschenhals ist. Der Client macht einen Call, aber dieser wird schwer, langsam zu berechnen und schlecht zu cachen.

5) Extra Roundtrips durch späte Auth-Checks

Wenn Auth erst spät geprüft wird, kann folgendes passieren: Seite lädt, 401 kommt, Token wird erneuert, alle Requests werden erneut versucht.

Machen Sie den Auth-Status früh verfügbar und feuern Sie keine Requests, bevor die Session bekannt ist.

Kurze Checkliste vor dem Shipping des Refactors

Machen Sie einen letzten Durchgang mit Fokus auf Nutzerzeit, nicht nur saubereren Code. Waterfalls schleichen sich oft durch kleine Änderungen wieder ein, wie ein neuer Feature-Flag-Call oder ein zusätzlicher "just in case"-Fetch.

Gehen Sie den Hauptbildschirm wie ein Erstnutzer bei kaltem Start (leerer Cache) durch. Wenn die Seite nichts Nützliches zeigen kann, bis viele Calls fertig sind, haben Sie wahrscheinlich noch eine versteckte Kette.

Eine kurze Pre-Ship-Checkliste:

• Starten Sie mit ein oder zwei "must-have"-Requests, laden Sie den Rest nach dem ersten sichtbaren Inhalt.
• Starten Sie unabhängige Calls im selben Moment (gleicher Tick), nicht nachdem ein anderes Promise resolved.
• Haben Sie einen klaren Besitzer für das Laden der Bildschirmdaten (eine Funktion oder Hook).
• Entfernen Sie Duplikate durch Design (gemeinsamer Client-Cache, memoized Loader oder ein aggregiertes Response).
• Überprüfen Sie Network-Timing und Time-to-Interactive nach dem Refactor mit denselben Throttling-Einstellungen.

Ein Realitäts-Check: Wenn Ihr Dashboard Profil, Permissions und Workspace parallel fired und dann Header und Nav schnell zeigt, sollte das so bleiben. Wenn ein neuer "Billing Status"-Badge später auf Permissions wartet, bevor er lädt, haben Sie eine neue Mini-Waterfall eingeführt.

Nächste Schritte: Bringen Sie Ihre App zurück zu schnellem, verlässlichem Laden

Wenn Ihre App sich nach dem Refactor noch langsam anfühlt, gehen Sie davon aus, dass weitere Waterfalls versteckt sind. Das ist in AI-generierten Codebasen üblich, wo ein Screen-Component sauber aussieht, aber ein Hook darunter Requests verketten, bei jedem Render neu laden oder dieselben Daten pro Reihe erneut anfragt.

Wählen Sie einen echten Bildschirm, den Nutzer brauchen (oft Dashboard oder Home), und messen Sie eine Zahl: Wie lange dauert es, bis der erste nutzbare Bildschirm erscheint? Planen Sie dann die kleinste Änderung, die diese Zahl verbessert.

Ein fokussiertes Audit hilft, "+Speed-Fixes+" zu vermeiden, die neue Bugs bringen. Achten Sie auf:

• Verkettete Fetches, die durch State-Updates ausgelöst werden (Fetch A setzt State, das Fetch B triggert)
• N+1-Requests (eine List-Anfrage plus für jedes Item ein weiterer Call)
• Wiederholte Calls durch fehlende Memoization oder instabile Dependencies
• Server-Endpunkte, die zu viele Daten zurückgeben, was Parsing und Rendering verlangsamt
• Riskante Abkürzungen, die bei Refactors auftreten (z. B. Secrets im Client oder unsichere Query-Erzeugung)

Wenn Sie ein unordentliches, AI-generiertes Projekt geerbt haben und eine zweite Meinung möchten: FixMyMess (fixmymess.ai) bietet Code-Diagnose und Reparaturen für kaputte AI-erstellte Apps, inklusive Entwirrung sequentieller Fetch-Ketten und Straffung von API-Calls, damit Bildschirme in Produktion vorhersehbar laden.