Resource-Wasserfall
Wasserfall-Diagramm aller statischen Resources einer Seite — Vollständiges Page-Speed-Audit.
So funktioniert dieses Tool
Resource-Wasserfall analysiert alle Resources einer Seite — den vollständigen Page-Speed-Audit-Workflow: Welche Resources lädt die Seite (HTML, CSS, JavaScript, Bilder, Fonts, iframes, XHR/fetch), wie groß ist jede einzelne, wie lange braucht sie (DNS-Auflösung, TCP-Connect, TLS-Handshake, TTFB, Total) und wer ist der Drittanbieter dahinter? Wir laden die Seite in einem echten Headless-Chromium und sehen daher genau das, was auch ein Besucher im Browser sieht — inklusive JavaScript-injizierter Requests, defer/async-Reihenfolge und Lazy-Loading.
Typische Anwendungsfälle
- Vor dem Relaunch prüfen: bremst der neue WP-Builder die Seite mit zu vielen JS-Bundles?
- Drittanbieter-Audit: Wie viele externe Domains lädt die Seite — passt das zur Cookie-Banner-Liste?
- Größen-Optimierung: das größte Image als Wasserfall-Eintrag identifizieren und konvertieren (WebP, Lazy-Load)
- TTFB-Bottlenecks finden: welche Resource hat den längsten Wait (TTFB)?
- Cache-Audit: laden viele Resources frisch, statt aus dem CDN-Cache (404/Cache-Miss-Verdacht)?
- Vor einem Lighthouse-Run: schauen ob die Resource-Liste plausibel ist
Häufige Fragen
Wie genau ist die Messung im Vergleich zum echten Browser?
Sehr nah dran — wir laden die Seite in einem echten Headless-Chromium (gleiche Engine wie Chrome). Erfasst werden DNS, TCP, TLS, TTFB und Total pro Resource direkt aus den Network-Events des Browsers. Auch JavaScript-injizierte fetch/XHR-Requests, defer/async-Timing, HTTP/2-Connection-Reuse und Connection-Pool-Limits sind sichtbar. Im Vergleich zu Chrome DevTools fehlen: Browser-Cache-Hits (wir starten immer mit leerem Cache, das ist das First-Visit-Worst-Case-Szenario das beim Audit relevanter ist) und Service-Worker-Optimierungen.
Werden auch JavaScript-nachgeladene Requests erfasst?
Ja. Da wir die Seite in einem echten Browser ausführen, erfassen wir alles — fetch/XHR aus dem JavaScript, dynamisch erzeugte Script-Tags, Lazy-Loaded-Bilder via IntersectionObserver, Web-Fonts die per CSS @font-face nachgeladen werden, Tracker-Pixel die Analytics-Bibliotheken nachladen.
Werden alle Resources gemessen?
Im Browser werden bis zu 200 Resources erfasst, auch per JavaScript nachgeladene — größere Seiten werden in der Reihenfolge ihres Auftretens abgeschnitten. Kann der Browser die Seite nicht laden, liest das Werkzeug ersatzweise das HTML: dann bis zu 80 Resources und ohne JavaScript-Nachzügler.
Was bedeutet „3rd"-Badge bei einer Resource?
Die Resource liegt nicht auf der eigenen Domain sondern auf einem fremden Host (CDN, Tracker, Font-Provider, etc.). Wir matchen via eTLD+1, sodass `www.example.com` und `cdn.example.com` als gleiche Site gelten. Bei DSGVO-relevanten Sites sollte man wissen welche Drittanbieter aktiv sind — der Cookie-Scanner ergänzt das mit Detail-Aufschlüsselung.
Wieso dauert ein Test 2-5 Sekunden?
Der Headless-Browser muss die Seite vollständig laden inklusive JavaScript-Ausführung. Wir warten zusätzlich auf Network-Idle (kurze Phase ohne neue Requests), damit auch JS-Nachzügler erfasst werden. Das ist deutlich aufwendiger als ein einfacher HTTP-Get, dafür sind die Daten realitätsnah.
Verwandte Tools
Daueraufsicht statt Stichprobe?
XICTRAQ überwacht Uptime, SSL, Security-Header, DSGVO und Performance 24/7. Free-Plan, keine Kreditkarte.