Browser-Reflow: Was ihn auslöst und wie er die Core Web Vitals beeinflusst

Was ist Browser-Reflow?

Reflow passiert, wenn der Browser die Position und Größe von Elementen auf der Seite neu berechnet. Jedes Mal, wenn Sie das DOM ändern oder eine CSS-Eigenschaft modifizieren, die das Layout beeinflusst, muss der Browser erneut herausfinden, wo alles hingehört. Diese Berechnung blockiert den Main Thread. Nichts anderes passiert, bis sie abgeschlossen ist.

Ein einzelner Reflow auf einer einfachen Seite dauert Mikrosekunden. Aber lösen Sie während einer Benutzerinteraktion Hunderte davon aus, und Sie haben es mit Hunderten von Millisekunden blockierter Main-Thread-Zeit zu tun. Das reicht aus, um bei Interaction to Next Paint durchzufallen.

Zuletzt überprüft von Arjen Karel im März 2026

Die Rendering-Pipeline

Um zu verstehen, warum Reflow teuer ist, müssen Sie wissen, wie der Browser eine Seite rendert. Jede visuelle Änderung durchläuft bis zu fünf Phasen:

JavaScript → Style → Layout → Paint → Composite

JavaScript (oder CSS) löst eine visuelle Änderung aus. Der Browser berechnet neu, welche Stile angewendet werden. Dann führt er das Layout (Reflow) aus, um die Geometrie zu berechnen. Danach zeichnet er die Pixel (Paint). Schließlich setzt er die Ebenen zusammen (Composite).

Nicht jede Änderung durchläuft alle fünf Phasen. Das ist die wichtigste Erkenntnis. Ändern Sie width oder height, und Sie lösen die gesamte Pipeline aus. Ändern Sie background-color, und Sie überspringen das Layout komplett (nur Paint + Composite). Ändern Sie transform oder opacity, und Sie überspringen sowohl Layout als auch Paint und gehen direkt zum Composite über. Der web.dev Rendering Performance Guide behandelt diese Pipeline im Detail.

Änderungen, die nur Composite erfordern, sind ressourcenschonend. Layout-Änderungen sind es nicht. Bei 60fps hat der Browser 16.66ms pro Frame, um alles zu erledigen. Nach Abzug des Browser-Overheads bleiben Ihnen etwa 10ms für Ihren Code. Wenn Sie diese Zeit für Reflow ausgeben, entsteht Ruckeln (Jank).

Was Reflow auslöst

Zwei Kategorien von Dingen verursachen einen Reflow: Änderungen, die das aktuelle Layout ungültig machen, und JavaScript-Lesezugriffe, die den Browser zwingen, das Layout sofort zu berechnen.

CSS-Eigenschaften, die ein Layout auslösen

Die Änderung einer dieser Eigenschaften zwingt den Browser zu einem Reflow:

• Dimensionen: width, height, padding, border, min-height, max-width
• Position: top, right, bottom, left, margin
• Layout-Modus: display, float, position, flex, grid
• Text: font-size, font-family, font-weight, line-height, text-align, white-space
• Inhalt: overflow, word-wrap

Eigenschaften wie color, background-color, visibility und box-shadow lösen einen Repaint aus, aber keinen Reflow. Eigenschaften wie transform, opacity und filter lösen keines von beiden aus. Dies sind die Eigenschaften, die Sie für Animationen und Übergänge (Transitions) verwenden sollten.

JavaScript-Eigenschaften, die synchrones Layout erzwingen

Hier wird es teuer. Bestimmte JavaScript-Eigenschaften zwingen den Browser dazu, das Layout genau jetzt synchron zu berechnen, was Ihr Skript blockiert. Paul Irish pflegt eine umfassende Liste (über 5.000 Sterne auf GitHub). Die häufigsten sind:

• offsetWidth, offsetHeight, offsetTop, offsetLeft
• clientWidth, clientHeight, clientTop, clientLeft
• scrollWidth, scrollHeight, scrollTop, scrollLeft
• getBoundingClientRect()
• getComputedStyle()
• innerText (ja, das Lesen von innerText erzwingt ein Layout)
• focus()
• scrollIntoView()

Das Auslesen einer dieser Eigenschaften nach der Änderung einer Layout-Eigenschaft erzwingt einen synchronen Reflow. Der Browser kann den Wert nicht zurückgeben, ohne vorher das Layout zu berechnen. Die Chrome DevTools markieren erzwungene Reflows, die 30ms überschreiten, als Leistungsengpass.

