Rendering pipeline & compositing

Core details

• Ordered pipeline: parse HTML/CSS → DOM/CSSOM → style recalculation → layout (reflow) → paint → composite (GPU surfaces).
• Invalidation ripple: structural DOM/CSS changes reschedule affected stages—you must know which edit buys layout vs paint-only.
• Forced synchronous layout (“layout thrash”): interleaving geometry reads after layout-invalidating writes in a tight JS loop forces synchronous layout flush per iteration (offsetWidth, scrollTop, etc.).
• Layers: promoted elements become composited surfaces; misuse increases GPU RAM pressure on mobile—not free performance sugar.
• Diagnostics: Chromium Performance timeline—purple “Layout”/Recalculate Style/Composite Layers scopes; Layers panel verifies promotion reality.

Understanding

The browser lazily merges work until it must paint—or until script queries geometry forcing consistency. Thrash emerges when JS unknowingly pings layout APIs during incremental DOM/CSS mutation loops. Composition moves painting off the main thread only after subtrees stabilize into layers; blindly promoting everything shifts memory exhaustion risk while barely changing CPU story.

Painting cost scales with invalidated pixels plus effects (filters, masking). Layout cost scales with number of impacted boxes. Style recalculation grows with selector graph fan-out—not always “cheap.”

Senior understanding

Interviewers probe whether you prescribe fixes because you measured:

Operational angle: regressions sneak through CLS bundles when intrinsic sizing omitted—you tie DOM mutations to UX metrics—not only JS CPU.

Diagram

See also

• Browser, HTML/CSS & React + hydration — how HTML/CSS feed this pipeline before frameworks
• Main-thread scheduling
• Hub overview: /frontend