Detailed explanation of the process of browser parsing and rendering HTML documents (picture and text)

This article brings you a detailed explanation (pictures and texts) of the process of browser parsing and rendering of HTML documents. It has certain reference value. Friends in need can refer to it. I hope it will be helpful to you.

The working principle of the browser

1. The high-level structure of the browser

The main components of the browser are:

1. User interface - including address bar, forward /back button, bookmark menu, etc. Apart from the display of the page you requested in the main browser window, every other portion of the display belongs to the user interface.

2. Browser engine - transmits instructions between the user interface and the rendering engine.

3. Presentation engine - Responsible for displaying the requested content. If the requested content is HTML, it is responsible for parsing the HTML and CSS content and displaying the parsed content on the screen.

4. Network - used for network calls, such as HTTP requests. Its interface is platform-independent and provides underlying implementation for all platforms.

5. User interface backend - used to draw basic widgets, such as combo boxes and windows. It exposes a platform-independent common interface, while using the operating system's user interface methods under the hood.

6. JavaScript interpreter. Used to parse and execute JavaScript code.

7. Data storage. This is the persistence layer. The browser needs to save various data on the hard drive, such as cookies. The new HTML specification (HTML5) defines a "web database", a complete (but lightweight) in-browser database.

It is worth noting that, unlike most browsers, each tab of the Chrome browser corresponds to a rendering engine instance. Each tab is an independent process.

2. Main process

The rendering engine will initially obtain the content of the requested document from the network layer. The size of the content is generally limited to 8000 blocks.

Then the basic process is as follows:

#The rendering engine will start to parse the HTML document and convert each tag one by one into the "content tree" DOM node. Style data in external CSS files and style elements is also parsed. This style information with visual instructions in HTML will be used to create another tree structure: the rendering tree.

The rendering tree contains multiple rectangles with visual properties such as color and size. The order in which these rectangles are arranged is the order in which they will appear on the screen.

After the presentation tree is constructed, the "layout" processing stage is entered, which is to assign each node an exact coordinate where it should appear on the screen. The next stage is drawing - the rendering engine traverses the rendering tree and the user interface backend layer draws each node.

It should be emphasized that this is a gradual process. To achieve a better user experience, the rendering engine will strive to display content on the screen as quickly as possible. It doesn't have to wait until the entire HTML document is parsed before it starts building the rendering tree and setting up the layout. While continuously receiving and processing the rest of the content from the network, the rendering engine will parse and display part of the content.

Main process example:

3. The order of processing scripts and style sheets

1. Script

The model of the network is synchronous. The web page author wants the parser to immediately parse and execute the script when it encounters the <script> tag. Parsing of the document will stop until the script completes execution. If the script is external, the parsing process will stop until the resource is fetched synchronously from the network and then continue. This model has been used for many years and is also specified in the HTML4 and HTML5 specifications. Authors can also mark the script as "defer" so that it does not stop document parsing but waits until parsing is complete before executing. HTML5 adds an option to mark scripts as asynchronous so that they can be parsed and executed by other threads. </script>

2. Pre-parsing

Both WebKit and Firefox have performed this optimization. While the script is executing, other threads parse the rest of the document to find and load additional resources that need to be loaded over the network. This way, resources can be loaded on parallel connections, increasing overall speed. Please note that the preparser does not modify the DOM tree, but leaves this work to the main parser; the preparser will only parse references to external resources (such as external scripts, style sheets, and images).

3. Style sheet

Style sheets, on the other hand, have a different model. In theory, applying a stylesheet does not change the DOM tree, so there seems to be no need to wait for the stylesheet and stop document parsing. But this involves a problem, that is, the script will request style information during the document parsing stage. If the styles haven't been loaded and parsed at that time, the script will get an incorrect response, which obviously creates a lot of problems. This may seem like an atypical case, but it's actually very common. Firefox disables all scripts during the loading and parsing process of style sheets. WebKit, on the other hand, only blocks a script if it tries to access a style property that might be affected by a style sheet that hasn't been loaded yet.

4. Presentation tree construction

While the DOM tree is being constructed, the browser will also build another tree structure: the presentation tree. This is a tree of visual elements in the order in which they appear, and is a visual representation of the document. What it does is allow you to draw things in the correct order.

Firefox calls elements in the rendering tree "frames". The term WebKit uses is renderer or rendering object.
The renderer knows how to lay out and draw itself and its child elements.

4. Layout

When the renderer is created and added to the rendering tree, it does not contain position and size information. The process of calculating these values ​​is called layout or rearrangement.

