From bytes to pixels

The browser receives bytes. The screen needs pixels. The rendering pipeline is everything in between, and this module walks through it stage by stage.

HTML bytes become tokens, and tokens become DOM nodes. CSS bytes become rules the browser can match against those nodes. From there the browser does five kinds of work:

1. Style calculation decides the computed value of every property on every element.
2. Layout calculates the size and position of each box.
3. Paint records drawing instructions for text, backgrounds, borders, and images.
4. Rasterization turns those instructions into actual pixels.
5. Compositing combines the painted layers into the frame you see.

Not every change runs every stage

Think of these stages as dependencies, not a fixed loop. Each stage needs the output of the previous one, but a change only re-runs the stages it invalidates.

Change the text of a paragraph and the browser needs style, layout, paint, and compositing, because the geometry may have moved. Change a background color and layout is untouched, only paint and compositing run. Animate a transform on its own layer and, after the setup, only compositing runs on each frame.

This is why some animations feel smooth and others stutter. We’ll get to the details in the compositing lesson.

JavaScript shares the thread

JavaScript runs on the main thread, the same thread that does most of the style and layout work. While your script runs, the pipeline waits. A long task delays pixels even when every network request finished long ago.

See the stages

Open the Performance panel and record a page load. In the Main track look for Parse HTML, Recalculate Style, Layout, Paint, and the compositing events. Your browser version may label or group them a bit differently, but the work is the same.

Try this on your own project: change an element’s width, then its background-color, then its transform, recording each change on its own. Before each recording, predict which stages you’ll see. Then check.