Was ist das DOM? Document Object Model erklärt

Was ist das DOM?

Das Document Object Model (DOM) ist die Darstellung einer Webseite im Arbeitsspeicher des Browsers. Beim Parsen von HTML baut der Browser einen Baum aus Knoten (Elemente, Text und Attribute), und Skripte nutzen die DOM-API, um Struktur, Stil und Inhalt dieses Baums zu lesen und zu ändern. Laut MDN ist das DOM eine Web-API und kein Teil der Sprache JavaScript selbst.

So baut der Browser das DOM

Der Browser wandelt HTML-Bytes in Zeichen, dann in Tokens und dann in Objekte um und verknüpft diese zu einem Baum, der die Eltern-Kind-Beziehungen des Markups abbildet. Dasselbe geschieht mit CSS, daraus entsteht ein eigener Baum, das CSSOM. Beide sind unabhängige Strukturen, die der Browser kombiniert, um zu entscheiden, was gezeichnet wird. Deshalb kann eine Seite nicht rendern, bevor ihr CSS bekannt ist. Das DOM ist keine wörtliche Kopie des Quelltexts: Leerraum bleibt als Textknoten erhalten, und Skripte können nach dem Laden Knoten hinzufügen, verschieben oder entfernen. Das DOM in den DevTools kann sich daher von „Seitenquelltext anzeigen“ unterscheiden.

Knoten, Elemente und die API

Jedes Objekt im Baum ist ein Knoten. Ein Element ist die häufigste Art, aber auch Text und Attribute sind Knoten. Das Objekt document ist die Wurzel, von der du ausgehst. Nimm dieses Markup:

<body>
  <h1>Pricing</h1>
  <p class="note">Billed monthly</p>
</body>

Drei Zeilen JavaScript wählen es aus, ändern es und reagieren darauf:

const note = document.querySelector(".note");   // erstes passendes Element wählen
note.textContent = "Billed yearly";               // Text ändern
note.addEventListener("click", () => note.remove()); // auf Klick reagieren, dann entfernen

Die Rendering-Ansätze unterscheiden sich vor allem darin, wo das DOM entsteht. In einer Single-Page-App erzeugt JavaScript den Großteil im Browser. Beim Server-Rendering schickt der Server HTML, der Browser baut daraus das DOM, und die Hydration hängt anschließend die Event-Handler an.

Wann ist das DOM bereit?

DOMContentLoaded wird ausgelöst, sobald das HTML vollständig geparst ist und die deferred Skripte gelaufen sind. Das Ereignis wartet nicht auf Bilder, Subframes oder async Skripte; das spätere load-Ereignis markiert die vollständig geladene Seite. MDN weist darauf hin, dass es ein häufiger Fehler ist, load zu nutzen, wo DOMContentLoaded reicht. Skripte, die vorhandene Elemente brauchen, sollten defer nutzen, auf DOMContentLoaded warten oder zuerst document.readyState prüfen.

Das DOM und die Seitengeschwindigkeit

Jede Änderung am DOM kann Style-, Layout- und Paint-Arbeit auslösen, und die Kosten wachsen mit der Größe des Baums. Lighthouse warnt, wenn der body mehr als etwa 800 Knoten hat, und meldet einen Fehler ab etwa 1.400. Große Bäume verlangsamen Style-Neuberechnung und Layout, und breite Selektoren wie querySelectorAll("li") können Tausende Knotenreferenzen im Speicher halten. Das zeigt sich in der Reaktionsfähigkeit und damit in Interaction to Next Paint (INP). Spät eingefügte Elemente ohne reservierten Platz verschieben außerdem Inhalte und verschlechtern den Cumulative Layout Shift.

Häufige Fehler

• Nutzereingaben mit innerHTML schreiben. MDN nennt es wohl den häufigsten Angriffsvektor für Cross-Site-Scripting. Nimm textContent für reinen Text.
• Layout Thrashing. Wechselt eine Schleife zwischen DOM-Lesezugriffen wie offsetWidth und Style-Schreibzugriffen, muss der Browser das Layout bei jedem Durchlauf neu berechnen. Lies zuerst alles gebündelt, schreibe danach.
• Zu früh abfragen. Ein Skript im <head> ohne defer läuft, bevor der Body existiert, daher liefert querySelector null.
• Tiefes, wrapper-lastiges Markup. Flache Verschachtelung, Flexbox oder Grid statt zusätzlicher Container-Elemente.
• Alles sofort rendern. Lange Listen und versteckte Bereiche erzeugen Knoten, die noch niemand sieht. Lade sie verzögert oder nutze content-visibility.

Das DOM in Tests und Monitoring

Ein Last-Test auf Protokollebene, etwa mit JMeter, sendet HTTP-Anfragen und baut nie ein DOM auf. Er sagt dir also nicht, wie schwer eine Seite für den Browser ist. Dafür brauchst du einen echten Browser. Der LoadFocus Core Web Vitals Checker zeigt Felddaten zu einer URL, auch zur Reaktionsfähigkeit, und Page Speed Monitoring führt geplante Lighthouse-Audits aus 25 Cloud-Regionen aus (Lighthouse ist das Werkzeug hinter der oben genannten DOM-Größen-Warnung). Zu INP-Optimierungen lies How to Optimize Interaction to Next Paint (auf Englisch), zum Einrichten von Alerts How to Monitor Core Web Vitals (auf Englisch).

Häufige Fragen: Document Object Model

Ist das DOM Teil von JavaScript?

Nein. Das DOM ist eine Web-API, die Browser bereitstellen. JavaScript ist die häufigste Sprache, um sie aufzurufen, aber das DOM ist getrennt definiert.

Was ist der Unterschied zwischen DOM und HTML-Quelltext?

Der Quelltext ist der Text, den dein Server sendet. Das DOM ist der lebendige Baum, den der Browser daraus baut. Skripte können das DOM nach dem Laden ändern, daher zeigen die DevTools womöglich Knoten, die nicht im Seitenquelltext stehen.

Wie viele DOM-Knoten sind zu viele?

Lighthouse warnt bei etwa 800 Knoten im Body und meldet einen Fehler bei etwa 1.400. Das sind Richtwerte, keine harten Grenzen, und eine Seite kann auch darunter langsam sein, wenn Selektoren und Layout aufwendig sind.

Was ist der Unterschied zwischen DOMContentLoaded und load?

DOMContentLoaded wird ausgelöst, wenn das HTML geparst ist und deferred Skripte gelaufen sind, ohne auf Bilder oder async Skripte zu warten. Das load-Ereignis folgt später, wenn die Seite vollständig geladen ist.

Warum ist innerHTML riskant?

Es parst einen String als HTML. Unbereinigte Nutzereingaben können so über Attribute wie onerror schädliches JavaScript ausführen. Nutze textContent, wenn der Inhalt reiner Text ist.

Beeinflusst die DOM-Größe die Core Web Vitals?

Ja, das kann sein. Aufwendige Style- und Layout-Arbeit durch ein großes DOM bremst Interaktionen, was in den INP einfließt, und spät eingefügte Elemente können das Layout verschieben.