A brief analysis of JavaScript asynchronous loading_javascript skills

Foreword

I believe you have encountered many problems with JavaScript script loading. Mainly in a few points——

1> File loading, file dependency and execution order issues caused by synchronous scripts and asynchronous scripts
2> Performance optimization issues caused by synchronous scripts and asynchronous scripts

A thorough understanding of all aspects related to script loading will not only help solve practical problems, but also help grasp and implement performance optimization.

First look at any script tag code——

Copy code The code is as follows:

If placed above the

, it will block all page rendering work, leaving the user in a "white screen of death" state until the script is loaded and executed. The script at the end of will only allow users to see a lifeless static page. The place where client-side rendering should be performed is scattered with ineffective controls and empty boxes. Get a test case -

Copy code The code is as follows:

I am the content

Among them, the content in test.js——

Copy code The code is as follows:

alert('I am the script code in the head. After executing the js here, the content rendering of the body will start!');

We will see that alert is a pause point, and at this time, the page is blank. But please note that the entire page has been loaded at this time. If the body contains tags with certain src attributes (such as the img tag above), the browser has already started loading related content. In short, please note that the working timing of the js engine and the rendering engine are mutually exclusive (some books call it the UI thread).

Therefore, we need - those scripts responsible for making the page look better and easier to use should be loaded immediately, while those scripts that can be loaded later should be loaded later.

1. Delayed execution of script

It is becoming more and more popular to place scripts at the end of the

tag of the page. In this way, on the one hand, users can see the page faster, and on the other hand, scripts can directly operate on the loaded DOM elements. For most scripts, this "move" is a huge improvement. The page model is as follows——

Copy code The code is as follows:

This does speed up the rendering time of the page significantly, but be aware that this may give the user a chance to interact with the page before the bodyScript is loaded. The reason is 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 occur 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 <script> tags. </script>

We can use defer to fulfill this requirement, that is -

Copy code The code is as follows:

Adding the defer attribute is equivalent to telling 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.

In this way, placing the delay script in the head tag will bring all the benefits of placing the script in the body tag, and it will also greatly increase the loading speed of large documents. The page mode at this time is——

Copy code The code is as follows:

But not all browsers support defer (for some modern browsers, if defer is declared, their internal scripts will not perform document.write and DOM rendering operations. IE4 all supports the defer attribute). This means that if you want to ensure that your delayed script can run after the document is loaded, you must encapsulate all the delayed script code in a structure such as jQuery's $(document).ready. It's worth it because almost 97% of your visitors get the benefits of parallel loading, while the other 3% still have access to fully functional JavaScript.

2. Complete parallelization of scripts

Make the loading and execution of scripts one step faster. I don’t want to wait for defer scripts to run one after another (defer reminds us of an orderly queuing scenario of quietly waiting for the document to load), nor do I want to wait until the document is ready before running these Scripts, I want to load as quickly as possible and run these scripts as quickly as possible. The async attribute of HTML5 comes to mind here, but be aware that it is a chaotic anarchy.

For example, we load two completely unrelated third-party scripts, the page runs just fine without them, and we don’t care which one runs first and which one runs last. Therefore, using the async attribute on these third-party scripts is equivalent to improving their running speed without spending a penny.

The async attribute is new to HTML5. The function is similar to defer, which allows DOM rendering while downloading the script. However, it will be executed as soon as possible after downloading (that is, the JS engine will be executed as soon as it is idle), and there is no guarantee that the script will be executed in order. They will complete before the onload event.

Firefox 3.6, Opera 10.5, IE 9 and the latest Chrome and Safari all support the async attribute. You can use async and defer at the same time, so that all IE after IE 4 support asynchronous loading, but be aware that async will overwrite defer.

Then the page model at this time is as follows——

Copy code The code is as follows:

Pay attention to the order of execution here - each script file is loaded, then headScript.js is executed, and then defferedScript.js is loaded in the background while the DOM is rendering. Then at the end of DOM rendering, defferedScript.js and the two asynchronous scripts will be run. It should be noted that for browsers that support the async attribute, these two scripts will run out of order.

3. Programmable script loading

Although the functions of the above two script attributes are very attractive, they are not widely used due to compatibility issues. Therefore, we use scripts more often to load other scripts. For example, we only want to load a script to those users who meet certain conditions, which is often referred to as "lazy loading".

At the browser API level, there are two reasonable ways to grab and run server scripts -

1> Generate ajax request and use eval function to process the response

2> Insert <script> tag into DOM </script>

