Avoiding Layout Thrash and Visual Flicker

Layout thrash occurs when JavaScript alternates between reading DOM properties and writing to the DOM in a loop. Each read after a write forces the browser to recalculate the layout synchronously to return an accurate value. This can turn what should be a single layout calculation into dozens, severely hurting performance.

React batches all setState calls within event handlers and effects into a single re-render. This natural batching prevents the read-write-read pattern that causes thrash within a single render cycle. In React 18, batching extends to async callbacks and Promises as well, reducing layout thrash from concurrent state updates.

Flicker occurs when a useEffect reads the DOM, updates state, triggers a re-render, and the browser paints twice: once with the initial state and once with the corrected state. The first paint flashes briefly before being replaced. This is most visible for effects that adjust layout properties like height, width, or position.

Open Chrome DevTools, go to the Rendering tab (via the three-dot menu under More tools), and enable "Paint flashing." Repaint areas are highlighted in green. If you see a component flash on first render and then immediately re-paint to a different layout, this confirms a double-paint caused by a useEffect-driven state update.

Move DOM reads and their resulting state updates from useEffect to useLayoutEffect. The same measurement and state update now happen synchronously before paint, React re-renders and commits in the same block, and the browser only paints the final, correct state. The green flashing in DevTools disappears.

The no-flicker pattern is: read DOM in useLayoutEffect, call setState with the measurement, React re-renders synchronously, commits the corrected DOM, and the browser paints once with the final result. This is the standard pattern for tooltip positioning, sticky header offsets, and animation setup.

The vast majority of effects belong in useEffect: data fetching (the loading flash is acceptable and expected), subscriptions to events or streams, logging and analytics, timers, and any effect that does not immediately affect visible layout. Over-using useLayoutEffect where useEffect would work is an anti-pattern that hurts performance.

Reserve useLayoutEffect for DOM measurements that feed back into visual output: tooltip positions, element size-based logic, scroll position restoration, and animation setup that reads initial dimensions. A clear symptom that tells you to switch is seeing a visible one-frame flash of incorrect layout on first render.

The two hooks have identical signatures: useLayoutEffect(callback, deps) vs useEffect(callback, deps). The only difference is the timing of when the callback runs. You can switch between them with a one-word change in the code. Start with useEffect and only change to useLayoutEffect if you confirm flicker.

It is valid and common to use both hooks in the same component for different concerns. For example, a chart component might use useLayoutEffect to measure its container width and set the SVG viewBox synchronously, and then use useEffect to fetch the chart data asynchronously. Each hook handles the concern where timing matters for it.

Beyond DevTools paint flashing, you can add a console counter inside your component to count renders. If a component logs "render" twice on first mount — once with the initial state and once with the corrected measurement — you have a double-paint scenario. Moving the measurement to useLayoutEffect should reduce it to one render logged after mount (the double in Strict Mode notwithstanding).

Which scenario is the correct reason to use useLayoutEffect instead of useEffect?

Layout thrash comes from alternating DOM reads and writes. React's batching prevents most of it within renders. Flicker happens when useEffect measures the DOM and updates state, causing two paints. Fix flicker by moving DOM measurements to useLayoutEffect. Default to useEffect for everything else: fetching, subscriptions, logging, and timers.