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 A `long-animation-frame` PerformanceObserver entry no longer fires for the interaction.