Reduce Forced Layout with Batched DOM Updates

A React profile can show that component render work is under control while the browser still spends time calculating layout. Those are different costs.

When JavaScript changes the DOM or a layout-relevant style, the browser can defer style calculation and layout until a rendering opportunity. But if JavaScript then asks for geometry that depends on stale rendering information, the browser may have to calculate it immediately. This is forced synchronous layout.

“May” matters: a DOM read is not automatically a geometry read, and a geometry read does not automatically force layout. The browser forces work only when the requested result needs relevant rendering information that is pending.

These APIs both expose an element’s width, but they do not mean the same thing. Choose the API that matches the measurement requirement; do not treat them as interchangeable.

Study these two values from the same board.

Layout thrashing occurs when code repeatedly crosses from a layout-affecting write to a geometry read. After each write, the next read may need the browser to make layout current again.

In this source order, adding .is-wide changes the board’s layout state. Each card width assignment is also layout-affecting. The next loop iteration reads board geometry after that preceding write, so it can synchronously demand layout again. The browser may perform normal layout after JavaScript finishes; that is different from layout synchronously demanded in the middle of JavaScript.

This is a pattern to diagnose, not yet a refactoring.

Create a local Vite fixture named layout-lab. It uses only local HTML, CSS, and JavaScript—no remote data, images, or fonts. Replace the scaffolded index.html and src/styles.css with the complete files below. On the next screen, create src/main.js from the two consecutive code sections.

Run these commands in a terminal.

Replace index.html with this complete file.

Replace src/styles.css with this complete file. The board alone controls its compact or wide width. Its lack of padding, border, and transform makes its border-box measurement unambiguous; the reserved scrollbar reduces viewport-width variation.

The baseline deliberately performs a repeated read/write sequence. It starts with 200 deterministic cards and uses native controls: each activation of Wide layout switches between wide and compact state, while Reset layout explicitly restores compact state. Every syncWidths() call reads the board's current border-box width for each card, then writes that card's inline width. Do not refactor this baseline yet.

Create src/main.js with this first section. It creates the fixed content before the measured interaction.

Append this directly after the preceding section in src/main.js. Initial sizing, reset work, and any resize work are outside the compact-to-wide interaction you will inspect.

Record one defined interaction using the optimized local build. Set the viewport to 1280 × 800 CSS px. Load or reset the page so compact mode is settled. Start recording immediately before one activation of Wide layout, then stop after the resulting wide layout settles.

Keep startup, Reset layout, and resizing outside this interaction window. They are separate sources of work. Save the raw trace so later comparisons can use the same scenario.

From the layout-lab project root, create the optimized build and serve its local preview.

Batching is not merely “put all reads first.” First identify which state a measurement must describe.

In Layout Lab, each card must receive the width of #board after Wide layout changes the board from compact to wide. The dependency-safe sequence is:

1. change the board mode;
2. read the resulting board width once;
3. compute one CSS-pixel value;
4. write that value to all 200 cards.

A read before the mode change might look cheaper, but it measures the compact board. That would change the interface’s meaning rather than optimize its implementation.

Replace the entire contents of src/main.js with the two code sections on this screen, in order. This produces the complete runnable batched variant: it preserves card creation, registers every listener once, performs initial compact sizing once, and keeps cleanup aligned with the registered handlers.

src/main.js — part 1 of 2

src/main.js — part 2 of 2

For multiple independent elements, collect every required measurement first, compute from those values, and then write. A genuinely dependent value may require another phase: a write can intentionally establish the state that a later read must measure. If that dependency is not truly required, redesign the relationship instead of pretending all reads can be moved earlier.

A card that simply fills #board has a CSS layout relationship, not a measurement requirement. The browser already knows the containing block’s width and can resolve a percentage width during normal layout.

In the css variant, changing .is-wide still changes the board from min(100%, 40rem) to min(100%, 60rem). Each .card follows that new width through CSS—without JavaScript reading board.getBoundingClientRect().width or assigning widths card by card.

The fixture’s box-model contract makes this relationship precise: cards use box-sizing: border-box and zero horizontal margins; #board has no padding, border, or transform. Therefore, width: 100% gives every card the board’s available width without a JavaScript measurement.

CSS removes avoidable JavaScript geometry work. The browser still performs normal style and layout work after the board class changes. That normal rendering work is not automatically a forced synchronous layout event.

In src/styles.css, retain the existing board rules and replace the corresponding .card rule with this version. Keep the remaining card appearance rules unchanged.

CSS must become the only owner of card widths. Remove syncWidths(), every call to it, the resize listener that existed only to run it, and every card.style.width assignment. Old inline width values override the stylesheet, so replace the prior module and reload the page to recreate the cards without those runtime styles.

The controls still own the board mode and its exposed state. Wide layout remains a toggle: a second activation returns to compact mode. Reset layout explicitly restores compact mode.

