跟我学习javascript的异步脚本加载

先来看这行代码：

rush:js;">

这确实大大缩短了加载时间，但要注意一点，这可能让用户有机会在加载bodyScripts.js 之前与页面交互。

2、脚本的提前加载与延迟运行

上面建议将大多数脚本放在中，因为这样既能让用户更快地看到网页，又能避免操控DOM之前绑定“就绪”事件的开销。但这种方式也有一个缺点，

即浏览器在加载完整个文档之前无法加载这些脚本，这对那些通过慢速连接传送的大型文档来说会是一大瓶颈。

理想情况下，脚本的加载应该与文档的加载同时进行，并且不影响DOM 的渲染。这样，一旦文档就绪就可以运行脚本，因为已经按照

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

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

很眼熟？这个结构和讨论defer 属性那一节给出的结构一样，唯一的区别是这里的某个脚本文件已经拼接了yepnope.js（很可能就在deferredScripts.js 的顶部），这样就可以独立地加载那些根据条件再加载的脚本（因为浏览器需要垫片脚本）和那些想要动态加载的脚本（以便回应用户的动作）。结果将是一个更小巧的deferredScripts.js。

四、Require.js/AMD 模块化加载

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

如案例一所示，有两个 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

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

跟我学习javascript的异步脚本加载

即浏览器在加载完整个文档之前无法加载这些脚本，这对那些通过慢速连接传送的大型文档来说会是一大瓶颈。

四、Require.js/AMD 模块化加载

相关推荐