Frontend Index Return to the interactive index →
Foundations

Browser Rendering Pipeline

How browsers turn HTML, CSS, and JavaScript into pixels through parsing, style, layout, paint, and compositing.

Last reviewed: September 2026

What it is

The rendering pipeline is the browser's sequence for converting documents and styles into a visual frame. The stages overlap and can repeat as content, styles, viewport size, or application state changes.

Mental model

Think in dependencies: the browser needs structure and styles before it can calculate geometry, and it needs geometry before it can paint. Compositing can then assemble independently painted layers without repainting everything.

Why it exists

A browser must reconcile network input, document semantics, CSS rules, script-driven changes, device constraints, and user preferences into responsive pixels.

When to use it

  • Diagnosing layout, paint, or animation cost
  • Explaining why a DOM or style change affects rendering
  • Choosing between layout-changing and compositor-friendly animation properties

Production considerations

  • Measure with browser performance tools before optimizing
  • Avoid repeated synchronous layout reads and writes
  • Treat layer promotion as a targeted tool, not a blanket fix

Accessibility implications

The accessibility tree is related to, but distinct from, the visual render tree. Visual hiding, DOM order, and semantic structure can affect users differently.

Performance implications

Work that triggers layout or large paint areas can delay frames. Transform and opacity animations are often cheaper, but actual behavior depends on the page and browser.

Primary documentation

Related Frontend Index entries