Web pages in the browser rendering process

Recently in learning performance optimization, learning the Yahoo military , but feel a bit foggy, because there are some things although they have been in use, but do not understand the reason why, such as the reduction of DNS query, CSS and JS file order. So it took time to understand the work of the browser, there is a classic article "How Browsers Works" , is very detailed, also has a Chinese translation . But the article is a little too long, also told a bunch of things, or to summarize their own.

Why should I understand the process of browser loading, parsing, rendering?

Well, let's talk first, why do we need to know this? If you want to write a best practice page, you need to know it well.

• Understand how the browser load, you can reference external style files, external JS, put them in the appropriate location, so that the browser to the fastest speed to load the file.
• To understand how the browser parses, you can build the DOM structure, organize CSS selectors, choose the best way to improve the resolution rate of the browser.
• Understand how the browser renders, understand the process of rendering, in setting element properties, writing JS file, you can reduce the "reflow" "repaint" consumption.

Body Start

First, the main function of the browser

　　 main features of the browseris to render a user-selected web resource, which needs to request resources from the server and display it in a browser window, with the format of the resource typically HTML, including PDFs, image, and other formats. The user uses the URI (Uniform Resource identifier Uniform Resource Identifier) to specify the location of the requested resource and, through DNS queries, translates the URL into an IP address. The entire browser work flow, previously discussed in the blog:
1, enter the URL.
2. The browser finds the IP address of the domain name.
3. The browser sends an HTTP request to the Web server
4. Permanent redirect Response for Web services
5. Browser tracking redirect address now, the browser knows the correct address to access, so it sends another fetch request.
6. The server "processes" the request, the server receives the fetch request, and then processes and returns a response.
7. The server sends back an HTML response
8. The browser starts to display HTML
9. The browser sends the request to get the object embedded in the HTML. When the browser displays HTML, it will notice the need to get a label for other address content. At this point, the browser sends a FETCH request to retrieve the files. These files include resources such as css/js/pictures, where the addresses of these resources go through a similar process to HTML reading. So the browser will find these domain names in DNS, send requests, redirect, etc. ..

So, how does a page, exactly, enter a URL from us to the last complete presentation in front of us? Also need to know how the browser is rendered:

Second, the browser rendering

Here is the basic flow of the rendering engine after it obtains the content:

Parse HTML to build a DOM tree, build a render tree, layout render tree, draw a render tree

Let's take a look at the diagram:

So, the browser will parse three things:
(1) html/svg/xhtml, parsing these three kinds of files will produce a DOM Tree.
(2) CSS , parsing CSS will produce a CSS rule tree.
(3) JavaScript scripts, mainly through the DOM API and the CSSOM API, manipulate DOM tree and CSS Rule tree.

Today I have a tangled morning, in the end how to parse how to render, my question is, the browser is to parse the first generation of the DOM tree, and then load the CSS JS file for rendering, or in the process of generating the DOM, encountered the link script and then loaded CSS JS, side loading side rendering. The reason why I have this question is that, look at the online post, said is not the same good! For example, this article I want to say, this write let me directly ignorant force, really is directly ignorant force ah, the process of learning, always encounter difficulties, but this time, let me really very difficult ah. But I'm just going to keep looking for information because I don't understand. ==! I've been checking my test test for a whole morning, and then I feel like I'm getting the point. Really recommend everyone to seriously see "How browsers work" This article, learning does not know the knowledge of the time, or from the more authoritative information look better, do not like me today, no head flies disorderly search.

Then the process of one, I am in accordance with their own understanding, if wrong, please correct me.

When the browser obtains an HTML file, it “自上而下” loads and parses the rendering during the load process.
Parsing:
1. The browser parses the HTML into a DOM tree, and the construction of the DOM tree is a deep traversal process: All the child nodes of the current node are built before the next sibling node of the current node is built.
2. Parse the CSS into CSS Rule Tree.
3. Construct Rendering tree based on dom trees and Cssom. Note: The Rendering tree is not the same as the DOM tree, because something like a Header or display:none doesn't have to be placed in the render tree.

4. With the render Tree, the browser can already know which nodes are in the Web page, the CSS definitions for each node, and their dependencies. The next step, called Layout, is to calculate the position of each node in the screen as the name implies.
5. The next step is to draw, which is to traverse the render tree and draw each node using the UI back-end layer.

Here's the point:

The process above is that 逐步完成 , for a better user experience, the rendering engine will render the content to the screen as early as possible, and will not wait until all the HTML has been resolved before building and laying out the render tree. It shows part of the content as part of parsing, and may also be downloading the rest of the content over the network. (This passage is said in "How browsers work", let me Enlightened)

Several concepts:
(1) Reflow (reflow): The browser takes time to render, and when it finds that a part has changed and affects the layout, it needs to go back and render again.
(2) Repaint (redraw): If you just change the background color of an element, text color, etc., does not affect the elements around or the internal layout of the properties, will only cause the browser Repaint, redraw a part.
Reflow takes more time than repaint, and it also affects performance. So when writing code, try to avoid too much reflow.

