Wasserfalldiagramm lesen: was jede Zeile über Tempo verrät

Das Netzwerk-Panel der Entwicklerwerkzeuge zeigt jede Anfrage einer Seite als Zeile einer Tabelle: Name, Status, Typ, Initiator, Größe, Dauer und ganz rechts den Wasserfall. Diese Spalte ist die einzige, die Zeit als Fläche darstellt. Die Netzwerk-Referenz von Chrome for Developers beschreibt ihren Zweck in drei kurzen Sätzen:

Daraus folgen drei Lesehilfen. Erstens ist die senkrechte Reihenfolge eine zeitliche: Eine Zeile weiter unten wurde später angestoßen, sie muss aber nicht später fertig sein. Zweitens bedeutet der waagrechte Abstand zwischen zwei Balkenanfängen, dass der Browser die zweite Anfrage erst später kannte oder erst später losschicken durfte. Drittens lässt sich die Sortierung umstellen: Ein Rechtsklick auf den Tabellenkopf bietet neben der Startzeit auch Antwortzeit, Endzeit, Gesamtdauer und Latenz an (Chrome for Developers). Für die Musterlesung in diesem Beitrag bleibt die Voreinstellung die richtige, denn fast alle Muster sind Muster der Startzeit.

Zwei senkrechte Linien zeichnet das Panel selbst: Blau steht für das Ereignis DOMContentLoaded, Rot für das Ereignis load. Für die Frage nach dem Tempo wichtiger ist eine dritte Linie, die dort fehlt: der Zeitpunkt des Largest Contentful Paint. Ihn liefert die Leistungsaufzeichnung im Performance-Bereich desselben Werkzeugs. Wer ihn sich im Wasserfall dazudenkt oder auf einem Bildschirmfoto einzeichnet, teilt die Anfragen in zwei Gruppen. Was links der LCP-Linie liegt, kann den LCP verzögert haben. Was rechts davon liegt, betrifft ihn nicht mehr, wohl aber Interaktion, Hauptthread und Datenvolumen.

Dass es auf das Bild ankommt und nicht auf die einzelne Zeile, zeigt schon die Menge. Am Desktop stellt die mittlere Seite sogar 77 Anfragen (Web Almanac 2025). Zeile für Zeile prüft das kaum jemand. Wer aber weiß, wie eine Treppe, eine Lücke oder ein Wartebalken aussieht, findet die zwei oder drei Zeilen, auf die es ankommt, in wenigen Minuten, und kann sie im Team so benennen, dass jeder dieselbe Stelle meint.

Ein Wasserfall ist nur so aussagekräftig wie die Aufnahme, aus der er stammt. Dateien aus dem Browser-Cache, Anfragen von Erweiterungen und ein schnelles Büronetz verdecken genau die Muster, um die es geht. Fünf Einstellungen machen eine Aufnahme lesbar und mit einer späteren vergleichbar:

Hilfreich ist außerdem die Einstellung „Capture screenshots“. Sie legt während des Ladens Bildschirmfotos an, und ein Klick auf ein Vorschaubild blendet alle Anfragen aus, die erst danach begonnen haben (Chrome for Developers). So lässt sich ohne Rechnen ablesen, welche Anfragen vor dem ersten sichtbaren Inhalt liefen und welche erst danach. Für die Abstimmung im Team lässt sich die Aufnahme als HAR-Datei weitergeben, und zwar in der bereinigten Fassung ohne Cookies und Anmeldedaten.

Gemessen wird die Vorlage, um die es geht: Produktseite, Kategorie, Warenkorb, Aktionsseite. Die Startseite ist oft nicht die langsamste Seite eines Shops, und ihr Wasserfall unterscheidet sich von dem einer Produktseite oft deutlich, weil dort andere Bilder, Skripte und Endpunkte im Spiel sind. Jede Vorlage braucht darum ihre eigene Aufnahme.

