From HTML/CSS to UI – Rendering process

Tram Ho


In the process of software development, along with the desire that the team ‘s products will have a good user experience, we are always faced with issues such as slow load of resources, waiting time for initialization. so long due to waiting for some content that is chưa-thật-sự-cần-thiết , then it is the phenomenon of FOUC (flash of unstyled content) when styles not ready, etc … and cloud …

For possible solutions to minimize these problems, we need to understand the process of rendering of the browser to a web page . How can it be displayed on the screen from file HTML/CSS/JS or other resources?


In this article, we will go to answer the question together ^^

Let’s get started!

Rendering process

When the browser sends a request to the server to fetch an HTML file , the server returns an HTML page in binary stream format – a text file with a response in the header :


You can see it on the Network tab in the Google Chrome DevTools window (opened with Cmd + Option + I or Ctrl + Shift + I ) as follows:

If the header does not contain this information, the browser will not understand how to handle the downloaded file and it will display in plain văn bản thuần túy format.

And if all goes well, from this information, the browser can convert binary format to a readable text file . From here, it can start reading the HTML file .

The process is the same for other resources like CSS files , Images , JS files , etc.


It is known that different browsers have different operating mechanisms, but the diagram below generally describes the rendering process as they compile source code HTML/CSS from server to client :

Now, let’s go through each stage together

DOM tree

Browser will read all the tags in the HTML source code and then build a DOM tree .

DOM stands for Document Object Model .

  • Each HTML tag corresponds to a node in the DOM Tree .
  • Each text inside the HTML tag will correspond to a text node .
  • Root node in the DOM tree is a documentElement ( <html> tag ) .



You can read more about the DOM through the article about Original DOM – Shadow DOM – Virtual DOM here .

So, if the file HTML has a <h1>DevNotes</h1> tag, then the DOM Tree has only một-node-duy-nhất h1 , right?

To know what the exact result is, try creating an file HTML with such content, then open it in your browser , check it in the Element tab in Google Chrome DevTools Console


CSSOM stands for CSS Object Model .

After the DOM tree is created, the browser will read the entire style sources ( user-agent CSS , external , embedded , inline , etc.) , determine the styles of the corresponding element node based on the specificity & cascades in CSS to Create the CSSOM tree (style structure) :

  • Browser tend to ignore some lines of code they don’t understand (for example, with browsers-khác-browser-hiện-tại prefix like -moz , -webkit , -o , etc.)
  • Each node will contain CSS style information for each corresponding DOM element (except for elements do not appear on the screen like <meta> tags , <script> tags , <title> tag , etc.)

Render tree

Once you have the DOM Tree and CSSOM tree , the browser will combine them into a Render tree .

Render tree will consist of nodes , text nodes and corresponding styles :

Each node on the render tree often called a frame (also referred to as a CSS box and follows the box model ) .

From here, the browser will paint ( draw ) the nodes of the Render tree onto the screen.


Hmmm ,

So, is there a difference between DOM tree and Render tree ?

Let’s compare it together!

DOM Tree vs. Render Tree

Looking at the diagram above, it is always possible to recognize that one has not applied styles and that one has already applied styles , right? ^^

And because of this difference, what I want to note here is that in some cases, the Render tree may be a little bớt cồng kềnh than the DOM tree .

Consider the example for easy visualization, suppose I have a <h1> tag for example. Thus, node h1 will exist in the DOM tree .

In CSS I have a style for it to be display: none , so when the Render tree is no longer this node h1 .

This is also a điểm-khác-nhau-cơ-bản different point to distinguish between how display: none vs. visibility:hidden / opacity: 0 is applied to an element .

This is similar to invisible elements , like <head> tag or any <meta> tag , <title> tag . They are not displayed on the screen so they are not in the Render tree but only in the DOM Tree

Repaint & Reflow

The initial rendering process is like that, but, if there are some changes to the input information such as the user added one element, changed the other, etc., how will the browser handle it?

Let’s find out 2 more keywords: Reflow and Repaint ^^


The process of partial render tree or some node recalculating is called reflow (or may be called relayout or layouting ) .

Parts of render tree (or the whole tree) are revalidated ⇒ Node dimensions recalculated.


In other words, this is a collection of processes where the browser recalculates the size and elements of elements on the web page .

Amazing right, the browser takes care of all 

But the downside of this process is that it runs synchronously , ie reflow but has not finished running, the guy behind will wait there

This means that if there are quá-nhiều-tiến-trình-reflow , the browser does not handle them, the FPS ( Frames Per Second ) will decrease, even leading to a dull or bad screen. especially the crash tab .


Parts of the screen are updated, either because of changes in geometric properties of a node or because of stylistic change .


The part of the render tree is updated due to changes in geometric properties or styles (such as color , background , etc.) is called repaint or redraw .


Both Repaint & Reflow have a lot to do with the user experience and application performance . We’ll go over some common situations that can cause Reflow, Repain to be limited at best nhé

What triggers?

Any change to the input information used to build the render tree can cause this Reflow/Repaint :

  • Add, delete, update a DOM node .
  • Hide the DOM node with display: none ( reflow and repaint ) or visibility: hidden (ONLY repaint )
  • Move, do animations with a DOM node .
  • Add stylesheet , adjust the values ​​of style properties .
  • Some of the user actions ( resize , scrolling , etc.)


Let’s take a quick look at some examples below:

How to minimize?

Once we understand why the reflow/repaint process takes place, we have a number of ways to reduce the negative effects from reflow/repaint in UX make it happen faster, the calculations are not too complicated.

Let’s list what they are:

  • Batching : This technique can be understood as simply grouping DOM read and write statements closely together, avoiding reading and writing DOM discrete, causing continuous reflow .
  • Reduce complexity of your selectors : Reducing the complexity of calling selectors will reduce the time required to pair and rebuild the style structure .
  • DOM Depth: The update a DOM node will lead to update all of the DOM node con , which means that the all of the DOM is update will have to be recalculated. If our DOM is too deep, it means that the calculation will become more complicated.

Above I just listed a few suggestions to minimize reflow/repaint . To find out more interesting solutions, you can read more on Google Developer or in the article Limiting reflow on the browser with super-specific examples.


Yayyy …

So we just learned together about the rendering process as well as repaint/ relayout of the browser already. I hope this article has been helpful to you guys ^^

Thank you for reading this post. Give me 1 upvote to have more motivation for the upcoming article nhé

By the way, come over to my house to play a bit and then return ^^

Have a nice weekend !


References: Phpied , Mr. ThinhDora , My Blog .

Share the news now

Source : Viblo