Avoiding Layout Thrashing Systematically

1. What layout thrashing actually is

Layout thrashing, sometimes called forced synchronous layout, occurs when JavaScript code alternately writes a layout property and then reads another layout property, repeatedly within the same function or loop. Every read access following a write access forces the browser to compute the entire pending layout immediately, instead of deferring it until the end of the current frame as usual. With ten iterations alternating reads and writes, this produces ten full, synchronous layout calculations instead of a single one at the end of the frame.

The effect is especially treacherous because the code looks harmless at first glance: a loop over a list of elements that reads each element's height and then sets a new position is a perfectly normal pattern in dynamic user interfaces. Yet exactly this combination of reading and writing per iteration is the core of the problem. Layout thrashing shows up in practice as noticeable jank during scroll interactions, slow resize reactions, and long main thread blocking, visible in the performance panel as repeated purple "Layout" blocks.

2. Which properties trigger a forced reflow

Not every DOM property triggers a forced reflow, but a well known group of properties and methods does so reliably as soon as it is queried after a write operation. These include offsetWidth, offsetHeight, offsetTop, offsetLeft, clientWidth, clientHeight, scrollWidth, scrollHeight, scrollTop and getBoundingClientRect(). getComputedStyle() also forces immediate calculation for certain properties, especially when the queried property depends on the current layout.

The reason for this forcing is simple: the browser can only return these values correctly if it has actually computed the layout. If a write operation such as setting style.width or adding a class still leaves the browser's internal state marked "dirty", this calculation must be caught up immediately before the read access can return a valid value. This forced intermediate calculation is the technical core of layout thrashing and cannot be avoided as long as read and write accesses remain mixed in this order.

3. The classic anti-pattern inside loops

The most common real world example of layout thrashing is a loop that, for each element in a list, first reads its height and then immediately writes a new height or position onto another element. If this loop runs over a hundred elements, it produces a hundred forced, synchronous layout calculations within a single JavaScript task, which on complex pages can quickly cause several hundred milliseconds of main thread blocking.

This pattern shows up especially often in masonry layouts, tables with dynamic column widths, and when synchronizing the height of multiple cards in a grid. The code looks locally correct because each individual operation makes sense on its own, the problem only emerges from the combination and repetition at scale. This very inconspicuousness is what makes layout thrashing one of the most commonly overlooked performance problems in single page applications with complex, data driven lists.

// ANTI-PATTERN: forces one synchronous layout per iteration
const cards = document.querySelectorAll(".card");
cards.forEach((card) => {
  const height = card.offsetHeight;   // READ: triggers layout if dirty
  card.style.height = `${height + 20}px`; // WRITE: marks layout dirty again
  // Next iteration's read forces a fresh, full layout recalculation
});

4. Read/write batching as the solution

The solution to layout thrashing is conceptually simple: all read accesses are collected in a first phase, before any write access happens at all, followed by all write accesses in a second, separate phase. This pattern is often called the FastDOM pattern, named after the JavaScript library of the same name that automates exactly this batching, but the principle can also be implemented by hand without an extra dependency.

The decisive advantage of this batching: since every read access happens before every write access, the browser only needs to compute the layout once, regardless of how many elements the loop processes. With a hundred elements, the number of layout calculations drops from potentially a hundred down to a single one, which can be the difference between a noticeably janky interface and a butter smooth scrolling experience.

// FIXED: batch all reads first, then all writes
const cards = document.querySelectorAll(".card");

// Phase 1: READ, collect all measurements first
const heights = Array.from(cards).map((card) => card.offsetHeight);

// Phase 2: WRITE, apply all changes after reading is complete
cards.forEach((card, i) => {
  card.style.height = `${heights[i] + 20}px`;
});
// Only one layout calculation happens, at the end of this task

5. requestAnimationFrame for scroll and resize handlers

Scroll and resize events fire far more often than the browser can actually re render, often several hundred times per second during fast trackpad gestures. If such a handler reads and writes directly, layout thrashing does not happen once but again on every single event firing. The solution is to move the actual DOM work into a requestAnimationFrame callback while making sure that only a single callback is scheduled per frame, even if the event fires multiple times.

This pattern, often called rAF throttling, synchronizes the DOM work with the browser's natural render cadence: requestAnimationFrame guarantees that the callback runs shortly before the next repaint, exactly the moment a layout would be due anyway. Combined with the read/write batching from the previous section, this allows building a scroll handler that consistently causes only one layout calculation per frame, regardless of event frequency.

// Throttle scroll handling to one batched read+write per frame
let scheduled = false;

