Finding Layout Thrashing in DevTools

Layout thrashing leaves an unmistakable signature in the Chrome DevTools Performance panel: purple Layout events flagged with red Forced reflow warnings, attributed through the call tree to the exact JavaScript line that read geometry. This guide walks the trace from capture to attribution to fix. It builds on Forced Synchronous Layouts, part of Layout and Paint Optimization.

Capturing a Usable Trace

A forced reflow that disappears at native CPU speed still drops frames on a mid-tier phone, so always throttle.

1. Performance panel → enable Screenshots and set CPU to 6× slowdown.
2. Click record, reproduce the janky interaction (scroll, accordion toggle, list update), then stop.
3. Zoom the main-thread track to the long task — the one with a red corner ribbon marking it as Long task (> 50ms).

The Visual Signature

Inside the long task, layout work is colored purple. Two markers confirm thrashing:

• A purple Layout (or Recalculate Style) block with a small red triangle in its top-right corner.
• Hovering it shows the warning: “Forced reflow is a likely performance bottleneck” along with the total time spent in forced layout for that task.

[Main Thread]  Task 21.3ms  ▸ red ribbon: Long task
├─ Function Call  renderRows  (19.0ms)
│  ├─ Recalculate Style  (3.2ms)   ⚠
│  └─ Layout  (11.8ms)             ⚠ Forced reflow — likely bottleneck
│     └─ get offsetHeight @ rows.js:42  ← attributed read
└─ Paint  (1.4ms)
Frame Budget: 16.6ms | Actual: 21.3ms — DROPPED

The aggregated “Recalculate Style / Layout” warning in the Summary tab gives you the total forced-layout time across the whole task — the number to drive toward zero.

Call-Tree Attribution

Select the warned Layout event, then open the Bottom-Up or Call Tree tab. The bottom-up view roots the layout cost at the DOM API that forced it — get offsetHeight, getBoundingClientRect, get scrollTop — and the Source link jumps straight to the offending line. This is the fastest way to find which read triggered the flush when the loop body is buried in framework code.

If the read sits inside a long-running JavaScript task, pair this trace with Observing Long Tasks with PerformanceObserver to catch the same regression in the field, where you cannot open DevTools.

Reproduction

This loop forces one layout per row because it reads offsetHeight right after writing a class:

// ❌ Reproduces forced reflow: read-after-write inside a loop
function renderRows(rows) {
  for (const row of rows) {
    row.classList.add('measured')   // write: dirties layout tree
    const h = row.offsetHeight      // read: forces synchronous layout (rows.js:42)
    row.dataset.h = h               // write: dirties again
  }
}

Run it over a few hundred rows under 6× throttling and the trace shows a stack of red-flagged Layout events whose durations sum to the warned total.

The Fix

Separate the phases so all writes land first, then all reads resolve in a single flush.

// ✅ One flush for every read; no forced reflow markers in the trace
function renderRows(rows) {
  rows.forEach((row) => row.classList.add('measured')) // write phase
  const heights = rows.map((row) => row.offsetHeight)  // single layout flush
  rows.forEach((row, i) => { row.dataset.h = heights[i] }) // write phase
}

Re-record the same interaction. The purple Layout block shrinks to one event with no red triangle, and the Recalculate Style / Layout summary warning vanishes. The detailed batching strategies — including requestAnimationFrame deferral and ResizeObserver — are in How to batch DOM reads and writes to prevent thrashing.

Verification Checklist

• No red triangles on any purple Layout block.
• Bottom-Up view no longer roots layout cost at a geometry getter.
• The interaction stays inside the 16.6ms frame budget at 6× CPU throttling.
• A long-animation-frame PerformanceObserver entry no longer fires for the interaction.

Reading the Warning Annotation

Chrome’s Performance panel does most of the detective work for you once you know where to look. A forced reflow shows up as a Layout event nested inside a JavaScript call frame — not at the frame boundary where a normal layout runs — and the timeline marks it with a red-cornered “Forced reflow” warning. Clicking that warning jumps straight to the line of code that read a geometry property mid-task, which is usually the fastest possible path from symptom to cause. The bottom-up and call-tree views then let you aggregate how much total time the forced layouts cost across the recording, which is the number that tells you whether the thrash is a minor inefficiency or the dominant cost of the interaction.

The second signal worth training your eye on is the pattern of alternating events. A healthy frame shows a single Layout at the end; a thrashing frame shows Layout, Recalculate Style, Layout, Recalculate Style repeating within one task, each pair triggered by a read that followed a write. When you see that sawtooth, the fix is always the same shape — gather the reads before the writes — and re-recording after the change should collapse the sawtooth into a single trailing layout. Confirming that collapse in a fresh trace is what turns “I think I fixed it” into “the forced reflows are gone,” and it takes only as long as a second recording.

Frequently Asked Questions

Related Guides

• Forced Synchronous Layouts — the parent guide on why geometry reads flush layout mid-task.
• How to batch DOM reads and writes to prevent thrashing — the full batching, requestAnimationFrame, and ResizeObserver playbook.
• Observing Long Tasks with PerformanceObserver — catch the same regression in the field.
• Layout and Paint Optimization — the broader pipeline stage this guide sits under.