Layout Thrashing: Das zu vermeidende Muster

Layout Thrashing passiert, wenn Ihr Code in einer Schleife abwechselnd Layout-Eigenschaften liest und schreibt. Jeder Lesezugriff erzwingt einen Reflow, da der vorherige Schreibzugriff das Layout ungültig gemacht hat. Ich sehe dieses Muster ständig in Karussell-Skripten, Akkordeon-Plugins und Analytics-Code, der Elementpositionen misst.

// SCHLECHT: erzwingt einen Reflow bei jeder Iteration
for (const el of elements) {
  el.style.width = box.offsetWidth + 'px'; // lesen + schreiben = erzwungener Reflow
}

Jede Iteration liest offsetWidth (erzwingt Layout) und schreibt dann style.width (macht Layout ungültig). Bei 100 Elementen sind das 100 erzwungene Reflows anstelle von einem.

// GUT: fassen Sie den Lesezugriff zusammen, dann die Schreibzugriffe
const width = box.offsetWidth; // einzelner Lesezugriff
for (const el of elements) {
  el.style.width = width + 'px'; // nur Schreibzugriffe, keine erzwungenen Reflows
}

Ein Lesezugriff, ein Reflow, fertig. Der web.dev-Leitfaden zu Layout Thrashing zeigt dieses Muster im Detail. Wenn Sie individuelle Elementgrößen lesen müssen, sammeln Sie zuerst alle Lesezugriffe und führen Sie dann alle Schreibzugriffe aus.

Erkennung von erzwungenem Reflow in den Chrome DevTools

Öffnen Sie das Performance-Panel und zeichnen Sie einen Trace auf. Erzwungene Reflows werden als violette "Layout"-Blöcke im Flame-Chart angezeigt. Wenn Chrome ein erzwungenes synchrones Layout erkennt, fügt es ein rotes Warndreieck hinzu. Bewegen Sie den Mauszeiger darüber, und Sie sehen genau, welche JavaScript-Zeile den Reflow ausgelöst hat.

Die Konsole protokolliert ebenfalls eine Warnung: "Forced reflow while executing JavaScript took Xms". Alles über 30ms ist ein Problem. Ich habe Seiten gesehen, bei denen ein einzelner Scroll-Event-Handler in jedem Frame 40ms an Layout-Arbeit auslöst.

Lighthouse markiert dies ebenfalls. Achten Sie auf die Diagnose "Avoid forced reflow" in der Kategorie Performance.

Wie sich Reflow auf die Core Web Vitals auswirkt

Interaction to Next Paint (INP)

Reflow wirkt sich auf zwei Arten direkt auf INP aus. Wenn bereits ein erzwungener Reflow läuft, wenn der Benutzer klickt, erhöht sich der Input Delay, da der Main Thread blockiert ist. Wenn der Klick-Handler selbst Layout-Arbeit auslöst, erhöht sich die Processing Time. So oder so wächst auch der Presentation Delay, da der Browser das Layout abschließen muss, bevor er die Antwort zeichnen (paint) kann.

Der INP-Grenzwert für "gut" liegt bei 200ms. Ein einzelner erzwungener Reflow von 30ms verbraucht bereits 15% dieses Budgets. Layout Thrashing in einem Event-Handler kann den INP leicht über 500ms treiben.

Über alle von CoreDash überwachten Websites hinweg weisen Seiten, die DOM-Lese- und Schreibzugriffe zusammenfassen, etwa 18% bessere INP-Werte auf im Vergleich zu Seiten mit Layout-Thrashing-Mustern.

Largest Contentful Paint (LCP)

Während des Ladens der Seite konkurriert der Reflow um die Zeit des Main Threads. Das Laden von Schriftarten (Font loading) ist eine häufige Quelle dafür: Wenn eine Web-Schriftart eintrifft und den Fallback-Text ersetzt, führt der Browser für jedes Element, das diese Schriftart verwendet, einen Reflow durch. Auf einer Seite mit viel Text kann dieser Reflow den LCP um 100ms oder mehr verzögern.

Bilder ohne explizite width- und height-Attribute verursachen das gleiche Problem. Laut dem Web Almanac 2025 haben 62% der mobilen Seiten immer noch mindestens ein Bild ohne Dimensionen. Wenn dieses Bild geladen wird, führt der Browser einen Reflow der Seite durch, um sich an die tatsächliche Größe anzupassen.

