[Dry goods] Ten minutes to understand the browser rendering process, dry goods to understand
In the previous article "Step 8 of tianlong", I described what happened after the browser entered the URL, I shared with you the whole process from entering the URL in the browser to displaying the final page. Some readers have reported to me that the final layout of browser rendering is not very clear. Therefore, this article will explain the browser rendering process separately. I hope everyone will have a new harvest.
Main browser component structure
(Main browser components)
Rendering Engine-webkit and Gecko
Firefox uses the rendering engine developed by Geoko-Mozilla.
Both Safari and Chrome use webkit. Webkit is an open-source rendering engine developed for the linux platform. Later, it was transplanted from Apple to Mac and Windows.
In this article, I mainly use the webkit rendering engine. Although the terms used by webkit and Gecko are slightly different, their main processes are basically the same.
(Webkit rendering engine process)
Key rendering path
The key rendering path refers to the HTML, CSS, javascript and other resources that the browser receives from the initial request, and then parses, constructs the tree, renders the layout, and draws, finally, the whole process is presented to the interface that the customer can see.
Therefore, the rendering process of the browser mainly includes the following steps:
Build a DOM tree
After the browser receives the HTML document from the server, it traverses the document node to generate a DOM tree.
It should be noted that the DOM tree may be blocked by the loading and execution of CSS and JS. The rendering blocking problem is described below.
Build a CSSOM rule tree
The browser parses the CSS file and generates the CSS rule tree. Each CSS file is analyzed into a StyleSheet object, and each object contains CSS rules. The CSS rule object contains the selector and declaration object corresponding to the CSS syntax and other objects.
Rendering Blocking
When the browser encounters a script tag, the DOM build is paused until the script is executed and the DOM is built. Every time a JavaScript script is executed, the construction of the DOM tree will be severely blocked. If the JavaScript script still operates CSSOM, but this CSSOM has not been downloaded or constructed yet, the browser may even delay script execution and DOM construction until the download and construction of its CSSOM is completed.
Therefore, the position of the script tag is very important. In actual use, you can follow the following two principles:
CSS priority: In the order of introduction, CSS resources are prior to JavaScript resources.
JS: We usually place JavaScript code at the bottom of the page, and JavaScript should affect DOM construction as little as possible.
When parsing html, the system inserts new elements into the dom tree, searches for css, and applies the corresponding style rules to the elements, the style sheets are matched from right to left.
For example, div p {font-size: 16px} looks for all p labels and determines whether its parent label is div before rendering with this style ).
Therefore, when writing CSS, we should try to use the id and class, And do not overwrite them.
Build a rendering tree
Using the DOM tree and CSS rule tree, we can build a rendering tree. The browser first traverses each visible node from the root node of the DOM tree. Find and apply the CSS style rules for each visible node.
After the rendering tree is built, each node is a visible node and contains its content and corresponding rule styles. This is the biggest difference between a rendering tree and a DOM tree. The rendering tree is used for display. Invisible elements will not appear in the tree, for example. In addition, the elements whose display is equal to none are not displayed in this tree, but those whose visibility is equal to Den den are displayed in this tree.
Rendering tree layout
The layout stage will traverse from the root node of the rendering tree, and then determine the exact size and position of each node object on the page. The output of the layout stage is a box model, it precisely captures the exact position and size of each element on the screen.
Rendering tree
In the rendering phase, traverse the rendering tree and call the paint () method of the Renderer to display its content on the screen. The rendering tree is drawn by the UI backend components of the browser.
Reflow and repaint:
Calculate the CSS style based on the rendering tree layout, that is, the geometric information such as the size and position of each node on the page. HTML is a stream layout by default. CSS and js will break this layout and change the DOM's appearance style, size, and position. Two important concepts are mentioned: replaint and reflow.
Replaint: redraws a part of the screen without affecting the overall layout. For example, the background color of a CSS is changed, but the element's geometric size and position remain unchanged.
Reflow: it means that the geometric size of the component has changed. We need to re-verify and calculate the rendering tree. Is a part or whole of the rendering tree changed. This is Reflow or Layout.
Therefore, we should try to reduce reflow and replaint as much as possible. I think this is one of the reasons why table layout is rarely useful.
Display: none triggers reflow. The visibility: hidden attribute is not an invisible attribute. Its semantics is a hidden element, but the element still occupies the layout space and is rendered into an empty box, therefore, visibility: hidden only triggers repaint, because there is no location change.
In some cases, for example, if the style of an element is modified, the browser does not immediately reflow or repaint once. Instead, it accumulates such operations and then performs a reflow, this is also called asynchronous reflow or incremental asynchronous reflow.
In some cases, for example, the resize window changes the default font of the page. For these operations, the browser will immediately reflow.
Summary
In this article, we have learned about the browser rendering process step by step. I believe everyone will have some new gains. If you have any questions about the browser rendering process, please feel free to contact us, learn and make progress together.
Author: GavinHsueh, QQ/: 753391279, focusing on website construction, O & M, and Enterprise web application development technologies.
For more technical articles and interactions, please follow the public account:
References:
Http://taligarsiel.com/Projects/howbrowserswork1.htm
Https://segmentfault.com/a/1190000012960187
Https://sylvanassun.github.io/2017/10/03/2017-10-03-BrowserCriticalRenderingPath/
Https://www.zybuluo.com/lizlalala/note/435042