Bei 76 Prozent der mobilen Seiten ist das LCP-Element ein Bild (Web Almanac 2025). Im Wasserfall lässt sich darum in den meisten Fällen eine Zeile benennen, auf die es ankommt: die Datei des LCP-Bildes. Die Faustregel von web.dev ist einfach. Das LCP-Bild sollte zur selben Zeit starten wie die erste Ressource, die die Seite lädt (web.dev). Beginnt es deutlich später, klafft zwischen dem Start der ersten Unteranfrage und dem Start des Bildes eine Lücke, in der die Leitung für das Wichtigste ungenutzt bleibt.

Diese Lücke ist die Ladeverzögerung, die zweite der vier LCP-Phasen. Für eine gut optimierte Seite nennt web.dev als Richtwert: Die Serverantwort und das Laden der Ressource machen je rund 40 Prozent des LCP aus, die Ladeverzögerung und die Renderverzögerung jeweils unter 10 Prozent (web.dev). Die Werte sind nach web.dev ausdrücklich Richtwerte, keine festen Regeln. Im Wasserfall genügt darum ein Vergleich: Ist die Lücke breiter als der Downloadbalken des Bildes, liegt hier der größte Hebel.

Eine häufige Ursache ist schnell gefunden. Rund 16 Prozent der Seiten laden ihr LCP-Bild per Lazy Loading und verzögern damit den Hauptinhalt (Web Almanac 2025). Im Wasserfall startet das Bild dann erst nach dem Layout, oft hinter mehreren Skripten. Weitere Kandidaten sind ein Kopfbereich als Karussell, dessen erstes Bild erst ein Skript einsetzt, und ein Einwilligungsbanner, das selbst zum größten Element wird und das eigentliche Bild verdrängt.

Eine zweite, meist schmalere Lücke kann nach dem Bild liegen: zwischen dem Ende seines Downloads und der LCP-Linie. Das ist die Renderverzögerung. Sie entsteht, wenn das Bild zwar geladen ist, aber noch nicht gezeigt werden kann, etwa weil ein Stylesheet die Darstellung blockiert oder weil ein Skript das Element erst einblendet. Wie man LCP-Bild und Wasserfall einer Produktseite Punkt für Punkt prüft, steht als Liste im Abschnitt LCP-Element und Wasserfall der Produktseite.

Manchmal ist eine Datei früh bekannt und startet trotzdem spät. Im Balken erscheint dann am Anfang ein langer Abschnitt Queueing oder Stalled, obwohl die Leitung frei scheint. Der Browser hält die Anfrage zurück, weil er andere für wichtiger hält. Die Priorität richtet sich nach der Art der Ressource und ihrer Stellung im Dokument (Chrome for Developers). Die Spalte Priority zeigt, wie er entschieden hat, und mit großen Zeilen auch, ob sich die Einstufung während des Ladens geändert hat. Über den Filter priority: lassen sich alle Anfragen einer Stufe gemeinsam anzeigen.

Bilder sind der typische Fall. Sie starten in Chrome mit niedriger Priorität und werden erst beim Layout hochgestuft, wenn sie im sichtbaren Bereich liegen. Seit Chrome 117 erhalten die ersten fünf großen Bilder mittlere Priorität, und zwei davon können in der ersten, engen Ladephase parallel laden (web.dev). Das hilft, ersetzt aber keine Angabe im Markup: Mit fetchpriority="high" startet das LCP-Bild sofort mit hoher Priorität. Auf 17 Prozent der mobilen Seiten mit LCP-Bild steht diese Angabe inzwischen (Web Almanac 2025). Wie man sie setzt und warum sie nur bei einem Element hilft, steht im Beitrag zu fetchpriority.

Das Protokoll spielt mit. Unter HTTP/1.1 greift zusätzlich die Grenze von sechs Verbindungen je Herkunft; die Warteschlangen stehen dann im Wasserfall wie Blöcke übereinander, weil jede weitere Anfrage auf eine freie Verbindung wartet. Unter HTTP/2 laufen die Anfragen einer Herkunft über eine gemeinsame Verbindung, und der Standard empfiehlt, mindestens 100 gleichzeitige Streams zuzulassen (RFC 9113). Dort entscheidet nicht die Zahl der Verbindungen, sondern die Reihenfolge, in der der Server antwortet.

