Network-Panel-Einstellungen der Chrome DevTools für die Core Web Vitals
Die Network-Panel-Einstellungen, die ich bei jedem Core-Web-Vitals-Audit nutze
Das Network-Panel der Chrome DevTools ist eines der nützlichsten Tools beim Debuggen der Core Web Vitals. Die Standardeinstellungen verstecken aber die Hälfte der Informationen, die du brauchst. So konfiguriere ich das Network-Panel bei jedem Audit.
Zuletzt geprüft von Arjen Karel im März 2026
Network-Panel konfigurieren
Öffne die Chrome DevTools (F12 oder Strg+Umschalt+I) und klicke auf den Tab „Network“, um ins Network-Panel zu gelangen.
Throttling
Deine Besucher sitzen nicht in deinem Büro-WLAN. Weltweit laufen immer noch 30 % der mobilen Verbindungen über 3G und weitere 55 % über 4G (GSMA Mobile Economy 2025). Netzwerk-Throttling zeigt dir, was deine Besucher sehen.
Klicke im Network-Panel auf das Dropdown „No throttling“. Wähle „Fast 4G“, „Slow 4G“ oder „3G“, um mobile Netzwerkbedingungen zu simulieren. Welche Option am besten passt, hängt von deiner Zielgruppe ab. Nutzt deine Zielgruppe typischerweise mobile High-End-Geräte bei schnellen Verbindungen, aktiviere „Fast 4G“. Sind die typischen Bedingungen etwas schlechter, wähle „Slow 4G“. Geh andernfalls auf Nummer sicher und nimm „3G“.
Einzelne Requests drosseln (Chrome 145+)
Seit Dezember 2025 kannst du einzelne Requests drosseln, statt die gesamte Seite. Klicke dazu mit rechts auf einen beliebigen Request im Network-Panel und wähle „Throttle request“. Damit beantwortest du Fragen wie: Was passiert mit meinem LCP, wenn dieses Third-Party-Script langsam lädt? Oder: Wie verhält sich meine Seite, wenn das CDN langsam ist, die Verbindung des Nutzers aber schnell? Das ist der schnellste Weg, um die Performance-Auswirkungen einer einzelnen Ressource zu isolieren.
Cache deaktivieren
Aktiviere im Network-Panel die Checkbox „Disable cache“, um deine Seite genau so zu testen, wie ein Erstbesucher sie erlebt.
Große Request-Zeilen aktivieren
Große Request-Zeilen zeigen entscheidende Details, die in der kompakten Standardansicht fehlen:
- Die Spalte size zeigt sowohl die komprimierte Übertragungsgröße (Transfer) als auch die tatsächliche unkomprimierte Größe jedes Requests.
- Die Spalte name zeigt den vollständigen Pfad und nicht nur den Dateinamen.
- Die Spalte priority zeigt die anfängliche und finale Fetch-Priority. So prüfst du, ob dein LCP-Bild mit hoher Priorität („High“) lädt, oder erkennst sofort, wenn Chrome eine Ressource neu priorisiert.
Screenshots aktivieren
Aktivierst du Screenshots, zeichnet Chrome jede visuelle Änderung beim Laden der Seite in einem Filmstrip auf. So erkennst du Layout-Shifts und siehst sofort, ob dein LCP-Element genau dann gerendert wird, wenn du es erwartest.
- Klicke in den Tab „Network“ und lade die Seite mit Strg+F5 (Cmd+R auf dem Mac) neu.
- Chrome nimmt während des Ladevorgangs Screenshots auf.
- Die Thumbnails dieser Screenshots erscheinen direkt unterhalb der Checkbox-Leiste im Network-Panel.
Die Screenshot-Übersicht bietet ein paar praktische Kniffe, die du vielleicht noch nicht kennst:
- Bewege den Mauszeiger über einen Screenshot, um den Aufnahmezeitpunkt zu sehen. Eine gelbe vertikale Linie im Overview-Diagramm zeigt die genaue Stelle.
- Klicke auf ein Thumbnail, um alle Requests auszublenden, die nach diesem Screenshot stattfanden.
- Doppelklicke auf ein Thumbnail, um den Screenshot zu vergrößern und im Detail zu betrachten.
Die besten Spalten im Network-Panel aktivieren
In den Standardspalten fehlen entscheidende Daten. Klicke mit rechts auf eine Spaltenüberschrift, um weitere Spalten einzublenden. Diese Spalten aktiviere ich bei jedem Audit:
| Spaltenname | Beschreibung | Warum das für die Core Web Vitals wichtig ist |
|---|---|---|
| Name | Name des Requests | Identifiziere jede Ressource, die der Browser herunterlädt |
| Status | HTTP-Statuscodes | Erkenne Weiterleitungen (301, 302), die deine TTFB verschlechtern, und 404-Fehler bei Ressourcen, die einen Netzwerk-Roundtrip verschwenden |
| Protocol | Verwendetes Netzwerkprotokoll | HTTP/3 verhindert Head-of-Line-Blocking. Laut Cloudflare Radar nutzen nur 21 % aller Requests HTTP/3. Unterstützt dein CDN HTTP/3 und du siehst kein h3 in dieser Spalte, prüfe deine DNS-Konfiguration |
| Domain | Domain der Ressource | Trennt First-Party- von Third-Party-Requests. Laut Web Almanac 2024 laden 92 % aller Seiten mindestens einen Drittanbieter. Die Sortierung nach Domain zeigt dir sofort, wie viel deines Waterfalls außerhalb deiner Kontrolle liegt |
| Type | Ressourcentyp | Filtere nach Typ, um Skripte, Bilder oder Fonts zu isolieren, die um Bandbreite konkurrieren |
| Initiator | Auslöser des Requests | Finde heraus, welches Script oder Stylesheet den jeweiligen Request ausgelöst hat. So verfolgst du eine langsame Kette kritischer Requests bis zum Ursprung zurück |
| Size | Transfer- und tatsächliche Größe | Erkenne unkomprimierte oder überdimensionierte Ressourcen. Eine typische mobile Seite lädt im Median 66 Requests mit insgesamt 2,3 MB (Web Almanac 2024) |
| Priority | Ladepriorität der Ressource | Zeigt die anfängliche und finale Fetch-Priority. Prüfe, ob dein LCP-Bild mit „High“ und unkritische Scripts mit „Low“ laden |
| Waterfall | Visuelle Timeline der Requests | Die Timeline, die zeigt, wo die Zeit verloren geht. Lange Balken vor dem First Paint schlagen direkt auf LCP und FCP durch |
Benutzerdefinierte Response-Header aktivieren
| Spaltenname | Beschreibung | Warum das für die Core Web Vitals wichtig ist |
|---|---|---|
| Cache-Control | Caching-Verhalten der Ressource | Prüfe, ob statische Assets lange Cache-Laufzeiten haben und HTML-Dokumente sinnvoll revalidiert werden. Mangelhaftes Caching zwingt wiederkehrende Besucher dazu, Ressourcen erneut herunterzuladen – das schadet jeder einzelnen Metrik. Siehe auch: Cloudflare-Caching-Konfiguration |
| Link | Link-Response-Header | Prüfe, ob dein Server Preload- oder Preconnect-Hinweise sendet – auch über 103 Early Hints |
| Content-Encoding | Verwendete Komprimierung | Stelle sicher, dass dein Server Brotli (br) statt gzip ausliefert. Brotli komprimiert JavaScript um 15 bis 20 % effizienter als gzip. Laut Web Almanac 2024 hat Brotli gzip bei JavaScript-Ressourcen mittlerweile überholt (45 % vs. 41 %) |
Willst du Response-Header für viele Seiten analysieren, ohne überall die DevTools zu öffnen, teste den HTTP Header Performance Analyzer.
Mit dem Performance-Panel verknüpfen
Das Network-Panel zeigt dir, was lädt und wann. Wechsle ins Performance-Panel, um zu sehen, wie jede Ressource die Core Web Vitals beeinflusst. Es liefert Live-Werte für LCP, CLS und INP ganz ohne Aufzeichnung und kann CrUX-Field-Data echter Nutzer einblenden. Nutze das Network-Panel für die Diagnose und das Performance-Panel zur Bestätigung.
Für ein dauerhaftes Monitoring über einzelne Debugging-Sessions hinaus verbindest du ein Real-User-Monitoring-Tool. So verfolgst du, ob deine Fixes im Network-Panel die Field Data im Laufe der Zeit wirklich verbessern.
Das komplette Setup
Lade die Seite mit diesen Einstellungen neu, und dein Network-Panel sieht so aus. Jede Spalte steht für einen Faktor, der die Core Web Vitals beeinflusst.
Brauchst du eine schnellere Website?
Ich bin Arjen und mache seit 17 Jahren langsame Websites schnell. Wenn du auf Probleme stößt, die du nicht selbst lösen kannst, schick mir deine URL und wir reden darüber.
Schick mir deine URLWarum funktioniert unser Fix nicht?
Manchmal liefert das CDN noch das alte HTML aus, oder der Fix steckt im Desktop-Template und Mobilgeräte nutzen ein anderes. Schick mir deine URL und das Problem, dann antworte ich mit ein paar Terminvorschlägen. Ich prüfe zuerst deine Field Data, dann arbeiten wir eine Stunde an deiner Website, und innerhalb eines Tages hast du meine Notizen schriftlich. 350 € zzgl. MwSt.
Schick mir deine URLKein Entwickler für den Fix? Ich mache die Arbeit selbst, auf einer Kopie deiner Website.
