HAR-Dateien erklärt: Der Blackbox-Rekorder deines Browsers

In einem Satz

Eine HAR-Datei ist ein JSON-formatiertes Protokoll der Interaktion eines Webbrowsers mit einer Website, das jede einzelne Netzwerkanfrage und -antwort bis ins kleinste Detail für eine spätere Analyse erfasst.

Welches Problem es löst

Stell dir das mal vor: Ein Nutzer am anderen Ende der Welt schreibt dir eine DM: „Deine App ist unbenutzbar langsam.“ Du probierst sie aus. Bei dir ist sie flott. Der Nutzer sagt, sie ist kaputt. Du sagst, „works on my machine“. Patt.

Das ist das klassische Aussage-gegen-Aussage-Problem in der Webentwicklung. Vor den modernen Browser-Tools war das Debuggen von Netzwerkproblemen aus der Ferne ein Albtraum aus Mutmaßungen, dem Wühlen in Server-Logs und dem Versuch, nicht-technische Nutzer dazu zu bringen, esoterische Fehlermeldungen zu beschreiben. Selbst mit dem Aufkommen der Browser-DevTools und ihrem glorreichen Netzwerk-Tab blieb das Problem bestehen: Die Daten waren flüchtig. Man konnte sie nicht einfach in Flaschen abfüllen und an einen Kollegen schicken. Ein Screenshot eines Wasserfalldiagramms erzählt nicht die ganze Geschichte.

Hier kommt das HTTP Archive Format, kurz HAR, ins Spiel. Es wurde von der Web Performance Working Group des W3C konzipiert, um ein standardisiertes, gemeinsam nutzbares Format für die Archivierung von HTTP-Transaktionen zu sein. Es ist das digitale Äquivalent dazu, einen Blackbox-Rekorder in den Browser eines Nutzers einzubauen.

Eine HAR-Datei löst das „Auf meinem Rechner geht's“-Problem, indem sie die gesamte Netzwerkkonversation zwischen einem Browser und einem Server für das Laden einer bestimmten Webseite aufzeichnet. Sie protokolliert jede Anfrage für ein Bild, ein Skript, eine Schriftart oder einen API-Aufruf. Sie loggt die exakten gesendeten Header, die ausgetauschten Cookies, die gefolgten Redirects und, was am wichtigsten ist, die genauen Timings für jede Phase der Anfrage.

So kann ein Entwickler in San Francisco genau sehen, was ein Nutzer in Singapur erlebt hat, Millisekunde für Millisekunde, ohne raten zu müssen. Es macht flüchtige, schwer reproduzierbare Netzwerkfehler analysierbar und verwandelt vage Beschwerden über „Langsamkeit“ in umsetzbare Daten.

Wie es unter der Haube funktioniert

Im Grunde ist eine HAR-Datei keine Magie. Es ist nur eine große, strukturierte JSON-Datei. Du kannst sie in einem Texteditor öffnen und alles sehen, obwohl ein spezieller Viewer das Analysieren unendlich einfacher macht. Werfen wir mal einen Blick hinein.

Die grundlegende Struktur: Es ist nur JSON

Eine HAR-Datei enthält ein einziges JSON-Objekt auf der obersten Ebene mit einem einzigen Schlüssel: log. Alles andere befindet sich innerhalb dieses log-Objekts.

{
  "log": {
    "version": "1.2",
    "creator": { "name": "Chrome", "version": "118.0.0.0" },
    "browser": { "name": "Chrome", "version": "118.0.0.0" },
    "pages": [ /* ... ein oder mehrere page-Objekte ... */ ],
    "entries": [ /* ... ein oder mehrere Request/Response-Objekte ... */ ]
  }
}

version: Die Version der HAR-Spezifikation, normalerweise „1.2“.
creator / browser: Metadaten darüber, welches Tool und welcher Browser die Datei generiert hat. Nützlich für den Kontext.
pages: Ein Array, das die Hauptseite(n) beschreibt, die geladen wurden. Es enthält den Seitentitel und Timings für übergeordnete Ereignisse wie onLoad und onContentLoad.
entries: Das ist der Star der Show. Es ist ein langes Array, bei dem jedes Objekt eine einzelne Netzwerkanfrage und die dazugehörige Antwort darstellt.

