search

Home >Web Front-end >JS Tutorial >Learn javascript asynchronous script loading with me_javascript skills

Learn javascript asynchronous script loading with me_javascript skills

WBOY
WBOYOriginal
2016-05-16 15:30:59967browse

Let’s look at this line of code first: 

<script src = "allMyClientSideCode.js"></script>

This is a little... not great. "Where should I put this?" developers will wonder, "Higher up, in the 93f0f5c25f18dab9d176bd4f6de5d30e tag? Or lower down, in the 6c04bd5ca3fcae76e30b72ad730ca86d tag?" Either approach will make rich scripts The end of the site was tragic. A large script in the 93f0f5c25f18dab9d176bd4f6de5d30e tag will stall all page rendering work, leaving the user in a "white screen of death" state until the script is loaded. The large script at the end of the 6c04bd5ca3fcae76e30b72ad730ca86d tag will only let the user see a lifeless static page, and the place where client-side rendering should be performed is scattered with non-functional controls and empty boxes.

A perfect solution to this problem requires dividing and conquering scripts: 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. But how can we decompress these scripts while ensuring their availability when called?

1. Re-understanding the 3f1c4e4b6b16bbbd69b2ee476dc4f83a tag

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.

For 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 created equal. 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 still 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: 

<html>
<head>
  <!--metadata and stylesheets go here -->
  <script src="headScripts.js"></scripts>
</head>
<body>
  <!-- content goes here -->
  <script src="bodyScripts.js"></script>
</body>
</html>

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 allow users to see the web page faster and avoid the overhead of binding the "ready" event before manipulating the DOM. But this method also has a disadvantage, that is, the browser cannot load these scripts before loading the entire document, which will be a bottleneck for large documents transmitted over slow connections.

Ideally, the script should be loaded at the same time as the document is loaded, and does 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. 

<script defer src = "deferredScript.js">

添加defer（延迟）属性相当于对浏览器说：“请马上开始加载这个脚本吧，但是，请等到文档就绪且所有此前具有defer 属性的脚本都结束运行之后再运行它。”在文档93f0f5c25f18dab9d176bd4f6de5d30e标签里放入延迟脚本，既能带来脚本置于6c04bd5ca3fcae76e30b72ad730ca86d标签时的全部好处，又能让大文档的加载速度大幅提升！

不足之处就是，并非所有浏览器都支持defer属性。这意味着，如果想确保自己的延迟脚本能在文档加载后运行，就必须将所有延迟脚本的代码都封装在诸如jQuery 之$(document).ready 之类的结构中。

上一节的页面例子改进如下：

<html>
<head>
  <!-- metadata and stylesheets go here -->
  <script src="headScripts.js"></scripts>
  <script defer src="deferredScripts.js"></script>
</head>
<body>
  <!-- content goes here -->
</body>
</html>

请记住deferredScripts 的封装很重要，这样即使浏览器不支持defer，deferredScripts 也会在文档就绪事件之后才运行。如果页面主体内容远远超过几千字节，那么付出这点代价是完全值得的。

3、 脚本的并行加载

如果你是斤斤计较到毫秒级页面加载时间的完美主义者，那么defer也许就像是淡而无味的薄盐酱油。你可不想一直等到此前所有的defer 脚本都运行结束，当然也肯定不想等到文档就绪之后才运行这些脚本，你就是想尽快加载并且尽快运行这些脚本。这也正是现代浏览器提供了async（异步）属性的原因。

<script async src = "speedyGonzales.js">
<script async src = "roadRunner.js">

如果说defer 让我们想到一种静静等待文档加载的有序排队场景，那么async 就会让我们想到混乱的无政府状态。前面给出的那两个脚本会以任意次序运行，而且只要JavaScript 引擎可用就会立即运行，而不论文档就绪与否。
对大多数脚本来说，async 是一块难以下咽的鸡肋。async 不像defer那样得到广泛的支持。同时，由于异步脚本会在任意时刻运行，它实在太容易引起海森堡蚁虫之灾了（脚本刚好结束加载时就会蚁虫四起）。
当我们加载一些第三方脚本，而且也不在乎它们谁先运行谁后运行。因此，对这些第三方脚本使用async 属性，相当于一分钱没花就提升了它们的运行速度。
上一个页面示例再添加两个独立的第三方小部件，得到的结果如下：

<html>
<head>
  <!-- metadata and stylesheets go here -->
  <script src="headScripts.js"></scripts>
  <script src="deferredScripts.js" defer></script>
</head>
<body>
  <!-- content goes here -->
  <script async defer src="feedbackWidget.js"></script>
  <script async defer src="chatWidget.js"></script>
</body>
</html>

这个页面结构清晰展示了脚本的优先次序。对于绝大多数浏览器，DOM的渲染只会延迟至headScripts.js 结束运行时。进行DOM渲染的同时会在后台加载deferredScripts.js。接着，在DOM 渲染结束时将运行deferredScripts.js 和那两个小部件脚本。这两个小部件脚本在那些支持async 的浏览器中会做无序运行。如果不确定这是否妥当，请勿使用async！
二、可编程的脚本加载
虽然3f1c4e4b6b16bbbd69b2ee476dc4f83a标签简单得令人心动，但有些情况确实需要更精致的脚本加载方式。我们可能只想给那些满足一定条件的用户加载某个脚本，譬如白金会员或达到一定级别的玩家，也可能只想当用户单击激活时才加载某个特性，譬如聊天小部件。
1、直接加载脚本
我们可以用类似下面这样的代码来插入3f1c4e4b6b16bbbd69b2ee476dc4f83a标签。

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

稍等，我们如何才能知道脚本何时加载结束呢？我们可以给脚本本身添加一些代码以触发事件，但如果要为每个待加载脚本都添加这样的代码，那也太闹心了。或者是另外一种情况，即我们不可能给第三方服务器上的脚本添加这样的代码。HTML5 规范定义了一个可以绑定回调的onload 属性。

script.onload = function() {
// 现在可以调用脚本里定义的函数了
};

不过， IE8 及更老的版本并不支持onload ， 它们支持的是onreadystatechange。某些浏览器在插入3f1c4e4b6b16bbbd69b2ee476dc4f83a标签时还会出现一些“灵异事件”。而且，这里甚至还没谈到错误处理呢！为了避免
所有这些令人头疼的问题，在此强烈建议使用脚本加载库。

三、yepnope的条件加载
yepnope是一个简单的、轻量级的脚本加载库（压缩后的精简版只有1.7KB），其设计目标就是真诚服务于最常见的动态脚本加载需求。
yepnope 最简单的用法是，加载脚本并对脚本完成运行这一事件返回一个回调。

yepnope({
  load: 'oompaLoompas.js',
  callback: function() {
  console.log('oompa-Loompas ready!');
  }
});

还是无动于衷？下面我们要用yepnope 来并行加载多个脚本并按给定次序运行它们。举个例子，假设我们想加载Backbone.js，而这个脚本又依赖于Underscore.js。为此，我们只需用数组形式提供这两个脚本的位置作为加载参数。

yepnope({
  load: ['underscore.js', 'backbone.js'],
  complete: function() {
  // 这里是Backbone 的业务逻辑
  }
});

请注意，这里使用了complete（完成）而不是callback（回调）。

其差别在于，脚本加载列表中的每个资源均会运行callback，而只有当所有脚本都加载完成后才会运行complete。yepnope 的标志性特征是条件加载。给定test 参数，yepnope 会根据该参数值是否为真而加载不同的资源。举个例子，可以以一定的准确度判断用户是否在用触摸屏设备，从而据此相应地加载不同的样式表及脚本。

yepnope({
  test: Modernizr.touch,
  yep: ['touchStyles.css', 'touchApplication.js'],
  nope: ['mouseStyles.css', 'mouseApplication.js'],
  complete: function() {
  // 不管是哪一种情况，应用程序均已就绪！
  }
});

我们只用寥寥几行代码就搭好了舞台，可以基于用户的接入设备而给他们完全不同的使用体验。当然，不是所有的条件加载都需要备齐yep（是）和nope（否）这两种测试结果。yepnope 最常见的用法之一就是加载垫片脚本以弥补老式浏览器缺失的功能。

yepnope({
  test: window.json,nope: ['json2.js'],
  complete: function() {
  // 现在可以放心地用JSON 了
  }
});

页面使用了yepnope 之后应该变成下面这种漂亮的标记结构：

<html>
<head>
  <!-- metadata and stylesheets go here -->
  <script src="headScripts.js"></scripts>
  <script src="deferredScripts.js" defer></script>
</head>
<body>
  <!-- content goes here -->
</body>
</html>

很眼熟？这个结构和讨论defer 属性那一节给出的结构一样，唯一的区别是这里的某个脚本文件已经拼接了yepnope.js（很可能就在deferredScripts.js 的顶部），这样就可以独立地加载那些根据条件再加载的脚本（因为浏览器需要垫片脚本）和那些想要动态加载的脚本（以便回应用户的动作）。结果将是一个更小巧的deferredScripts.js。
四、Require.js/AMD 模块化加载
开发人员想通过脚本加载器让混乱不堪的富脚本应用变得更规整有序一些，而Require.js 就是这样一种选择。Require.js 这个强大的工具包能够自动和AMD技术一起捋顺哪怕最复杂的脚本依赖图。
现在先来看一个用到Require.js 同名函数的简单脚本加载示例。

require(['moment'], function(moment) {
  console.log(moment().format('dddd')); // 星期几
});

require 函数接受一个由模块名称构成的数组，然后并行地加载所有这些脚本模块。与yepnope 不同，Require.js 不会保证按顺序运行目标脚本，只是保证它们的运行次序能满足各自的依赖性要求，但前提是
这些脚本的定义遵守了AMD（Asynchronous Module Definition，异步模块定义）规范。
案例一： 加载 JavaScript 文件

 <script src="./js/require.js"></script> 
<script> 
  require(["./js/a.js", "./js/b.js"], function() { 
       myFunctionA(); 
       myFunctionB(); 
    }); 
</script>

如案例一 所示，有两个 JavaScript 文件 a.js 和 b.js，里面各自定义了 myFunctionA 和 myFunctionB 两个方法，通过下面这个方式可以用 RequireJS 来加载这两个文件，在 function 部分的代码可以引用这两个文件里的方法。

require 方法里的这个字符串数组参数可以允许不同的值，当字符串是以”.js”结尾，或者以”/”开头，或者就是一个 URL 时，RequireJS 会认为用户是在直接加载一个 JavaScript 文件，否则，当字符串是类似”my/module”的时候，它会认为这是一个模块，并且会以用户配置的 baseUrl 和 paths 来加载相应的模块所在的 JavaScript 文件。配置的部分会在稍后详细介绍。

这里要指出的是，RequireJS 默认情况下并没有保证 myFunctionA 和 myFunctionB 一定是在页面加载完成以后执行的，在有需要保证页面加载以后执行脚本时，RequireJS 提供了一个独立的 domReady 模块，需要去 RequireJS 官方网站下载这个模块，它并没有包含在 RequireJS 中。有了 domReady 模块，案例一 的代码稍做修改加上对 domReady 的依赖就可以了。
案例二： 页面加载后执行 JavaScript

 <script src="./js/require.js"></script> 
<script> 
  require(["domReady!", "./js/a.js", "./js/b.js"], function() { 
       myFunctionA(); 
       myFunctionB(); 
    }); 
</script>

执行案例二的代码后，通过 Firebug 可以看到 RequireJS 会在当前的页面上插入为 a.js 和 b.js 分别声明了一个 27835793f4768f4164d1421d99e293bc 标签，用于异步方式下载 JavaScript 文件。async 属性目前绝大部分浏览器已经支持，它表明了这个 27835793f4768f4164d1421d99e293bc 标签中的 js 文件不会阻塞其他页面内容的下载。
案例三：RequireJS 插入的 27835793f4768f4164d1421d99e293bc

<script type="text/javascript" charset="utf-8" async="" data-requirecontext="_" 
 data-requiremodule="js/a.js" src="js/a.js"></script>

AMD推行一个由Require.js 负责提供的名叫define 的全局函数，该函数有3 个参数：

  • 模块名称，
  • 模块依赖性列表，
  • 在那些依赖性模块加载结束时触发的回调。

使用 RequireJS 来定义 JavaScript 模块
这里的 JavaScript 模块与传统的 JavaScript 代码不一样的地方在于它无须访问全局的变量。模块化的设计使得 JavaScript 代码在需要访问”全局变量”的时候，都可以通过依赖关系，把这些”全局变量”作为参数传递到模块的实现体里，在实现中就避免了访问或者声明全局的变量或者函数，有效的避免大量而且复杂的命名空间管理。
如同 CommonJS 的 AMD 规范所述，定义 JavaScript 模块是通过 define 方法来实现的。
下面我们先来看一个简单的例子，这个例子通过定义一个 student 模块和一个 class 模块，在主程序中实现创建 student 对象并将 student 对象放到 class 中去。
案例四： student 模块，student.js

define(function(){ 
   return { 
    createStudent: function(name, gender){ 
       return { 
         name: name, 
         gender: gender 
       }; 
    } 
   }; 
 });

案例五：class 模块，class.js

 define(function() { 
 var allStudents = []; 
    return { 
      classID: "001", 
      department: "computer", 
      addToClass: function(student) { 
      allStudents.push(student); 
      }, 
      getClassSize: function() { 
      return allStudents.length; 
      } 
    }; 
   } 
 );

案例六： 主程序

 require(["js/student", "js/class"], function(student, clz) { 
   clz.addToClass(student.createStudent("Jack", "male")); 
   clz.addToClass(student.createStudent("Rose", "female")); 
   console.log(clz.getClassSize()); // 输出 2 
 });

student 模块和 class 模块都是独立的模块，下面我们再定义一个新的模块，这个模块依赖 student 和 class 模块，这样主程序部分的逻辑也可以包装进去了。
案例七：依赖 student 和 class 模块的 manager 模块，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(); 
    } 
   }; 
});

案例八：新的主程序

require(["js/manager"], function(manager) { 
   manager.addNewStudent("Jack", "male"); 
   manager.addNewStudent("Rose", "female"); 
   console.log(manager.getMyClassSize());// 输出 2 
 });

通过上面的代码示例，我们已经清楚的了解了如何写一个模块，这个模块如何被使用，模块间的依赖关系如何定义。

其实要想让自己的站点更快捷，可以异步加载那些暂时用不到的脚本。为此最简单的做法是审慎地使用defer 属性和async 属性。如果要求根据条件来加载脚本，请考虑像yepnope 这样的脚本加载器。如果站点存在大量相互依赖的脚本，请考虑Require.js。选择最适合任务的工具，然后使用它，享受它带来的便捷。

以上就是关于javascript的异步脚本加载的全部内容，想对大家的学习有所帮助。

Statement：
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn
Previous article：jQuery implements simple file upload progress bar effect_jqueryNext article：jQuery implements simple file upload progress bar effect_jquery

Related articles

See more