While scrolling a page, Chrome's console prints `[Violation] Forced reflow while executing JavaScript took 47ms`. What is that warning telling you about your code, and what would you do with it?

## What the message actually is `[Violation] …` lines are Chrome's own performance advisories. They are printed by the browser, not by your code, they are warnings rather than errors, and nothing in the page failed when one appears. Chrome has a family of them — a long-running task, a `'scroll'` handler that took too long, a non-passive listener added to a scroll-blocking event — and *forced reflow* is the one that fires when a script made the browser run layout synchronously and that work exceeded an internal time threshold. Firefox and Safari do not emit this message at all, so its absence in another browser is not evidence that the problem is gone. ## Why the browser was forced Some DOM properties cannot be answered from whatever the browser last computed. If your script has changed the DOM or its styles since the last layout, and then asks for a geometry value — `offsetHeight`, `getBoundingClientRect()`, `scrollTop`, certain `getComputedStyle()` values — the browser has to bring layout up to date before it can return a number. That is the "forced" part: layout that would normally have happened once, at the browser's convenience before the next paint, happened in the middle of your function instead. One such read is cheap when nothing is pending. The expensive shape is a loop that writes something, reads a geometry value, writes again, reads again — every read pays for the write before it. ## What the number means, and what it hides The milliseconds in the message are the time the browser spent doing forced layout work while that script was running. That is a *lower bound* on the damage, not the total: the script's own work, style recalculation, and the paint that follows are all on top of it. A 47ms figure on a 60Hz display has already blown roughly three frames' worth of budget by itself. Chrome also collapses repeats, so a handler firing on every scroll event may print far fewer lines than the number of times it actually forced layout — never read the count of console lines as the frequency of the problem. ## What the warning does not tell you It names no function, no file, no element and no stack. That is the whole reason triage does not stop here. Two candidates can look at the same line and reach opposite conclusions, because the warning is equally consistent with your own scroll handler, a measurement inside a UI library, and a third-party widget measuring its own container. ## Turning it into a fix The reliable path is: reproduce the interaction while recording a performance trace, find the scripting entry that covers it, and look for layout work repeated many times inside a single call rather than once at the end. DevTools flags forced layouts and can point at the JavaScript that triggered them, which gives you the call site the console message withheld. Only then do you change code — and the shape of the fix is either to stop interleaving reads with writes, or to stop measuring at all and let an observer tell you what changed. Afterwards, re-record: the proof is that the repeated layout entries collapse to one per frame, not that the console line stopped appearing. ## When it is fine to leave alone Prioritise by where it lands. A forced reflow inside a scroll frame or inside a click handler is user-visible — it delays the next paint and shows up in interaction latency. The same 47ms once during application bootstrap, off any interaction path, is usually worth a note and nothing more. Silencing the message by filtering the console is the one response that is always wrong: it removes the only free signal you had while leaving the frame cost exactly where it was.