We as a developer/engineer spend most of our time on browsers (Chrome, Firefox, Safari, Opera etc) while building web apps/pages. But we might not have thought a lot about how the browsers are actually rendering our beautifully crafted web app/pages.

In this article, I will go through the steps of how the browsers render the web pages, so at the end of this article, we will be equiped with the knowledge of the browser rendering and have better ideas of how to improve the performance of the web pages.

Before we dive into it, just for the note that each browser might have a different browser architecture so the approach each browser takes for the rendering process might be different from one another. But this article will give you the overall ideas of how the browser rendering generally works.

Components of browser

The web browser consists of several components as shown below for the general overview.

When a user types search terms or a URL in the address bar of the browser’s user interface, the UI thread decides whether the input should be sent to a search engine or a website from the URL. When the user hits the enter, the network thread goes through several processes to request the data and receives the response from the server and if the response is an HTML/CSS file, it will go through the rendering process as below.

Rendering engines

Throughout this article, we are going to focus on the rendering engine (from the image above). The main job of the rendering engine is to:

… draw text and images on the screen. The engine draws structured text from a document (often HTML), and formats it properly based on the given style declarations (often given in CSS).
– MDN

You might have already heard of Blink, Gecko and WebKit , and they are the rendering engine names of the different browser manufacturers.

Rendering engine flow

The rendering engine goes through the 5 steps to render content on the screen.

Let’s take a look at the first phase, Parsing.

1. Parsing

During the Parsing step, the rendering engine creates DOM tree for HTML and CSSOM tree for CSS. First, let’s take a look at how the DOM tree is created.

DOM tree

When the HTML (same to CSS and JS) files are sent to the browser from the server, the browser doesn’t receive it as HTML format, and magically understands and display it on the screen. It actually receives the file in the raw bytes format and the rendering engine goes through the following 5 steps to create the DOM tree (and almost same for the CSSOM tree too) during the parsing step.

Throughout this article, we are going to use the below HTML as an example.

1. Bytes

As mentioned above, the server sends the HTML in the raw bytes of data and it must be converted to the format that the browser can understand.

The next step is to convert the raw bytes to characters.

2. Characters

The parser goes through each raw bytes of data and convert it to characters. For our HTML example, it will look something like:

If you are familiar with HTML, you might probably understand the converted characters, however, for the browser, it still doesn’t mean anything. It’s just a plain text and it needs to be tokenised.

3. Tokens

The characters are further parsed into tokens. The parser understands the HTML tag inside the angle brackets, and it creates the tokens including the start and end tags and its associated attributes names and values, for example, the <img> tag contains src and alt attributes as specified by HTML Standard.

During the tokenisation, at some points, the adoption agency algorithm is invoked and handles the missing closing tags. Because the HTML errors are handled gracefully, the missing closing tag such as </p> is a valid HTML markup. If you wanted to dig into more details of how HTML parser is handling the erroneous markup, check out this article, An introduction to error handling and strange cases in the parser.

4. Nodes

After the tokenisation, the tokens are converted to nodes. The nodes are objects with their properties and rules. Each node represents an HTML tag.

5. DOM

The final step for the parsing is creating the Document Object Model. The nodes created above are linked in a tree data structure which creates the relationships and hierarchies between different tags (e.g., parent-child, adjacent sibling etc) and captures the properties and relationships of the document markup.

We now have created the DOM tree and the document markups are ready. Next let’s take a look how CSSOM tree is created to style the elements.

CSSOM tree

While the browser is constructing the DOM, when it sees the <link> tag inside the <head> section, it immediately starts to fetch the style resource and the browser won’t render any processed content until CSS Object Model (CSSOM) is constructed. This is why CSS is treated as a render blocking resource.

Just like DOM, when the browser receives CSS in the raw bytes, it goes through quite similar to the process of constructing DOM tree.

With the CSS styles below as an example,

body { font-size: 16px; }
h1 { color: green; }
span { font-weight: 400; }
h1 span { disaply: none; font-style: italic; }
img { display: block; }

it will be constructed with the CSSOM tree as the following screenshot. The below CSSOM tree example only contains the above example styles but in the real case, the user agent styles will also be applied to the node and then recursively go through the tree structure and apply more specific rules which creates the CSS Specificity. That’s why CSS stands for Cascading Style Sheets.

From the example above, the span inside h1 contains not only font-style: italic; and display: none; but also cascading down:

font-size: 16px from <body>
color: green from <h1>
font-weight: 400 from <span>

Overall, in the Parsing step, the DOM tree and CSSOM tree are constructed. In the next step, they will be combined and created as Render tree.

2. Style

In the style step, the DOM and CSSOM trees are combined into a render tree.

Render tree fusion — DOM + CSSOM = Render Tree

The render tree starts with the root of the DOM tree and traverse each node, and figuring out what CSS rules to apply to each node.

Any nodes with display: none; will not be included in the render tree (even though it is included in the DOM tree) and they will not appear in the rendered output. Whereas nodes visibility: hidden; will still be included in the render tree because the nodes are still taking up the space.