HTML uses a flow-based layout model, which means that in most cases geometric information can be calculated in only one pass. Elements later in the flow generally do not affect the geometry of elements earlier in the flow, so the layout can traverse the document from left to right and top to bottom. But there are exceptions, such as HTML table calculations that require more than one pass.

The coordinate system is established relative to the root frame, using upper and left coordinates.

Layout is a recursive process. It starts at the root renderer (corresponding to the element of the HTML document) and then recursively traverses some or all of the frame hierarchy, calculating geometry information for each renderer that needs to be calculated.

The root renderer's position is 0,0 on the left, and its size is the viewport (that is, the visible area of ​​the browser window).
All renderers have a "layout" or "reflow" method, and each renderer will call the layout method of its descendants that need to be laid out.

5. Drawing

In the drawing phase, the system will traverse the rendering tree and call the "paint" method of the renderer to display the content of the renderer on the screen. . The drawing work is done using the basic components of the user interface.

Summary of personal understanding

1. Parser and pre-parsing mechanism

The presentation engine obtains the content of the requested document from the network layer, and then starts parsing the HTML document, and convert each tag one by one into DOM nodes on the DOM tree (content tree), and also parse the style data in external CSS files and style elements. These style information with visual instructions in HTML will be used to create another tree structure: Rendering Tree (rendering tree) . After the rendering tree is built, the rendering engine will lay out and draw the rendering tree.

The parsing of the rendering engine includes HTML parsing and CSS parsing. The output "parse tree" of the HTML parser is a tree structure composed of DOM elements and attribute nodes. DOM is the Document Object Model ( Abbreviation for Document Object Model). It is an object representation of an HTML document and an interface between external content (such as JavaScript) and HTML elements. The root node of the parse tree is the "Document" object. The CSS parser parses the style data in CSS style files and style elements into a CSS rule tree, and the browser combines the CSS rule tree and the DOM tree to generate a rendering tree.

JavaScript Interpreter Used to parse and execute JavaScript code.

Generally speaking, we think that the browser receives the HTML document content from the network layer, and then starts to parse the document to generate a DOM tree. When it encounters CSS style sheet tags or JS script tags, it starts a new thread to download them, and Continue to build the DOM tree, the browser builds the rendering tree based on the DOM tree, and finally the browser draws the rendering book to the user interface.

In the above description, it is important to point out that the parsing and rendering of HTML documents is a gradual process. In order to achieve a better user experience, the rendering engine will strive to display content on the screen as quickly as possible. It doesn't have to wait until the entire HTML document is parsed before it starts building the rendering tree and setting up the layout. The rendering engine parses and displays portions of the content while it continues to receive and process the rest of the content from the network.

Browser pre-parsing. Both WebKit and Firefox implement this optimization. While the script is executing, other threads parse the rest of the HTML document, identifying and loading additional resources that need to be loaded over the network. This way, resources can be loaded on parallel connections, increasing overall speed. Note that the preparser does not modify the DOM tree, leaving this work to the main parser; the preparser only parses references to external resources (such as external scripts, stylesheets, and images).

The browser's pre-parsing can alleviate the situation where rendering is blocked. For example, the preloader finds the <script src="last.js"></script> tag during document parsing. , the last.js file will be loaded and placed in the browser cache, so that when the parser encounters this <script> tag, since the preloader has already loaded the last.js file, last.js will It is executed immediately, without waiting for resources to be fetched from the network, which slows down the blocking of rendering. </script>

2. CSS and JS processing sequence and blocking analysis

During the parsing and rendering process of HTML documents, external style sheets and scripts are executed sequentially and loaded concurrently.

JS scripts will block the parsing of HTML documents, including the construction of the DOM tree and the construction of the rendering tree; the CSS style sheet will block the construction of the rendering tree, but the DOM tree will still continue to be constructed (unless the script tag is encountered and the css The file has not been loaded yet), but it will not be rendered and drawn on the page.

During the parsing process of the HTML document, when the parser encounters the <script> tag, it will immediately parse and execute the script. The parsing of the HTML document will be blocked until the script is executed. If the script is external, the parsing process will stop until the resource is fetched from the network and parsed and executed, and then the subsequent content will be parsed. </script>

Theoretically, applying a stylesheet does not change the DOM tree, so there seems to be no need to wait for the stylesheet and stop document parsing. But this involves a problem, that is, the script will request style information during the document parsing stage. If the styles haven't been loaded and parsed at that time, the script will get an incorrect response, which obviously creates a lot of problems. This may seem like an atypical case, but it's actually very common. Firefox disables all scripts during the loading and parsing process of style sheets. WebKit, on the other hand, only blocks a script if it tries to access a style property that might be affected by a style sheet that hasn't been loaded yet.

