Ein Netzwerk-Panel ohne DevTools — der Network-Tab von JustZix
Das Netzwerk-Panel der DevTools hat einen hartnäckigen Mangel: es zeichnet nur auf, solange es geöffnet ist. Neu laden, vergessen es vorher zu öffnen, und die Anfrage, die du brauchtest, ist weg. Die Output Console von JustZix hat einen Network-Tab, der in der Seite lebt, Verkehr über chrome.webRequest erfasst und einen Hintergrundpuffer hält — sodass er Anfragen sieht, die vor dem Öffnen des Fensters ausgelöst wurden. So funktioniert er und hier passt er hin.
Wie die Erfassung funktioniert: chrome.webRequest
Der Network-Tab hängt sich nicht in fetch oder XMLHttpRequest im Seitencode ein. Er nutzt chrome.webRequest — eine API auf Browser-Ebene, die die Erweiterung über die webRequest-Manifest-Berechtigung anzapft. Das bedeutet, er beobachtet Anfragen auf der Browser-Schicht, an derselben Stelle wie der Netzwerk-Stack.
Die praktische Folge ist das Hauptmerkmal: ein Hintergrundpuffer. Die Erweiterung führt eine laufende Aufzeichnung der Anfragen für den Tab. Wenn du die Output Console öffnest, ist der Network-Tab bereits mit dem gefüllt, was passiert ist, bevor du angekommen bist. Kein „neu laden, um zu erfassen"-Tanz.
Den Network-Tab öffnen
Öffne die Output Console über das Menü des schwebenden JustZix-Buttons oder als TEMP-Fenster mit Strg+Alt+K, und wechsle dann zum Network-Tab. Sein Badge zeigt die Live-Anfragenanzahl. Wegen des Puffers ist die Liste selbst auf einer Seite, die du vor Minuten geladen hast, nicht leer.
Was jede Spalte bedeutet
Jede erfasste Anfrage ist eine Zeile. Die Spalten:
| Spalte | Bedeutung |
|---|---|
| Method | HTTP-Verb — GET, POST, PUT, DELETE, … |
| URL | Die vollständige Anfrage-URL. |
| Status | HTTP-Statuscode — 200, 301, 404, 500, … |
| Ressourcentyp | Welche Art von Anfrage: document, script, stylesheet, image, xhr/fetch, font, … |
| Größe | Wie viele Bytes die Anfrage übertragen hat. |
| Dauer | Wie lange die Anfrage gedauert hat, in Millisekunden. |
| Remote-Adresse | Die IP-Adresse, die die Anfrage tatsächlich erreicht hat. |
| Initiator | Was die Anfrage ausgelöst hat — das Skript oder die Ressource, die sie angestoßen hat. |
Method, Status und URL sagen dir, was passiert ist. Größe und Dauer sagen dir, wie teuer es war. Remote-Adresse und Initiator sagen dir, wohin sie ging und wer sie gestartet hat — die beiden Spalten, die am wichtigsten sind, wenn du eine Anfrage jagst, die du nicht selbst geschrieben hast.
Die kontextabhängige Filterleiste — drei Reihen
Die Filterleiste der Output Console ist kontextabhängig; im Network-Tab erweitert sie sich zu drei Reihen von Bedienelementen:
- Ressourcentyp — eine Checkbox-Reihe: document, script, stylesheet, image, xhr/fetch, font und mehr. Hak die Typen ab, die dich nicht interessieren. Debuggst du eine API? Behalte nur xhr/fetch und der Lärm von Bildern und Schriften verschwindet.
- HTTP-Statusklasse — eine Checkbox-Reihe nach Klasse:
2xx,3xx,4xx,5xx. Hak2xxund3xxab, um nur die Fehlschläge zu sehen. - Größe + Dauer + Domain — zwei Bereichs-Schieberegler (0–100000, Dauer in Millisekunden) plus ein Domain-Filterfeld.
Die Checkbox-Reihen haben Alle auswählen / Alle leeren-Kürzel, sodass du alles leeren und den einen gewünschten Typ ankreuzen kannst, oder umgekehrt — kein händisches Durchklicken von zehn Boxen.
Die Schieberegler und der Domain-Filter
Die Bereichs-Schieberegler verwandeln vagen Verdacht in eine präzise Abfrage:
- Dauer-Schieberegler — setze ein Minimum und nur langsame Anfragen überleben. Zieh ihn auf
2000ms hoch und du hast eine Liste von allem, was länger als zwei Sekunden gedauert hat. - Größen-Schieberegler — dieselbe Idee für Bytes. Setze eine Untergrenze und die übergroßen Payloads — das unoptimierte Hero-Bild, der 400-KB-JSON-Blob — schwimmen nach oben.
- Domain-Filter — tippe ein Domain-Fragment, um nur Anfragen an diesen Host zu behalten. Tippe
google-analyticsoderdoubleclickund du siehst genau den Drittanbieter-Verkehr, den du prüfen wolltest.
All das stapelt sich mit dem stets sichtbaren Suchfeld unter der Filterleiste — ein Live-Filter für Teilzeichenketten ohne Groß-/Kleinschreibung über die Zeilen. Esc leert die Suche.
Anwendungsfall 1 — API-Aufrufe debuggen
Leere die Ressourcentyp-Reihe, kreuze nur xhr/fetch an. Jetzt ist der Network-Tab nur der API-Verkehr deiner Anwendung — keine Skripte, keine Bilder. Löse die Aktion aus, die du debuggst, und beobachte, wie die Anfrage erscheint: Method, URL, Status, wie lange sie gedauert hat. Wenn der Status falsch ist, weißt du sofort, ob das Problem die Anfrage ist oder der Code, der die Antwort verarbeitet.
Anwendungsfall 2 — langsame oder übergroße Anfragen finden
Zieh den Dauer-Schieberegler auf einen Schwellenwert hoch — sagen wir 1500 ms — und die Liste schrumpft auf deine langsamsten Anfragen. Mach dasselbe mit dem Größen-Schieberegler, um schwere Payloads ans Licht zu bringen. Zwei Züge und du hast eine Performance-Shortlist: die Anfragen, die tatsächlich eine Optimierung wert sind, herausgefiltert aus den Dutzenden, die in Ordnung sind.
Anwendungsfall 3 — 4xx- und 5xx-Fehlschläge aufspüren
Das ist die Sache, die der Errors-Tab nicht für dich erledigen kann. Ein fehlgeschlagenes fetch oder XHR ist keine JavaScript-Ausnahme — es erreicht den Errors-Tab nie. Um kaputte Anfragen zu finden, komm zum Network-Tab und hak 2xx und 3xx in der Status-Reihe ab. Was übrig bleibt, ist jede 4xx und 5xx: der fehlende Endpunkt, der Auth-Fehlschlag, der Serverfehler. Füge einen Suchbegriff hinzu, um einen Pfad festzunageln.
Anwendungsfall 4 — Drittanbieter-Tracker und Beacons prüfen
Jede Website lädt Dinge, die sie nicht unbedingt angekündigt hat — Analytics, Werbe-Pixel, Beacons. Tippe eine Tracker-Domain in den Domain-Filter oder beobachte die Initiator-Spalte, um zu sehen, welches Skript welchen Beacon ausgelöst hat. Kombiniert mit der Remote-Adresse-Spalte kannst du genau sagen, wohin Daten gehen. Es ist eine schnelle, ehrliche Datenschutzprüfung ohne irgendwelche Spezialwerkzeuge.
Ehrlicher Vergleich mit dem DevTools-Netzwerk-Panel
Das DevTools-Netzwerk-Panel ist mächtiger — dieser Tab tut nicht so, als wäre es anders. Aber die Kompromisse sind real und sie schneiden in beide Richtungen:
| JustZix Network-Tab | DevTools Network | |
|---|---|---|
| Wo es lebt | In der Seite, ziehbares Fenster | Separates angedocktes/abgedocktes Panel |
| Braucht DevTools | Nein | Ja |
| Erfasst, bevor du es geöffnet hast | Ja — Hintergrundpuffer | Nein — nur solange geöffnet |
| Anfrage-Metadaten | Ja — Method, Status, Größe, Dauer, IP, Initiator | Ja |
| Antwort-Bodies | Nein | Ja |
| Anfrage-/Antwort-Header, Timing-Wasserfall | Nein | Ja |
Die entscheidende Einschränkung: chrome.webRequest liefert Anfrage-Metadaten, keine Antwort-Bodies. Wenn du das JSON lesen musst, das eine Anfrage zurückgegeben hat, sind die DevTools weiterhin dein Werkzeug. Wenn du wissen musst, welche Anfragen ausgelöst wurden, ob sie erfolgreich waren, wie langsam sie waren und wohin sie gingen — inklusive Anfragen von vor dem Zeitpunkt, an dem du angefangen hast zu schauen — erledigt das der Network-Tab im Tab, ganz ohne DevTools.
Wann man wonach greift
- Network-Tab — schnelle Triage, gesperrte Rechner, Anfragen abfangen, die beim Seitenladen ausgelöst werden, Drittanbieter-Verkehr prüfen, ein Debugging-Setup als Teil einer Regel teilen.
- DevTools Network — Antwort-Bodies inspizieren, Header lesen, der Timing-Wasserfall, Drosselung, Anfragen erneut abspielen.
Sie sind keine Rivalen. Der Network-Tab erledigt die alltägliche Frage „was tut diese Seite auf der Leitung"; die DevTools erledigen den Deep Dive.
Siehe auch
- Die neu gebaute Output Console — alle sechs Tabs erklärt
- JustZix-Beispiele — einsatzbereite CSS- und JS-Regeln
Ein Netzwerk-Panel, das von vor dem Öffnen erfasst, direkt im Tab — kein F12 nötig. Lade JustZix herunter — es ist kostenlos, läuft auf Chrome 100+ und braucht etwa zwei Minuten zur Installation.
Bewerte diesen Beitrag
Noch keine Bewertungen — sei der Erste.