【 Dry stuff 】 Ten minutes to read the browser rendering process

In an article I wrote earlier, I shared with you the entire process from entering a URL into a browser to displaying the final page. Some readers have told me that the final browser rendering layout is not very clear, so this article will start with a separate browser rendering process, I hope you can learn something new.

Structure of major browser components

(Major browser components)

Rendering engines – WebKit and Gecko

Firefox uses Geoko, Mozilla’s own rendering engine.

Safari and Chrome both use WebKit. Webkit is an open source rendering engine that was originally developed for Linux and later ported by Apple to Mac and Windows.

I’ll focus on the WebKit rendering engine in this article, and although webKit and Gecko use slightly different terminology, their main flow is basically the same.

(WebKit Rendering engine flow)

Key render path

The key render path is the process by which the browser receives the requested HTML, CSS, javascript and other resources, parses, builds the tree, renders the layout, draws, and finally presents the interface to the customer.

So the browser rendering process mainly includes the following steps:

Parsing the HTML generates a DOM tree.
Parsing CSS generates a CSSOM rule tree.
Combine the DOM tree with the CSSOM rule tree to generate the render tree.
Traverse the render tree to start the layout, calculating the location size information for each node.
Draws each node of the render tree to the screen.

Build a DOM tree

When the browser receives the HTML document from the server, it traverses the document nodes to generate a DOM tree.

It is important to note that the DOM tree generation process may be blocked by CSS and JS load execution. Rendering blocking is covered below.

Build the CSSOM rule tree

The browser parses the CSS file and generates a CSS rule tree. Each CSS file is parsed into a StyleSheet object, and each object contains the CSS rule. CSS rule objects contain selectors and declaration objects corresponding to CSS syntax, as well as other objects.

Render block

When the browser encounters a script tag, DOM building is paused until the script completes execution, and then DOM building continues. Each time the JavaScript script is executed, it will severely block the DOM tree construction. If the JavaScript script also operates on a CSSOM that has not been downloaded and built, the browser will even delay the script execution and DOM construction until the CSSOM has been downloaded and built.

Therefore, the position of the script tag is important. In practice, the following two principles can be followed:

CSS priority: CSS resources are introduced before JavaScript resources. JS behind: We usually put JS code at the bottom of the page, and JavaScript should affect DOM construction as little as possible.

When parsing HTML, new elements are inserted into the DOM tree, CSS is searched, and the style rules are applied to the elements. The search style sheets are matched from right to left.

For example, div p {font-size: 16px} will look for all p tags and determine whether the parent tag is div before deciding whether to render in this style. So, when we write CSS, try to use ID and class, do not cascade.

Building a Render tree

From DOM trees and CSS rule trees we can build render trees. The browser iterates through each visible node starting at the root of the DOM tree. For each visible node, find the appropriate CSS style rule and apply it.

After the rendering tree is built, each node is visible and has its content and the style of the corresponding rule. This is the biggest difference between a render tree and a DOM tree. Render trees are used for display, so invisible elements are not present in the tree, for example. Otherwise, elements whose display equals none will not be displayed in the tree, but elements whose visibility equals hidden will be displayed in the tree.

Render tree layout

The layout phase starts at the root node of the render tree and determines the exact size and position of each node object on the page. The output of the layout phase is a box model that captures the exact position and size of each element on the screen.

Render tree rendering

In the paint phase, the render tree is traversed, calling the renderer’s paint() method to display its contents on the screen. The rendering tree is done by the browser’s UI back-end component.

Reflow and repaint:

Based on the render tree layout, compute CSS styles, which are geometric information such as the size and position of each node in the page. HTML has a streaming layout by default, and CSS and JS break this layout by changing the look and feel of the DOM as well as its size and position. Two important concepts come up here: replaint and reflow. Replaint: Part of the screen is redrawn without affecting the overall layout, e.g. the background color of a CSS is changed, but the geometry and position of elements remain the same. Reflow: means that the geometry of the component has changed and we need to revalidate and evaluate the render tree. Part or all of the render tree has changed. That’s a Reflow, or Layout. Reflow and Replaint should be kept to a minimum, which I think is one of the reasons why table layouts are rarely used today.

Display: None triggers reflow, visibility: The hidden property is not an invisible property, its semantics are to hide the element, but the element still occupies the layout space and will be rendered as an empty box, so visibility: Hidden will only trigger repaint because no position change has taken place.

In some cases, such as changing the style of an element, the browser does not reflow or repaint once immediately. Instead, the browser will accumulate a batch of such operations and do a reflow. This is also called asynchronous or incremental asynchronous reflow. In some cases, such as the resize window, the default font of the page is changed. For these operations, the browser reflow immediately.

summary

In this paper, we gradually understand the browser rendering process again, I believe that we must have new harvest, if you have any questions about the browser rendering process, welcome feedback, we communicate together, learn together, common progress.

References:

Taligarsiel.com/Projects/ho…

Segmentfault.com/a/119000001…

Sylvanassun. Making. IO / 2017/10/03 /…