reasons for Reflow:

(1) When the page is initialized;
(2) when manipulating the DOM;
(3) The dimensions of some elements have changed;
(4) If the properties of the CSS have changed.

Reduce Reflow/repaint

(1) Do not modify the DOM style one by one. Instead, you might as well pre-define the CSS class and then modify the DOM's className.
(2) Do not place the attribute value of the DOM node in a loop as a variable in the loop.
(3) for animated HTML components using fixed or absoult position, then modifying their CSS is not reflow.
(4) Never use table layout. Because a small minor change can cause the entire table to be re-laid.

I should have been all over the Internet on the browser load parsing rendering process of the article all read, which wrote a better version is the following:

HTML page loading and parsing process
1. The user enters the URL (assuming it is an HTML page, and is the first access), the browser makes a request to the server, the server returns the HTML file;
2. The browser starts loading the HTML code and discovers that there is a <link> tag in the &NBSP;
3. The browser also sends out the CSS file request, the server returns this CSS file; &NBSP;
4. The browser continues to load the HTML section of the code, and the CSS file has been handed, you can start rendering the page; &NBSP;
5. The browser finds a tag in the code that refers to a picture that makes a request to the server. At this point the browser will not wait until the picture is finished downloading, but continue to render the following code; &NBSP;
6. The server returns the picture file, because the picture occupies a certain area, affects the arrangement of the later paragraph, So the browser needs to go back and re-render this part of the code; &NBSP;
7. The browser discovers a

other considerations related to the topic of discussion you should note that when you write CSS:

CSS selectors are matched from right to left. From right to left! So, #nav Li we think this is a very simple rule, seconds can match to the desired element, but, however, is from right to left to match ah, so, will go to find all Li, and then to determine whether its parent element is not #nav. , therefore, you need to note when writing CSS:

1. Dom depth is as shallow as possible.
2. Reduce the number of inline JavaScript and CSS.
3. Use modern, legitimate CSS properties.
4. Do not specify the class name or label for the ID selector because the ID can uniquely identify an element.
5. Avoid descendant selectors and use sub-selectors as much as possible. Cause: The probability of a child-element match is greater than the descendant-element-match character. Descendant selector, #tp p{} sub-selector: #tp >p{}
6. Avoid using wildcards, for example,. mod. HD *{font-size:14px;} depending on the matching order, wildcards are first matched, that is, wildcard characters are matched first, and then matched. HD (that is, to traverse all the nodes on the DOM tree for his parent element), and then match. MoD, This performance cost is conceivable.

about the location of the script tag

now, most of us will put the script tag before the body end tag, so what's the reason? I did a test today, too.

<! DOCTYPE html><Html><Head><Metacharset="Utf-8" ><Title> Test JS Code location</Title><ScriptType= "Text/javascript" > var item = document.getElementById ( "item"); Cosole.log (item); </script></ head><body> <div id=  "item" width= "100px" height=" 100px "> Hello </ div></body> </HTML>         

There is a JS code in the above code, to print an element in the console, I put the script tag in the head, the console print is null.

I also put the JS code before the body end tag, the print is the DIV element

So, with this simple example, we can see that the JS code is executed immediately after loading.
I did another test, wrote a dead loop in the JS code, put it in the head tag,

<! DOCTYPE html><Html><Head><Metacharset="Utf-8" ><Title> Test JS Code location</Title><ScriptType="Text/javascript" > var item = document.getElementById ( "item"); while (true) {console.log (1); Span class= "Hljs-tag" ></script> </ head><body> <div id=  "item" width= "100px" height=" 100px "> Hello </ div> </body> </HTML>         

The page is like this:

has been performing that print 1 of the Dead Loop, the back of the body is not loaded rendering out. So, for this small example, we can see that the download and execution of JS blocks the construction of the DOM tree.

So, the features of JavaScript loading and execution:
(1) Execute immediately upon loading;
(2) execution will block the subsequent content of the page (including rendering of the page, download of other resources). Reason: Because the browser needs a stable DOM tree structure, and JS is likely to have code directly changed the DOM tree structure, such as using document.write or appendchild, Even the direct use of the location.href to jump, the browser in order to prevent the occurrence of JS modified DOM tree, the need to rebuild the DOM tree, so it will block the other download and rendering.

ways to reduce the impact of JavaScript on performance:

1. Putting all the script tags at the bottom of the page, which is the body closing tag, ensures that the DOM tree rendering is done before the script executes.
2. Merge the scripts as much as you can. The fewer script tags in the page, the faster the load and the quicker the response. This is true for both the outer-chain script and the inline script.
3. A way to download JavaScript scripts without blocking:
   (1) Use the defer attribute of the script tag (only for IE and Firefox 3.5 or later);
   (2) Use the dynamically created script element to download and execute the code;

Web pages in the browser rendering process