useEffect vs useLayoutEffect: What Is the Difference?
Learn the timing difference between useEffect and useLayoutEffect and when to choose each to avoid visible UI flicker.
Expected Interview Answer
useEffect runs its callback asynchronously after the browser has painted the updated DOM to the screen, while useLayoutEffect runs synchronously after DOM mutations but before the browser paints, blocking the paint until the callback finishes.
Both hooks let you run side effects tied to a component’s render, and both receive the same dependency-array semantics, but the timing relative to the browser’s paint cycle is what separates them. useEffect is deferred: React commits DOM changes, the browser paints, and only then does the effect callback run, which keeps the main thread free for the user to see the update immediately, at the cost of a possible visible flash if the effect itself needs to change layout-affecting styles. useLayoutEffect runs synchronously right after the DOM is mutated but before the browser has a chance to paint, so any layout reads (like measuring an element’s size) or layout writes (like repositioning a tooltip) happen invisibly to the user, with no flash, but at the cost of blocking the paint, which can hurt performance if the callback is slow. The practical rule is to default to useEffect for anything that is not directly about measuring or synchronously mutating layout, and reach for useLayoutEffect only when a visible flicker would otherwise occur, such as positioning an element based on a DOM measurement taken in that same render cycle.
- useEffect keeps the main thread unblocked for perceived performance
- useLayoutEffect eliminates visible flicker for layout-dependent DOM reads/writes
- Both share identical dependency-array and cleanup-function semantics
- Clear default (useEffect) with a narrow, well-defined escape hatch (useLayoutEffect) keeps code predictable
AI Mentor Explanation
useEffect is like a groundskeeper who repairs the pitch after the umpires have already let play resume for the day, doing touch-ups in the background without holding anyone up. useLayoutEffect is like a groundskeeper who must finish repairing a dangerous crack before the umpires will allow the very next ball to be bowled, holding play entirely until the fix is done. Both are pitch maintenance triggered by the same events, but one blocks the next action and one does not. Choosing between them is choosing whether the fix must be invisible to spectators before anything proceeds, or can happen just after play has already resumed.
Step-by-Step Explanation
Step 1
React commits DOM mutations
React applies the calculated changes to the actual DOM after rendering completes.
Step 2
useLayoutEffect runs synchronously
Before the browser paints, useLayoutEffect callbacks run, blocking paint until they finish — ideal for layout reads/writes.
Step 3
Browser paints the screen
The updated DOM, including any useLayoutEffect adjustments, becomes visible to the user in one paint.
Step 4
useEffect runs asynchronously
After paint, useEffect callbacks run without blocking the browser, suitable for most side effects like data fetching or subscriptions.
What Interviewer Expects
- Precise description of the paint-timing difference, not just “one is synchronous”
- A concrete example of when a visible flicker would justify useLayoutEffect
- Awareness that useEffect should be the default choice for most side effects
- Mention that both share the same dependency-array and cleanup semantics
Common Mistakes
- Saying useLayoutEffect “runs before render” instead of “before paint, after DOM mutation”
- Defaulting to useLayoutEffect for data fetching, unnecessarily blocking paint
- Not mentioning the performance cost of blocking paint with a slow useLayoutEffect callback
- Confusing this pair with useEffect vs useMemo, an unrelated distinction
Best Answer (HR Friendly)
“useEffect runs after the browser has already shown the update on screen, so it does not slow things down, and I use it for most side effects like fetching data. useLayoutEffect runs right before the screen updates, so I only reach for it when I need to measure or reposition something and want to avoid a visible flicker, like calculating a tooltip’s position before it appears.”
Code Example
function Tooltip({ anchorRef, text }) {
const tooltipRef = useRef(null)
const [top, setTop] = useState(0)
// Runs before paint: repositions before the user ever sees
// the tooltip in the wrong spot.
useLayoutEffect(() => {
const anchorRect = anchorRef.current.getBoundingClientRect()
setTop(anchorRect.bottom + 8)
}, [anchorRef])
// Runs after paint: fine for non-visual side effects.
useEffect(() => {
logTooltipShown(text)
}, [text])
return <div ref={tooltipRef} style={{ position: 'absolute', top }}>{text}</div>
}Follow-up Questions
- What happens if you use useLayoutEffect for a slow, expensive computation?
- Does useLayoutEffect run on the server during SSR, and what warning does React give?
- How do useEffect and useLayoutEffect differ in cleanup timing?
- When would you use useInsertionEffect instead of either of these?
MCQ Practice
1. When does useLayoutEffect run relative to the browser paint?
useLayoutEffect blocks paint, running right after DOM mutation and before the screen updates visually.
2. Which hook should be the default choice for most side effects like data fetching?
useEffect runs after paint and does not block the browser, making it the safer default.
3. What is a valid reason to reach for useLayoutEffect instead of useEffect?
useLayoutEffect runs before paint, so layout reads/writes complete before the user sees anything.
Flash Cards
When does useEffect run? — Asynchronously, after the browser has painted the updated DOM.
When does useLayoutEffect run? — Synchronously after DOM mutation but before the browser paints, blocking paint.
Default choice for most side effects? — useEffect — it does not block the browser from painting.
When should you use useLayoutEffect? — Only when a visible flicker would occur, e.g. measuring/repositioning DOM before paint.