How a browser draws a page

Rendering is a page’s road from bytes to pixels: HTML is parsed into the DOM, CSS into the CSSOM, then come the render tree, layout and painting.

The response has arrived: what next

By now you know how the browser found the server, set up a secure connection and received a response: the code 200 and a body, that is, the bytes of HTML. But bytes aren’t a page yet. The browser still has to turn them into a picture on the screen, and that road is divided into stages too. It is useful to know them, because this is where the “white screen”, when nothing shows for a long time, and the “jumping layout”, when text slides out from under your finger, are born.

The whole chain looks like this:

1. Bytes into characters. By the encoding from the Content-Type header, the bytes are read as letters.
2. Characters into the DOM. The browser finds the tags and builds from them a tree of elements: the DOM (Document Object Model). It does this as data arrives, without waiting for the end of the file.
3. CSS into the CSSOM. When it meets styles, the browser builds a tree from the rules in the same way: the CSSOM.
4. The render tree. The DOM and CSSOM are joined into a tree of what will be visible. Elements with the style display: none don’t get into it.
5. Layout. For each element the size and place on the page are worked out.
6. Painting. The pixels are filled in, sometimes in layers, and the layers are composited onto the screen.

Experiment on the diagram below: it uses your browser’s real parsers. Change the HTML or CSS and see how the result changes at each stage.

HTML<h1>Project title</h1> <p>Description: who you are and what you do.</p> <p class="secret">This paragraph is hidden.</p> CSSh1 { color: #8a3b12; } .secret { display: none; }

1. Bytes2. DOM3. CSSOM4. Render tree5. Layout6. Paint

The browser reads the characters, finds the tags and builds from them a tree of elements, the DOM. Here it is (text is nodes too):

What delays the first paint

A script in the head: noneordinarywith the defer attribute

Styles: inside the pagein a separate file

Made-up numbers. HTML parsing will finish after 100 ms. The styles will be ready after 0 ms. First paint: 150 ms.

Check yourself: what is the DOM, and where does it come from?

The tree of a page’s elements in the browser’s memory. The browser builds it from the HTML as it parses.

What stops the pipeline

Not all stages are equally calm. Two important rules:

• CSS blocks painting. Until the browser has the styles, it paints nothing, so as not to show bare text and a second later abruptly rearrange it. That is why the styles needed on the first screen are kept small and linked at the very start.
• An ordinary script blocks parsing. When it meets a <script>, the browser stops building the DOM, downloads the script, runs it and only then goes on: after all, a script can change the page. To keep it from getting in the way, it is given the attribute defer (run after parsing) or async (run as soon as it has downloaded).

A white screen often comes from exactly this: a heavy style sheet or script delays the first paint. The lower part of the diagram above shows the order: switch the script type and the way the styles are linked, and see when the first paint happens (the numbers are made up, they show the order, not a measurement).

The jumping layout

The browser works out layout from what it knows. Until a picture has loaded, it doesn’t know its size and leaves no room. When the picture arrives, everything below it shifts. The same goes for a font that loaded later and turned out wider, and for an ad block inserted at the top. A person reaches for a button, and it slides away.

There is one cure: tell the browser sizes in advance. Pictures have the attributes width and height for this, and room is reserved for ads and embeds. In the part on quality we’ll see how this is measured, and look at the speed metrics introduced by Google, called Core Web Vitals.

Check yourself: why does a page “jump” as pictures load?

Until a picture arrives, the browser doesn’t know its size and leaves no room. When it appears, everything else shifts down.

Looking for yourself, in the developer tools

The developer tools (F12) have a Network tab. Reload the page with the tab open, and you will see:

• a list of the requests the page made: the page itself, styles, scripts, pictures, fonts;
• for each, the response code, the type, the size and the time;
• at the bottom: how many requests, and how much data in all.

That is how you see what exactly makes a page heavy. Sort by size, and the heaviest resources come to the top. For comparison, open the first site in history: it has one request, one page of a kilobyte. Remember the lesson on packets: the 50 kilobyte budget for a modem.

The whole road in a minute

You have reached the end of the first part. Here is the whole road of a page, which you can now trace:

1. You type the address https://www.example.com/services/.
2. DNS finds the server’s IP address from the name www.example.com.
3. TCP sets up a connection (a three-step handshake), cutting the data into packets.
4. TLS agrees on a key and checks the certificate: the channel is now protected.
5. HTTP: the browser sends the request GET /services/, and the server answers with the code 200 and a body.
6. The browser builds the DOM and CSSOM, works out the layout and paints the pixels.

Every step can break, and now you know where to look. The site won’t open at all: DNS or the connection. A security warning: the certificate. A 404 or 500 error: the HTTP response. A white screen or jumps: the rendering stage.

Practice

You are in the era of 1996, comparing it with today. Open the first site in history in a new tab, and any modern one. For each, look at the Network tab and fill in the table with the number of requests and the heaviest resource. On the second site, find what holds up the first paint: a style sheet at the start of the page, an ordinary script, a big picture.

The practice preview won’t show you the network: the page in it isn’t downloaded over the network, it is filled in whole. That is why you need to open real sites.

What was wrong with 1996

Pages were then laid out with nested tables, and the browser couldn’t show a table until it had worked out all of its cells: a white screen was normal. Today layout is CSS’s job, and the browser paints a page in parts. In the next part you’ll start writing yourself: HTML, the language a page is built from.