DOM-Größe reduzieren: weniger Knoten, mehr Tempo

Bis Lighthouse 12 war die DOM-Bewertung ein reines Zählspiel. Das Audit „Avoid an excessive DOM size“ schlug Alarm, sobald eine Seite bestimmte Knotenzahlen überschritt – unabhängig davon, ob diese Knoten überhaupt teure Arbeit verursachten. Mit Lighthouse 13 vom Oktober 2025 hat Google diese Logik grundlegend geändert. Aus dem statischen Audit ist die Insight „DOM-Größe optimieren“ geworden, die nicht mehr nur Knoten zählt, sondern die tatsächliche Style- und Layout-Arbeit misst (Chrome for Developers).

Die neue Insight schlägt erst an, wenn eine Layout- oder Stilneuberechnung länger als 40 Millisekunden dauert (Chrome for Developers). Als große Layout-Aktualisierung gilt dabei eine, die mehr als 100 Layout-Objekte betrifft; eine große Stilneuberechnung erfasst mehr als 300 Elemente (Chrome for Developers). Der Vorteil dieser Umstellung: Eine Seite mit vielen, aber statischen Knoten, die keine teure Neuberechnung auslösen, wird nicht länger fälschlich abgestraft. Umgekehrt rückt die Insight genau die Fälle in den Fokus, in denen das DOM die Interaktivität real ausbremst.

Für die Praxis bedeutet das eine Verschiebung vom Symptom zur Ursache. Die reine Knotenzahl bleibt ein nützlicher Frühindikator – eine Seite mit mehreren tausend Knoten wird fast zwangsläufig irgendwo teure Neuberechnungen auslösen. Doch die Insight zwingt dazu, den Blick auf die tatsächlich betroffenen Elemente pro Interaktion zu richten. Genau diese Messung steht am Anfang jeder strukturierten Performance-Analyse, bevor eine einzige Zeile Markup verändert wird.

Zwei Muster verursachen die große Mehrheit aller aufgeblähten Bäume. Das erste sind große Listen ohne Begrenzung: Kategorieseiten mit hunderten Produkten, endlose Tabellen, Kommentarlisten oder Verzeichnisse. Jede einzelne Produktkachel besteht schnell aus einem Dutzend Knoten – Bild, Titel, Preis, Badges, Buttons, Wrapper. Bei 120 Artikeln auf einer Seite sind das allein für die Liste weit über tausend Knoten, und der umgebende Listen-Container überschreitet leicht die Grenze von 60 Kindern je Element.

Das zweite Muster ist die Wrapper-Div-Suppe generischer Page-Builder. Um flexibel zu sein, umschließen viele Baukastensysteme jeden Abschnitt, jede Zeile, jede Spalte und jedes Element mit mehreren zusätzlichen Container-Divs. Aus einem inhaltlich einfachen Abschnitt werden so fünf oder sechs Verschachtelungsebenen, die keinerlei sichtbaren Zweck erfüllen, aber die Baumtiefe in die Höhe treiben. Beide Muster zusammen – breite Listen und tiefe Verschachtelung – erzeugen genau die Bäume, die bei jeder Interaktion teure Neuberechnungen auslösen.

Wo Inhalte im DOM verbleiben müssen, aber nicht sofort sichtbar sind, hilft die CSS-Eigenschaft content-visibility: auto. Sie erlaubt dem Browser, das Rendering – Stilberechnung und Layout – für Bereiche außerhalb des Sichtfensters zunächst zu überspringen und erst nachzuholen, wenn diese in den sichtbaren Bereich gelangen. Die Knoten bleiben im Baum, doch die teure Arbeit fällt beim ersten Laden weg. In einem Beispiel der web.dev-Dokumentation sank die anfängliche Rendering-Zeit einer langen Seite dadurch von 232 Millisekunden auf 30 Millisekunden (web.dev).

Entscheidend ist die Begleiteigenschaft contain-intrinsic-size. Sie gibt dem Browser eine geschätzte Größe für die noch nicht gerenderten Bereiche vor, damit die Bildlaufleiste stabil bleibt und beim Hineinscrollen kein Layout-Sprung entsteht. Ohne diese Angabe würde das Nachrendern die Seitenhöhe verändern und den Cumulative Layout Shift verschlechtern – wie sich solche Sprünge vermeiden lassen, vertieft der Beitrag zum Vermeiden von Layout-Verschiebungen. Richtig eingesetzt entlastet content-visibility den ersten Frame, ohne die Struktur oder das Verhalten der Seite zu verändern.

content-visibility ersetzt keine Virtualisierung, sondern ergänzt sie. Virtualisierung entfernt Knoten aus dem DOM und senkt damit die Gesamtzahl; content-visibility lässt die Knoten im Baum, spart aber die Rendering-Arbeit für das, was gerade nicht zu sehen ist. Für lange, statische Inhaltsseiten – Artikel, Dokumentationen, FAQ-Strecken – ist content-visibility oft die einfachere und völlig ausreichende Lösung.

Ein wiederkehrendes Muster verdeutlicht, wie die Maßnahmen ineinandergreifen. Ausgangslage: Eine Kategorieseite eines Online-Shops auf Basis von Shopware CE meldet in den Felddaten träge Interaktionen bei der Produktfilterung – ein häufiges Szenario in der Shopware-Performance-Optimierung. Die DOM-Insight und das DevTools-Panel weisen die Seite mit rund 1.900 Knoten, einer Baumtiefe von 38 Ebenen und einer Stilneuberechnung von 92 Millisekunden je Filterklick aus (Projekterfahrung). Die Ursache: 120 Produktkacheln auf einer Seite, jede mehrfach in Wrapper-Divs geschachtelt.

Der Optimierungspfad setzt an drei Punkten an. Erstens begrenzt Pagination die Liste auf 24 Produkte je Seite, was die Knotenzahl der Liste unmittelbar senkt. Zweitens entfernt eine Überarbeitung des Kachel-Markups zwei überflüssige Wrapper-Ebenen pro Produkt und ersetzt sie durch ein einzelnes Grid, wodurch die Baumtiefe deutlich sinkt. Drittens überspringt content-visibility das Rendering der noch nicht sichtbaren Kacheln. In der Summe fällt die Seite auf rund 720 Knoten, eine Tiefe von 12 Ebenen und eine Stilneuberechnung von 24 Millisekunden – ohne dass ein einziges Produkt oder eine Funktion entfernt wurde (Projekterfahrung). Vergleichbare Ausgangslagen begegnen uns in vielen Projekten quer durch Branchen und Vorlagen-Typen.

Wichtig ist die abschließende Validierung im Feld. Da die offiziellen Felddaten als rollierender 28-Tage-Durchschnitt aktualisiert werden, zeigt sich die Wirkung einer Optimierung erst mit einigen Wochen Verzögerung in den offiziellen Werten. Bis dahin liefert eigenes Real User Monitoring den schnelleren Rückkanal, und die DOM-Insight bestätigt bereits im Labor, dass die teuren Neuberechnungen unter die 40-Millisekunden-Schwelle gerutscht sind.