One thing to note is that even if no CSS is provided, each DOM node still comes with default styles, user agent styles, from the browser, for example, <h1> heading is bigger than <h2>.

3. Layout

Once the browser knows what CSS rules to apply to which nodes and which nodes are displayed with their computed style, it can begin to compute the geometry of each node such as width, height and x/y coordinates; how much space it takes and where it is on the screen.

The first time when the size and dimensions are determined is called Layout and the subsequent recalculations of the size and dimensions when every time something changed to the layout is called reflow.

Reflow

Reflow causes forcing the browser to recalculate the dimensions and position of other elements and re-render page. This process is fairly expensive process.

From our HTML example,

There are no width and height specified for the img element so the browser doesn’t know the dimensions of the image until it is fully downloaded. When the image is downloaded, the browser now needs to recalculate the dimensions and positions, and it can cause the other elements to be shifted.

To fix this issue, we can provide width and height to the img element so the browser doesn’t have to wait to recalculate its dimensions.

4. Paint

It’s time to paint! In this phase, the individual nodes are painted by converting each node calculated in the layout phase to actual pixels on the screen and the process includes drawing every visual part of an element such as text, colors, images, borders, shadows and buttons.

In this paint phase, users start to see something on the screen and there are several paint times are measured. Most commonly, you may have already heard of First Contentful Paint (FCP) and First Meaningful Paint (FMP).

First contentful paint vs first meaningful paint

FCP and FMP are often the same but there are some subtle differences.

FCP is the time measured when the browser renders the first piece of content from the DOM and this is an important indication telling users that the page is loading. You can track the FCP score in the Chrome Lighthouse in the Performance category.

FMP is the time measured when the browser paints the primary content and it is visible to the users. Often it is hard to measure because the browser engine doesn’t really accurately know what content the users would be most interested so FMP usually measures the biggest above-the-fold layout changes happened.

Due to the inconsistent results with FMP, FMP is deprecated in Lighthouse 6.0, instead it now provides Largest Contentful Paint (LCP).

Largest Contentful Paint

LCP measures the render time of the largest image or text block visible within the viewport relative to when the page first started loading. The Chrome team suggests to have LCP less than 2.5 sec for the good user experience.

You can check LCP score in the Lighthouse.

Animation – 60 fps

During the paint phase, we also need to watch out the rendering performance especially when we are animating elements or scrolling pages.

Most of modern browsers refresh their screens 60 times a second (60 frames per second). That means each frame has about 10ms (16.66ms from 1 second / 60 minus minus some garbage collection) in budget to accomplish the operations such as calculating styles, reflow and paint. When the animation goes out of the budget and misses the frames, we see the animation goes “janky”.

Hardware-Acceleration

One of the ways we can avoid the janky animation is to use CSS transforms to let the GPU do the tasks so CPU can do other tasks. This is called Hardware-Acceleration.

A good example is to use translate3D instead of left CSS property when animating the position of the DOM elements because translate3d creates new composite layer that is uploaded directly to GPU and won’t require to repaint.

So like the example above, the modern browsers handle the process more efficiently by separating parts of a page into several composite layers, and move the layers and composite a new frame.

5. Compositing

Now we are at the final phase and the compositing is essential to ensure to draw the elements in the different layers, especially those overlapping each other in the right order.

During this phase, the layers are sent to the GPU to display it on the screen. To make this operation more efficient, the layers are separated into different frames and sent to GPU. The separated layers can be found in Chrome DevTool > Layers menu.

Great! Now the elements are rendered on the screen 😀

Improving rendering performance

We talked about how the browser rendering works and in this section, let’s talk about 3 scenarios and discuss how we can improve the rendering performance.

1. Layout -> Paint → Composite

When the geometry of an element such as width, height or its position gets changed, the browser needs to recalculate the geometry of all other elements and ‘reflows’ the page. This causes all affected areas to be repainted and composited back together again.

2. Paint → Composite

When the ‘paint only’ properties are changed, such as the color, shadow or background-image, there will be no changes in the layout so the browser will skip the layout phase and rework from the paint phase.

3. Composite

If we change a property which requires neither layout nor paint such as transform of an element, the browser will only do the composite phase.

Choosing the best rendering optimisation

So from the scenarios above, the last one is cheapest and boosts the rendering performance as it can avoid the layout and paint phase. As mentioned above, a great example is to use transform: translate3d(50px, 0, 0) instead of left: 50px because the transform can make a use of the Hardware-acceleration. Whereas left requires altering the geometry of the element and it causes the browser to perform the layout operations.

There are many ways to optimise the browser rendering and I will discuss more on this topic in the future articles.

In conclusion

In this article, we looked at how the browser renders content from parsing to compositing. I hope this article gives you a good understanding of the rendering pipeline and tips to improve the rendering performance.

In the future articles, I will be talking more on optimising the browser rendering and improving the performance so please stay tuned. ✌️