The 3f1c4e4b6b16bbbd69b2ee476dc4f83a tag in modern browsers is divided into two new types: classic and non-blocking. Let’s discuss how to use these two tags to load pages as quickly as possible. 1. Where will blocking scripts go? The standard version of the 3f1c4e4b6b16bbbd69b2ee476dc4f83a tag is often called a blocking tag. This term must be understood in context: when modern browsers see a blocking 3f1c4e4b6b16bbbd69b2ee476dc4f83a tag, they skip the blocking point and continue reading the document and downloading other resources (scripts and stylesheets). But the browser won't evaluate those resources beyond the choke point until the script is downloaded and run. Therefore, if a web document has five blocking 3f1c4e4b6b16bbbd69b2ee476dc4f83a tags within its 93f0f5c25f18dab9d176bd4f6de5d30e tag, the user will see nothing but the page title until all five scripts have been downloaded and run. Not only that, but even if these scripts run, they can only see the portion of the document before the blocking point. If you want to see all the goodies waiting to be loaded in the 6c04bd5ca3fcae76e30b72ad730ca86d tag, you have to bind an event handler to an event like document.onreadystatechange. Based on the above reasons, it is becoming more and more popular to place scripts at the end of the 6c04bd5ca3fcae76e30b72ad730ca86d tag on the page. In this way, on the one hand, users can see the page faster, and on the other hand, scripts can also actively access the DOM without waiting for events to trigger themselves. For most scripts, this "move" is a huge improvement. But not all scripts are the same. Before moving down the script, ask yourself 2 questions. Is it possible that this script is called directly by inline JavaScript in the 6c04bd5ca3fcae76e30b72ad730ca86d tag? The answer may be obvious, but it’s worth checking. Will this script affect the appearance of the rendered page? Typekit host fonts are one example. If you place the Typekit script at the end of the document, the page text will be rendered twice, immediately when the document is read, and again when the script is run. As long as one of the answers to the above questions is yes, then the script should be placed in the 93f0f5c25f18dab9d176bd4f6de5d30e tag, otherwise it can be placed in the 6c04bd5ca3fcae76e30b72ad730ca86d tag. The document shape is: This does significantly improve load times, but be aware that this may give the user a chance to interact with the page before bodyScripts.js is loaded. 2. Early loading and delayed running of scripts It is recommended to place most scripts in 6c04bd5ca3fcae76e30b72ad730ca86d, because this will not only allow users to see the web page faster, but also Avoid the overhead of binding the "ready" event before manipulating the DOM. But this approach also has the disadvantage that the browser cannot load these scripts until the entire document has been loaded, which can be a bottleneck for large documents sent over slow connections. Ideally, the loading of the script should be done simultaneously with the loading of the document and not affect the rendering of the DOM. This way, you can run the script once the document is ready because the scripts have already been loaded in the order of the 3f1c4e4b6b16bbbd69b2ee476dc4f83a tags. If you have read this far, you must be eager to write a custom Ajax script loader to meet such needs! However, most browsers support a simpler solution. Adding the defer (delay) attribute is equivalent to saying to the browser: "Please start loading this script now, but please wait until the document is ready and all previous scripts with the defer attribute have finished running before running it. "Putting a delayed script in the document's 93f0f5c25f18dab9d176bd4f6de5d30e tag not only brings all the benefits of placing the script in the 6c04bd5ca3fcae76e30b72ad730ca86d tag, but also greatly improves the loading speed of large documents! The disadvantage is that not all browsers support the defer attribute. This means that if you want to ensure that your deferred script can run after the document is loaded, you must encapsulate all the deferred script code in a structure such as jQuery's $(document).ready. The page example in the previous section is improved as follows: Please remember that the encapsulation of deferredScripts is important, so that even if the browser does not support defer, deferredScripts will not run until after the document ready event. If the main content of the page is much larger than a few kilobytes, it's totally worth the price. 3. Parallel loading of scripts If you are a perfectionist who cares about page loading time in milliseconds, then defer may be like tasteless soy sauce. You don't want to wait until all previous defer scripts have finished running, and you certainly don't want to wait until the document is ready before running these scripts. You just want to load and run these scripts as quickly as possible. This is why modern browsers provide the async attribute. 如果说defer 让我们想到一种静静等待文档加载的有序排队场景，那么async 就会让我们想到混乱的无政府状态。前面给出的那两个脚本会以任意次序运行，而且只要JavaScript 引擎可用就会立即运行，而不论文档就绪与否。对大多数脚本来说，async 是一块难以下咽的鸡肋。async 不像defer那样得到广泛的支持。同时，由于异步脚本会在任意时刻运行，它实在太容易引起海森堡蚁虫之灾了（脚本刚好结束加载时就会蚁虫四起）。当我们加载一些第三方脚本，而且也不在乎它们谁先运行谁后运行。因此，对这些第三方脚本使用async 属性，相当于一分钱没花就提升了它们的运行速度。上一个页面示例再添加两个独立的第三方小部件，得到的结果如下： 这个页面结构清晰展示了脚本的优先次序。对于绝大多数浏览器，DOM的渲染只会延迟至headScripts.js 结束运行时。进行DOM渲染的同时会在后台加载deferredScripts.js。接着，在DOM 渲染结束时将运行deferredScripts.js 和那两个小部件脚本。这两个小部件脚本在那些支持async 的浏览器中会做无序运行。如果不确定这是否妥当，请勿使用async！