Open the HTML file in a browser and break the HTML file. The javascript parsing will terminate the HTML rendering.

<html>
<body>
    <div>1</div>
    <script>
    let div1 = document.getElementsByTagName('div') [0]
    div1.innerText = 'time.geekbang'
    </script>
    <div>test</div>
</body>
</html>
Copy the code

If the JS code is inserted as a script tag, the network process will be introduced to download the JS code when it is loaded here, and parsing the HTML document will also be interrupted.

<html>
<body>
    <div>1</div>
    <script type="text/javascript" src='foo.js'></script>
    <div>test</div>
</body>
</html>
Copy the code

Also, if there is no DOM-related code in the JavaScript file to manipulate, you can set the JavaScript script to load asynchronously and mark the code with async or defer

Both Async and defer are asynchronous, but there are some differences. Scripts using the Async flag are executed as soon as they are loaded. The script file that uses the defer tag needs to be executed before the DOMContentLoaded event.

As you can see, in order to reduce the impact of JS parsing on HTML parsing, the least impact should be defer, followed by Async.

May have a look have any reference in this part of content getbootstrap.com/docs/5.0/cu…

How Browsers work this article has some more to figure out.

Speculative parsing Both WebKit and Firefox do this optimization. While executing scripts, another thread parses the rest of the document and finds out what other resources need to be loaded from the network and loads them. In this way, resources can be loaded on parallel connections and overall speed is improved. Note: the speculative parser only parses references to external resources like external scripts, style sheets and images: It doesn’t modify the DOM tree — that is left to the main parser.

This means that after the script tag is encountered, js is executed, but at the same time another thread is used to parse the rest of the HTML to download other external resources in the HTML, so that the download can be synchronized. However, the DOM is not modified after the download, and execution continues until the content is parsed to the downloaded location.

Style sheets Style sheets on the other hand have a different model. Conceptually it seems that since style sheets don’t change the DOM tree, there is no reason to wait for them and stop the document parsing. There is an issue, though, of scripts asking for style information during the document parsing stage. If the style is not loaded and parsed yet, the script will get wrong answers and apparently this caused lots of problems. It seems to be an edge case but is quite common. Firefox blocks all scripts when there is a style sheet that is still being loaded and parsed. WebKit blocks scripts only when they try to access certain style properties that may be affected by unloaded style sheets.

Since JS can also fetch and modify style content, js execution must wait until the style file has been downloaded and parsed. So CSS also blocks JS.

In the process of rendering tree generation, it involves the multi-layer problem of CSS, that is, the layout in the vertical, that is, in addition to the two-dimensional position of the screen, also need to consider the three-dimensional position in the vertical, such as position absolute or float elements.

Render Tree is generated by both DOM and CSSOM, so overly complex CSS and useless CSS will slow down the render Tree generation process.