When would you choose useLayoutEffect over useEffect?

React commit phase and paint timing.
Use useLayoutEffect to measure or mutate DOM before paint to stop flicker; useEffect runs after paint.
Using it for data fetching or ignoring its blocking cost.
WHAT THIS TESTS: This question probes whether you understand the boundary between React's commit phase and the browser's paint cycle. A senior engineer should know that useLayoutEffect fires synchronously after all DOM mutations but before the browser repaints the screen, while useEffect fires after the paint. The interviewer wants to see that you grasp the performance trade-off: blocking paint can prevent visual flicker but also blocks the main thread.
A GOOD ANSWER COVERS: First, the timing distinction in plain terms. useLayoutEffect runs immediately after React commits changes to the DOM and before the browser repaints the screen. useEffect runs after the paint, making it non-blocking. Second, a concrete scenario where synchronous measurement and mutation matter, such as positioning a tooltip or modal based on the measured height or position of a trigger element. Third, the user impact. Because useLayoutEffect blocks paint, the user never sees the intermediate wrong state, whereas useEffect would show a flash of incorrectly positioned content before the correction. Fourth, the default recommendation. The answer should state that useEffect is preferred for almost all side effects, and useLayoutEffect should be reserved for layout measurements that absolutely must happen before paint.
COMMON WRONG ANSWERS: A major red flag is saying that useLayoutEffect is only for server-side rendering or that it runs before the DOM is updated. Another is claiming it is safer or more predictable than useEffect and should be used by default. Some candidates describe data fetching in useLayoutEffect, which misses the point entirely because fetching does not depend on DOM paint timing. Finally, failing to mention the performance cost of blocking the browser's main thread suggests shallow knowledge.
LIKELY FOLLOW-UPS: The interviewer may ask how you would handle the same problem in a server-rendered environment where useLayoutEffect warns or does nothing. They might also ask about useInsertionEffect for CSS-in-JS, or how to reduce layout thrashing when reading and writing DOM values repeatedly. Another follow-up is asking for a specific performance budget or how you would measure the impact of a synchronous layout effect on frame time.
ONE CONCRETE EXAMPLE: Imagine a tooltip that needs to appear above a button. If the tooltip height is unknown, you might render it first, then measure its bounding rectangle with getBoundingClientRect, and finally adjust its top position to sit flush above the button. If you do this in useEffect, the user sees the tooltip render in the wrong spot for one frame and then snap into place. If you do it in useLayoutEffect, the measurement and adjustment happen before the browser paints, so the tooltip appears in the correct position immediately.
Source: react.dev
Read the original → react.dev
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.