Der Star der Show: Das `entries`-Array

Wenn du eine HAR-Datei analysierst, verbringst du 99 % deiner Zeit in den entries. Jeder Eintrag ist ein komplettes Dossier für eine einzelne Ressource.

Hier ist ein vereinfachter Blick auf einen einzelnen Eintrag:

{
  "startedDateTime": "2023-10-27T10:30:05.123Z",
  "time": 258.45,
  "request": { /* ... Details der Anfrage ... */ },
  "response": { /* ... Details der Antwort ... */ },
  "timings": { /* ... die saftige Performance-Aufschlüsselung ... */ },
  "pageref": "page_1"
}

startedDateTime: Der exakte UTC-Zeitstempel, wann die Anfrage gestartet wurde.
time: Die gesamte verstrichene Zeit für die Anfrage in Millisekunden, von Anfang bis Ende.
request: Ein Objekt, das alles enthält, was der Browser an den Server gesendet hat.
response: Ein Objekt, das alles enthält, was der Server zurückgeschickt hat.
timings: Die Goldgrube für's Performance-Debugging. Das sezieren wir als Nächstes.
pageref: Eine ID, die diese Anfrage mit einer der pages im pages-Array verknüpft.

Anatomie einer Anfrage und Antwort

Die request- und response-Objekte sind Spiegelbilder dessen, was du in den DevTools sehen würdest.

Das request-Objekt enthält Details zu:

method: GET, POST, PUT, etc.
url: Die vollständige URL der Ressource.
headers: Ein Array aller Request-Header wie User-Agent, Accept und Cookie.
queryString: Ein Array aller Query-Parameter in der URL.
postData: Bei POST-Requests enthält dies den Payload, wie Formulardaten oder einen JSON-Body.

Das response-Objekt enthält Details zu:

status: Der HTTP-Statuscode (z. B. 200, 404, 500).
statusText: Der Klartext zum Status (z. B. OK, Not Found).
headers: Ein Array aller Response-Header wie Content-Type, Cache-Control und Set-Cookie.
content: Ein Objekt, das den Response-Body beschreibt, einschließlich seiner size, mimeType und oft des Bodys selbst in der text-Eigenschaft (obwohl dies aus Platz- oder Sicherheitsgründen weggelassen werden kann).

Die Aufschlüsselung des Timing-Wasserfalls

Das timings-Objekt ist das, was das farbenfrohe Wasserfalldiagramm in einem HAR-Viewer antreibt. Es schlüsselt die gesamte time einer Anfrage in ihre einzelnen Phasen auf. Diese zu verstehen ist der Schlüssel zur Diagnose, warum eine Anfrage langsam war.

Timing	Was es bedeutet
`blocked`	Zeit, die die Anfrage in der Warteschlange des Browsers verbrachte, bevor sie überhaupt starten konnte. Oft aufgrund von Verbindungslimits.
`dns`	Zeit für die DNS-Abfrage. Ein hoher Wert könnte auf einen langsamen DNS-Anbieter hinweisen.
`connect`	Zeit, die benötigt wurde, um eine TCP-Verbindung zum Server aufzubauen. Beinhaltet die `ssl`-Zeit.
`ssl`	(Teil von `connect`) Zeit für den SSL/TLS-Handshake. Hohe Werte können auf Serverkonfigurations- oder Netzwerkprobleme hinweisen.
`send`	Zeit, die zum Senden der HTTP-Anfrage an den Server benötigt wurde. Normalerweise sehr kurz.
`wait`	Time To First Byte (TTFB). Der entscheidende Wert. Zeit, die gewartet wurde, bis der Server die Anfrage verarbeitet und das erste Byte der Antwort gesendet hat. Eine lange `wait`-Zeit ist fast immer ein Backend-Problem.
`receive`	Zeit, die zum Herunterladen des Response-Bodys vom Server benötigt wurde. Eine lange `receive`-Zeit bei einer kleinen Datei könnte auf ein langsames Netzwerk hindeuten; bei einer großen Datei ist sie zu erwarten.

