Wie funktioniert ein Browser?

 (howbrowserswork.com)
67 Punkte von GN⁺ 2026-01-06 | 1 Kommentare | Auf WhatsApp teilen
  • Ein interaktiver Lernleitfaden, der sowohl Webentwicklern als auch allgemeinen Nutzern ein intuitives Verständnis der internen Funktionsweise von Browsern vermitteln soll
  • Vom Eintrag in die Adressleiste bis zu Erstellung von HTTP-Anfragen, DNS-Auflösung, TCP-Verbindung, HTML-Parsing, DOM-Aufbau und Rendering-Pipeline wird der Ablauf Schritt für Schritt visualisiert
  • Jeder Schritt besteht aus Beispielen, die sich direkt eingeben oder manipulieren lassen, sodass sich Netzwerkkommunikation und Rendering experimentell nachvollziehen lassen
  • Zeigt die Rolle des DOM und die Unterschiede zwischen den Phasen Layout–Paint–Composite klar auf, sodass sich leistungsrelevante Faktoren visuell erkennen lassen
  • Für Entwickler, die die Browserarchitektur lernen oder Web-Performance-Optimierung verstehen möchten, ein Material, mit dem sich Kernkonzepte systematisch erarbeiten lassen

Überblick

  • Dieser Leitfaden wurde für Menschen entwickelt, die das Web täglich nutzen, aber nicht klar verstehen, wie ein Browser funktioniert
    • Er ergänzt bestehende Materialien, die oft entweder zu technisch oder zu oberflächlich sind
    • Konzipiert, damit sich technische Details mithilfe kleiner interaktiver Beispiele intuitiv erlernen lassen
  • Details zu HTTP-Versionen, SSL/TLS oder dem genauen Ablauf von DNS werden ausgelassen; stattdessen ist der Leitfaden knapp auf die Kernkonzepte fokussiert
  • Das Projekt ist als Open Source veröffentlicht, und über GitHub können Verbesserungsvorschläge eingereicht werden

Browser und URL

  • Jede Zeichenfolge, die ein Nutzer in die Adressleiste eingibt, wird intern in eine URL umgewandelt
  • Nach dem Drücken der Eingabetaste steht eine interaktive Oberfläche bereit, mit der sich dieser Umwandlungsprozess direkt nachvollziehen lässt

Von der URL zur HTTP-Anfrage

  • Nachdem der Browser die exakte URL des Ziels bestimmt hat, sendet er eine HTTP-Anfrage an den Server
  • Ein Beispiel für Request-Header sieht so aus 
    Host: example.com
Accept: text/html
    Anzeige
  • Der Header Host dient als Kennung des Servers, an den die Anfrage gesendet wird

Auflösung der Serveradresse (DNS)

  • Ein Browser kann Domainnamen wie example.com nicht direkt verwenden
    • Zur Kommunikation mit dem Server müssen sie über das DNS-System in eine IP-Adresse übersetzt werden
  • Gibt man eine Domain in das Eingabefeld ein, lässt sich das Ergebnis der DNS-Auflösung (IP-Adresse) anzeigen

Aufbau der TCP-Verbindung

  • Nachdem über DNS die IP-Adresse ermittelt wurde, baut der Browser mithilfe des TCP-Protokolls eine zuverlässige Verbindung zum Server auf
  • Die Verbindung wird über den 3-Wege-Handshake hergestellt
    1. SYN: Der Client fordert eine Verbindung an
    2. SYN-ACK: Der Server antwortet und bestätigt
    3. ACK: Der Client bestätigt abschließend
  • TCP sorgt mit Reihenfolgegarantie und Wiederholungsübertragung für eine stabile Kommunikation
  • Man kann das Netzwerk trennen oder Pakete manipulieren und so die Übertragungsstabilität experimentell untersuchen
Anzeige

