The CSS Rendering Pipeline: Reflow vs Repaint & Why `transform` Is Cheap

14 questions

Follow a pixel from CSS to screen: Style → Layout → Paint → Composite. See exactly what makes the browser re-run Layout (reflow) versus just Paint (repaint), why transform and opacity ride the compositor and skip both, and how reading offsetHeight at the wrong moment forces a synchronous layout. The rendering-side companion to the event-loop quiz — same main thread, the other half of its story. Every claim is grounded in the browser's documented rendering steps.

Start

Questions

Not answered. What is the correct order of the browser's rendering pipeline?
Not answered. What does the Style (Recalculate Style) step actually compute?
Not answered. Which pipeline steps must run on each frame of the width transition?
Not answered. What has Firefox (Gecko) historically called the step Chrome's DevTools labels Layout?
Not answered. Which change triggers a repaint but no reflow?
Not answered. Which of these property changes force a Layout (reflow)?
Not answered. Why are transform and opacity the two 'cheap' properties to animate?
Not answered. Which way of sliding the card 100px down is cheaper per frame, and why?
Not answered. A 500ms synchronous task blocks the main thread. Which animation keeps moving?
Not answered. What does will-change: transform actually do — and what is the catch?
Not answered. Which lines force a synchronous layout right after a style write?
Not answered. Why is this loop slow, and what is the one-line fix?
Not answered. Rounded to two decimals, how many milliseconds is the 60fps frame budget?
Not answered. Which statements about the rendering pipeline are true?