Die gesamte time für einen Eintrag ist die Summe dieser einzelnen (nicht-negativen) Timings. Wenn ein HAR-Viewer dir einen Balken für eine Anfrage anzeigt, reiht er diese timings-Werte visuell aneinander.

Geschichten aus der Praxis

Der Fall der mysteriösen Langsamkeit

Ein hektischer PM schreibt dem Team: „Die neue Checkout-Seite ist für unseren größten Kunden super langsam! Sie drohen abzuspringen!“ Das Entwicklerteam probiert den Checkout-Flow aus. Er ist blitzschnell. Der Kunde besteht darauf, dass es 20 Sekunden dauert, eine Bestellung zu bestätigen. Statt eines fruchtlosen Hin und Hers erklärt der leitende Entwickler dem Kunden, wie er eine HAR-Datei exportieren kann.

Beim Öffnen der Datei ist das Problem sofort offensichtlich. In den entries hat die POST-Anfrage an /api/v1/finalize_order eine Gesamt-time von 20.145 ms. Ein Blick auf das timings-Objekt zeigt, dass die wait-Zeit (TTFB) über 20.000 ms beträgt. Der Backend-Server braucht 20 Sekunden, um zu antworten. Es stellt sich heraus, dass dieser spezielle Kunde eine riesige Bestellhistorie hatte und eine nicht optimierte Datenbankabfrage zu einem Timeout führte, aber nur für sein Konto. Die HAR-Datei lieferte den rauchenden Colt, der direkt auf einen bestimmten Backend-Prozess zeigte.

Die Lektion: Eine HAR-Datei erfasst benutzerspezifische Bedingungen (wie Kontodaten), die du nicht nachstellen kannst, und verwandelt ein Rätsel in einen gezielten Bug-Report.

Der aufgeblähte Bundle-Übeltäter

Eine Marketing-Website geht live und die Absprungrate geht durch die Decke. Sie fühlt sich einfach schwerfällig an. Ein Frontend-Entwickler ruft die Seite auf, öffnet die DevTools, zeichnet eine Sitzung auf und exportiert die HAR-Datei.

Im HAR-Viewer sortiert er die Einträge nach Größe. Ganz oben steht main.acb123.js mit satten 5,2 MB. Der Wasserfall zeigt, dass es sich um eine renderblockierende Ressource handelt; nichts erscheint auf der Seite, bis dieser Koloss fertig heruntergeladen ist. Allein die receive-Zeit beträgt mehrere Sekunden, selbst bei einer schnellen Verbindung. Schlimmer noch, beim Betrachten der response-Header für diesen Eintrag stellen sie fest, dass der Server keinen Content-Encoding: gzip-Header sendet, obwohl der Browser in den request-Headern Accept-Encoding: gzip gesendet hat. Das JavaScript-Bundle wurde nicht komprimiert.

Die Lektion: HAR-Dateien machen es trivial einfach, Performance-Killer wie übergroße Assets und Server-Fehlkonfigurationen zu erkennen, die deine Ladezeit killen.

Die unendliche Redirect-Schleife

Ein Nutzer beschwert sich, dass er sich nicht einloggen kann. Er gibt seine Anmeldedaten ein, klickt auf „Einloggen“ und wird sofort ohne Fehler auf die Login-Seite zurückgeworfen. Es ist eine klassische Schleife. Der Support bittet den Nutzer um eine HAR-Datei des Anmeldeversuchs.

Die entries-Liste in der HAR erzählt eine klare Geschichte:

Ein POST /login ist erfolgreich und erhält einen 302 Redirect zu /dashboard. Die Antwort enthält einen Set-Cookie-Header mit dem Session-Token.
Der Browser folgt dem Redirect und macht eine GET /dashboard-Anfrage.
Der Server antwortet auf GET /dashboard mit einem 302 Redirect zurück zu /login.

