Understand the rendering process of HTML pages in preparation for learning front-end performance optimization
|
I'm currently learning about front-end performance optimization. It's necessary to understand the page rendering process in order to find the right remedy and identify performance bottlenecks. Here are some of the things I saw, shared with you. Reference: Understanding the renderer The rendering of the page has the following characteristics : • Single-threaded event loop • Well-defined, continuous, and orderly operations (HTML5) • Tokenization and DOM tree construction • Request resources and preload them • Build the render tree and draw the page Specifically : When we get the corresponding bytes of HTML from the network, the DOM tree starts to be built. The browser's thread for updating the UI is responsible. The construction of the DOM tree will be blocked when the following situations occur: • The HTML response stream is blocked on the network • There are unloaded scripts •A script node is encountered, but 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 a single-threaded event loop, even if there is no script or style blocking, 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 and async attributes • No style file matching the media type • No script nodes or style nodes are inserted by the parser Below, let's illustrate this with an example (complete code) : Copy code The code is as follows:<html> <body> <link rel="stylesheet" href="example.css"> <div>Hi there!</div> <script> document.write('<script src="other.js"></scr' + 'ipt>'); </script> <div>Hi again!</div> <script src="last.js"></script> </body> </html> The code is easy to understand, and if you open it in a browser, the desired page will be displayed immediately. Next, let's use slow motion playback to see how it is rendered. Copy code The code is as follows:<html> <body> <link rel="stylesheet" href="example.css"> <div>Hi there!</div> <script>... First, the parser encounters example.css and downloads it from the network. The process of downloading the style sheet is time-consuming, but the parser is not blocked and continues parsing. Next, the parser encounters a script tag, but because the style file has not been loaded, the execution of the script is blocked. The parser is blocked and cannot continue parsing. The render tree will also be blocked by the style file, so no browser will render the page at this time. In other words, if the example.css file cannot be downloaded, Hi there! will not be displayed. Next, continue. . . Copy code The code is as follows:<html> <body> <link rel="stylesheet" href="example.css"> <div>Hi there!</div> <script> document.write('<script src="other.js"></scr' + 'ipt>'); </script> Once the example.css file is loaded, the render tree is built. After the inline script is executed, the parser will be immediately blocked by other.js. Once the parser is blocked, the browser receives the paint request and "Hi there!" is displayed on the page. When other.js is loaded, the parser continues to parse downwards. . . Copy code The code is as follows:<html> <body> <link rel="stylesheet" href="example.css"> <div>Hi there!</div> <script> document.write('<script src="other.js"></scr' + 'ipt>'); </script> <div>Hi again!</div> <script src="last.js"></script> The parser is blocked when it encounters last.js, and then the browser receives another rendering request, and "Hi again!" is displayed on the page. Finally, last.js will be loaded and executed. However, to alleviate rendering blocking, modern browsers use speculative loading. In the above case, scripts and style files will seriously block the rendering of the page. I guess the purpose of preloading is to reduce this blocking time. When rendering is blocked, it does the following: • A lightweight HTML (or CSS) scanner continues scanning in the document • Find the URLs of resource files that may be used in the future • Download them before the renderer uses them. However, guesswork preloading cannot detect resource files loaded via JavaScript (e.g., document.write()). Note : All "modern" browsers support this method. Let's look back at the example above and guess how preloading works. Copy code The code is as follows:<html> <body> <link rel="stylesheet" href="example.css"> <div>Hi there!</div> <script>... The parser returns example.css and gets it from the network. The parser is not blocked and continues parsing. When it encounters an inline script node, it is blocked. Since the style file has not been loaded, the execution of the script is blocked. The render tree is also blocked by the stylesheet, so the browser doesn’t receive the render request and can’t see anything. So far, it's the same approach as just mentioned. But then things changed. The speculative loader continues to “read” the document, finds last.js and tries to load it. Next: Copy code The code is as follows:<html> <body> <link rel="stylesheet" href="example.css"> <div>Hi there!</div> <script> document.write('<script src="other.js"></scr' + 'ipt>'); </script> Once example.css is loaded, the render tree is built and inline scripts can be executed, and then the parser is blocked by other.js again. After the parser is blocked, the browser receives the first render request and “Hi there!” is displayed on the page. This step is the same as the previous one. Then: Copy code The code is as follows:<html> <body> <link rel="stylesheet" href="example.css"> <div>Hi there!</div> <script> document.write('<script src="other.js"></scr' + 'ipt>'); </script> <div>Hi again!</div> <script src="last.js"></script> The parser finds last.js, but because the preloader has just loaded it and placed it in the browser cache, last.js will be executed immediately. After that, the browser will receive the rendering request and "Hi again" will be displayed on the page. By comparing the two situations, I hope everyone can have a certain understanding of page rendering, and then make some targeted optimizations. good evening! (End)^_^ |
<<: JavaScript basics of this pointing
>>: A detailed tutorial on how to install Jenkins on Docker for beginners
Recommend
Detailed explanation of Nginx installation, SSL configuration and common commands under Centos7.x
1. Installation Install using yum ##Automatically...
A brief discussion on an efficient algorithm for constructing tree structures in JavaScript
Table of contents introduction Ideas Establish ID...
css3 animation ball rolling js control animation pause
CSS3 can create animations, which can replace man...
Comparison of efficiency between single-table query and multi-table join query in MySql database
During this period of time, while working on a pr...
Two methods to disable form controls in HTML: readonly and disabled
In the process of making web pages, we often use f...
What are the differences between var let const in JavaScript
Table of contents 1. Repeated declaration 1.1 var...
How to implement a binary search tree using JavaScript
One of the most commonly used and discussed data ...
Vue+flask realizes video synthesis function (drag and drop upload)
Table of contents We have written about drag and ...
Summary of React's way of creating components
Table of contents 1. Create components using func...
Use and understanding of MySQL triggers
Table of contents 1. What is a trigger? 2. Create...
Two-hour introductory Docker tutorial
Table of contents 1.0 Introduction 2.0 Docker Ins...
What to do if the auto-increment primary key in MySQL is used up
In the interview, you should have experienced the...
Detailed explanation of Mysql's concurrent parameter adjustment
Table of contents Query cache optimization Overvi...
js implements a simple shopping cart module
This article example shares the specific code of ...
HTML simple web form creation example introduction
<input> is used to collect user information ...