跟我學習javascript的非同步腳本載入_javascript技巧
- WBOY原創
- 2016-05-16 15:30:591011瀏覽
先來看這行程式碼：
<script src = "allMyClientSideCode.js"></script>
這有點…不怎麼樣。 「這該放在哪裡？」開發人員會奇怪，「靠上點，放到
標籤裡？還是靠下點，放到標籤裡？」這兩種做法都會讓富腳本站點的下場很淒慘。 標籤裡的大腳本會滯壓所有頁面渲染工作，使得使用者在腳本載入完畢之前一直處於「白屏死機」狀態。而標籤末尾的大腳本只會讓用戶看到毫無生命力的靜態頁面，原本應該進行客戶端渲染的地方卻散佈著不起作用 的控件和空空如也的方框。完美解決這個問題需要對腳本分而治之：那些負責讓頁面更好看、更好用的腳本應該立即加載，而那些可以待會兒再加載的腳本稍後再加載。但是怎麼才能既滯壓這些腳本，又能保證它們在被呼叫時的可用性呢？
一、<script>標籤的再認識</script>
現代瀏覽器中的<script>標籤分成了兩種新類型：經典型和非阻塞型。接下來討論如何運用這兩種標籤來盡快載入頁面。 </script>
1、阻塞型腳本何去何從？
標準版本的<script>標籤常被稱為阻塞型標籤。這個字必須放在上下文中理解：現代瀏覽器看到阻塞型<script>標籤時，會跳過阻塞點繼續讀取文件及下載其他資源（腳本和樣式表）。但直到腳本下載完畢並執行之後，瀏覽器才會評估阻塞點之後的那些資源。因此，如果網頁文件的<head>標籤裡有5 個阻塞型<script>標籤，則在所有這5 個腳本都下載完畢並運行之前，用戶除了頁面標題之外看不到任何東西。不僅如此，即便這些腳本運行了，它們也只能看到阻塞點之前的那部分文件。如果想看到<body>標籤中正等待載入的那些好東西，就必須給像document.onreadystatechange 這樣的事件綁定一個事件處理器。 </script>
基於上述原因，現在越來越流行把腳本放在頁面
標籤的尾部。這樣，一方面使用者可以更快地看到頁面，另一方面腳本也可以主動親密接觸DOM 而無需等待事件來觸發自己。對大多數腳本而言，這次「搬家」是個巨大的進步。但並非所有腳本都一樣。在向下搬動腳本之前，請先問自己2 個問題。
- 該腳本是否有可能被標籤裡的內嵌JavaScript 直接呼叫？答案可能一目了然，但仍值得核實一遍。
- 該腳本是否會影響已渲染頁面的外觀？ Typekit 宿主字體就是一個例子。如果把Typekit 腳本放在文件結尾，那麼頁面文字就會渲染兩次，也就是讀取文件時即時渲染，腳本執行時再渲染。
上述問題只要有一個答案是肯定的，那麼該腳本就應該放在
標籤中，否則就可以放在標籤中，文檔形如：<html> <head> <!--metadata and stylesheets go here --> <script src="headScripts.js"></scripts> </head> <body> <!-- content goes here --> <script src="bodyScripts.js"></script> </body> </html>
這確實大大縮短了載入時間，但要注意一點，這可能會讓使用者有機會在載入bodyScripts.js 之前與頁面互動。
2、腳本的提前載入與延遲運作
上面建議將大多數腳本放在
中，因為這樣既能讓使用者更快地看到網頁，又能避免操控DOM之前綁定「就緒」事件的開銷。但這種方式也有一個缺點，即瀏覽器在載入完整個文件之前無法載入這些腳本，這對那些透過慢速連線傳送的大型文件來說會是一大瓶頸。理想情況下，腳本的載入應該與文件的載入同時進行，並且不影響DOM 的渲染。這樣，一旦文件就緒就可以運行腳本，因為已經按照<script>標籤的順序載入了對應腳本。 </script>
如果大家已經讀到這裡了，那麼一定會迫不及待地想寫一個自訂Ajax 腳本載入器以滿足這樣的需求！不過，大多數瀏覽器都支援一個更為簡單的解決方案。
<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的异步脚本加载的全部内容，想对大家的学习有所帮助。