The Rendering Pipeline

DOM plus CSSOM to style to layout to paint to composite — and the invalidation rules that decide which of those stages a given change actually costs you.

The Rendering Pipeline
▶ lab

DOM plus CSSOM become computed styles, then geometry, then paint commands, then a composited frame — and most updates re-run only part of that.

Q · What does the browser actually do between a change to the page and a new frame on the screen?
Style Calculation

Selector matching, cascade resolution and inheritance turn every rule you shipped into exactly one computed value per property, per element.

Q · What is the browser computing during the style stage, and what actually makes that computation expensive?
Style Invalidation

A change does not recalculate the document — it dirties a set of elements. The size of that set is the cost, and your selectors are what decide it.

Q · When something changes, how does the browser decide which elements need their style recomputed?
The Cost of a Change
▶ lab

The table you should be able to reconstruct from first principles: which stages each common change invalidates, and why the honest answer is so often "it depends".

Q · For this specific change, which stages of the rendering pipeline does the browser actually have to re-run?
CSS Containment

`contain` is a promise you make to the engine — nothing inside this box affects anything outside it — and in exchange, invalidation stops at the boundary.

Q · How do I tell the browser that a subtree cannot affect the rest of the page, and what am I giving up by saying so?
content-visibility

Ask the engine to skip rendering work for content nobody is looking at yet — and take on responsibility for its size, its scrollbar and whether anyone can find it.

Q · Can the browser simply not render the parts of the page nobody can see, and what does that cost me?