Frontend
Browser Rendering Pipeline
The path from HTML to pixels: parse into DOM and CSSOM, build the render tree, then layout, paint and composite. Knowing it explains why layout thrashing is slow, why transform and opacity animate cheaply, and what the critical rendering path means for first paint. Optimising is mostly doing less work per frame.
Purpose
The browser turns your code into pixels through a fixed pipeline: HTML parses into the DOM, CSS into the CSSOM, the two combine into a render tree, then layout computes geometry, paint rasterises, and composite assembles layers on the GPU. It matters because each stage can be re-triggered by your code — and the earlier the stage, the more expensive the re-run. Changing geometry re-does layout, paint and composite; changing transform re-does only composite.
When to Use It
This model is the diagnosis kit for frontend performance: janky scrolling and animation (work exceeding the ~16ms frame budget), slow first paint (render-blocking CSS and synchronous scripts on the critical rendering path), and mysterious slowness in loops that alternate reading and writing layout properties — layout thrashing, where each read forces a synchronous reflow.
Trade-offs
The rules can be over-applied: promoting everything to its own compositor layer with will-change eats GPU memory, and micro-optimising paint before measuring is effort spent blind. The frame budget also shifts the trade — code that is fine on a desktop is jank on a mid-range phone, so the target device defines what counts as slow.
Implementation
Animate transform and opacity, never top/width. Batch DOM reads before writes (or use requestAnimationFrame) to avoid thrashing. Cut the critical path: inline critical CSS, defer scripts, lazy-load below the fold, and let content-visibility: auto skip off-screen rendering. Then verify in the DevTools Performance panel — the flame chart shows which stage you actually paid for.