HTTP-Anfrage und -Antwort

  • Nach dem Aufbau der TCP-Verbindung sendet der Browser eine HTTP-Anfrage, und der Server liefert eine HTTP-Antwort zurück
  • Der Weg von Anfrage und Antwort wird visuell dargestellt, sodass sich der Paketfluss beobachten lässt
  • Sobald die Antwort eintrifft, trennt der Browser Header und Body und beginnt mit dem Rendern von HTML

HTML-Parsing und Erzeugung des DOM-Baums

  • Der Browser übergibt die HTML-Bytes an den Parser, um einen DOM-Baum zu erzeugen
  • Gibt man Beispiel-HTML ein, lässt sich visuell nachvollziehen, wie Tags wie und in DOM-Knoten umgewandelt werden
  • Das Parsing erfolgt streamingbasiert, sodass Knoten schon erzeugt werden können, bevor das gesamte Dokument angekommen ist
  • Wenn ein ``-Tag auftaucht, wird das Parsing vorübergehend angehalten und das Skript ausgeführt
  • Das fertige DOM wird mit CSS kombiniert und bildet den Render Tree

Warum das DOM wichtig ist

  • Das DOM (Document Object Model) ist das Dokumentmodell im Speicher des Browsers und die zentrale gemeinsam genutzte Struktur für HTML-Parser, CSS-Selektor-Engine und JavaScript-Laufzeitumgebung
  • Änderungen am DOM wirken sich sofort auf Layout, Styles und Nutzerinteraktionen aus
  • Wenn JavaScript-Code geändert wird, zeigt eine Vorschaufunktion DOM-Veränderungen in Echtzeit an

Layout, Paint, Composite

  • Sobald DOM und CSS bereit sind, startet der Browser die Rendering-Pipeline
    • Layout (Reflow): Berechnung von Größe und Position der Elemente
    • Paint: Füllen der Pixel
    • Composite: Zusammenführen der Layer auf der GPU
  • Eine Farbänderung führt nur zu erneutem Paint, eine Größenänderung dagegen zu erneutem Layout und Paint
  • Per Klick lässt sich prüfen, welche Schritte jeweils erneut ausgeführt werden
  • Es wird visuell gezeigt, dass Seiten mit vielen Layout-Berechnungen langsamer gerendert werden

Zusammenfassung

  • Ein Leitfaden, mit dem sich der gesamte Weg von der Adresseingabe bis zum Rendering durch eigenes Ausprobieren erlernen lässt
  • Wer alle Schritte durchläuft, kann ein klares mentales Modell der Browser-Funktionsweise aufbauen
  • Das Projekt ist Open Source; auf GitHub können über Issues oder Pull Requests Verbesserungsvorschläge eingereicht werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-01-06
