跟我学习跟我学习javascript的异步脚本加载的异步脚本加载
先来看这行代码：
<script src = "allMyClientSideCode.js"></script>
这有点儿……不怎么样。“这该放在哪儿？”开发人员会奇怪，“靠上点，放到<head>标签里？还是靠下点，放到<body>标签
里？”这两种做法都会让富脚本站点的下场很凄惨。<head>标签里的大脚本会滞压所有页面渲染工作，使得用户在脚本加载完
毕之前一直处于“白屏死机”状态。而<body>标签末尾的大脚本只会让用户看到毫无生命力的静态页面，原本应该进行客户端渲
染的地方却散布着不起作用 的控件和空空如也的方框。
完美解决这个问题需要对脚本分而治之：那些负责让页面更好看、更好用的脚本应该立即加载，而那些可以待会儿再加载的脚
本稍后再加载。但是怎样才能既滞压这些脚本，又能保证它们在被调用时的可用性呢？
一、一、<script>标签的再认识标签的再认识
现代浏览器中的<script>标签分成了两种新类型：经典型和非阻塞型。接下来讨论如何运用这两种标签来尽快加载页面。
1、阻塞型脚本何去何从？、阻塞型脚本何去何从？
标准版本的<script>标签常常被称作阻塞型标签。这个词必须放在上下文中进行理解：现代浏览器看到阻塞型<script>标签
时，会跳过阻塞点继续读取文档及下载其他资源（脚本和样式表）。但直到脚本下载完毕并运行之后，浏览器才会评估阻塞点
之后的那些资源。因此，如果网页文档的<head>标签里有5 个阻塞型<script>标签，则在所有这5 个脚本均下载完毕并运行之
前，用户除了页面标题之外看不到任何东西。不仅如此，即便这些脚本运行了，它们也只能看到阻塞点之前的那部分文档。如
果想看到<body>标签中正等待加载的那些好东西，就必须给像document.onreadystatechange 这样的事件绑定一个事件处理
器。
基于上述原因，现在越来越流行把脚本放在页面<body>标签的尾部。这样，一方面用户可以更快地看到页面，另一方面脚本
也可以主动亲密接触DOM 而无需等待事件来触发自己。对大多数脚本而言，这次“搬家”是个巨大的进步。
但并非所有脚本都一样。在向下搬动脚本之前，请先问自己2 个问题。
该脚本是否有可能被<body>标签里的内联JavaScript 直接调用？答案可能一目了然，但仍值得核查一遍。
该脚本是否会影响已渲染页面的外观？Typekit 宿主字体就是一个例子。如果把Typekit 脚本放在文档末尾，那么页面文本就会
渲染两次，即读取文档时即刻渲染，脚本运行时再次渲染。
上述问题只要有一个答案是肯定的，那么该脚本就应该放在<head>标签中，否则就可以放在<body>标签中，文档形如：
<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、、 脚本的提前加载与延迟运行脚本的提前加载与延迟运行
上面建议将大多数脚本放在<body>中，因为这样既能让用户更快地看到网页，又能避免操控DOM之前绑定“就绪”事件的开
销。但这种方式也有一个缺点，即浏览器在加载完整个文档之前无法加载这些脚本，这对那些通过慢速连接传送的大型文档来即浏览器在加载完整个文档之前无法加载这些脚本，这对那些通过慢速连接传送的大型文档来
说会是一大瓶颈。说会是一大瓶颈。
理想情况下，脚本的加载应该与文档的加载同时进行，并且不影响DOM 的渲染。这样，一旦文档就绪就可以运行脚本，因为
已经按照<script>标签的次序加载了相应脚本。
如果大家已经读到这里了，那么一定会迫不及待地想写一个自定义Ajax 脚本加载器以满足这样的需求！不过，大多数浏览器
都支持一个更为简单的解决方案。
<script defer src = "deferredScript.js">
添加defer（延迟）属性相当于对浏览器说：“请马上开始加载这个脚本吧，但是，请等到文档就绪且所有此前具有defer 属性
的脚本都结束运行之后再运行它。”在文档<head>标签里放入延迟脚本，既能带来脚本置于<body>标签时的全部好处，又能让
大文档的加载速度大幅提升！
不足之处就是，并非所有浏览器都支持defer属性。这意味着，如果想确保自己的延迟脚本能在文档加载后运行，就必须将所
资源评论
