前言
关于JavaScript脚本加载的问题，相信大家碰到很多。主要在几个点——
1> 同步脚本和异步脚本带来的文件加载、文件依赖及执行顺序问题 2> 同步脚本和异步脚本带来的性能优化问题
深入理解脚本加载相关的方方面面问题，不仅利于解决实际问题，更加利于对性能优化的把握并执行。
如果放在
上面，会阻塞所有页面渲染工作，使得用户在脚本加载完毕并执行完毕之前一直处于“白屏死机”状态。而末尾的打脚本只会让用户看到毫无生命力的静态页面，原本应该进行客户端渲染的地方却散布着不起作用的控件和空空如也的方框。拿一个测试用例——添加defer属性相当于告诉浏览器：请马上开始加载这个脚本吧，但是，请等到文档就绪且此前所有具有defer属性的脚本都结束运行之后再运行它。
这样，在head标签里放入延迟脚本，技能带来脚本置于body标签时的所有好处，又能让大文档的加载速度大幅提升。此时的页面模式便是——
但是并非所有的浏览器都支持defer（对于一些modern浏览器，如果声明defer，其内部脚本将不会执行document.write及DOM渲染操作。IE4+均支持defer属性）。这意味着，如果想确保自己的延迟脚本能在文档加载后运行，就必须将所有延迟脚本的代码都封装在诸如jQuery之$(document).ready之类的结构中。这是值得的，因为差不多97%的访客都能享受到并行加载的好处，同时另外3%的访客仍然能使用功能完整的JavaScript。
二、脚本的完全并行化
让脚本的加载及执行再快一步，我不想等到defer脚本一个接着一个运行（defer让我们想到一种静静等待文档加载的有序排队场景），更不想等到文档就绪之后才运行这些脚本，我想要尽快加载并且尽快运行这些脚本。这里也就想到了HTML5的async属性，但是要注意，它是一种混乱的无政府状态。
例如，我们加载两个完全不相干的第三方脚本，页面没有它们也运行得很好，而且也不在乎它们谁先运行谁后运行。因此，对这些第三方脚本使用async属性，相当于一分钱没花就提升了它们的运行速度。
async属性是HTML5新增的。作用和defer类似，即允许在下载脚本的同时进行DOM的渲染。但是它将在下载后尽快执行（即JS引擎空闲了立马执行），不能保证脚本会按顺序执行。它们将在onload 事件之前完成。
Firefox 3.6、Opera 10.5、IE 9 和 最新的Chrome 和 Safari 都支持 async 属性。可以同时使用 async 和 defer，这样IE 4之后的所有 IE 都支持异步加载，但是要注意，async会覆盖掉defer。
那么此时的页面模型如下——
要注意这里的执行顺序——各个脚本文件加载，接着执行headScript.js，紧接着在DOM渲染的同时会在后台加载defferedScript.js。接着在DOM渲染结束时将运行defferedScript.js和那两个异步脚本，要注意对于支持async属性的浏览器而言，这两个脚本将做无序运行。
三、可编程的脚本加载
尽管上面两个脚本属性的功能非常吸引人，但是由于兼容性的问题，应用并不是很广泛。故此，我们更多使用脚本加载其他脚本。例如，我们只想给那些满足一定条件的用户加载某个脚本，也就是经常提到的“懒加载”。
在浏览器API层面，有两种合理的方法来抓取并运行服务器脚本——
2> 向DOM插入