DOM-Größe reduzieren

Der Lighthouse-Befund Übermäßige DOM-Größe vermeiden zählt die Elemente einer Seite und warnt, wenn es zu viele sind. Das DOM ist das Modell des HTML im Speicher des Browsers; jedes Element darin muss gestylt, im Layout platziert und aktuell gehalten werden. Eine Seite mit mehreren tausend Elementen kostet mehr Speicher, mehr Zeit bei jeder Neuberechnung von Stilen und Layout und mehr Arbeit bei jeder Interaktion, die die Seite verändert. Das zeigt sich selten als einzelne langsame Anfrage, weshalb es leicht übersehen wird, und es ist eine der häufigsten verborgenen Ursachen für einen schlechten Interaction to Next Paint.

Was der Befund prüft

Lighthouse meldet drei Zahlen: die Gesamtzahl der DOM-Elemente, die maximale Verschachtelungstiefe und die maximale Zahl von Kindern unter einem Elternelement. Es warnt ab 800 Elementen und bewertet ab 1.400 als Fehler. Die Grenzen sind Faustregeln, keine harten Limits: Eine Seite mit 1.000 einfachen Elementen kann problemlos sein, 600 Elemente mit komplexen CSS-Selektoren und häufigen Updates können langsam sein. Die drei Zahlen zusammen zeigen auf die Ursache: Eine sehr hohe Gesamtzahl deutet auf gerendert, aber versteckte Inhalte hin, tiefe Verschachtelung auf Wrapper-Divs aus einem Page Builder oder Komponenten-Framework, ein sehr breites Elternelement auf eine vollständig gerenderte lange Liste.

Warum ein großes DOM langsam ist

• Stilberechnung. Ändert sich CSS oder wird eine Klasse umgeschaltet, muss der Browser Selektoren erneut gegen die betroffenen Elemente abgleichen. Mehr Elemente und breitere Selektoren bedeuten mehr Arbeit pro Änderung.
• Layout. Position und Größe werden für jedes Element im betroffenen Teilbaum berechnet. Ein durch eine Interaktion ausgelöstes Layout dauert auf einer Seite mit 5.000 Elementen messbar länger als auf einer mit 500, und diese Zeit landet direkt im INP.
• Speicher. Jedes Element hält ein eigenes Objekt mit Stil- und Layoutdaten. Auf schwachen Smartphones bringt ein sehr großes DOM die Seite in Richtung Speicherknappheit und Ruckeln.
• Hydrierung und Skripte. Frameworks, die das DOM beim Start durchlaufen, und Skripte mit breiten Selektoren skalieren mit seiner Größe. Das speist die Ausführungszeit und die Total Blocking Time.

So reduzieren Sie die DOM-Größe

1. Herausfinden, woher die Elemente kommen

Das Elements-Panel der Chrome DevTools zeigt den Baum; der Konsolenbefehl document.querySelectorAll('*').length liefert die Zahl. Um die schweren Äste zu finden, zählen Sie die Kinder je Abschnitt:

// Abschnitte der obersten Ebene nach Elementzahl sortiert
[...document.body.children]
  .map(el => [el.tagName + (el.id ? '#' + el.id : ''), el.querySelectorAll('*').length])
  .sort((a, b) => b[1] - a[1]);

Typische Verursacher sind vollständig gerenderte Mega-Menüs, versteckte Mobil- und Desktop-Varianten derselben Komponente, Karussells mit allen Folien im DOM, lange Produktraster, eingebettete Widgets und hundertfach inline eingefügte SVG-Icons.

2. Nicht rendern, was nicht sichtbar ist

Inhalte hinter Tabs, Akkordeons, Mega-Menüs und Modalen müssen erst existieren, wenn sie geöffnet werden. Rendern Sie sie bei Bedarf, oder nutzen Sie das Attribut hidden zusammen mit content-visibility: auto für lange Abschnitte unterhalb des sichtbaren Bereichs. Damit überspringt der Browser das Layout für Inhalte außerhalb des Bildschirms:

.long-section {
  content-visibility: auto;
  contain-intrinsic-size: 1px 800px; /* Platz reservieren, damit nichts springt */
}

3. Lange Listen virtualisieren

Eine Tabelle mit 2.000 Zeilen oder ein Feed mit hunderten Karten sollte nur die Zeilen im und nahe am Viewport rendern. Bibliotheken zur Listen-Virtualisierung gibt es für jedes Framework; für einfache Seiten erledigen Paginierung oder ein Button zum Nachladen dieselbe Aufgabe mit weniger Code.

4. Wrapper-Elemente entfernen

Page Builder und Komponentenbibliotheken packen jeden Block oft in drei bis sechs Divs für Abstände und Ausrichtung. Modernes CSS (Grid, Flexbox, gap, logische Eigenschaften) macht die meisten davon überflüssig. Bei WordPress kann ein Block-Theme statt eines shortcode-lastigen Builders, oder die schlankere Ausgabeoption des Builders, das DOM halbieren.

5. Keine zwei Layouts ausliefern

Wer eine Mobil- und eine Desktop-Version von Header, Navigation oder Produktraster rendert und eine davon per CSS versteckt, verdoppelt das DOM für diese Komponente. Bauen Sie eine responsive Version. Wo zwei Versionen unvermeidlich sind, rendern Sie die zweite erst ab dem Breakpoint, an dem sie gebraucht wird.

6. SVG-Sprites und Icon-Fonts sparsam nutzen

Dasselbe SVG-Icon mit 40 Elementen in 100 Listeneinträgen inline einzufügen ergibt 4.000 Elemente. Referenzieren Sie stattdessen ein Sprite per <use>, oder laden Sie Icons als Bilder, wo keine Interaktivität nötig ist.

7. Einbettungen von Drittanbietern im Blick behalten

Chat-Widgets, Bewertungskarussells, Social Feeds und Cookie-Banner bringen eigene Teilbäume mit, manchmal tausende Elemente in einem iframe oder direkt in der Seite. Der Ratgeber zu Drittanbieter-Code beschreibt, wie Sie sie später laden oder durch leichtere Alternativen ersetzen.

Hinweise je Plattform

• WordPress: Page Builder sind die häufigste Ursache. Prüfen Sie die Einstellungen des Builders auf eine Option für reduziertes Markup, begrenzen Sie verschachtelte Container und entfernen Sie ungenutzte Widgets aus den Templates.
• Shopify: Kollektionsseiten mit vielen Produkten und Abschnitte mit allen gerenderten Folien treiben die Zahl hoch. Begrenzen Sie Produkte je Seite, rendern Sie Karussells verzögert und entfernen Sie App-Blöcke, die verstecktes Markup einfügen.
• Single-Page-Apps: Routen, die frühere Ansichten nie abbauen, und Komponenten, die vollständige Listen zum Filtern rendern, sammeln über die Sitzung Elemente an. Virtualisieren Sie Listen und bauen Sie versteckte Routen ab.

Häufige Fragen

Sind 1.400 Elemente eine harte Grenze?

Nein. Ab dort markiert Lighthouse den Befund als Fehler. Seiten mit einfachen Elementen und wenig Interaktion können darüber problemlos sein, komplexe Seiten darunter langsam. Nehmen Sie die Zahl als Anlass, nach gerenderten, aber ungenutzten Inhalten zu suchen.

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

Indirekt, aber stark. Große DOMs verlangsamen Layout- und Stilarbeit, was den INP erhöht, und sie vergrößern das HTML, das der Browser vor dem ersten Paint parsen muss.

Kann ich das DOM verkleinern, ohne das Design zu ändern?

Meistens. Der Überschuss stammt vor allem aus versteckten Inhalten, doppelten Layouts, Wrapper-Elementen und vollständigen Listen, nichts davon sieht der Besucher. Das sichtbare Design kann bleiben.

Wie finde ich die größten Verursacher schnell?

Zählen Sie die Elemente je Abschnitt der obersten Ebene in der DevTools-Konsole und öffnen Sie den größten Abschnitt im Elements-Panel. Das Muster ist meist binnen einer Minute erkennbar.