Understanding the Browser Rendering Pipeline

Every pixel you see on screen goes through a precise pipeline. Understanding it is crucial for building performant UIs at Google-scale.

The Critical Rendering Path

1. Parse HTML → DOM Tree
2. Parse CSS → CSSOM Tree
3. Combine → Render Tree (only visible elements)
4. Layout → Calculate geometry (position, size)
5. Paint → Fill in pixels (colors, borders, shadows)
6. Composite → Layer composition on GPU

Layout (Reflow) vs Paint (Repaint)

Layout is triggered when geometry changes: width, height, position, font-size. It's expensive because it affects descendants.

Paint is triggered by visual changes that don't affect geometry: color, visibility, background-image.

The Worst Offenders

Compositing: The GPU Fast Lane

Properties like transform and opacity skip layout and paint entirely — they go straight to the compositor thread on the GPU.

will-change: Use Wisely

will-change promotes an element to its own compositor layer. But each layer costs GPU memory. At Google, we only use it for elements that will actually animate.

Production Tips

• Use Chrome DevTools Performance tab to identify layout thrashing
• Avoid reading layout properties inside animation frames
• Prefer requestAnimationFrame over setTimeout for visual updates
• Use contain: layout to limit reflow scope