Layout thrashing
Slap yourself if
You think layout thrashing is just 'reading offsetHeight too often' or believe the browser can always batch layouts for you.
Why this exists
Because teams still ship UIs that feel inexplicably slow even though CPU usage is low and no long tasks appear — forced synchronous layout is the hidden tax.
Mental model
Layout thrashing is not about expensive layout — it is about destroying the browser’s ability to defer and batch layout work.
- The browser marks layout as dirty after DOM writes.
- A layout read forces an immediate, synchronous layout flush.
- Subsequent writes invalidate that layout again.
- The cycle repeats, preventing batching and blowing up frame time.
- Interleaving DOM reads and writes in loops.
- Measuring layout inside scroll or resize handlers.
- Framework abstractions hiding read/write boundaries.
- Assuming the browser will 'optimize it away'.
Layout thrashing happens when DOM reads force synchronous layout recalculation repeatedly because layout-invalidating writes keep occurring between reads.
- Blames CSS complexity instead of access patterns.
- Says modern browsers handle this automatically.
- Cannot explain why reads can be expensive.
- Talks about reflow without mentioning forced sync.
Deep dive
Requires Pro
Premium deep dives include more internals, more scars.