Layout Thrashing and Forced Synchronous Layout

The plain-language idea

Normally, the browser is lazy on purpose: when JS changes several styles in a row, it doesn't recompute Layout after each one — it queues the work and runs Layout once, right before the next paint. That batching is what keeps a page fast even when a script touches a dozen elements.

That laziness breaks the moment JS reads a layout-dependent property — offsetHeight, offsetWidth, offsetTop, getBoundingClientRect(), scrollTop, clientWidth, and similar. To answer accurately, the browser can't hand back a stale number from before the pending style changes; it has to run any queued Layout work immediately, synchronously, right there in your script. This is called forced synchronous layout (sometimes "layout thrashing" refers to the anti-pattern that triggers it repeatedly).

Layout thrashing is the specific anti-pattern where code alternates writes and reads inside a loop: write a style, read a layout property, write again, read again. Each read forces a full synchronous Layout recalculation of everything queued so far, so instead of one Layout pass for the whole loop, you get one Layout pass per iteration — turning what should be cheap into a genuine main-thread bottleneck.

See it in a real thing: resizing a list of items

// Thrashing: write, then read, on every iteration
function resizeAll(items) {
  items.forEach((item) => {
    item.style.width = "200px";        // write — queues Layout
    const height = item.offsetHeight;  // read — forces Layout to run NOW
    item.style.height = `${height * 2}px`; // write — queues Layout again
  });
}

// Batched: all reads first, then all writes — one Layout pass total
function resizeAll(items) {
  const heights = items.map((item) => item.offsetHeight); // read phase
  items.forEach((item, i) => {
    item.style.width = "200px";                 // write phase
    item.style.height = `${heights[i] * 2}px`;
  });
}

The first version forces one synchronous Layout per item — for a list of 200 items, that's 200 separate Layout recalculations in a single loop. The second version reads every value while nothing is pending (a single, cheap Layout, if any), then writes everything after, so the browser's normal once-per-frame batching applies. Same visible result, dramatically different cost. This is exactly the "read phase, then write phase" pattern behind libraries like FastDOM, and it's the manual discipline those libraries automate.

What people usually miss

Watch out

• The cost isn't the read or the write alone — it's the alternation. A loop that does all its reads, then all its writes, triggers at most one forced layout. The same operations interleaved trigger one per iteration.
• This is a common, specific cause of a "long task." A loop like this doing real work across hundreds of DOM nodes can easily exceed 50ms on the main thread — directly the mechanism behind slow event-handler code that shows up as a poor Processing Time contribution to INP.
• It's invisible in the code's structure — it only shows up under profiling. The loop above looks completely ordinary; nothing about the syntax screams "performance bug." The DevTools Performance panel flags this explicitly as "Forced reflow" or "Forced synchronous layout" with a stack trace pointing at the exact read call.
• Animation loops (requestAnimationFrame callbacks) are a common place this hides, because each frame's callback often both measures an element's position and then moves it, and it's easy to interleave those without noticing across iterations of the animation.

Why this matters in interviews

"Why is this loop slow even though each operation looks cheap individually?" is a real diagnostic question, and recognizing an interleaved read/write pattern as forced synchronous layout — then fixing it by separating the read phase from the write phase — is a concrete, demonstrable skill interviewers specifically probe for.