Reflow and repaint are frequently used almost interchangeably in casual conversation, but they represent genuinely different costs in the rendering pipeline — and mixing them up leads to either overly cautious or dangerously naive performance decisions.
1Reflow: When Geometry Itself Changes
Reflow is triggered by any property change that could affect an element's size or position — width, height, margin, padding, border-width, font-size, or even adding/removing an element from the DOM. Because CSS layout is inherently relational (an element's final geometry often depends on its siblings, ancestors, and descendants), a reflow doesn't necessarily stay contained to the one element that changed — it can cascade outward, forcing the browser to recompute geometry for a much larger subtree of the page.
This relational, cascading nature is exactly what makes reflow the more expensive of the two costs, and why 'does this property change affect geometry' is the first, most useful question to ask when reasoning about a CSS change's performance impact.
2Repaint: When Only Appearance Changes
Repaint happens when a property changes an element's visual appearance without touching its size or position — background-color, border-color (not border-width, which affects geometry), box-shadow, visibility (as opposed to display, which does affect geometry and triggers reflow). The browser can redraw just the affected pixels within already-known, unchanged geometry, which is a meaningfully cheaper operation than recalculating layout.
A useful mental test: 'if this property changed, would any element's box move or resize?' If no, it's repaint-only; if yes, it's reflow (which then also implies a subsequent repaint and composite, since the pipeline always runs downstream stages after an earlier one is invalidated).
3The Real-World Cost Is Repetition, Not A Single Instance
A single reflow, even on a fairly complex page, typically completes well within a single animation frame's budget (roughly 16ms for 60fps) and is imperceptible on its own. The genuine, visible performance problem shows up when a reflow-triggering change gets repeated at high frequency — most commonly inside a scroll or resize event listener that fires dozens of times per second, or inside a JavaScript loop that alternates reading and writing layout-dependent properties (a pattern called 'layout thrashing').
This reframes the practical guidance: it's rarely necessary to obsessively avoid every possible reflow-triggering change. The actual skill is recognizing the specific situations — high-frequency event handlers, animation loops, interleaved DOM read/write patterns — where a reflow's cost gets multiplied enough to become visibly, measurably problematic.
4Step-by-Step Breakdown
Two Different Costs, Often Confused. Building directly on the rendering pipeline, 'reflow' and 'repaint' are the two specific, distinct costs a CSS change can trigger. Confusing them — treating every visual update as equally expensive — leads either to over-cautious code that avoids harmless changes, or under-cautious code that doesn't realize a specific change is genuinely costly.
Reflow: Recalculating Geometry. Reflow is exactly the Layout stage from the rendering pipeline: recalculating the size and position of elements. Any property that can change an element's geometry — width, height, margin, padding, font-size, display — triggers it, and because layout is relational, a reflow can cascade to affect elements well beyond the one that actually changed.
What Triggers Reflow. Why does changing font-size trigger reflow, not just repaint?
- →It doesn't — font-size only ever triggers repaint
- →Larger or smaller text changes how much space the element occupies, which is a geometry change
- →This behavior varies unpredictably between browsers
Repaint: Redrawing Pixels, Same Geometry. Repaint happens when an element's appearance changes but its geometry doesn't — a background-color, border-color, or visibility change redraws the affected pixels without needing to recalculate anyone's size or position. Cheaper than reflow, but not free, since it still requires re-rendering visual content.
What Triggers Repaint (Not Reflow). Why does changing background-color trigger only repaint, not reflow?
- →Because the element's size and position remain completely unchanged — only its visual appearance updates
- →Because color values are inherently cheaper for the browser to parse than length values
- →background-color changes are actually ignored by the rendering engine
The Cascading Cost Of Reflow On Large Pages. The real-world danger of reflow isn't any single instance — it's a reflow triggered inside a loop or on every scroll/resize event, repeated dozens or hundreds of times per second, each one potentially touching a large portion of a complex page's DOM tree.
Reflow In High-Frequency Events. Why is triggering a reflow-causing style change inside a scroll event listener particularly risky?
- →It's actually a one-time cost regardless of how often the listener fires
- →Scroll events can fire many times per second, so an expensive reflow gets repeated at that same high frequency
- →Scroll events don't have any special relationship to reflow
Reflow And Repaint Distinguished. You can now confidently distinguish which CSS changes trigger the expensive, cascading reflow versus the cheaper, visual-only repaint, and you understand why the real-world danger isn't a single reflow but a reflow-triggering change repeated at high frequency inside a scroll, resize, or animation loop.
Move An Element Without Triggering Layout. The standalone translate property is compositor-driven, avoiding the layout recalculation that changing top/left causes.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Scroll-Linked Reflow Loops Can Make A Page Feel Unresponsive To Users Relying On Assistive Navigation
A page that visibly stutters or lags during scrolling due to repeated reflow can be especially disruptive for screen magnifier users or those navigating with switch devices, where smooth, predictable motion matters more for successful interaction.
2Diagnosing Reflow-Heavy Interactions Helps Prioritize Fixes That Improve Overall Interaction Responsiveness
Interaction responsiveness benefits every user, but disproportionately helps users with motor impairments who may already need more time or precision to complete an interaction — a laggy interface compounds that difficulty.
SEO Implications
- 1
Excessive Reflow During Scroll Or Resize Directly Harms Interaction Responsiveness Metrics
Repeated, expensive reflow triggered by scroll or resize handlers can cause dropped frames and input delay, both of which are captured by responsiveness-related Core Web Vitals metrics search engines factor into ranking.
- 2
Recognizing Repaint-Only Changes Enables Safer, Cheaper Interactive Feedback Effects
Choosing repaint-only properties (like background-color or box-shadow) for hover and interaction feedback keeps those effects cheap even on pages with complex layouts, avoiding unnecessary reflow-driven performance cost for purely cosmetic feedback.
Best Practices
Ask 'Would This Property Change Move Or Resize Any Element's Box' Before Assuming A Change Is Cheap
This single question reliably distinguishes reflow-triggering changes from repaint-only ones, and is the fastest mental model for reasoning about a given property's performance cost.
Audit Scroll And Resize Event Handlers Specifically For Reflow-Triggering Style Reads/Writes
These high-frequency events are where a reflow's cost gets multiplied enough to become visibly problematic — they deserve more scrutiny than a one-off style change triggered by a click.
Frequent Bugs
A page feels sluggish specifically while scrolling, even though it's fine otherwise.
Check the scroll event listener for any reflow-triggering style changes (geometry properties) and either remove them, throttle them, or replace them with a Composite-only property like transform.
A JavaScript loop that measures and resizes many elements causes a visible page freeze.
This is classic layout thrashing — interleaved reads (offsetWidth, getBoundingClientRect) and writes (style.width) each forcing a fresh reflow; batch all reads first, then all writes.
Real-World Examples
Diagnosing Scroll Jank Caused By Reflow
A parallax scroll effect originally implemented by updating an element's top property on every scroll event, refactored to use transform to eliminate the repeated reflow.
// Before: reflow on every scroll event
el.style.top = scrollY * 0.5 + 'px';
// After: Composite-only, no reflow
el.style.transform = `translateY(${scrollY * 0.5}px)`;