Repaint vs Reflow: How Do They Affect Rendering Performance?
Learn the difference between repaint and reflow, why layout recalculation is expensive, and how to avoid layout thrashing.
Expected Interview Answer
Reflow (layout) recalculates the position and geometry of elements across the page and is expensive, while repaint only redraws pixels for visual changes like color that do not affect layout, making it comparatively cheap.
The browser rendering pipeline runs roughly: style calculation, layout (reflow), paint, and composite. Changing a property that affects geometry — width, height, margin, or inserting/removing a DOM node — forces the browser to recompute the box model for that element and often its siblings and ancestors, which is a reflow. Changing something purely visual, like background-color or visibility, skips layout and goes straight to repaint, which is far cheaper. Triggering many reflows in a tight loop, especially by reading layout properties like offsetHeight right after writing styles, causes “layout thrashing” where the browser is forced to synchronously recalculate layout repeatedly instead of batching changes, which is one of the most common real-world jank sources in interactive UIs.
- Understanding the pipeline lets you batch DOM writes to avoid layout thrashing
- Animating transform/opacity avoids both reflow and paint, running on the compositor
- Reading layout properties after writes forces synchronous reflow — a key perf trap
- Reduces jank in scroll-heavy or animation-heavy interfaces
AI Mentor Explanation
Reflow is like the ground staff remeasuring and repositioning the entire pitch markings after moving a sightscreen, because every boundary rope and fielding position depends on that geometry. Repaint is only touching up the paint on the boundary rope color, which never requires remeasuring anything. If the crew alternates one measurement, one paint touch-up, one measurement, one paint touch-up, they waste hours on redundant remeasuring instead of batching all position changes first. That geometry-recalculation-versus-pixel-refresh distinction is exactly reflow versus repaint.
Step-by-Step Explanation
Step 1
Style recalculation
The browser determines which CSS rules apply to each element after a change.
Step 2
Layout (reflow)
Geometry-affecting properties trigger recomputation of size and position for affected elements and their neighbors.
Step 3
Paint
The browser fills in pixels — colors, borders, shadows — for the affected regions.
Step 4
Composite
Painted layers are combined on the GPU; transform/opacity changes can skip straight to this step.
What Interviewer Expects
- Clear distinction between geometry-affecting (reflow) and visual-only (repaint) changes
- Awareness that reading layout properties after writes forces synchronous reflow
- Knowledge that transform/opacity animations avoid both reflow and paint
- Practical strategies to batch DOM reads and writes
Common Mistakes
- Using the terms reflow and repaint interchangeably
- Interleaving DOM reads (offsetHeight) and writes in a loop, causing layout thrashing
- Animating width/top/left instead of transform, forcing reflow every frame
- Assuming all style changes are equally expensive
Best Answer (HR Friendly)
“Reflow is when the browser has to recalculate where everything on the page goes, which is expensive, while repaint is just redrawing colors without moving anything, which is much cheaper. Knowing the difference helps you write code that avoids unnecessary layout recalculations and keeps animations smooth.”
Code Example
// Bad: forces reflow on every iteration (read after write)
boxes.forEach(box => {
box.style.width = box.offsetWidth + 10 + 'px' // read then write, repeated
})
// Good: batch all reads first, then all writes
const widths = boxes.map(box => box.offsetWidth)
boxes.forEach((box, i) => {
box.style.width = widths[i] + 10 + 'px'
})
// Best for animation: use transform, which skips layout and paint
el.style.transform = 'translateX(100px)'Follow-up Questions
- What is layout thrashing and how do you avoid it?
- Why do transform and opacity animate more smoothly than top/left?
- What tools would you use in DevTools to diagnose excessive reflows?
- How does the browser rendering pipeline differ between the main thread and the compositor?
MCQ Practice
1. Which CSS change is most likely to trigger a reflow?
Changing width affects element geometry, forcing the browser to recompute layout.
2. What causes “layout thrashing”?
Reading a layout property right after writing one forces the browser to flush pending layout work immediately, repeatedly.
3. Why do transform and opacity animations tend to be smoother than animating width or top?
Transform and opacity changes can be composited directly, avoiding the expensive layout and paint steps.
Flash Cards
What triggers reflow? — Changes to geometry-affecting properties like width, height, or margin, or DOM structure changes.
What triggers repaint only? — Visual-only changes like background-color or visibility that do not affect layout.
What is layout thrashing? — Interleaved reads and writes of layout properties causing repeated synchronous reflows.
Which properties avoid both reflow and paint? — transform and opacity, handled by the compositor.