HAR-Datei-Viewer & Analyzer

Was ist eine HAR-Datei?

HAR steht für HTTP Archive. Es ist eine JSON-Datei, die die Netzwerkaktivität eines Browser-Tabs festhält: jeden Request der Seite, was zurückkam und wie lange jeder Schritt gedauert hat. Das Format wurde als Entwurf einer Spezifikation beschrieben, und Version 1.2 exportieren heute Chrome, Edge, Firefox und Safari, ebenso Proxys wie Charles und Fiddler.

Im Objekt log findest du:

• pages: ein Eintrag pro Seitenaufruf mit den Zeiten für DOMContentLoaded und load.
• entries: ein Eintrag pro Request mit Methode, URL, HTTP-Version, Headern, Cookies, Query-String und gesendeten Daten.
• response: Statuscode, Header, gesetzte Cookies, MIME-Typ, Größen und oft der Body selbst (binäre Bodies stehen als Base64 drin).
• timings: wie lange der Request blockiert war und wie lange DNS, Verbindungsaufbau, TLS, Senden, Warten und Empfangen gedauert haben.
• Browser-Extras: Felder mit Unterstrich am Anfang, etwa _resourceType und _transferSize von Chrome. Dieser Viewer nutzt sie, wenn sie vorhanden sind.

So erstellst du eine HAR-Datei in Chrome, Edge, Firefox und Safari

Der Ablauf ist überall gleich: Entwicklertools öffnen, das Log über Seitenwechsel hinweg behalten, das Problem nachstellen, exportieren. Die Menünamen unten sind die englischen Bezeichnungen. In deutschsprachigen Entwicklertools sind sie entsprechend übersetzt.

Chrome und Edge bereinigen standardmäßig. Aktuelle Versionen lassen Cookies und Authorization-Header aus der exportierten Datei weg. Braucht die Person, die debuggt, diese Daten (etwa bei einem Login- oder Session-Fehler), öffne die DevTools-Einstellungen, geh zu Preferences, such den Abschnitt Network und schalte Allow to generate HAR with sensitive data ein. Danach bietet das Export-Menü eine Variante mit sensiblen Daten an. Schick diese Datei nur an Leute, denen du vertraust, und bereinige alles, was sie nicht brauchen.

Wasserfall und Timings richtig lesen

Jeder Balken im Wasserfall beginnt beim Start des Requests und ist so lang, wie der Request gedauert hat, alles auf einer gemeinsamen Zeitachse ab dem ersten Request der Datei. Die blaue Linie markiert DOMContentLoaded (das HTML ist verarbeitet), die rote Linie load (Bilder, Styles und Skripte sind fertig). Die farbigen Abschnitte in einem Balken sind die Timing-Phasen:

• Blockiert: Zeit in der Warteschlange, bevor der Request rausgehen konnte. Lange Wartezeiten bedeuten meist zu viele gleichzeitige Requests an einen Host (Browser öffnen über HTTP/1.1 etwa sechs Verbindungen pro Host) oder einen niedriger priorisierten Request, der warten muss.
• DNS: das Nachschlagen der IP-Adresse des Servers. Das zahlt nur der erste Request an einen Host.
• Verbindung und SSL: TCP-Verbindung aufbauen und TLS aushandeln. In einer HAR-Datei ist die SSL-Zeit in der Verbindungszeit enthalten. Der Viewer zeichnet beides als getrennte Abschnitte, ohne doppelt zu zählen.
• Senden: das Hochladen des Requests. Fast null, außer du sendest einen großen Body.
• Warten (TTFB): Time to First Byte, vom Ende des Sendens bis zum ersten Byte der Antwort. Das ist die Rechenzeit des Servers plus ein Netzwerk-Roundtrip. Wartet ein API-Call lange, deutet das auf das Backend hin, nicht auf den Browser.
• Empfangen: das Herunterladen der Antwort. Lange Empfangszeiten bedeuten eine große Datenmenge oder eine langsame Verbindung.

Muster, auf die du achten solltest: eine Treppe aus Requests, die jeweils auf den vorherigen warten (eine Abhängigkeitskette, die sich vielleicht parallelisieren lässt), eine Lücke ohne Netzwerkaktivität (JavaScript arbeitet, bevor der nächste Fetch startet) und ein langsamer Request, von dem alles danach abhängt. Sortier nach Zeit, um die langsamsten Aufrufe zu finden, oder klick auf die Kachel Langsamster.

HAR-Dateien und Sicherheit

Eine HAR-Datei ist eine vollständige Kopie dessen, was dein Browser gesendet und empfangen hat, und dazu gehören die Schlüssel zu deinem Konto:

• Session-Cookies: Wer sie hat, kann oft bis zum Ablauf der Session als du auftreten, ganz ohne Passwort.
• Bearer-Tokens und API-Keys: in Authorization-Headern, eigenen Headern wie X-API-Key und in Query-Strings.
• Formulardaten: alles, was du während der Aufzeichnung in ein Formular getippt hast, auch Passwörter auf einer Login-Seite.
• Personenbezogene Daten: Namen, E-Mail-Adressen, Anschriften und Bestelldetails in Response-Bodies.

Das ist keine Theorie. Im Oktober 2023 haben Angreifer, die in das Support-System von Okta eingedrungen waren, Session-Tokens aus HAR-Dateien abgegriffen, die Kunden an ihre Tickets gehängt hatten. Bevor du eine HAR-Datei teilst: Nimm nur die nötigen Schritte auf, nutze wenn möglich ein Testkonto, lass die Datei oben durch Bereinigen laufen, schick sie über das Support-Portal statt über einen öffentlichen Kanal und melde dich danach ab, damit eine durchgerutschte Session nicht mehr funktioniert.

HAR-Dateien in Bug-Reports

Eine HAR-Datei zeigt, was im Netzwerk passiert ist, aber nicht, was die Nutzerin oder der Nutzer gesehen hat. Gib deshalb Kontext mit:

• Einen Screenshot oder eine Bildschirmaufnahme der Fehlermeldung oder des kaputten Zustands, damit klar ist, welcher Request zählt.
• Die genaue Uhrzeit mit Zeitzone, zu der du den Fehler nachgestellt hast, damit das Backend-Team denselben Moment in den Server-Logs findet.
• Die Schritte, die du während der Aufzeichnung gemacht hast, in der richtigen Reihenfolge.
• Den fehlerhaften Request: Schalte „Nur Fehler“ ein, notiere URL, Status und eine eventuelle Request-ID aus den Response-Headern und zitiere den Fehler-Body.
• Browser und Version, und ob der Fehler auch in einem privaten Fenster auftritt.

„Als cURL kopieren“ macht aus einem Request einen Befehl, den Entwickler im Terminal erneut ausführen können. Dabei werden die Original-Header samt Tokens kopiert. Entferne sie also, bevor du den Befehl irgendwo teilst.