How does the browser display the page?

Objectives

By the end of the lesson, you can describe the steps of rendering (DOM, CSSOM, render tree, layout, paint), say why the DOM is not the same as the tree visible on the screen, and understand why the page can change even after "loading".

Why do we need to know the process?

The arrival of the HTTP response is not yet the finished, visible page. If the user says "the page is slow", the fault can be in the network, in the server, but also in the browser's processing. Whoever knows the steps can say where to look for the cause, and understands why the content jumps while you click a button, or why the page stays empty until a style sheet arrives.

The process in one picture

The student opens the course page. First the title and the text appear, an image arrives later, and the custom font replaces the default one even later. So the page is not completed in a single moment.

flowchart LR
    H["HTML arrives"] --> D["DOM is built"]
    C["CSS arrives"] --> S["CSSOM is built"]
    D --> R["Render tree"]
    S --> R
    R --> L["Layout"]
    L --> P["Paint"]

The diagram is an educational simplification: real browser engines work in parallel and in several steps, and JavaScript can start further changes. MDN calls the process the critical rendering path.

The steps

1. Building the DOM. The browser parses the HTML in pieces and builds the document tree (see 3.2). The HTML reveals what further resources will be needed, and the browser can start requesting them.
2. Building the CSSOM. The processed, object-like model of CSS is the CSSOM (CSS Object Model). Unlike the DOM, it is not built incrementally: according to MDN, CSS is render-blocking, and the browser does not paint until all the CSS has arrived and been processed. This is why a page can be empty or unstyled while the style sheet is delayed.
3. Render tree. The DOM and the CSSOM together give the render tree, which contains only the visible content. An element with display: none is in the DOM but not in the render tree.
4. Layout. The browser calculates the size and position of every visible element. It runs again if the render tree changes or the size of the viewport changes.
5. Paint. The calculated elements become pixels. On loading, the whole screen is painted, afterwards only the changed parts.

JavaScript and repainting

JavaScript can modify the DOM and the styles. If new text appears when you click a "Show details" button, the browser, depending on the kind of change, has to recalculate the layout and/or repaint the affected part. Not every change is equally costly: adding text that pushes down the elements below it takes more work than a color change.

A classic <script> (without async/defer) stops the parsing of the HTML until it has been downloaded and has run (see 3.4). Long-running JavaScript can therefore delay the appearance of the page and the reaction of the interface. This does not mean it should be avoided: an interactive application needs it. The task is to understand its role and its cost.

What does "loaded" mean?

There is no single perfect "done" moment. The browser can show usable text while a lower-priority image is still arriving. The reverse can also happen: every file has arrived, but because of a long JavaScript task the interface does not respond. From the point of view of the user experience, therefore, the perceived appearance and reaction count, not just the time of the last network request (see chapters 9 and 10).

If the font arrives later, the size and wrapping of the text can change. If the size of an image is not known in advance, the content below it can shift after loading. This is annoying for the user, especially if they were just about to click a button. The solution is to give images width and height attributes so the browser reserves space in advance (MDN recommends this too).

Worked example: the Kurzuspont course page while loading

Time	What is visible?	Why?
0 ms	Blank page	The HTML and CSS have not arrived yet.
after the first HTML + CSS arrive	The title and the text	The DOM and CSSOM are ready, the render tree, layout, and paint can follow.
later	The photo of the instructor	The image is a separate request, it arrived late.
even later	The new font	The text is rewritten, and the re-wrapping can move the button.
after the program has run	The filter field works	The JavaScript has arrived and run.

(The times are illustrative, not measurements.)

Common misconceptions

Statement	Clarification
"The server sends a finished picture to the browser."	The browser processes a document and resources, and calculates the picture itself.
"Everything is visible when the HTML arrives."	CSS, images, fonts, and programs may also be needed.
"Every element of the DOM is visible."	display: none elements are not in the render tree.
"A fast page is one with few files."	The appearance of the important content and the reaction time of the interface count.
"JavaScript only runs after loading."	A classic script stops parsing during loading.

In brief

• The steps of rendering: DOM, CSSOM, render tree, layout, paint.
• CSS is render-blocking, so the page is not painted until the style sheet has arrived.
• The render tree contains only the visible content.
• JavaScript can cause changes, recalculation, and delays.
• The "loaded" state is not a single moment but a gradual process.

Review questions

1. What is the difference between the DOM and the render tree?
2. Why does CSS block painting?
3. Why can a button jump on the screen while the page is loading?
4. Why is it not enough to look at the time of the last network request to judge slowness?

Learning resources

• Critical rendering path (MDN) — the steps, with the blocking role of CSS.
• <img> element (MDN) — the role of width and height in avoiding layout shifts.