Avoid large, complex layouts and layout thrashing

Layout cost: what matters and when it hurts

Layout is the browser pass where geometric information—size and position—is calculated for every element. Tools differ on the name (Chrome, Edge and Safari call it Layout; Firefox calls it Reflow), but the work is the same: CSS, element contents and parent relationships all feed into where things end up on screen.

Two factors drive layout cost:

• The number of elements requiring layout, which follows from overall DOM size.
• The complexity of the layouts those elements need.

Layout is also almost always scoped to the entire document, not a subtree. With a large DOM, the browser has to resolve positions and dimensions for many elements, and that takes time.

Layout's role in interaction latency

Interaction latency is the time from a user input until the browser presents the next frame showing the result—the aspect of performance measured by Interaction to Next Paint. The portion of that time spent getting the frame on screen is the presentation delay. Since visual feedback often requires some layout work, the key to keeping INP low is to avoid layout where possible, and where it can't be avoided, keep that work minimal so the next frame isn't delayed.

When layout gets triggered

Style changes don't always require layout. The browser only recalculates and re-renders when changes touch geometric properties such as width, height, left, or top. When they do, you pay the full cost of figuring out locations and dimensions.

If layout can't be avoided, DevTools is the tool for diagnosing the bottleneck. Record a trace in the Timeline tab while interacting with your site. In the breakdown, look for how much time layout consumes per frame and which elements were involved.

In a sample trace, over 28 milliseconds of each frame went to layout. Given only 16 milliseconds are available per frame for smooth animation, that far exceeds budget. DevTools also reports the render tree size (1,618 elements in that case) and how many nodes needed layout (only 5).

Layout cost relates to DOM size—not with a tight coupling, but larger DOMs generally mean higher layout costs when a recalculation is unavoidable.

Forced synchronous layouts

Frame production normally follows a fixed order: JavaScript runs first, then style calculations, then layout. But JavaScript can force layout to happen earlier than the browser would schedule it. That's a forced synchronous layout (or forced reflow), and it can add unnecessary work to a frame.

At the start of script execution, the browser knows all layout values from the previous frame. Reading a value like the height of an element at that point is cheap:

// Read at frame start: no layout needed, value is already known.
var height = box.offsetHeight;

The problem arises when styles change before a value is read:

// Write first, then read.
box.classList.add('super-big');
var height = box.offsetHeight;

To answer the height query correctly now, the browser must first apply the class change and run layout—then it can return the value. That's both unnecessary and potentially expensive.

The fix is to batch reads first, using the previous frame's layout values, then apply writes afterward. For the example above, a more efficient version reads the height before any style change:

// Read first (uses last frame's layout), then write.
var height = box.offsetHeight;
box.classList.add('super-big');

In practice, querying values from the last frame is usually sufficient. Forcing style calculation and layout synchronously, before the browser would do it, is a bottleneck you should typically avoid.

Layout thrashing

Forced synchronous layouts become far worse when they happen repeatedly in a short span, a pattern known as layout thrashing:

function resizeAllParagraphsToMatchBoxWidth() {
  for (var i = 0; i < paragraphs.length; i++) {
    paragraphs[i].style.width = box.offsetWidth + 'px';
  }
}

Each loop iteration reads box.offsetWidth, then immediately writes to a paragraph's width. On the next iteration, the browser must account for the style change made since its last read, so it applies the changes and runs layout again—every single iteration.

Read values first, then write:

// Read once.
var width = box.offsetWidth;

function resizeAllParagraphsToMatchBoxWidth() {
  for (var i = 0; i < paragraphs.length; i++) {
    paragraphs[i].style.width = width + 'px';
  }
}

This sample resizes paragraphs and overflows the container; a real page would also need to consider its own content. The guiding principle is to separate reads from writes.

Detecting the problem

DevTools offers a Forced Reflow insight under the Performance panel to quickly identify forced synchronous layouts. In the field, the Long Animation Frame API script attribution exposes the forcedStyleAndLayoutDuration property, which reports the same problem with a real-usage signal.