But no matter which situation causes the blocking, the external resources that should be loaded will still be loaded, such as external scripts, style sheets and pictures. Parsing of HTML documents may be blocked, but loading of external resources is not.

CSS The loading of external style sheets will block the execution of external scripts, but it will not block the loading of external scripts. This can be verified through Network - Waterfall in the chrome debugging tool, but it should be noted that chrome's maximum number of concurrent connections (same domain name) is 6.

As you can see from the above two screenshots, the jquery.min.js script file is loaded in parallel with style files such as bootstrap.css. However, since Chrome has an upper limit of 6 concurrent connections, the loading of bootstrap.min.js scripts, xxx.css styles and other files will wait until the previous files are loaded and will not start loading until there are available connections.

After understanding the above information, we can optimize the page accordingly, such as compressing CSS files, using CDN, distributing resources under multiple domain names, and merging them CSS files, reduce the number of HTTP requests, etc. to improve the loading speed of CSS and reduce the blocking time of HTML document parsing and rendering.

browser only allows six TCP connections per origin on HTTP 1.

The browser's limit on the number of concurrent requests is for the same domain name. Therefore, CDN acceleration technology can be used to improve the response speed of users accessing the website, so that resource loading using CDN will not occupy the number of concurrent connections under the current domain name, thereby reducing blocking time.

Web page performance

Understanding the process of parsing and rendering HTML documents is of great significance to analyzing web page performance. It can help us find the key factors that affect web page performance. For example, we know that the execution of JS external scripts will block the parsing of documents, and heavyweight third-party plug-ins will affect the loading speed of the homepage. If this affects the user experience, we need to consider whether the cost of using this third-party plug-in is It is too high. Can other lightweight plug-ins be used instead, or only some of the modules can be used.

Take Datatables as an example:

The above picture is a Network screenshot of a project page. The part in the red box is blank for about 700ms. We You need to know why the page is loading like this. What is the browser doing during this blank time?

We analyze the Timeline graph to see the specific information of the browser during this period, as follows:

We can see from the Timeline chart that within the time interval of 250ms~900ms, the browser is executing the datatables.min.js script code. The execution of this script blocks the parsing of the document. It takes about 700ms, which corresponds to the blank space in the Network diagram.

We continue to look at the total time it takes to complete the page and evaluate the impact of 700ms, as follows:

As you can see, the total time it takes to complete the page It is 1.66s. It can be seen that the execution time of datatables.min.js accounts for a large proportion. You should carefully consider whether you must use this plug-in, whether you can use other lightweight plug-ins to replace it, or whether you can streamline the plug-in. Unnecessary modules, or abandon the use of plug-ins.

Reference Materials-1
The browser receives the HTML code, which may be a complete document or a chunk, and begins parsing. The parsing process is to first build the DOM tree, then build the rendering tree based on the DOM tree, and finally the browser draws the rendering tree onto the page.
The process of building a dom tree is to build it from top to bottom based on the html code. When a script file is loaded/executed, it will block the subsequent dom tree construction (javascript may change the dom tree), and when a css file is encountered, it will Blocks the construction of the rendering tree, that is, the DOM tree continues to be constructed (unless a script tag is encountered and the CSS file is still not loaded), but it will not be rendered and drawn on the page. No matter which one is blocked, the loaded file will still be loaded, such as other css/js/image files in the html document.
In addition, javascript will be executed after it is loaded, and the execution process also blocks the construction of the tree. Other content is parsed after execution is completed, rather than loading other content after execution.

Author: Jiabing
Link: https://www.zhihu.com/questio...

References-2
First of all, Open source browsers generally download html pages at 8k per chunk.
Then parse the page to generate a DOM tree. When encountering css tags or JS script tags, start a new thread to download them and continue to build the DOM.
After downloading, the CSS is parsed into a CSS rule tree, and the browser combines the CSS rule tree and the DOM tree to generate a Render Tree.
Note: Building CSS Object Model (CSSOM) will block the execution of JavaScript. The execution of JavaScript will also block the construction of the DOM.
After downloading JavaScript, you can modify the DOM through the DOM API and modify the style scope Render Tree through the CSSOM API.
Each modification will cause the Render Tree to be re-layout and re-drawn. As long as the DOM is modified or the shape or size of the element is modified, Reflow will be triggered. Simply modifying the color of the element only requires Repaint (calling the API of the operating system Native GUI to draw).

Author: Chen Jin
Link: https://www.zhihu.com/questio...

This article has ended here, there are more exciting things For content, you can pay attention to the JavaScript Video Tutorial column on the PHP Chinese website!

The above is the detailed content of Detailed explanation of the process of browser parsing and rendering HTML documents (picture and text). For more information, please follow other related articles on the PHP Chinese website!