function onScroll() {
  if (scheduled) return;
  scheduled = true;

  requestAnimationFrame(() => {
    // READ phase
    const scrollY = window.scrollY;
    const headerHeight = document.querySelector(".header").offsetHeight;

    // WRITE phase, after all reads are done
    document.querySelector(".sidebar").style.top = `${headerHeight}px`;
    document.body.classList.toggle("is-scrolled", scrollY > 100);

    scheduled = false;
  });
}

window.addEventListener("scroll", onScroll, { passive: true });

6. The FLIP technique for layout animations

Layout animations, such as reordering a list or expanding a card to a new position, are a particularly vulnerable area for layout thrashing, because they almost inevitably require position measurements before and after a DOM change. The FLIP technique, an acronym for First, Last, Invert, Play, solves this problem in a structured way: first the starting position is measured, then the DOM change is performed immediately and the ending position is measured, then the element is visually moved back to the starting position via transform, and only at the end is it animated to the ending position.

The decisive trick with FLIP: both measurements, First and Last, happen deliberately bundled together, with no further write operations in between that would force another intermediate calculation. The actual animation runs exclusively through transform and opacity, two properties that can be animated on the compositor thread without triggering a new layout at all. This interplay of clean batching and compositor properties makes FLIP the reference solution for smooth list reorder animations.

7. Containment and will-change as a complement

CSS containment through contain: layout reduces the reach of a forced reflow but does not prevent it fundamentally: if JavaScript reads and writes alternately inside a container with containment, layout thrashing still occurs, only its impact stays confined to that container instead of spreading across the entire page. Containment and batching therefore solve different parts of the same problem and should be used together, not as substitutes for each other.

will-change: transform can help promote an element to its own compositor layer ahead of time, so that later transform changes no longer trigger a layout calculation. It matters to set will-change only on elements that are actually about to be animated, and to remove the property afterward, because permanently maintaining many compositor layers considerably increases memory usage and can, in extreme cases, become a performance drag itself.

8. Spotting layout thrashing in the performance panel

In the Chrome DevTools performance panel, layout thrashing shows up as a sequence of short, repeating purple bars labeled "Layout", often directly followed by a red marker with the warning "Forced reflow". This warning appears exactly when DevTools detects that a read access forced a still pending layout calculation. Clicking one of these bars reveals the exact stack trace that led to the forced calculation, usually down to the precise source line.

For automated detection, the browser's Long Tasks API is also useful, reporting tasks over fifty milliseconds, a typical symptom of undetected layout thrashing in production environments. Anyone wanting to consistently avoid performance regressions integrates an automated check into the CI pipeline, for example via Playwright traces that look for the characteristic sequence of style recalculation and layout bars within a single task.

Another useful indicator is the Long Animation Frames API, which for several Chrome versions has also provided information about the cause of a long frame, including the involved script URLs and function names. This allows tracing layout thrashing back to the source file responsible, even in minified production code, without necessarily needing source maps. For teams with multiple developers, this is a practical entry point for quickly attributing recurring regressions to a specific module.

In practice it helps to define a fixed threshold for acceptable layout time per frame, for example sixteen milliseconds for a smooth sixty frames per second, and to check this value automatically against every pull request. That way layout thrashing stays not a one time fixed problem but a permanently monitored metric in the development process.

Some teams add a code review criterion for this: any loop that reads DOM properties must explicitly justify why no read/write batching is necessary. This simple rule prevents most new cases of layout thrashing before they ever reach the main branch.

Over time, this turns layout thrashing from an occasional firefighting exercise into a metric that is tracked and enforced like any other quality gate in the codebase.

9. Anti-pattern and solution in direct comparison

The following table contrasts the most common causes of layout thrashing with the respective recommended solution patterns.

The common denominator across all solution patterns in this table is a strict separation of reading and writing, combined with a deliberate synchronization to the browser's natural render frequency through requestAnimationFrame. Anyone who has internalized this principle recognizes layout thrashing candidates while writing the code, without depending on a performance panel.

10. Summary

Layout thrashing arises when read and write accesses to layout properties happen in alternation, forcing the browser into repeated, synchronous layout calculations. Properties like offsetHeight, getBoundingClientRect() and getComputedStyle() trigger this forcing as soon as they are queried after a write operation. The solution is consistent read/write batching, which bundles all read accesses before all write accesses, turning potentially hundreds of layout calculations into a single one.

For scroll and resize handlers, requestAnimationFrame throttling complements batching by limiting DOM work to at most one execution per frame. The FLIP technique solves the same problem specifically for layout animations by bundling measurements and running the actual animation through compositor properties like transform. CSS containment additionally limits the reach of any remaining reflow to individual containers, but does not replace the need to cleanly separate reading and writing in JavaScript.

11. FAQ: Avoiding Layout Thrashing