Take a look at the standard defined browser rendering process (found online):
The process of opening a Web page in a browser
- The first time the user accesses the URL, the browser makes a request to the server, and the server returns the HTML file;
- The browser starts loading the HTML code and finds a link tag inside the head tag that references an external CSS or JS file;
- The browser also issued a CSS and JS file request, the server returned this CSS,JS file;
- The browser continues to load the code of the body part of the HTML, and the Css,js file has already been handed, and can start rendering the page;
- The browser finds an IMG tag in the code that references a picture and 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 ;
- The server returns a picture file, because the picture occupies a certain area, affecting the layout of the page, so the browser needs to return to re-render this part of the code;
- The browser discovers a script tag containing a line of JavaScript code and executes it quickly;
- The JavaScript script executes this statement, which commands the browser to hide a div (style.display= "none") from the code. The cup has, suddenly missing such an element, the browser has to re-render this part of the code;
- Finally wait until the arrival of HTML, the browser tears ...
The order in which the browser loads and renders HTML
- IE browser download order is from top to bottom, the order of rendering is also from top to bottom, download and rendering is done at the same time.
- when you render to a portion of a page, all of its parts are already downloaded (not that all associated elements have been downloaded)
- If you encounter semantic explanatory tags embedded file (js script, CSS style), then the download process of IE will enable the individual connection to download.
- And after the download to parse, the parsing process, stop all the page down the download of elements, blocking loading .
- After the download is complete, the stylesheet is parsed with all previously downloaded stylesheets, and after parsing is complete, all previous elements (including previously rendered) are re-rendered.
- JS, CSS, if there is a redefinition, after the definition function will overwrite the pre-defined function.
JS's Loading
- Cannot download and analyze in parallel (blocking download)
- The Web mode is synchronous, the developer wants to parse the script immediately when parsing to a script tag, and block the parsing of the document until the script executes; if the script is externally referenced, when JS is quoted, the browser sends a JS The request will always wait for the request to return, and the process will be synchronized, blocking the parsing of the document until the resource is requested. Because the browser needs a stable DOM tree structure, and JS is likely to have code to directly change the structure of the DOM tree, 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. This pattern has been maintained for many years and is specifically specified in HTML4 and HTML5. The developer can identify the script as defer so that it does not block document parsing and executes after the document resolves. HTML5 adds the option to mark the script as asynchronous so that the parsing of the script is performed using another thread.
Here are a few points to explain:
1. We know that the processing of the browser is parsing the HTML generated DOM tree-> based on the DOM tree and style sheet generated by the render tree-> rendering of the render tree display . In order for the user to see the page more quickly, the browser generates part of the render tree and displays it by parsing the HTML to generate a local DOM tree.
2. Two external resources in this process are blocking script execution, which blocks rendering, respectively, external JS and external CSS. External JS is blocking the generation of Dom tree , because the browser needs a solid DOM tree, and JS may break the structure (of course, it may also change the style "note is style rather than style sheet", but this does not block will not affect) The external CSS style sheet also blocks the execution of the script, in theory, since the stylesheet does not change the DOM tree, there is no need to stop parsing the document waiting for them, however, there is a problem that the script may request the style information during the parsing of the document, if the style has not yet loaded and parsed, The script will get the wrong value, obviously this will cause a lot of problems, which seems to be an edge situation, but it is very common. Firefox blocks all scripts while the stylesheet is still loaded and parsed, and chrome blocks the scripts only when the script tries to access certain style properties that might be affected by the non-loaded style sheet.
3. Its external resources are not blocking rendering , compared to the film, we can see a lot of times the frame of the page is presented, that is, the position of the picture is not displayed, until the picture is downloaded and then re-rendered.
Optimization of modern browsers:
follow the standard browser rendering and download process. The following code should load the external resources in the same order as the resources in HTML. Where head adds an external resource request HTTP://hm.baidu.com/hm.js?a041a0f4ff93aef6aa83f34134331a1d should be loaded before all styles
<HTML><Head> ... <!--Baidu Statistics Code - <Script> var_HMT=_HMT|| []; (function() { varHost=Document.location.hostname; if(/lcfarm.com$/Ig.test (host)) { varHM=Document.createelement ("Script"); HM.SRC= "//hm.baidu.com/hm.js?a041a0f4ff93aef6aa83f34134331a1d"; vars=document.getElementsByTagName ("Script")[0]; S.parentnode.insertbefore (hm, s); } })(); </Script> <Linkrel= "stylesheet"type= "Text/css"href= "//static.lcfarm.com/pc-dist/pkg/index.html_aio_f9db6a6.css"> <Linkrel= "stylesheet"type= "Text/css"href= "//static.lcfarm.com/pc-dist/common/css/common_530eedd.css"> <Linkrel= "stylesheet"type= "Text/css"href= "//static.lcfarm.com/pc-dist/css/index_8b620da.css"> <Linkrel= "stylesheet"type= "Text/css"href= "//static.lcfarm.com/pc-dist/pkg/index.html_aio_2_2379650.css"></Head><Body> ... <Scripttype= "Text/javascript"Data-loader=""src= "//static.lcfarm.com/pc-dist/common/dep/mod_36ad799.js"></Script> <Scripttype= "Text/javascript"Data-loader=""src= "//static.lcfarm.com/pc-dist/common/dep/jquery_c07f226.js"></Script> <Scripttype= "Text/javascript"src= "//static.lcfarm.com/pc-dist/common/js/jquery/jquery.cookie_546183c.js"></Script> <Scripttype= "Text/javascript"src= "//static.lcfarm.com/pc-dist/pkg/common_85ea494.js"></Script> <Scripttype= "Text/javascript"src= "//static.lcfarm.com/pc-dist/pkg/index.html_aio_350303c.js"></Script></Body></HTML>
But actually in Chrome. Firefox, ie8+ and other browsers found the following effect (using https://www.webpagetest.org/test)
Why? This is pre-parsing (speculative parsing)
both WebKit and Firefox do this optimization, and when the script is executed, another thread parses the rest of the document and loads the resources that need to be loaded over the network later . This approach allows resources to be loaded in parallel to make the overall speed faster. It is important to note that pre-parsing does not change the DOM tree, which leaves this work to the main parsing process and only parses references to external resources, such as external scripts, stylesheets, and pictures.
As shown in the diagram above, you can see that when executing the script and parsing a lot of external resource references, and starting the thread to download them, the main thread is still waiting for Hm.js to return.
The process of loading and rendering HTML in a browser (standard defined procedures and optimization of modern browsers)