me_javascript 기술로 javascript 비동기 스크립트 로딩 배우기
- WBOY원래의
- 2016-05-16 15:30:591020검색
먼저 다음 코드 줄을 살펴보겠습니다.
<script src = "allMyClientSideCode.js"></script>
이건 좀... 별로네요. "이것을 어디에 두어야 할까요?" 개발자들은 "더 높은 곳에 있는 93f0f5c25f18dab9d176bd4f6de5d30e 태그에? 아니면 더 낮은 곳에 있는 6c04bd5ca3fcae76e30b72ad730ca86d 태그에?"라고 궁금해할 것입니다. . 93f0f5c25f18dab9d176bd4f6de5d30e 태그의 큰 스크립트는 모든 페이지 렌더링 작업을 중단시켜 스크립트가 로드될 때까지 사용자를 "백색 화면" 상태로 남겨둡니다. 6c04bd5ca3fcae76e30b72ad730ca86d 태그 끝에 있는 큰 스크립트는 사용자에게 생명이 없는 정적 페이지만 표시하며 클라이언트 측 렌더링이 수행되어야 하는 위치는 작동하지 않는 컨트롤과 빈 상자로 흩어져 있습니다.
이 문제를 완벽하게 해결하려면 스크립트를 분할하고 정복해야 합니다. 페이지를 더 보기 좋고 사용하기 쉽게 만드는 스크립트는 즉시 로드해야 하고, 나중에 로드할 수 있는 스크립트는 나중에 로드해야 합니다. 하지만 호출 시 가용성을 보장하면서 이러한 스크립트의 압축을 어떻게 풀 수 있을까요?
1. 3f1c4e4b6b16bbbd69b2ee476dc4f83a 태그에 대한 이해
최신 브라우저의 3f1c4e4b6b16bbbd69b2ee476dc4f83a 태그는 클래식과 비차단이라는 두 가지 새로운 유형으로 나뉩니다. 이 두 태그를 사용하여 페이지를 최대한 빨리 로드하는 방법에 대해 논의해 보겠습니다.
1. 차단 스크립트는 어디로 갈까요?
3f1c4e4b6b16bbbd69b2ee476dc4f83a 태그의 표준 버전을 차단 태그라고도 합니다. 이 용어는 문맥에 맞게 이해해야 합니다. 최신 브라우저에서 차단하는 3f1c4e4b6b16bbbd69b2ee476dc4f83a 태그를 보면 차단 지점을 건너뛰고 계속해서 문서를 읽고 다른 리소스(스크립트 및 스타일시트)를 다운로드합니다. 그러나 브라우저는 스크립트가 다운로드되어 실행될 때까지 초크 포인트를 넘어 해당 리소스를 평가하지 않습니다. 따라서 웹 문서의 93f0f5c25f18dab9d176bd4f6de5d30e 태그 내에 5개의 차단 3f1c4e4b6b16bbbd69b2ee476dc4f83a 태그가 있는 경우 5개의 스크립트가 모두 다운로드되어 실행될 때까지 사용자에게는 페이지 제목만 표시됩니다. 그뿐만 아니라 이러한 스크립트가 실행되더라도 문서에서 차단 지점 이전 부분만 볼 수 있습니다. 6c04bd5ca3fcae76e30b72ad730ca86d 태그에 로드되기를 기다리는 모든 항목을 보려면 document.onreadystatechange와 같은 이벤트에 이벤트 핸들러를 바인딩해야 합니다.
위의 이유로 페이지의 6c04bd5ca3fcae76e30b72ad730ca86d 태그 끝에 스크립트를 배치하는 것이 점점 더 인기를 얻고 있습니다. 이러한 방식으로 사용자는 페이지를 더 빠르게 볼 수 있고, 스크립트는 이벤트가 스스로 트리거될 때까지 기다리지 않고 DOM에 적극적으로 액세스할 수도 있습니다. 대부분의 스크립트에서 이 "이동"은 엄청난 개선입니다.
그러나 모든 스크립트가 동일하게 생성되는 것은 아닙니다. 스크립트를 아래로 이동하기 전에 스스로에게 2가지 질문을 던져보세요.
- 이 스크립트가 6c04bd5ca3fcae76e30b72ad730ca86d 태그의 인라인 JavaScript에 의해 직접 호출될 수 있습니까? 대답은 분명할 수도 있지만 여전히 확인해 볼 가치가 있습니다.
- 이 스크립트가 렌더링된 페이지의 모양에 영향을 미치나요? Typekit 호스트 글꼴이 한 가지 예입니다. Typekit 스크립트를 문서 끝에 배치하면 페이지 텍스트가 문서를 읽을 때 즉시 렌더링되고, 스크립트가 실행될 때 다시 두 번 렌더링됩니다.
위 질문에 대한 대답 중 하나가 '예'이면 스크립트는 93f0f5c25f18dab9d176bd4f6de5d30e 태그에 배치되어야 하며, 그렇지 않으면 문서 모양은 다음과 같습니다. 🎜>
<html> <head> <!--metadata and stylesheets go here --> <script src="headScripts.js"></scripts> </head> <body> <!-- content goes here --> <script src="bodyScripts.js"></script> </body> </html>
2. 스크립트 조기 로딩 및 지연 실행
대부분의 스크립트를 6c04bd5ca3fcae76e30b72ad730ca86d에 배치하는 것이 좋습니다. 이렇게 하면 사용자가 웹페이지를 더 빠르게 볼 수 있고 DOM을 조작하기 전에 "ready" 이벤트를 바인딩하는 오버헤드를 피할 수 있습니다. 하지만 이 방법에는 단점도 있습니다.즉, 브라우저는 전체 문서를 로드하기 전에 이러한 스크립트를 로드할 수 없으며 이는 느린 연결을 통해 전송되는 대용량 문서에 병목 현상이 발생합니다.
이상적으로는 문서가 로드되는 동시에 스크립트도 로드되어야 하며 DOM 렌더링에 영향을 주지 않습니다. 이렇게 하면 스크립트가 3f1c4e4b6b16bbbd69b2ee476dc4f83a 태그 순서대로 이미 로드되어 있으므로 문서가 준비되면 스크립트를 실행할 수 있습니다.지금까지 읽으셨다면 이러한 요구 사항을 충족할 수 있는 사용자 정의 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的异步脚本加载的全部内容，想对大家的学习有所帮助。