The render pipeline: six stages from bytes to pixels

You hit Enter on a URL. Bytes start arriving. Somewhere between the first packet and the moment a button is clickable on screen, the browser ran a six-stage pipeline — and most pages spend the wrong amount of time in the wrong stage. The frame budget is 16.67 ms at 60 fps.

The six stages

The browser turns HTML + CSS + JS into pixels in exactly six steps, always in this order:

Two threads do the work. The main thread owns Parse HTML, CSSOM construction, style recalc, layout, and paint setup. The compositor thread assembles GPU-friendly layers and ships them to the GPU.

The kitchen metaphor

The browser is a restaurant kitchen. Parsing HTML is reading the order ticket. CSSOM is reading the recipe book. Style is matching ingredients to dishes. Layout is measuring the plate and arranging food on it. Paint is the actual cooking — heat and colour. Composite is the runner who picks up six plates at once and walks them to the table.

If any station is slow, the whole table waits.

The 16.67 ms frame budget

You hit 60 frames per second only if the whole kitchen finishes in 16.67 ms. Drop a frame and the user sees a stutter — a scrolling list judders, a button feels sticky, a chart lags behind the mouse.

The fix is almost never “make JS faster” — it’s “stop the kitchen from re-doing layout when it could have just rearranged plates.”

Read-aloud frame. Bea · Browser opens a profile card. Sven · Origin server narrates the kitchen: “0.5 ms parse the avatar div, 0.4 ms build the styles, 0.2 ms match selectors, 3 ms measure boxes — wait, the image hadn’t loaded so we re-measured, that’s another 2 ms — 1.5 ms paint, 0.5 ms composite. Frame is 8.1 ms. Fine. Now what if the user scrolls and we re-trigger layout fifty times per second? That’s 100 ms per second on layout alone, six dropped frames, the scroll feels heavy.”