From bytes to pixels.

Open Copperpot's product page for the Enamel casserole on a phone. The server sends text: 96 KB of markup and, a little later, a 48 KB stylesheet. The screen needs something completely different, a rectangle of pixels with a colour for each one. No single algorithm goes straight from one to the other. The browser gets there in stages, and each stage builds a structure that answers one question.

Parsing asks what the document contains, and answers with the DOM. Parsing the stylesheet asks which rules exist, and answers with the CSSOM. Style asks which of those rules win for each element, and answers with a computed style per element. The layout tree asks which elements actually produce boxes. Layout asks where each box goes and how big it is. Paint asks what to draw and in which order, and answers with a list of drawing commands. Raster runs those commands to get pixels, and compositing stacks the rasterized layers into the frame you see.

The split is what makes the web fast enough. Because every stage keeps its output, a later change only has to redo the stages whose inputs it changed. Recolouring a button border does not move anything, so layout is skipped. Sliding a photo with a transform does not even need repainting. Knowing which stage a change wakes up is the single most useful thing this topic teaches.

Before anything can be parsed, bytes have to become characters, and that needs an encoding. The browser looks for a byte order mark at the very start, then for a charset on the Content-Type header, and failing both it scans the beginning of the file for a meta charset declaration. The HTML Standard encourages browsers to look only at the first 1,024 bytes for it, so Copperpot puts <meta charset="utf-8"> as the first element in head. Declared later, or not at all, a page can be decoded with a guessed encoding and, when the guess turns out wrong, decoded again from the start.

The tokenizer then reads characters and emits tokens: a doctype, start tags with their attributes, end tags, runs of text, comments. It is a state machine that changes mode as it goes, so the same less-than sign means a tag in body text, plain text inside a <textarea> and nothing special inside a <script> until the matching end tag. Tokens are handed to tree construction one at a time; the browser does not wait for the whole file.

Tree construction keeps a stack of open elements and decides, token by token, where each node goes. It knows the rules a person writing the markup may have skipped: html, head and body exist even when nobody wrote them, a table row always sits inside a tbody, and a new <p> closes an open one. Copperpot's template omits all of those and the tree still comes out the same in every browser, because the standard defines a recovery for every kind of mistake. There is no such thing as a fatal error when parsing HTML, which is very different from parsing JSON or XML.

Nodes are appended as soon as their tokens arrive, so the DOM grows while the bytes are still downloading. That is what lets a browser show the header and the title of a long page before its footer exists. Two things can interrupt the flow: a classic script without async or defer makes the parser stop and run it, because the script could write more markup into the stream, and the first paint waits for the stylesheets in head. Who waits for whom, and how async, defer and the preload scanner change it, is the subject of What blocks the parser and the first paint.

main.css goes through its own parser and becomes the CSSOM: style sheets holding rules, each rule a selector and a block of declarations. It is a separate structure from the DOM, and on its own it says nothing about any particular element.

Style calculation joins the two. For each element the engine finds the rules whose selectors match it, sorts the competing declarations by the cascade (origin and importance, then layers, then specificity, then order of appearance), fills in what nothing set by inheriting from the parent or using the initial value, and resolves relative values where it can, such as 1.5em to 24px. The result is a computed style for every element and every property. Copperpot's price paragraph ends up with a colour, a font size and a margin even though its own rule only names two of those.

Engines avoid repeating work here: they index rules so that most selectors are never tried against most elements, share computed styles between siblings that match the same rules, and after a change restyle only the elements a changed class or attribute could affect. Style is still proportional to how many elements need it, which is why a class toggled on body can be more expensive than the same class on one button.

Layout does not work on the DOM. It works on a tree of boxes built from the DOM and the computed styles, often called the layout tree or render tree. The two trees disagree in instructive places. Elements whose display is none produce no box at all, and neither do their descendants; head and everything in it is display:none by default. Pseudo-elements such as ::before produce boxes even though they are not in the DOM. An element with display:contents gives up its own box but its children keep theirs, as if they belonged to its parent. And an element with visibility:hidden keeps its box, because it still takes up space; it is simply not drawn.

Layout walks the box tree and works out the size and position of every box. Widths mostly flow down from the parent: the viewport is 393 CSS pixels wide on Copperpot's test phone, main has 16px of padding on each side, so the product block's content is 361px wide. Heights mostly flow up from the children: the price paragraph is as tall as its line of text, which depends on the font, which may not have loaded yet. Text is shaped and broken into lines here, so a longer product name can push everything below it down. The rules that decide where each box goes (normal flow, flex, grid, positioned boxes) belong to the formatting contexts topics; what matters here is that layout's output is geometry, and that geometry is what paint and hit testing read.

Because a box's position depends on what comes before it and its size on what is inside it, a change in one place can move many others. Engines mark dirty boxes and skip clean subtrees, and in Chromium the result of layout is an immutable fragment tree that is reused where its inputs did not change. The first layout of a page is usually just called layout; later ones are often called reflows.

Paint does not produce pixels. It walks the laid-out boxes in paint order and records commands: fill this rounded rectangle with cream, draw this text run in rust at these coordinates, draw this image into that rectangle. Paint order is not DOM order. Backgrounds go under borders, borders under content, and positioned or z-indexed boxes go where their stacking context puts them, so Copperpot's sticky header is recorded after the product photo it overlaps even though the header comes first in the markup.

Raster executes those commands into actual pixels. Large areas are cut into tiles and drawn in parallel on raster threads, often with the GPU's help, starting with the tiles in or near the viewport. Images are decoded here too, which is why a large hero photo can sit in memory as compressed bytes well before it is ready to draw. Keeping raster off the main thread means a slow decode does not freeze script or input.

Parts of a page may be painted into separate layers: a video, a canvas, a fixed header, an element being animated with transform or opacity. Compositing stacks those rasterized layers with their current offsets, transforms, clips and opacities, and the result is the frame sent to the display. Because the layers are already pixels, moving one or fading it means recompositing, not repainting. That is how a page can scroll, or a photo can slide, while the main thread is busy elsewhere. Which elements get a layer of their own, and what that costs in memory, is covered in Layers and compositing.

Two things to read off the waterfall. First, parsing is not the bottleneck on this page: the DOM is complete 54 ms before the stylesheet arrives, and the screen stays blank for that whole window. Second, rendering is incremental when its inputs allow it. With the CSSOM ready early, the browser paints the part of the DOM it has and adds to it as chunks arrive, so the visitor sees the price a sixth of a second sooner. Two milestones from the Paint Timing specification name these moments: first paint is the first frame that shows anything other than the default background, and first contentful paint is the first frame that shows text, an image, a non-blank canvas or an SVG from the DOM. On this page the first frame already holds the product name, so the two coincide; a page whose first frame is only a coloured header bar would record them apart. Why the stylesheet holds back the first frame, and what preloading and inlining do about it, is the subject of What blocks the parser and the first paint, which also follows readyState, DOMContentLoaded and load through the same visit; the page-load card turns the same picture into LCP.