Home > Article > Web Front-end > Understand the rendering process of html pages in preparation for learning front-end performance optimization_HTML/Xhtml_Web page production
Understand the rendering process of html pages in preparation for learning front-end performance optimization_HTML/Xhtml_Web page production
- WBOYOriginal
- 2016-05-16 16:40:411482browse
Recently, I am learning about front-end performance optimization. It is necessary to understand the page rendering process in order to prescribe the right medicine and find out the performance bottleneck. Here are some things I saw, to share with you.
Reference: Understanding the renderer
The rendering of the page has the following characteristics:
•Single-threaded event polling
•Well-defined, continuous, orderly operations (HTML5)
•Word segmentation and building DOM tree
•Requesting resources and preloading
•Building rendering tree and drawing the page
Specifically:
When we get HTML from the network When the corresponding bytes are reached, the DOM tree begins to be constructed. The browser's thread that updates the UI is responsible for this. When encountering the following situations, the construction of the DOM tree will be blocked:
•HTML response flow is blocked in the network
•There is an unloaded script
•A script node is encountered, but this There are still unloaded style files
The rendering tree is built from the DOM tree and will be blocked by the style files.
Because it is based on single-threaded event polling, even if there is no blocking of scripts and styles, when these scripts or styles are parsed, executed and applied, the rendering of the page will be blocked.
Some situations that will not block page rendering:
• Defined defer attribute and async attribute
• No matching media type style file
• Did not pass the parser Insert script node or style node
Below, let’s illustrate with an example (complete code) :
<script> <br> document.write('<script src="other.js">< ;/scr' 'ipt>'); <br> </script>
After the parser encounters last.js will be blocked, and then the browser receives another draw request, and "Hi again!" is displayed on the page. Finally last.js will be loaded and executed.
However, in order to slow down rendering blocking, modern browsers use speculative loading.
In the above case, scripts and style files will seriously block the rendering of the page. Guess the purpose of preloading is to reduce this blocking time. When rendering is blocked, it will do the following:
• A lightweight HTML (or CSS) scanner (scanner) continues to scan the document
• Find resources that may be used in the future URLs of files
• Download them before the renderer uses them
However, preloading cannot discover resource files that are loaded via javascript (e.g., document.write()).
Note: All "modern" browsers support this method.
Go back and look at the above example to guess how preloading works.
< body>
<script>... <br> </div> <br>The parser returned example.css and obtained it from the network. The parser was not blocked and continued parsing. When it encountered an inline script node, it was blocked because the style file was not loaded. Blocks script execution. The render tree is also blocked by the style file, so the browser doesn't receive the render request and can't see anything. So far, it's the same way as just mentioned. But then things changed. <br><br>The speculative loader continues to "read" the document, discovers last.js and loads it. Next: <br><br><div class="msgheader"> <div class="right"><span style="CURSOR: pointer" onclick="copycode(getid('phpcode28'));"><u>Copy the code</u></span></div>The code is as follows:</div> <div class="msgborder" id="phpcode28"> <br><html> <br><body> <br> <link rel="stylesheet" href="example.css"> <br> <div>Hi there!</div> <br> <script> <br> document.write('<script src="other.js"></scr' 'ipt>'); <br> </script>
Once the example.css file After the loading is completed, the rendering tree is completed and the inline script can be executed. After that, the parser is blocked by other.js. After the parser is blocked, the browser will receive the first rendering request, and "Hi there!" will be displayed on the page. This step is consistent with the situation just now. Then:
<script> <br> document .write('<script src="other.js"></scr' 'ipt>'); <br> </script>
The parser found last.js, but because the preloader had just loaded it , placed in the browser's cache, so last.js will be executed immediately. Afterwards, the browser will receive a rendering request and "Hi again" will be displayed on the page.
By comparing the two situations before and after, I hope everyone can have a certain understanding of page rendering, and then make some targeted optimizations. Good night! (End)^_^