Erzwungenes synchrones Layout: Geometrie nach dem Schreiben ins DOM lesen

Was passiert

Normalerweise erfolgt das Layout, nachdem dein JavaScript fertig ist, einmal pro Frame. Aber wenn du das DOM änderst und dann sofort eine Layout-Eigenschaft liest — offsetWidth, scrollHeight, getBoundingClientRect(), getComputedStyle() — muss der Browser anhalten und das Layout genau dort synchron innerhalb deiner Aufgabe berechnen, weil die Antwort von deiner ausstehenden Änderung abhängt.

Ein erzwungenes Layout ist auf einer kleinen Seite billig. Auf einem großen DOM oder in einer Schleife wiederholt (was zu Layout-Thrashing wird) fügt es dem Handler Hunderte Millisekunden hinzu.

So erkennst du es

• Lange Processing Time in der INP-Aufschlüsselung, mit Layout-Blöcken, die in den DevTools Performance in die Skript-Aufgabe verschachtelt sind („Forced reflow“-Warnung).
• Die Long Animation Frames API meldet eine große forcedStyleAndLayoutDuration für dein Skript.
• Der Handler verändert das DOM und misst zugleich Elemente.

So behebst du es

• Lies die gesamte Geometrie vor dem ersten DOM-Schreibzugriff in der Aufgabe.
• Cache Messwerte, die sich nicht ändern (Elementgrößen, Containerbreite), statt sie bei jedem Event neu zu lesen.
• Wenn du nach einer Änderung messen musst, verschiebe den Lesezugriff auf das requestAnimationFrame des nächsten Frames, oder nutze ResizeObserver / IntersectionObserver statt Geometrie abzufragen.

Problem

grid.style.width = next + "px"            // write: layout is now dirty
const rect = cell.getBoundingClientRect()  // read → forced synchronous layout

Lösung

const rect = cell.getBoundingClientRect()  // read first, layout is clean
grid.style.width = next + "px"             // write after; browser lays out
                                           // once, before the next paint