Hacker-News-Kommentare

  • Nicht alle Browser hatten von Anfang an ein DOM
    Anfangs gab es WorldWideWeb (Nexus, 1990), Erwise (1992), ViolaWWW (1992), Lynx (1992), NCSA Mosaic (1993), Netscape 1.0 (1994) und IE 1.0 (1995)
    Lynx ist bis heute bewusst ein Browser ohne DOM geblieben
    AOL 1.0–2.0 verwendete eine statische Engine (AOLPress) ohne programmierbare Objekte
    Mit dem DOM interagieren konnte man erst ab Netscape 2.0 (1995), IE 3.0 (1996), AOL 3.0 (1996) und Opera 3.0 (1997)
    Danach nutzten Netscape 4.0 (document.layers) und IE 4.0 (document.all) jeweils unterschiedliche Modelle
    Das erste standardisierte DOM war W3C DOM Level 1 (1998); IE 5.0 (1999) unterstützte es teilweise, Konqueror 2.0 (2000) und Netscape 6.0 (2000) begannen mit vollständiger Unterstützung
    Safari 1.0 (2003), Firefox 1.0 (2004) und Chrome 1.0 (2008) unterstützten von Anfang an das standardisierte DOM und folgen heute dem WHATWG DOM Living Standard

    • Auch der Browser Dillo hat weiterhin keine DOM-Struktur
      Er rendert durch direkte Interpretation von HTML-Text und benötigt deshalb sehr wenig RAM
    • Ich frage mich, ob die Formulierung „DOM in modernen Browsern“ genauer wäre

  • Tolles Projekt
    Für HN-Leser lohnt es sich, dazu auch High-Performance Browser Networking und Every Layout anzuschauen
    Beides sind hervorragende Materialien, die Web-Performance und CSS-Struktur sehr tiefgehend behandeln

    • HPBN ist wirklich ein hervorragend geschriebenes Buch
      In Kapitel 4 habe ich die TLS-Frame-Struktur verstanden und konnte dadurch in meinem früheren Job Latenzprobleme debuggen
      Auch der Abschnitt über die Trade-offs beim Anpassen der TLS-Frame-Größe war interessant
      Praktisch braucht man das nicht oft, aber es war gut zu wissen, dass Feintuning auf Netzwerkebene möglich ist
    • Danke für den HPBN-Link, wirklich sehr interessantes Material

  • Ein interessanter Ansatz, der sich anfühlt wie browser.engineering ohne Installation
    Wenn Browser- und Server-Beispiele gezeigt werden, würden visuelle Icons (z. B. Desktop/Server) das Verständnis wahrscheinlich erleichtern

    • Es ist geplant, weitere Abschnitte und Details hinzuzufügen
      Im Moment sammle ich erst Feedback, und der Vorschlag mit den Icons ist eine gute Idee, die ich mir ansehen werde

  • Hat mir sehr gut gefallen, daher mit einem Lesezeichen versehen
    Schade ist nur, dass der Ladevorgang von Ressourcen wie Bildern, Stylesheets und Skripten auf Basis von HTML/DOM fehlt
    Genau dieser Teil ist wichtig, um zu verstehen, warum Seitenstile kaputtgehen oder Bilder fehlen

    • Das wurde bewusst ausgelassen, um es einfach zu halten
      Ich überlege gerade, wie sich diese Blöcke ergänzen lassen, ohne alles zu kompliziert zu machen

  • Wenn das Browserfenster schmal ist (unter 1170 px), überlappt der Inhaltsverzeichnis-Abschnitt den Haupttext

    • Wird gerade behoben

  • Die URL-Parsing-Logik könnte noch etwas verfeinert werden
    Die meisten Nutzer werden damit zwar kein Problem haben, aber Browser behandeln auch Protokoll-Schemata außer https:// und http:// speziell
    Es wäre gut, solche Fälle ebenfalls abzufangen
    Siehe: List of URI schemes

  • Hervorragendes Projekt
    Ich frage mich, ob als nächster Schritt geplant ist, mehr Details zum Reflow-Prozess hinzuzufügen

  • Schade, dass mehr als die Hälfte der Seite für Netzwerkanfragen verwendet wird
    Der wirklich komplexe Teil eines Browsers liegt eigentlich in der Parsing- und Rendering-Pipeline

    • Der Teil über die Rendering-Engine soll noch ausführlicher behandelt werden
      Ich wusste nicht, in welchem Abschnitt ich tiefer einsteigen sollte, daher habe ich es erst einmal veröffentlicht und sammle nun Feedback
    • Auch das DOM kann man als Teil der Rendering-Pipeline betrachten

  • Vielleicht eine abwegige Frage, aber ich frage mich, wie es wäre, DNS-Abfragen komplett abzuschaffen und nur mit menschenlesbaren Domainnamen zu arbeiten

    • Noch abwegiger wäre der Gedanke, statt über IP-Adressen über Ethernet-Adressen zu routen
      Die Idee wäre, das gesamte Internet wie einen einzigen riesigen Switch zu machen
      Ich habe einmal einen Artikel eines Tailscale-Gründers gesehen, der eine ähnliche Idee behandelte

  • Tolle Arbeit