Für diese Reihenfolge gibt es ein eigenes Signal. RFC 9218 beschreibt eine Dringlichkeit auf einer Skala von 0 bis 7, bei der kleinere Werte Vorrang haben (RFC 9218); fehlt die Angabe, gilt der Wert 3 (RFC 9218). Ob Server oder CDN die Signale des Browsers beachten, zeigt der Wasserfall: Kommt das LCP-Bild trotz hoher Priorität erst nach großen Skripten an, liegt die Ursache nicht im Markup, sondern in der Auslieferung. Auch alte Kunstgriffe wie das Verteilen von Dateien auf viele Subdomains schaden unter HTTP/2 eher: Jede Subdomain braucht einen eigenen Verbindungsaufbau, und über getrennte Verbindungen hinweg kann der Browser die Prioritäten nicht mehr gemeinsam steuern.

Das sechste Muster erkennt man an der Spalte Domain: eine Gruppe von Zeilen anderer Herkunft, die jeweils mit eigener Namensauflösung und eigenem Verbindungsaufbau beginnen. Bei mindestens 90 Prozent der Seiten ist wenigstens ein Drittanbieter beteiligt (Web Almanac 2025). Oft hängen diese Zeilen aneinander, weil ein Tag-Manager ein Skript lädt, das ein weiteres lädt. Die mittlere Tiefe solcher Einbindungsketten liegt bei 3 (Web Almanac 2025). Das ist die Treppe aus dem ersten Muster, nur auf fremden Servern, auf deren Antwortzeit Sie keinen Einfluss haben.

Für das Tempo zählen zwei Fragen. Erstens: Liegt der Block links der LCP-Linie und konkurriert er mit dem LCP-Bild um Bandbreite und Hauptthread? Zweitens: Kommt das LCP-Bild selbst von einer fremden Herkunft? Bei 16 bis 18 Prozent der Seiten liegt das LCP-Bild auf einem anderen Host als das Dokument (Web Almanac 2025). Dann steht vor seinem Download ein eigener Verbindungsaufbau, den ein preconnect vorziehen oder die Auslieferung über die eigene Domain ganz vermeiden kann.

Ob ein fremdes Skript wirklich bremst, lässt sich ohne Ausbau prüfen. Der Filter domain: zeigt nur die Zeilen einer Herkunft, mit dem Kästchen Invert blendet man sie aus (Chrome for Developers). Im Bereich Request Conditions lassen sich einzelne Adressen probeweise sperren, und der Vergleich zweier Aufnahmen zeigt, was die Seite ohne sie gewinnt. Wie man danach entscheidet, was bleibt, was verzögert lädt und was durch eine Fassade ersetzt wird, beschreibt der Beitrag Third-Party-Skripte entschlacken.

Ende November ändert sich in vielen Shops die Startseite und mit ihr der Wasserfall. Aktionsbanner, Countdown-Skripte, zusätzliche Kampagnenpixel und neue Landingpages kommen hinzu, oft kurzfristig und ohne eigene Messung. Jede dieser Ergänzungen kann eines der sechs Muster erzeugen: Das Banner wird zum neuen LCP-Element und startet per Skript, das Pixel öffnet einen neuen Block fremder Herkunft, die Landingpage hängt an einer Weiterleitung aus der Kampagnenadresse.

Der Aufwand für die Kontrolle ist überschaubar. Eine Aufnahme der Aktionsseite und eine der normalen Startseite, beide mit abgeschaltetem Cache und derselben Drosselung, nebeneinandergelegt, zeigen sofort, was neu ist. Zusammen mit dem Vorwärmen des Caches zum Aktionsstart ist das eine gut investierte Stunde vor einer Woche mit viel Kampagnenverkehr. Diese Punkte gehören auf die Liste: