Home > Developer > JavaScript
Look at this line of code first:
<script src = "allmyclientsidecode.js" ></script>
It's kind of ... It's not good. "Where should I put it?" "Developers would be surprised," put the dots on the
The perfect solution to this problem involves scripting and dividing: the scripts that are responsible for making the page look better and more used should be loaded immediately, and the scripts that can be loaded later will then be loaded. But how can you Shang these scripts and make sure they are available when they are invoked?
First, the recognition of <script> label
The <script> tags in modern browsers are divided into two new types: Classic and non-blocking. Next, we'll discuss how to use both tags to load the page as quickly as possible.
1. What is the pattern of blocking scripts?
Standard versions of <script> tags are often referred to as blocking tags. The word must be understood in context: When a modern browser sees a blocking <script> tag, it skips over the blocking point to continue reading the document and downloading other resources (scripts and stylesheets). However, the browser does not evaluate the resources after the blocking point until the script has been downloaded and run. Therefore, if there are 5 blocked <script> tags in the
For the above reasons, it is becoming more and more popular to place scripts at the end of the page <body> tag. This allows the user to see the page more quickly on the one hand, while the script can proactively touch the DOM without waiting for events to trigger itself. For most scripts, this "move" is a huge improvement.
But not all scripts are the same. Please ask yourself 2 questions before moving down the script.
As long as one answer is yes, the script should be placed in the
This really shortens the load time, but note that this may give the user an opportunity to interact with the page before loading bodyscripts.js.
2, the script in advance loading and delayed operation
It is recommended that most scripts be placed in <body> because it allows users to see the web more quickly and avoid the overhead of binding "ready" events before manipulating the DOM. But there is also a disadvantage that browsers cannot load these scripts until the entire document is loaded, which can be a major bottleneck for large documents that are delivered over a slow connection.
Ideally, the script should load concurrently with the loading of the document and not affect the rendering of the DOM. This allows the script to run once the document is ready because the script has been loaded in the order of <script> tags.
If you've already read this, you'll be eager to write a custom Ajax script loader to meet this need! However, most browsers support a simpler solution.
<script defer src = "deferredscript.js" >
Adding defer (delay) properties is equivalent to saying to the browser: "Please start loading this script right away, but wait until the document is ready and all previous scripts with the defer attribute are finished and run it." "Putting a delay script in a document
The disadvantage is that not all browsers support the defer property. This means that if you want to make sure that your delay scripts run after the document is loaded, you must encapsulate all the deferred script code in a structure such as jquery $ (document). Ready.
The page example in the previous section is improved as follows:
Keep in mind that deferredscripts encapsulation is important so that even if the browser does not support defer,deferredscripts, it will run after the document-ready event. If the main content of the page is far more than thousands of bytes, it is entirely worthwhile to pay this price.
3, parallel loading of the script
If you are a perfectionist who is preoccupied with the millisecond page load time, then defer may be like a bland, thin salt sauce. You don't want to wait until all the defer scripts are finished running, and certainly don't want to wait until the document is ready to run the scripts, you just want to load and run the scripts as quickly as you can. This is why modern browsers provide async (asynchronous) properties.
<script async src = "speedygonzales.js" > <script async src = "Roadrunner.js" >
If defer let us think of a quiet waiting for the document to load the orderly queue scene, then Async will let us think of Chaos anarchy. The two scripts given above will run in any order and will run immediately as long as the JavaScript engine is available, regardless of whether the paper file is ready or not.
For most scripts, async is an inedible piece of chicken. Async is not as widely supported as defer. At the same time, because the asynchronous script runs at any time, it is too easy to cause the Heisenberg bug (the script will be four when it's just finished loading).
When we load some third-party scripts, and don't care who runs them first. Therefore, using the Async attribute for these third-party scripts, the equivalent of a penny without a flower increases their speed.
The previous page example adds two separate third party widgets, and the results are as follows:
This page structure clearly shows the precedence of the script. For most browsers, the rendering of the DOM is deferred until the end of the Headscripts.js run. Dom rendering will also load the deferredscripts.js in the background. Next, the Deferredscripts.js and the two widget scripts will run at the end of the DOM rendering. These two widget scripts run in a disorderly operation in browsers that support async. If you are unsure if this is appropriate, do not use async!
Second, programmable script loading
While <script> tags are simple to move through, there are situations that require more sophisticated script loading. We may just want to load a script, such as a Platinum member or a player who reaches a certain level, to those who meet certain criteria, or just want to load a feature, such as a chat widget, when the user clicks Activate.
1. Direct Load Script
We can insert <script> tags with code similar to the following.
var head = document.getElementsByTagName (' head ') [0];
var script = document.createelement (' script ');
SCRIPT.SRC = '/js/feature.js ';
Head.appendchild (script);
Wait a minute, how do we know when the script finishes loading? We could add some code to the script itself to trigger the event, but it would be annoying to add such code to each of the scripts to be loaded. Alternatively, it is not possible to add such code to a script on a third party server. The HTML5 specification defines an OnLoad property that can bind a callback.
Script.onload = function () {
//now can invoke the functions defined in the script
};
However, IE8 and older versions do not support the onload, and they support onreadystatechange. Some browsers may also have "supernatural events" when inserting <script> tags. Also, there is not even a mention of error handling here! To avoid
All of these headaches, this is strongly recommended for using script loading libraries.
Third, the Yepnope condition loading
Yepnope is a simple, lightweight script-loading library (only 1.7KB after a condensed compact version) designed to sincerely serve the most common dynamic script load requirements.
The simplest use of yepnope is to load the script and return a callback to the event that the script finishes running.
Yepnope ({
load: ' oompaloompas.js ',
callback:function () {
console.log (' Oompa-loompas ready! ');
}
});
or indifferent? Here we'll use Yepnope to load multiple scripts in parallel and run them in the given order. For example, suppose we want to load backbone.js, and this script relies on underscore.js. To do this, we simply provide the location of the two scripts as the load parameter in the form of an array.
Yepnope ({
load: [' underscore.js ', ' backbone.js '],
complete:function () {
//Here is the backbone business logic
}
});
Note that the complete (finish) is used here instead of the callback (callback).
The difference is that each resource in the script load list runs callback, and the complete is run only when all the scripts have completed loading. The iconic feature of Yepnope is conditional loading. Given the test parameter, Yepnope loads different resources based on whether the parameter value is true. For example, you can determine whether a user is using a touchscreen device with a certain degree of accuracy, thus loading different stylesheets and scripts accordingly.
Yepnope ({
test:Modernizr.touch,
yep: [' touchstyles.css ', ' touchapplication.js '],
nope: [' Mousestyles.css ', ' mouseapplication.js '],
complete:function () {
//In either case, the application is ready!
}
});
We built the stage with just a few lines of code and could give them a completely different experience based on the user's access to the device. Of course, not all conditional loads need to have both yep (yes) and nope (no) test results. One of the most common uses of yepnope is to load the shim script to compensate for the missing features of older browsers.
Yepnope ({
test:window.json,nope: [' json2.js '],
complete:function () {
//now can confidently use JSON
}
});
After the page has used yepnope, it should be the following beautiful markup structure:
You look familiar? This structure is the same as the one given in the section on the defer attribute, the only difference being that a script file here has been spliced yepnope.js (probably at the top of Deferredscripts.js), This allows you to load the scripts that are loaded conditionally (because the browser requires a shim script) and those that want to load dynamically (in order to respond to the user's actions). The result will be a more compact deferredscripts.js.
Iv. Modular loading of REQUIRE.JS/AMD
Require.js is an option that developers want to use as a scripting loader to get messy rich script applications to become more orderly. Require.js This powerful toolkit allows you to automate even the most complex scripting dependencies with AMD technology.
Now let's look at a simple script load example that uses a function with the same name as Require.js.
Require ([' moment '], function (moment) {
Console.log (Moment (). Format (' dddd '));
The Require function accepts an array of module names and then loads all of these script modules in parallel. Unlike Yepnope, Require.js does not guarantee that target scripts are run sequentially, only to ensure that their order of operation satisfies their dependency requirements, provided that
The definitions of these scripts comply with the specification of AMD (asynchronous module definition, asynchronous modules definitions).
Case One: loading JavaScript files
<script src= "./js/require.js" ></script>
<script>
require (["./js/a.js", "./js/b.js"], function () {
Myfunctiona ();
Myfunctionb ();
});
</script>
As shown in the case, there are two JavaScript files A.js and b.js, each of which defines the Myfunctiona and myfunctionb two methods, which can be used to load the two files with Requirejs, in the function part of the The code can refer to the methods in these two files.
This string array parameter in the Require method can allow different values, when the string is terminated with ". js", or starts with "/", or is a URL, the Requirejs thinks the user is loading a JavaScript file directly, otherwise, when the string is similar to " My/module ", it will consider this a module and will load the JavaScript file of the corresponding module with the user-configured BaseURL and Paths. The configuration section will be covered in more detail later.
The point here is that Requirejs by default does not guarantee that Myfunctiona and MYFUNCTIONB must be executed after the page is loaded, and that when there is a need to ensure that the page is loaded after the script is executed, REQUIREJS provides an independent Domready module, you need to go to the Requirejs official website to download this module, it is not included in the Requirejs. With the Domready module, case one of the code to do a little modification coupled with the dependence on the Domready can be.
case Two: After the page loads execute JavaScript
<script src= "./js/require.js" ></script>
<script>
require (["domready!", "./js/a.js", ". Js/b.js "], function () {
Myfunctiona ();
Myfunctionb ();
});
</script>
After executing the code for case two, you can see through Firebug that Requirejs will insert a.js and b.js on the current page and declare a < script> label separately for downloading JavaScript files asynchronously. The async attribute is currently supported by most browsers, indicating that the JS file in the < script> tab will not block downloads of other page content.
case Three: Requirejs inserted < script>
<script type= "Text/javascript" charset= "Utf-8" "async=" _ " data-requirecontext=" data-requiremodule= "Src=" Js/a.js "></script>
AMD implements a global function called define, which is provided by Require.js, which has 3 parameters:
Use Requirejs to define JavaScript modules
The JavaScript module here is different from the traditional JavaScript code in that it does not need to access global variables. The modular design allows JavaScript code to access the "global variables", through dependencies, these "global variables" as parameters to pass to the module's implementation body, in the implementation of the access or declaration of global variables or functions, Effectively avoids large and complex namespace management.
As described in the COMMONJS AMD specification, the definition of JavaScript modules is implemented through define methods.
Let's take a look at a simple example by defining a student module and a class module, implementing creating student objects in the main program and putting student objects into class.
case FOUR: Student module, Student.js
Define (function () {return
{
createstudent:function (name, gender) {return {
name:name,
Gender: gender};};
Case five: class module, Class.js
Define (function () {
var allstudents = [];
return {
ClassID: "001",
Department: "Computer",
addtoclass:function (student) {
Allstudents.push ( Student);
},
getclasssize:function () {return
allstudents.length;
}
;}
);
Case SIX: Main program
Require (["Js/student", "js/class"], function (student, CLZ) {
Clz.addtoclass (student.createstudent ("Jack", " Male "));
Clz.addtoclass (Student.createstudent ("Rose", "female"));
Console.log (Clz.getclasssize ()); Output 2
});
Student modules and class modules are separate modules, we define a new module, which relies on student and class modules so that the logic of the main program part can be packaged.
Case Seven: The manager module that relies on the student and class modules, manager.js
Define (["Js/student", "js/class"], function (student, CLZ) {return
{
addnewstudent:function (name, gender) {
Clz.addtoclass (student.createstudent (name, gender));
},
getmyclasssize:function () {
return Clz.getclasssize ();}};
Case EIGHT: the new main program
Require (["Js/manager"], function (manager) {
manager.addnewstudent ("Jack", "male");
Manager.addnewstudent ("Rose", "female");
Console.log (Manager.getmyclasssize ());//Output 2
});
With the code example above, we have a clear understanding of how to write a module, how this module is used, and how dependencies between modules are defined.
In fact, if you want to make your site faster, you can asynchronously load those temporarily unavailable script. The easiest way to do this is to use the Defer property and the Async property prudently. If you want to load the script according to the criteria, consider a script loader like Yepnope. Consider require.js if there are a lot of interdependent scripts on your site. Choose the tool that works best for your task, and then use it to enjoy the convenience it brings.
This is the full contents of the asynchronous script loading of JavaScript, which is helpful to everyone's learning.
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
