Layout Thrashing & Forced Synchronous Layout

The Invisible Performance Killer

Take a look at this code. It looks completely harmless. For a single element, it runs in under 1ms. But throw 100 elements at it, and suddenly it takes 400ms. What went wrong?

const elements = document.querySelectorAll('.card');

elements.forEach(el => {
  const height = el.offsetHeight;           // READ
  el.style.height = (height * 1.2) + 'px';  // WRITE
});

Each iteration reads offsetHeight (forcing layout calculation) then writes style.height (invalidating layout). The next iteration reads again — forcing a complete synchronous layout recalculation. With 100 elements, the browser recalculates layout 100 times in a single frame. This is layout thrashing.

Properties That Force Synchronous Layout

So which properties are the troublemakers? Any property that returns geometry information requires an up-to-date layout. If the layout is dirty (styles have changed since the last calculation), reading these properties forces the browser to stop everything and recalculate:

Element Geometry

// All of these force layout if style changes are pending:
element.offsetTop      element.offsetLeft
element.offsetWidth    element.offsetHeight
element.scrollTop      element.scrollLeft
element.scrollWidth    element.scrollHeight
element.clientTop      element.clientLeft
element.clientWidth    element.clientHeight

Methods That Trigger Layout

element.getBoundingClientRect()
element.getClientRects()
element.computedStyleMap()
window.getComputedStyle(element)
element.focus()            // may trigger scroll → layout
element.scrollTo()
element.scrollIntoView()

Window Properties

window.scrollX          window.scrollY
window.innerWidth       window.innerHeight
window.outerWidth       window.outerHeight

How Browser Batching Normally Works

Here is the thing most people miss: the browser is actually really smart about this by default. When you make multiple style changes without reading anything in between, the browser batches them efficiently:

// The browser does NOT recalculate layout between these lines:
el.style.width = '200px';
el.style.height = '100px';
el.style.padding = '16px';
el.style.margin = '8px';
// Layout is calculated once, at the next paint (requestAnimationFrame or implicit)

The browser marks the layout as dirty on the first write and defers recalculation. All four writes produce a single layout pass. This is the browser's default optimization — and it is very effective.

Layout thrashing defeats this optimization by inserting reads between writes:

// Forced layout on EVERY read:
el.style.width = '200px';
const w = el.offsetWidth;       // Force layout #1
el.style.height = '100px';
const h = el.offsetHeight;      // Force layout #2
el.style.padding = '16px';
const p = el.clientHeight;      // Force layout #3

The Real-World Thrashing Pattern

Now let's look at how this shows up in the wild. The most common thrashing pattern is deceptively simple — looping over elements, reading one property and writing another:

// ❌ THRASHING — O(n) forced layouts
function resizeCards(cards) {
  cards.forEach(card => {
    const width = card.offsetWidth;                    // READ → forces layout
    card.style.height = (width * 0.75) + 'px';         // WRITE → invalidates layout
  });
}

Why it thrashes: On the first iteration, offsetWidth is cheap (layout is clean). The style.height write dirties the layout. On the second iteration, offsetWidth forces a full layout recalculation because the layout is dirty from the previous write. This repeats for every element.

// ✅ FIXED — batch reads, then batch writes
function resizeCards(cards) {
  // Phase 1: Read all values (single layout calculation)
  const widths = Array.from(cards).map(card => card.offsetWidth);

  // Phase 2: Write all values (no reads, so no forced layouts)
  cards.forEach((card, i) => {
    card.style.height = (widths[i] * 0.75) + 'px';
  });
}

Measuring Layout Thrashing

Performance Panel (DevTools)

Record a performance trace and look for:

• Purple bars labeled "Layout" that appear repeatedly in a single frame
• "Forced reflow" warnings in the bottom-up view
• Layout events with "Recalculation Forced" in the event details

Performance API

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.entryType === 'longtask') {
      console.warn('Long task detected:', entry.duration, 'ms');
    }
  }
});
observer.observe({ type: 'longtask', buffered: true });

Console Timing

function measureThrashing(cards) {
  console.time('thrashing');
  cards.forEach(card => {
    const h = card.offsetHeight;
    card.style.height = (h + 10) + 'px';
  });
  console.timeEnd('thrashing');

  console.time('batched');
  const heights = Array.from(cards).map(c => c.offsetHeight);
  cards.forEach((card, i) => {
    card.style.height = (heights[i] + 10) + 'px';
  });
  console.timeEnd('batched');
}
// Typical result: thrashing: 180ms, batched: 3ms (60x faster)

The fastdom Pattern

Batching reads and writes manually is straightforward when all the code is in one function. But what about when reads and writes come from different components, different event handlers, different parts of the app? That is where the fastdom pattern comes in. It schedules DOM reads and writes into separate phases using requestAnimationFrame:

// Concept (simplified fastdom):
const reads = [];
const writes = [];
let scheduled = false;

function measure(fn) {
  reads.push(fn);
  schedule();
}

function mutate(fn) {
  writes.push(fn);
  schedule();
}

function schedule() {
  if (scheduled) return;
  scheduled = true;
  requestAnimationFrame(() => {
    // Execute ALL reads first
    reads.forEach(fn => fn());
    reads.length = 0;
    // Then ALL writes
    writes.forEach(fn => fn());
    writes.length = 0;
    scheduled = false;
  });
}

Usage:

cards.forEach(card => {
  measure(() => {
    const width = card.offsetWidth;
    mutate(() => {
      card.style.height = (width * 0.75) + 'px';
    });
  });
});

All reads execute in one batch, then all writes. Zero forced layouts regardless of how many components schedule reads and writes independently.

Layout Scope and Containment

And this is where it gets even more interesting. Forced layouts are expensive partly because layout is often global — changing one element's height can ripple through siblings, parents, and descendants. But you can limit the blast radius. CSS contain: layout limits this scope:

.card {
  contain: layout;
}

With contain: layout, a forced layout triggered by reading a card's dimensions only recalculates the subtree inside that card — not the entire document. This does not eliminate thrashing but reduces the cost of each forced layout.

Common Thrashing Patterns in Frameworks

jQuery Plugins (Legacy)

// ❌ Classic jQuery thrashing
$('.item').each(function() {
  const h = $(this).height();         // READ
  $(this).css('lineHeight', h + 'px'); // WRITE
});

Animation Libraries

// ❌ Manual animation loop with reads
function animate() {
  elements.forEach(el => {
    const rect = el.getBoundingClientRect();  // READ
    el.style.transform = `translateX(${rect.left + 1}px)`; // WRITE
  });
  requestAnimationFrame(animate);
}

The fix: use transform values tracked in JavaScript instead of reading from the DOM:

// ✅ Track position in JS, never read from DOM
const positions = elements.map(() => 0);

function animate() {
  elements.forEach((el, i) => {
    positions[i] += 1;
    el.style.transform = `translateX(${positions[i]}px)`;
  });
  requestAnimationFrame(animate);
}