Cumulative Layout Shift (CLS)

Reflow selbst verursacht keinen CLS. CLS tritt auf, wenn sich sichtbare Elemente bewegen, nachdem der Benutzer sie gesehen hat. Aber Reflow durch spät ladende Inhalte (eingefügte Anzeigen, Bilder ohne Größenangabe, dynamisch eingefügte Elemente) ist der Mechanismus hinter den meisten Layout-Verschiebungen (Layout Shifts). Beheben Sie den Reflow-Auslöser, und der Layout Shift verschwindet.

CSS-Übergänge (Transitions), die Layout-Eigenschaften animieren, sind eine weitere Quelle. Der Übergang von height oder margin verursacht bei jedem Animations-Frame einen Reflow.

Reflow mit modernem CSS verhindern

Nur-Composite-Animationen

Animieren Sie transform und opacity anstelle von width, height, top oder left. Diese laufen auf dem GPU-Compositor-Thread und überspringen das Layout komplett. Möchten Sie ein Element verschieben? Verwenden Sie transform: translateX(). Möchten Sie es visuell in der Größe ändern? Verwenden Sie transform: scale(). Der Web Almanac 2025 fand heraus, dass 40% der mobilen Seiten immer noch nicht-compositete Animationen verwenden. Das bedeutet, dass 40% der Seiten bei jedem Frame unnötige Layout-Arbeit verrichten.

CSS Containment

Die Eigenschaft contain teilt dem Browser mit, dass das Innere eines Elements vom Rest der Seite unabhängig ist. Wenn sich innerhalb eines contained Elements etwas ändert, führt der Browser nur für diesen Teilbaum (Subtree) einen Reflow durch anstatt für das gesamte Dokument.

article {
  contain: content;
}

Dies ist besonders nützlich für Seiten mit einem großen DOM. Je mehr Elemente der Browser während eines Reflows prüfen muss, desto länger dauert es. Containment begrenzt den Wirkungsradius (Blast Radius).

content-visibility

content-visibility: auto weist den Browser an, Layout-, Paint- und Stilberechnungen für Elemente zu überspringen, die sich außerhalb des sichtbaren Bereichs (offscreen) befinden. Als Google dies auf einer Reise-Blog-Demo testete, sank die Rendering-Zeit von 232ms auf 30ms. Eine 7-fache Verbesserung.

.section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

contain-intrinsic-size gibt dem Browser eine Platzhalterhöhe, damit die Berechnungen der Bildlaufleiste (Scrollbar) korrekt bleiben. Diese Eigenschaft wurde im September 2025 als Baseline Newly Available eingestuft, was bedeutet, dass sie in allen gängigen Browsern funktioniert.

Praktische Checkliste

1. Fassen Sie DOM-Lesezugriffe vor Schreibzugriffen zusammen (Batching). Wechseln Sie niemals zwischen dem Lesen von Layout-Eigenschaften und dem Schreiben von Stiländerungen.
2. Legen Sie explizite Dimensionen für Bilder und Einbettungen fest. Dies verhindert einen Reflow, wenn die Ressource geladen wird.
3. Animieren Sie nur mit transform und opacity. Diese überspringen Layout und Paint komplett.
4. Verwenden Sie contain: content für unabhängige Abschnitte. Dies begrenzt den Reflow auf den geänderten Teilbaum.
5. Fügen Sie content-visibility: auto zu Below-the-Fold-Abschnitten hinzu. Dies überspringt das Layout für nicht sichtbare Inhalte.
6. Bevorzugen Sie Flexbox gegenüber Floats. Flexbox-Layouts sind bei gleicher Elementanzahl etwa viermal schneller als Float-Layouts.
7. Yield to the main thread (geben Sie den Main Thread frei) zwischen teuren DOM-Operationen, um die Seite reaktionsfähig zu halten.
8. Verzögern Sie Skripte, die das DOM verändern, bis das initiale Rendern abgeschlossen ist.

Überwachen Sie die tatsächlichen Auswirkungen dieser Änderungen mit Real User Monitoring. Labor-Tools wie Lighthouse zeigen Ihnen die Layout-Kosten isoliert, aber Felddaten zeigen, ob Ihre Nutzer die Verbesserung tatsächlich erleben.