Browser Rendering Pipeline: Layout (Reflow) vs Paint vs Composite (Performance)

A deep, interview-ready guide to how browsers render pages: DOM/CSSOM, render tree, layout (reflow), paint, compositing, GPU layers, and practical performance fixes.

F

Frontend Interview Team

February 08, 2026

~24 min
Browser Rendering Pipeline: Layout (Reflow) vs Paint vs Composite (Performance)

Performance interviews often ask vague questions like:

  • “What causes reflow?”
  • “How would you optimize rendering?”

To answer confidently, you need a mental model of the rendering pipeline.

30‑second interview answer

Browsers render by building the DOM and CSSOM, combining into a render tree, then running layout (reflow), paint, and compositing. Layout is expensive because it computes geometry. Many changes trigger layout+paint; transforms and opacity often only trigger compositing (cheaper). For performance, avoid layout thrashing, animate with transforms, and profile with DevTools.

Key points

  • Pipeline: DOM/CSSOM → render tree → layout → paint → composite.
  • Layout/reflow is expensive.
  • transform/opacity are usually compositor-friendly.
  • Profile, don’t guess.

1) The rendering pipeline (high level)

Most browsers follow this flow:

  1. Parse HTML → DOM
  2. Parse CSS → CSSOM
  3. Combine DOM + CSSOM → Render Tree
  4. Layout (a.k.a. reflow): compute geometry (sizes/positions)
  5. Paint: fill pixels (text, colors, shadows)
  6. Composite: put layers together (often on GPU)

Not every change triggers every step.


2) DOM, CSSOM, Render Tree

  • DOM = structure of elements
  • CSSOM = resolved CSS rules
  • Render tree = visible nodes with computed styles (e.g., display:none nodes not included)

Interview tip: Layout depends on both DOM structure and computed CSS.


3) Layout (Reflow): what it is

Layout computes:

  • element sizes
  • positions
  • line breaks

Layout is expensive because it can affect many nodes.

Common triggers

  • changing width/height, padding/margin
  • changing display, font-size
  • inserting/removing DOM nodes

4) Paint: what it is

Paint fills pixels for visual properties:

  • color, background
  • text
  • shadows
  • borders

Paint can be expensive on large areas or heavy effects.

Common triggers

  • changing color, background-color, box-shadow
  • large repaints

5) Composite: what it is

Compositing combines layers into the final image.

Good news: some changes can be handled mostly at compositing stage (cheap), especially:

  • transform
  • opacity

This is why “animate with transform/opacity” is a common best practice.


6) Layout thrashing (classic performance bug)

Layout thrashing happens when you interleave reads and writes:

for (const el of elements) {
  const h = el.offsetHeight; // read (forces layout)
  el.style.height = h + 10 + 'px'; // write (invalidates)
}

Fix: batch reads then writes.

const heights = elements.map((el) => el.offsetHeight);
heights.forEach((h, i) => {
  elements[i].style.height = h + 10 + 'px';
});

7) “Force reflow” and why reading layout can be expensive

Properties that can trigger layout calculation when read:

  • offsetHeight/Width
  • getBoundingClientRect()
  • scrollTop (sometimes)

If styles are “dirty”, reading these forces the browser to flush pending changes.


8) How to profile (what to say in interviews)

Chrome DevTools Performance panel

  • record a trace
  • look for:
    • “Recalculate Style”
    • “Layout”
    • “Paint”
    • “Composite Layers”

Key metrics

  • FPS
  • long tasks
  • layout count
  • paint time

9) Practical optimization playbook

Prefer composited animations

  • Use transform: translate/scale/rotate
  • Use opacity

Avoid expensive paints

  • reduce heavy shadows
  • limit large fixed backgrounds

Contain layout

Use contain to limit layout/paint impact:

.card { contain: layout paint; }

Reduce DOM size

  • virtualize long lists
  • avoid deep nesting

10) Interview Q&A

Q: What’s reflow?

  • Layout step where browser computes geometry.

Q: What changes avoid reflow?

  • transforms/opacity often avoid layout.

Q: How do you detect layout thrashing?

  • DevTools Performance trace + pattern of repeated Layout events.

Summary checklist

  • I can name the pipeline steps.
  • I know layout/reflow is expensive.
  • I can explain compositor-friendly animations.
  • I can explain layout thrashing and how to detect it.

Summary

  • Rendering pipeline: DOM/CSSOM → layout → paint → composite.
  • Layout (reflow) is expensive; avoid forcing it.
  • Animate with transform/opacity.
  • Profile with DevTools and optimize based on evidence.