The latter method is better because the browser will worry about generating HTTP requests for us. Furthermore, eval has some practical problems: it leaks scope, makes debugging messy, and can potentially degrade performance. Therefore, to load a script named feture.js, we should use code similar to the following:

Copy code The code is as follows:

var head = document.getElementsByTagName('head')[0];
var script = document.createElement('script');
script.src = 'feature.js';
head.appendChild(script);

Of course, we have to deal with callback monitoring. The HTML5 specification defines an onload attribute that can bind callbacks.

Copy code The code is as follows:

script.onload = function() {
console.log('script loaded...');
}

However, IE8 and older versions do not support onload, they support onreadystatechange. Moreover, error handling is still weird. Here, you can refer to some popular school-based loading libraries, such as labjs, yepnope, requirejs, etc.

As follows, I encapsulated a simple loadjs file——

Copy code The code is as follows:

var loadJS = function(url,callback){
var head = document.getElementsByTagName('head')[0];
var script = document.createElement('script');
Script.src = url;
​ script.type = "text/javascript";
Head.appendChild(script);

// script tag, IE has onreadystatechange event, w3c standard has onload event
// IE9 also supports W3C standard onload
var ua = navigator.userAgent,
        ua_version;
// IE6/7/8
If (/MSIE ([^;] )/.test(ua)) {
        ua_version = parseFloat(RegExp["$1"], 10);
If (ua_version                script.onreadystatechange = function(){
If (this.readyState == "loaded" ){
                    callback();
                }
            }
         } else {
              script.onload = function(){
                 callback();
            };
}
} else {
         script.onload = function(){
             callback();
        };
}
};

I won’t talk about the asynchronous loading of scripts using document.write here. Few people do this now because the differences between browsers are really confusing.

Be aware that if you use the Image object to asynchronously preload js files, the js code inside will not be executed.

Finally, let’s talk about asynchronous loading scripts in requirejs.

requirejs does not guarantee that the target scripts will be run in order, but only that their running order can meet their respective dependency requirements. This ensures that all scripts are loaded in parallel as quickly as possible and executed in an orderly manner according to the dependency topology.

4. Summary

OK, at this point, the statement of asynchronous loading script is over. Let me elaborate on the optimization sequence here again——

1> In the traditional way, we use script tags to embed directly into the html document. There are two situations here -

a> Embed into the head tag - please note that doing so will not affect the parallel loading of other static resource files in the document content. What it will affect is the rendering of the document content, that is, the DOM rendering at this time will is blocked, showing a white screen.

b> Embed at the bottom of the body tag - In order to avoid the white screen phenomenon, we prioritized DOM rendering and then executed the script, but the problem came again. Let’s talk about the first problem first - if the content of the DOM document is relatively large, there will be a delay in binding the interactive events, and the experience will be worse. Of course, we need to let important scripts execute first according to needs. Let's talk about the second problem - since the script files are at the bottom of the body, the loading of these scripts is delayed compared to the scripts in the head. Therefore, as for the bottom of the body, it is not the end point of optimization.

c> Add the defer attribute - we want the scripts to be loaded in parallel as soon as possible, so we still put these scripts into the head. The script should be loaded simultaneously with the loading of the document and should not affect the rendering of the DOM. This way, the script can be run once the document is ready. So there is an attribute like defer. But pay attention to its compatibility. For browsers that do not support the defer attribute, we need to encapsulate the code in $(document).ready such as jQuery. It should be noted that all scripts with defer attributes are executed sequentially in the order of their appearance, so they are also strictly synchronized.

2> The previous point is all about synchronous execution of scripts (note that the loading process of these scripts is parallel, the only difference is who triggers the request first and who triggers the request later). The next optimization point is It is "parallel execution of scripts". Of course, we know that at a point in time, only one js file can be executed. The "parallel" here means that whoever loads it first will execute it immediately as long as the js engine is idle at this time. The optimization here is divided into two types——

a> Adding the async attribute can indeed accomplish the optimization points we mentioned above, but it has high limitations, that is, it is only for loading non-dependent scripts. The most appropriate example is to introduce multiple Third party script. There is also the combination with the deffer attribute, which is really troublesome. Of course, it also has compatibility issues. The above three problems result in its limited application. When using async, be sure to pay strict attention to dependencies.

b> Script loading script - Obviously, we use it to achieve the purpose of "parallel execution of scripts". At the same time, it is also convenient for us to control script dependency issues, so we use intelligent loading management for js asynchronous loading in requirejs.

Okay, let’s write it here.

Here, I am only talking about asynchronous loading scripts. There is another piece of content, which is asynchronous loading of style files or other static resources. To be continued...