The browser's rendering pipeline

Bytes in, pixels out — and the only question is which stages your change re-runs.

Somebody has to turn your text into coloured pixels, and then do it again in sixteen milliseconds.

You have never told a browser where to put anything, in pixels, and you have never asked it to redraw. Both are being done for you, on a schedule you do not set, by a machine with about five stages in it. This page assumes nothing: no graphics, no computer science course, and none of the words on the rest of this tutorial.

WHAT THE BROWSER IS ACTUALLY BEING ASKED TO DO

You send text. The screen needs colours.

A browser receives a string of characters — <h1>Ada</h1> — and has to end up with a decision about every pixel in a rectangle: this one is white, this one is black, this one is the grey at the edge of a letter. Nothing in the text says where anything goes or how big it is. Everything between those two things is what this page is about.

And it has to do it again sixty times a second

Not once. A screen redraws itself around 60 times a second, and anything that moves — a scroll, a hover, a caret blinking — is a new decision about every pixel. That gives the browser about 16.7 milliseconds per frame to notice what changed and produce the next picture. Almost every rule on this page is a consequence of that number.

So it is built as stages, and it skips the ones it can

Doing all of it from scratch each frame would be hopeless. Instead the work is cut into stages, each one taking the previous stage's output — parse, style, layout, paint, composite — and each one's result is kept. When something changes, the browser re-runs the stages that the change actually invalidated and reuses everything above them.

Which makes one question worth everything

Not *how fast is my code*, but which stages does this change re-run. Two lines that look equally innocent can differ by every stage in the machine — and that is not a matter of degree. One of them re-runs layout for the whole document; the other one re-runs nothing and is handled by a different thread entirely.

None of that is specific to the web. A game engine and a word processor have the same problem and solve it the same way; what is unusual here is that the document arrives over a network, a piece at a time, while the drawing is already happening.

WHAT YOU ACTUALLY CONTROL

You cannot ask for a frame

There is no “redraw now”. The browser decides when there is a rendering opportunity and runs a named algorithm then. Your requestAnimationFrame callback is a passenger inside it, not the driver.

Nothing you write applies immediately

Setting el.style.width marks something dirty and returns. The work happens later, in the frame — which is why fifty changes in a row cost one layout rather than fifty, and why the one thing that breaks the batching is asking a question.

Your code and the rendering share one thread

Style, layout, paint and every line of your JavaScript take turns on the same thread. A function that takes 300 ms takes 300 ms away from drawing. The compositor is the exception, and it is the only one.

Two of the words here are not standards

“Reflow” is Firefox's internal name for layout, and “layout” itself has no normative definition anywhere. What the standards define is the box tree and the used value. The engines' vocabulary is what everybody speaks; it is worth knowing it is vocabulary.

Which is a short list, and it is the good news. There is one thing to learn to make a page feel fast, and it is which stages your change costs.

THE FIVE STAGES, AND WHAT EACH ONE IS FOR

Parse

Turn the HTML text into a tree of objects — the DOM — and the CSS text into the CSSOM. Two separate jobs, because they arrive as two separate files.

This is the only stage that runs once. Everything below it runs again and again for the life of the page.

Style

For every element, work out what every CSS property ends up being: which rules matched, which won, what was inherited, what the default was.

It stops exactly where geometry would start. The standards' own phrase: as far as possible without laying out the document.

Layout

Turn those values into geometry. Where is this box, how wide, how tall. width: 50% becomes 384 pixels here and not before.

One box's size moves the next one, so this is rarely scoped to the element you changed.

Paint

Work out how to draw each box: the text, the background, the border, the shadow. The output is a list of drawing commands, not pixels yet.

Turning the list into actual pixels is a separate step called raster, and it happens on other threads.

Composite

Stack the separately drawn pieces into the final image, in the right order, and move them about without redrawing them.

Most of this is on a second thread. That is why a page with a frozen script still scrolls.

Those five are the developer's version, and they are what Chrome's own documentation still uses. Chrome's engine actually has twelve — Animate, Style, Layout, Pre-paint, Scroll, Paint, Commit, Layerize, Raster, Activate, Aggregate, Draw — and the last six of those are what the single word “composite” is hiding. The machine view at 09 draws the nine that a page author can affect.

SO THE WHOLE SUBJECT IS ONE QUESTION

Given a change, which stages have to run again? A change to width invalidates geometry, so layout has to run, and then everything below it. A change to background-color cannot move anything, so layout is skipped and paint runs. A change to transform invalidates neither, so the compositor moves a picture it already has — and can do it on a thread your code is not holding.

Every lesson here is one consequence of that. A script in the middle of the body stops the first stage. A stylesheet in the head stops the whole pipeline reaching the screen. A loop that asks for a width drags layout into the middle of itself, once per iteration. And a blocked thread stops everything except the one stage that was never on it.

Next: the same thing stated compactly, as something to look a fact up in.