Hacking Book | Free Online Hacking Learning


brief introduction to the rendering principle of browser

Posted by graebner at 2020-04-13

When you see this title, you will surely think of the divine article "how browsers work". This article talks about many details of the browser in detail, and it has also been translated into Chinese. Why do I want to write another one? For two reasons,

1) This article is too long and too expensive to read at one go.

2) You can learn a lot after reading this article with great effort, but it seems to be of little help to your work.

So, I am going to write this article to solve these two problems. I hope you can read it on your way to work or in the toilet, and learn something that can be used in your work.

Browser workflow

Let's cut the crap and take a look at the picture:

From the above figure, we can see the following:

1) The browser parses three things:

2) After parsing, the browser engine will construct rendering tree through DOM tree and CSS rule tree. Be careful:

3) At last, we call the API of native GUI to draw.

DOM analysis

The DOM tree of HTML is parsed as follows:

The above HTML will be parsed as follows:

Here is another case with SVG tags.

CSS analysis

The parsing of CSS looks like the following (gecko is the way of Firefox). Suppose we have the following HTML documents:

So DOM tree looks like this:

Then our CSS document is as follows:

So our CSS rule tree will look like this:

Note that the fourth rule in the figure appears two times, one independent and one at the child node of rule 3. Therefore, we can know that the establishment of CSS rule tree is based on DOM tree. CSS matching DOM tree is mainly to parse CSS selectors from right to left. Many people think it will be faster, but it is not necessarily. The key also depends on how our CSS selector is written.

Note: CSS matching HTML elements is a fairly complex and performance issue. So, you will see a lot of people tell you that DOM tree should be small, CSS should use ID and class as much as possible, don't stack them in a transitional way

Through these two trees, we can get a style context tree, which is as follows (attach the CSS rule node to the DOM tree):

Therefore, Firefox basically generates CSS rule tree through CSS parsing, then generates style context tree by comparing DOM, and then Firefox completes by associating style context tree with its render tree (frame tree). Note: render tree will remove some invisible nodes. The so-called frame in Firefox is a DOM node. Don't be confused by its name.

Note: unlike Firefox, WebKit uses two trees to do this. WebKit also has a style object, which directly stores the style object in the corresponding DOM node.


The rendering process is basically as follows (four steps in yellow):

Note: there are many connecting lines in the above process, which means that JavaScript dynamically modifies the DOM property or CSS property, which will lead to a new layout. Some changes will not, that is, the arrows pointing to the sky, such as the modified CSS rule is not matched, etc.

Here are two important concepts: reflow and retain. These two are not the same thing.

Here is a video of layout / reflow when opening Wikipedia (Note: HTML will also do reflow once during initialization, which is called internal reflow). You can feel it:

The cost of reflow is much higher than that of repaint. Every node in DOM tree will have reflow method. Reflow of a node may lead to reflow of child nodes, even parent nodes and peers. On some high-performance computers, it may not be much, but if reflow happens on mobile phones, the process is very painful and power consuming.

Therefore, the following actions are likely to be more expensive.

Note: display: none will trigger reflow, while visibility: hidden will only trigger retain, because no location change is found.

Say two more sentences about scrolling. Generally speaking, if all the pixels on our page will scroll when scrolling, there is no problem in performance, because our video card is very fast for this algorithm of moving the full screen pixels up and down. But if you have a fixed background image, or some elements do not follow the scrolling, and some elements are animations, the scrolling action will be quite a painful process for the browser. You can see how bad many of these pages are when scrolling. Because scrolling can also cause reflow.

Basically, reflow has the following reasons:

OK, let's take an example:

Of course, our browser is smart. It will not reflow or retain every time you change the style as above. Generally speaking, the browser will accumulate such operations and make a reflow, which is also called asynchronous reflow or incremental asynchronous reflow. But in some cases, the browser will not do so, such as: resize window, change the default font of the page, etc. For these operations, the browser will reflow immediately.

But sometimes, our script will prevent the browser from doing so. For example, if we request the following DOM values:

Because, if our program needs these values, then the browser needs to return the latest values, and this will flush out some style changes, resulting in frequent reflow / retain.

Reduce reflow / retain

Here are some best practices:

1) Don't change the DOM style one by one. Instead, it's better to predefine the class of CSS and then modify the classname of DOM.

2) Change DOM offline. Such as:

3) Do not put the attribute value of DOM node in a loop as a variable in the loop. Otherwise, it will lead to a large number of reading and writing properties of this node.

4) Modify the lower level DOM as much as possible. Of course, changing the DOM at the bottom of the hierarchy may cause a large area of reflow, but it may also have a small impact.

5) Using fixed or absault positions for animated HTML components, modifying their CSS will not reflow.

6) Never use a table layout. Because a small change may cause the whole table to be rearranged.

In this manner, the user agent can begin to lay out the table once the entire first row has been received. Cells in subsequent rows do not affect column widths. Any cell that has content that overflows uses the ‘overflow’ property to determine whether to clip the overflow content.

Fixed layout, CSS 2.1 Specification

This algorithm may be inefficient since it requires the user agent to have access to all the content in the table before determining the final layout and may demand more than one pass.

Automatic layout, CSS 2.1 Specification

Several tools and articles

Sometimes, you may find that under ie, you don't know what you have modified. As a result, the CPU goes up to 100% in a flash, and then it takes several seconds to recover / reflow. This kind of thing often happens in the age of IE. So, we need some tools to help us see if there is anything inappropriate in our code.

Finally, don't forget the following articles to improve browser performance:

Reference resources

Follow coolshell wechat public account and wechat applet

——===Visit cool shell 404 to find the missing child. = = = --