In a Chrome DevTools performance recording, one JavaScript call in the flame chart sits above dozens of alternating short "Recalculate Style" and "Layout" entries, instead of a single layout at the end of the frame. What does that pattern tell you, and how do you get from it to the line of code responsible?

## The signature A browser prefers to lay out once per frame: run your JavaScript, then recalculate style, lay out, paint, composite. When a trace shows that rhythm, the rendering work appears as one block after the scripting block. Layout thrashing produces the opposite shape — a single scripting entry with many short *Recalculate Style* / *Layout* pairs nested underneath it, in a repeating sawtooth. Every pair is one round trip: something in the loop invalidated layout, and the next statement asked for a value that could not be answered without redoing it. The visual cue is the *repetition inside one call*, not the total time. Ten milliseconds of layout in one entry and ten milliseconds spread over sixty entries mean different things and have different fixes. ## Read it as a count first Before touching code, ask how many layout entries there are and what on the page is that many. If a table has forty rows and the trace shows roughly forty layout entries, you have both the diagnosis and the prediction: doubling the rows doubles the cost, so the interaction degrades linearly with data size. That is also the cheapest way to prove the fix later — the same interaction on the same data should show one layout entry, not forty. ## Getting to the call site The flame chart tells you *which* script call owns the sawtooth; the layout entries tell you *who forced them*. Select one of the layout entries and read its detail pane: DevTools flags layout that was forced by script and links back to the JavaScript responsible, so you can jump to the source line that performed the read. Chrome's console may also have printed a forced-reflow violation during the same interaction, which corroborates the finding but names no location. Two supporting views are worth the click. The **Bottom-Up** view, filtered to the interaction's time range, aggregates how much of the frame went into layout and style — that is the number that tells you whether this is worth an afternoon. The **Call Tree** view shows the path from the event handler down to the offending function, which matters when the reading line is inside a shared helper called from three places rather than in the handler you were looking at. ## What the same trace could have been instead Attribution is only useful if you can rule things out. - **One long layout entry.** Layout ran once but took a long time. That is not thrashing; it points at the size or shape of the document — a very large DOM, a deeply nested or highly interdependent structure — and the remedy is structural, not a reordering of reads and writes. - **A long scripting entry with no layout underneath.** The main thread was busy with computation, parsing, or framework work. Reordering DOM access will not move it. - **Repeated layout across many separate frames.** Each frame lays out once, which is normal; if it is still too slow, the question is why the page relayouts every frame, not whether reads and writes are interleaved. - **Layout entries with no script above them.** Something outside your code — a media element resizing, a font swapping in, an image arriving without dimensions — is invalidating layout. ## From attribution to a fix Once you have the call site, the fix is one of three shapes, in increasing order of value. Separate the passes so all measurement happens before all mutation. Cache the measurement when it cannot change during the loop — measuring a container's width once outside the loop instead of once per child often removes the whole sawtooth. Best of all, delete the measurement: if the code is only asking "is this on screen" or "has this box changed size", an observer reports that without your code ever reading geometry. ```js // one read, then N writes — the sawtooth collapses to a single layout const width = container.getBoundingClientRect().width; for (const child of container.children) { child.style.width = `${width / 2}px`; } ``` ## Prove it, then stop Re-record the same interaction and compare: the layout entries under that call should collapse to one, and total layout time in Bottom-Up should fall by roughly the factor you predicted from the count. If layout time barely moves, the sawtooth was not where the frame was going, and you have learned that before shipping a refactor nobody needed.