Warum? Der Entwickler inspiziert den GET /dashboard-Request-Eintrag. Im Cookie-Header fehlt das Session-Token. Dann überprüft er die Antwort des ursprünglichen POST /login. Der Set-Cookie-Header lautete session_id=...; Secure; HttpOnly. Das Secure-Flag bedeutet, dass der Browser das Cookie nur über HTTPS senden wird. Der Nutzer befand sich jedoch in einer http://staging.example.com-Umgebung. Der Browser weigerte sich korrekterweise, das sichere Cookie über eine unsichere Verbindung zu senden, sodass der Server ihn nie als eingeloggt erkannte.

Die Lektion: HAR-Dateien geben dir eine perfekte Frame-für-Frame-Wiedergabe von HTTP-Redirects und Header-Austauschen, was es ermöglicht, komplexe Authentifizierungsabläufe zu debuggen, die still und leise fehlschlagen.

Häufige Fehler und Fallstricke

Vergessen, „Protokoll beibehalten“ (Preserve log) zu aktivieren. Wenn dein Bug den Wechsel von Seite A zu Seite B beinhaltet, musst du die Option „Preserve log“ (oder eine entsprechende Option) in den DevTools aktivieren. Andernfalls wird das Protokoll bei der Navigation gelöscht und deine HAR-Datei enthält nur Anfragen für Seite B.
Sensible Daten teilen. HAR-Dateien sind wahllose Aufzeichnungsgeräte. Sie erfassen API-Schlüssel, Session-Token in Cookies und personenbezogene Daten in POST-Bodys. Bereinige HAR-Dateien immer, bevor du sie in öffentlichen Bug-Trackern oder Foren teilst.
Die blocked-Zeit falsch interpretieren. Eine hohe blocked-Zeit bedeutet nicht immer, dass das Netzwerk überlastet ist. Browser haben ein Limit, wie viele parallele Verbindungen sie zu einer einzigen Domain öffnen (normalerweise 6). Wenn du 20 Bildanfragen auf einmal abfeuerst, werden 14 davon im blocked-Zustand warten, bis eine der ersten 6 fertig ist.
Den Cache-Status ignorieren. Wenn du die Performance beim ersten Laden testest, musst du die Aufzeichnung mit deaktiviertem Browser-Cache durchführen. Andernfalls siehst du viele 304 Not Modified-Antworten oder Anfragen, die in weniger als einer Millisekunde abgeschlossen werden, was nicht der Erfahrung eines neuen Nutzers entspricht.

Warum du es auf dem Schirm haben solltest

Du solltest die Verwendung einer HAR-Datei in Betracht ziehen, wann immer die Netzwerkkommunikation ein potenzieller Verdächtiger ist.

Wenn ein Nutzer ein Performance-Problem meldet, das du nicht reproduzieren kannst.
Wenn du eine langsam ladende Seite optimieren und die größten Engpässe identifizieren möchtest.
Wenn du einen mehrstufigen API-Flow debuggst, wie einen OAuth-Login oder einen Zahlungsprozess, und die genaue Abfolge der Ereignisse sehen musst.
Wenn du einen Bug-Report bei einem Drittanbieter (wie einem CDN oder API-Provider) einreichen und ihm einen unwiderlegbaren Beweis für das Problem liefern möchtest. Eine HAR-Datei ist die universelle Sprache für Netzwerkprobleme.

Tauche tiefer ein

HAR 1.2 Specification: Die ursprüngliche, de-facto Spezifikation, die die Struktur von HAR-Dateien definiert.
Google Chrome DevTools: Network features reference: Eine ausführliche Anleitung zu dem Tool, das am häufigsten zur Erstellung von HAR-Dateien verwendet wird.
MDN Web Docs: Network request list: Mozillas exzellente Dokumentation zur Interpretation von Netzwerkanfragen in den DevTools von Firefox.
What is a HAR File?: Ein guter, allgemeiner Überblick darüber, wie man HAR-Dateien zur Fehlerbehebung generiert und verwendet.