Understand the rendering process of HTML pages in preparation for learning front-end performance optimization (continued)

Last night I wrote an essay about the browser rendering process, but I only explained it through a small piece of code. It was not tested through a browser, so it was not convincing enough and there were still many imperfections. Today I tested it in the browser and shared the results with you. The test process may be a bit messy, and I hope you understand.

Tested browsers : Chrome v 24.0.1312.52 m, Firefox v18.0, Opera v12.12.

In the WebKit kernel, when a web page is displayed, there will be a parser to parse the HTML document, then generate a render tree, and finally render the page. This is done in one thread, so the two are not happening at the same time.

I divided it into two cases and tested them in different browsers.

The test results show that in Chrome, the location of the style file affects the download time of the image, while there is no difference between the two situations in the other two browsers. The following is the detailed testing process.

Test 1: The style file is in the head, and the other two script files are one at the beginning of the body and one at the bottom of the body.

Tested code:

After I opened the page in the browser, I quickly took a screenshot of the webpage, as shown below (click to view a larger image, the same below):

As can be seen from the above figure, the test.htm document has been loaded, nothing is displayed on the page yet, example.css is in the pending state, but last.js at the bottom has been loaded. This means that Chrome has preloaded, downloaded in advance, and placed it in the browser cache. Although last.js has been loaded, it has not been executed yet because the style file in front of it will block the execution of the script.

Next, when example.css is loaded, Hi there! is displayed on the screen. The browser screenshot is as follows :

It can be seen from the network request that example.css has been loaded and other.js is in the pending state, but the three pictures under the script tag have been downloaded at this time. This is due to the browser's pre-loading function. However, since the browser rendering is blocked by the other.js script, these three pictures and the "Hi again" on them will not be displayed. In addition, the code in last.js has not been executed at this time.

Next, when other.js is loaded, the browser will build the render tree, display "Hi again", and display the image. Since last.js has been downloaded previously, last.js will be executed immediately. The entire rendering process is completed. As shown in the following figure:

From this, we can see that Chrome will pre-load the script resources in the body (style files are not tested). The JS dynamically loaded by the JavaScript script will not affect the download of the image file, but it will affect the rendering of the image below it.

2. Test results in Firefox

After opening the page in Firefox, quickly take a screenshot as shown below:

This is obviously different from Chrome. "Hi there!" is displayed on the page, but the background color is white, indicating that the style file has not been downloaded yet. It will not be displayed in Chrome until the style file is loaded.

Next, when the entire page is loaded, the screenshot is as follows:

From the waterfall flow of the request, we can see that, similar to Chrome, the browser preloads last.js. Unlike Chrome, Firefox does not preload the image, but waits until other.js is loaded before loading it.

In Firefox, style files do not affect document rendering (the most typical phenomenon is that the webpage is displayed in a messy manner at first, without any style, but it displays normally after the style files are downloaded). In the body, the JS file dynamically loaded by JavaScript will block the download of the images behind it.

3. In Opera browser

After testing in Opera, it was found that the Opera browser is more "rules-abiding". All resources are loaded in sequence, and there is no so-called pre-loading. The following is a picture of the overall effect:

In Opera, style files will block page rendering, which is similar to Chrome. However, Opera's request waterfall flow shows that all resources on the page are loaded step by step, and other.js is loaded before last.js. No preloading.

Test 2: The style file is at the beginning of the body, and the location of the script file is the same as in Test 1.

 Copy code
 The code is as follows:

 <!doctype html>
 <html>
 <head>
 <title>Test Page</title>
 </head>
 <body>
 <link rel="stylesheet" type="text/css" href="example.aspx?sleep=3" />
 <div>
 Hi, there!

 <script type="text/javascript">
 document.write("<script src='other.aspx?sleep=5'></scr" + "ipt>");
 </script>

 <div>
 Hi, again!</div>
 <img src="images/marx.jpg" alt="Marx" />
 <img src="images/engels.jpg" alt="Engels" />
 <img src="images/Lenin.jpg" alt="Lenin" />

 <script src="last.aspx" type="text/javascript"></script>

 </body>
 </html>

 After testing, I found that in Firefox and Opera, the results were the same as in Test 1, but slightly different in Chrome. In Test 1, the image would not be downloaded until the style file in the head was loaded, but in Test 2, it would be downloaded in parallel with the style file, as shown below: 

Summarize :

Preloading does exist, but it is not found in Opera; Chrome's images can be downloaded in parallel with style files in the body, but not in parallel with style files in the head. The script is executed after the style file preceding it is loaded. In Chrome and Opera, unloaded resources will block the rendering of the elements behind them, but Firefox will not. The test results may be related to the browser version.

After reading all this, do you feel it is a bit confusing? I want to express it as clearly as possible, but due to my limited level, I can only do this. I hope you can point out if there are any inappropriate points. You can also try it yourself.

(End)^_^