Reading and writing cost differently

The browser is lazy on purpose. When you change a style, it does not immediately recompute the layout, it marks the page dirty and batches the work until it needs the result, usually just before the next frame. That laziness is most of why DOM manipulation is fast enough to be usable at all.

But some things you can read are only knowable after layout has run. offsetTop, offsetHeight, getBoundingClientRect(), scrollTop, getComputedStyle(), focus(), ask for any of these and the browser cannot answer from stale data. It must flush everything pending and lay out immediately. That is a forced synchronous layout, and one of them is fine.

The problem is the loop. Write a style, read a geometry, write, read, fifty times. Every read forces a layout that the write just invalidated, so you have caused fifty layouts where one would have done. This is layout thrashing, and it is the most common performance bug in hand-written DOM code, common enough that it has a name and that Chrome DevTools flags it specifically.

The fix is structural and simple: read everything first, then write everything. The reads all come from one layout because nothing invalidated it in between; the writes all batch because nothing read in between. Fifty layouts become one, and the code is usually clearer as well.

The instrument below runs both versions side by side with a forced-layout counter. Watching it climb to fifty in one column and stay at one in the other is more persuasive than the paragraph you just read. Then do the reorder exercise at the bottom, three statements, and getting them in the right order is the entire skill.

for (const box of boxes) {           // 50 of them
  box.style.width = grow(box) + 'px'; // write: marks layout dirty
  total += box.offsetHeight;          // read: forces layout NOW
}

const heights = boxes.map((b) => b.offsetHeight); // read all
const next = heights.map(grow);                   // no DOM
boxes.forEach((b, i) => {                         // write all
  b.style.width = next[i] + 'px';
});

// what it is now: 50 forced layouts
for (const b of boxes) {
  b.style.width = b.offsetWidth * 1.1 + 'px';
}

To find it in real code: open the Performance panel, record an interaction, and look for the purple layout blocks. A long row of them is thrashing, and Chrome will often label the offending read for you. Then look at where it is: in your own code, or in a library, or, increasingly often, in something a model generated, because the interleaved version is the one that reads more naturally and therefore appears more in training data.