Replace the complete contents of src/main.js with this runnable css variant. It creates the same 200 cards, retains native control behavior, and has no geometry read or resize synchronization.

Use the frame variant only when imperative card sizing remains necessary. It is an alternative to the css variant, not an extra layer on top of CSS sizing.

requestAnimationFrame() requests a callback before a future rendering update. It does not prove that an earlier change has painted, and it does not make a geometry read free. Its value here is that a mode change and several resize events can share one pending callback.

When that callback runs, it must measure the board then—not when an earlier event occurred. The resulting syncWidths() call still preserves the batched Read → Compute → Write sequence using the latest board state.

Switch away from the preceding css variant before using the frame variant: JavaScript must be the single owner of the card widths here. In src/styles.css, replace the .card rule with the version below, which removes width: 100% but keeps the fixture's box-model constraints.

Then replace all of src/main.js with the next two code sections in order. This complete module recreates the same deterministic 200 cards before it collects them for imperative sizing.

src/styles.css — replace the .card rule

src/main.js — part 1 of 2

src/main.js — part 2 of 2; append directly after part 1

pendingFrame stores an animation-frame identifier; null means that no callback is queued. The guard leaves an existing identifier untouched, so repeated events do not create additional callbacks.

The callback resets that identifier before syncWidths() runs. A later event can therefore schedule a new update. destroy() removes every registered listener, cancels a callback that is still queued, and returns the identifier to null. A callback already running cannot be cancelled, but queued work must not update a disposed interface.

A useful comparison keeps the interaction meaning the same in every recording. Compare baseline with one candidate—batched, css, or frame—while holding content, starting state, browser, optimized build mode, throttling, viewport, and interaction window constant.

For Layout Lab, warm each build the same way, let compact mode settle, then activate Wide layout once at 1280 × 800 CSS px. Keep startup, Reset layout, and resizing outside this interaction window. Collect at least three recordings per variant.

A resize burst is a different scenario. Record and evaluate it separately; do not mix it with compact-to-wide recordings.

Keep the raw recordings, then summarize each metric with a median and range. Compare attributed forced-layout events, total Layout time inside the same interaction window, and available interaction timing. If a browser does not expose a metric, write N/A; do not invent precision.

This illustrative example compares only baseline and batched for the controlled compact-to-wide interaction. Its numbers are not targets for your machine.

A faster trace is not enough. Your chosen candidate must still start in compact mode, make all 200 cards match #board, toggle Wide layout from compact to wide and back, and let Reset layout explicitly restore compact mode.

Keep correctness checks separate from performance recordings. This journey deliberately reads rendered geometry to assert the final interface. Those test reads are not production work, so do not include them in your forced-layout comparison.

From the layout-lab project root, install Playwright locally and install the Chromium browser used by this local journey.

Create playwright.config.js. This correctness server uses port 4174, distinct from the port 4173 preview used for performance recordings. reuseExistingServer: false requires Playwright to start a fresh server from your current source, rather than silently testing a stale server.

Create tests/layout.spec.js with these helpers. widthsMatch() waits for a settled state, including a pending frame update, and checks the maximum width difference across every card—not just the first one.

Append this targeted journey. Reset is tested at 1280 × 800 CSS px, where compact and wide board widths differ. The later narrow viewport check is a separate responsive-layout assertion.

Run this now, before adding the optional frame cleanup diagnostic on the next screen. Playwright starts a fresh server on port 4174 for this run; a preview still running on port 4173 is not reused. At this point the file contains one test, so one passing test is the expected shape of the result.

Do this only for the frame variant. Add let syncCount = 0; immediately before const syncWidths, then add syncCount += 1; as the first statement inside syncWidths(). Append this hook immediately after the existing destroy() definition. It exposes the local scheduler solely for this cleanup check; remove the counter and hook after testing.

For the frame variant, append this second test to tests/layout.spec.js. It settles startup work, queues a new update, destroys the interface before that callback runs, then attempts resize and button events. The assertions require no queued frame, no additional width sync, and no changed pressed state.

With the temporary hook present in the current frame source, run the full file. The fresh port-4174 server ensures this run loads that current source rather than an earlier preview. Both tests should pass before you remove the temporary diagnostic code.

For baseline, batched, or css, append the same second test but do not add the frame hook. The test deliberately skips because this cleanup contract applies only to the frame scheduler. The interaction journey must still pass.

Run automation, then inspect the same local candidate manually. Do not merge a resize-burst investigation into the fixed compact-to-wide performance recording. A passing browser journey proves only its explicit assertions; it cannot substitute for these observations.

A performance change is ready to keep only when one record connects why the work happened, what changed, and what stayed correct.

Start with the cause you observed: the baseline alternated a board-width geometry read with card-width writes, producing repeated forced synchronous layout. Then identify the single candidate you compared: batched, css, or frame.

Your decision is not based on an event count alone. It combines repeated trace evidence with the targeted behavior and accessibility journey. If any part is uncertain, the honest outcome is investigate, not an unsupported claim of success.