Description of HTML parsing principles

Standard web front-end engineers need to know the rendering/redrawing principle of the browser (or corresponding player)

I have to work harder on this. I really didn’t explain it very clearly, so I just G-ed it, and there weren’t many results. When I found one, I wrote it down. . .

The following part comes from handawei-javaeye's blog:

Web pages run in various browsers, and the speed of browser loading and rendering pages directly affects the user experience
Simply put, page rendering is the process in which the browser displays the HTML code in the browser window according to the rules defined by CSS. First, let’s have a general understanding of how the browser works:
1. The user enters the URL (assuming it is an HTML page and it is the first visit), the browser sends a request to the server, and the server returns the HTML file;
2. The browser starts loading the html code and finds that there is a tag in the

tag that refers to an external CSS file;
3. The browser sends a request for a CSS file again, and the server returns the CSS file;
　4. The browser continues to load the code of the part of the html, and the CSS file has been obtained, and the page can be rendered;
　5. The browser finds an in the code The tag references an image and makes a request to the server. At this time, the browser will not wait until the image is downloaded, but will continue to render the following code;
6. The server returns the image file. Since the image occupies a certain area, it affects the arrangement of the following paragraphs, so the browser needs to go back to re-render this part of the code;
7. The browser finds a <script> tag containing a line of Javascript code and runs it quickly; <br/> 8. The Javascript script executes this statement, which commands the browser to hide Remove a <div> in the code (style.display=”none”). Oops, suddenly such an element is missing, and the browser has to re-render this part of the code; <br/> 9. Finally, when arrives, the browser bursts into tears... <br/> 10. Wait, it's not over yet. The user clicked the "Skin Change" button in the interface, and Javascript asked the browser to change the CSS path of the <link> tag; <br/> 11. The browser summoned everyone present <div&gt ;<span><ul><li>We, "Everyone pack their bags, we have to start over...", the browser requested a new CSS file from the server and re-rendered the page. <br/> <p> <p> The browser is running back and forth every day. You must know that the quality of the html and css codes written by different people is uneven. Maybe one day I died while running. Fortunately, there is still a group of people in this world - page reconstruction engineers. They are usually very inconspicuous. They just help visual designers cut pictures and change words. In fact, they do a lot of practical things behind the scenes. <p>Speaking of why the page is slow? That's because the browser takes time and effort to render, especially when it finds that a certain part has changed slightly and affects the layout, and needs to go back and re-render. Experts call this rollback process called reflow. <p><p style="max-width:90%"><img src="/static/imghw/default1.png" data-src="https://img.php.cn//upload/image/963/493/887/1488959472280777.jpg" class="lazy" title="Description of HTML parsing principles" alt="Description of HTML parsing principles" style="max-width:90%" style="max-width:90%"/> Reflow is almost inevitable. Some popular effects on the interface now, such as folding and expanding tree-like directories (essentially the display and hiding of elements), etc., will cause browser reflow. Mouse sliding, clicking... As long as these actions cause changes in the area, positioning, margins and other attributes of certain elements on the page, they will cause re-rendering within, around, or even the entire page. Usually we can't predict which part of the code the browser will reflow, they all affect each other. <p><p style="text-align: center;"><img src="/static/imghw/default1.png" data-src="https://img.php.cn//upload/image/435/481/759/1488959491648314.jpg" class="lazy" title="Description of HTML parsing principles" alt="Description of HTML parsing principles" style="max-width:90%" style="max-width:90%"/># The reflow problem can be optimized, and we can minimize unnecessary reflow. For example, the <img alt="Description of HTML parsing principles" > image loading problem in the example at the beginning is actually a reflow that can be avoided - just set the width and height of the image. In this way, the browser knows the area occupied by the image and reserves the space before loading the image. <p>In addition, there is a term that looks similar to reflow: repaint, which is called redraw in Chinese. If you just change the background color, text color, border color, etc. of an element without affecting its surrounding or internal layout, it will only cause the browser to repaint. The speed of repaint is obviously faster than reflow (under IE, you need to change the term, reflow is slower than repaint). Next time, we will use a series of experiments to illustrate the optimization of reflow under browsers such as Firefox and IE. <p><p>##</script>

The above is the detailed content of Description of HTML parsing principles. For more information, please follow other related articles on the PHP Chinese website!