What Causes Reflows?

A reflow is the browser recalculating the position and size of every element on the page. It is expensive because the layout of the page is interdependent: change the width of one element and the browser may have to work out new positions for its siblings, its children and everything that follows it in the flow.

The main triggers are changes that affect geometry. Setting a width, a height, a margin, a padding, a border or a font size on an element can all force a reflow. Changing the display property between block and flex, adding or removing an element from the flow, and scrolling can do it as well. The browser also reflows when the content changes in a way that alters the size, such as when a web font finishes loading and replaces a fallback font with different metrics.

The part that surprises people is that a reflow can be triggered by reading, not just by writing. Asking for a layout property such as offsetHeight, offsetWidth, scrollTop or the result of getBoundingClientRect forces the browser to flush any pending style and layout work and compute the answer right now, synchronously. If that read happens in the middle of a batch of writes, the browser has to do the work twice, once for the writes and again for the read.

That repeated flush is called layout thrashing, and it is the single most common cause of a slow page in hand-written interface code.

Separate your reads from your writes. Collect every measurement you need first, then apply every change. The browser then recalculates the layout once instead of once per element.

// The DOM only exists in a browser, so check before using it.
if (typeof document !== "undefined") {
  const items = [...document.querySelectorAll(".item")];

  // Bad: read, write, read, write - each pair forces a layout.
  items.forEach((el) => {
    const height = el.offsetHeight;
    el.style.height = `${height + 10}px`;
  });

  // Better: every read first, then every write.
  const heights = items.map((el) => el.offsetHeight);
  items.forEach((el, i) => {
    el.style.height = `${heights[i] + 10}px`;
  });

  // Build new content off the page and attach it in one operation.
  const fragment = document.createDocumentFragment();
  for (const label of ["One", "Two", "Three"]) {
    const li = document.createElement("li");
    li.textContent = label;
    fragment.appendChild(li);
  }
  document.querySelector("ul").appendChild(fragment);

  console.log("updates applied");
} else {
  console.log("No DOM in this runtime - open a browser console to try it.");
}

Three techniques are worth naming. The first is batching, as above. The second is building content in a document fragment, which lives outside the document so no layout happens until you attach it, and attaching it in one operation. The third is choosing properties that do not affect layout. Changing the opacity or the transform of an element is handled by the compositor and does not trigger a reflow, while changing the width or the top position does.

There is a fourth approach that removes the problem entirely. If the element is positioned with the transform property rather than with left and top, moving it is a compositor operation. This is why good animation libraries animate transforms, and it is a good interview point about knowing which CSS properties are layout safe.

One more note. Modern browsers batch layout work automatically within a single task, so a read after a write in the same function does not always force a synchronous recalculation. The problem appears when the browser has already painted between the write and the read, which is what happens across animation frames or inside a loop that yields. The batching advice is still correct, because it makes the intent explicit and it removes the dependency on engine heuristics.