useLayoutEffect: Synchronous Effects Before Browser Paint

useLayoutEffect is useEffect's synchronous twin, running its code after DOM mutations but before the browser repaints. Use it to read DOM layout and re-render to prevent visual flickers, like positioning a tooltip. Its main footgun: it blocks rendering.
Why it exists
React's standard useEffect hook runs asynchronously after the browser has painted the screen. This is usually efficient, but if you need to measure a newly rendered DOM element and immediately change the layout based on that measurement, useEffect can cause a visible flicker: one frame with the initial render, a second with the corrected layout. useLayoutEffect was created to solve this specific flicker problem.
The mental model
Think of useLayoutEffect as an emergency brake for rendering. While useEffect lets the browser paint and then runs your code, useLayoutEffect says, "Stop! Before you show anything to the user, I need to run this code, re-render if needed, and only then can you paint." It's a synchronous hook that blocks the browser's rendering process.
How it works
The execution flow is: React renders your component, React commits changes to the DOM, useLayoutEffect runs its setup function synchronously, and finally, the browser paints the screen. If you set state inside useLayoutEffect, React will synchronously trigger a re-render before the browser gets a chance to paint. This entire sequence happens in one go from the user's perspective, preventing any intermediate, incorrect state from being visible.
When to use it
The primary use case is measuring DOM layout and then updating state based on those measurements. For example, calculating the height of a component with getBoundingClientRect() to correctly position a tooltip above or below it. This prevents the tooltip from appearing in the wrong place for one frame and then snapping into its correct position.
When not to use it
Do not use useLayoutEffect for anything that doesn't require an immediate, pre-paint layout calculation. Data fetching, setting up event listeners, or any other side effect that doesn't cause visual flicker should go in useEffect. Using useLayoutEffect unnecessarily blocks rendering and can make your app feel sluggish. Also, since it relies on a browser DOM, it will not run and will produce a warning during server-side rendering (SSR).
One canonical example
To position a tooltip, you might render it first to see how big it is, then adjust its 'top' style. With useEffect, the user might see the tooltip flicker. With useLayoutEffect, you can get its dimensions and set its position before the browser ever paints it. A typical implementation would be: useLayoutEffect(() => { const { height } = ref.current.getBoundingClientRect(); setTooltipHeight(height); }, []); This ensures the tooltip appears in its final, correct position in a single paint.
Interview question
When is useLayoutEffect the most appropriate choice over useEffect?
- a.To perform data fetching operations immediately after a component renders.
- b.To optimize performance for non-visual updates by ensuring they run synchronously.
- c.To execute code that must run after the browser has finished painting the screen.
- d.To measure a DOM element's dimensions and update its position before the user sees any intermediate layout.Correct
Why? this is the answer
useLayoutEffect is specifically designed for scenarios where you need to read DOM layout and make synchronous updates to prevent visual flickers before the browser paints. Option D directly describes this primary use case. Option C describes useEffect, which runs asynchronously after the browser has painted.
Just read this? Test yourself on what you have been reading.
Read the original → react.dev
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on react — each one lists the topics its interview covers.
See open roles