From tags
to pixels.

A browser turns your markup into pixels through a fixed sequence of stages called the render pipeline (or critical rendering path). It parses HTML into the DOM tree and CSS into the CSSOM, combines them into a render tree of everything visible, then runs layout to compute the exact position and size of every box, paint to fill in the pixels (text, colors, borders, shadows), and finally composite to stack the painted layers into the image you see.

The crucial fact is that the stages are ordered and dependent: each one feeds the next, so a change early in the pipeline forces everything downstream to run again. Change the text content and you may re-run layout, paint, and composite. Change only a color and you can skip layout and just repaint. Change only a transform and you can skip layout and paint, going straight to composite. That dependency chain is the entire performance story: the cost of a visual update is decided by how far back in the pipeline your change reaches. And the stage you most want to avoid re-running is layout.

Layout — also called reflow — is where the browser computes the geometry of every element: where each box sits and how big it is. It's the pipeline's most expensive stage, and the reason is interdependence. Boxes affect each other: make one element wider and it can push its siblings, stretch its parent, and shift all their descendants. So a single geometric change can force the browser to recompute a whole subtree, at a cost that grows with the number of nodes it has to lay out.

Anything that touches geometry triggers a reflow: changing width, height, margin, padding, top/left, font-size, or adding/removing a DOM node. Changes that only affect appearance — color, background, visibility — skip layout and only repaint, which is much cheaper. This split is the single most useful thing to internalize about browser performance: geometric changes are expensive because they cascade; cosmetic changes are cheap because they don't. Every front-end optimization about "smooth scrolling" and "jank-free animation" is, at bottom, about not paying the reflow tax more often than you must.

The classic performance killer is layout thrashing: forcing the browser to reflow many times in a row when one would do. The browser is actually smart — it tries to batch your DOM changes and reflow once, at the end of the frame. You defeat that batching by interleaving writes and reads.

The trap is subtle because reading looks harmless. But when you read a layout property like offsetHeight after having written a geometric change, the browser can't give you a stale number — it must synchronously flush a reflow to compute the current value. Do that inside a loop (write, read, write, read…) and you trigger a reflow per iteration instead of one at the end. The fix is a discipline: batch reads and writes separately — gather all the measurements you need first, then apply all the mutations — so the browser coalesces everything into a single layout pass. Batching geometric updates is one of the highest-leverage optimizations in front-end code, and it's the direct payoff of understanding reflow.

Only geometric property changes force a reflow; a reflow's cost scales with the number of nodes it must lay out. Batched, many geometric writes collapse to one reflow; unbatched, each triggers its own:

3 geometric writes over 100 nodes: batched = 1×100 = 100 units; thrashing = 3×100 = 300. Paint-only changes (color, background) = 0 reflows.

So the cost of a visual change depends entirely on which stage it reaches and how many times you re-enter it:

The further right, the cheaper. The runnable version below classifies properties and computes reflow counts and total layout work, batched vs not.

To animate at a smooth 60 frames per second, the browser has ~16 milliseconds per frame to produce a new picture. Run layout and paint every frame and you'll blow that budget and drop frames (jank). The trick is to stay on the cheapest part of the pipeline — compositing — by animating only properties that don't need layout or paint:

So the practical rule for movement is: use transform: translate() instead of top/left, and opacity instead of changing visibility or background — because transform and opacity can be handled by the compositor on a separate layer, frequently on the GPU, without ever re-running layout or paint. That's why two animations that look like they do "the same thing" can feel utterly different: one takes the composite-only fast path and glides; the other reflows every frame and stutters. Combined with batching your reads and writes, staying on the composite path is most of what "web performance" means in practice. Understand the pipeline and the fix for a janky page is usually obvious: figure out which stage you're re-running every frame, and stop.

The first is forced synchronous layout hidden in innocent code — a loop that sets a style and then reads offsetHeight/getBoundingClientRect() right after. Each read forces the browser to flush a reflow to answer accurately, so a loop over N elements can cause N reflows. It's the most common cause of scroll and animation jank, and it's invisible unless you know to look. The fix is the batching discipline: read all layout values in one pass, then write all mutations in the next.

Two more. Animating layout properties: transitioning width or left triggers reflow every frame and will never be smooth on a complex page — reach for transform instead, always. And giant DOM trees: since reflow cost grows with the number of nodes involved, a page with tens of thousands of DOM nodes reflows slowly no matter how careful you are; virtualize long lists (render only what's on screen) so layout works on a small tree. The unifying idea is that the browser is a pipeline with one expensive stage, and your job is to reach that stage as rarely as possible: prefer cosmetic changes to geometric ones, batch the geometric ones you can't avoid, and animate on the compositor. Learn the pipeline and web performance stops being folklore — it becomes a short, mechanical checklist about which stage a change re-runs and how often.