defer和async（原生js学习）转

（1）

页面下载过程要干的事情

页面parse完毕----DOMContentLoaded（DOM树建立完毕）----onload（全部资源下完，图片，iframe，flash这些）

注意js脚本要下载并执行完毕，dom树才能出来，因为script标签也属dom的一部分，同时因为js也许有dom的操作，所以必须要等js脚本执行完毕，才能完成dom的构建。

parse的过程则可理解为对文档全部扫一遍，知道要干什么，接下来才是整个DOM的构建过程。parse the markup and set the dom

（2）

如果既没defer也没async，而且js仍放于头部，则页面要等待js的下载和js的执行，会出现空白页的情况。

（3）

defer不被所有浏览器支持。defer之后，脚本的执行在页面解析完毕以后，在DOMContentLoaded事件之前。

（4）

async的特点是，一下载完成就执行，多个js如果都设置async则能形成并行下载，不一定按照文档的排放顺序，所以多个js之间有依赖关系，则容易出现问题，同时只能应用于外部脚本。

Asynchronous scripts are guaranteed to execute before the page’s load event and may execute before or after DOMContentLoaded (see Chapter 13 for details). Firefox 3.6, Safari 5, and Chrome 7 support asynchronous scripts.

async最少要比load快，，，，有可能快或者慢于DOMContentLoaded（不知道为什么，感觉它要比defer还快的，而且defer都是快于DOMContentLoaded，这个疑问以后来搞。。）

如果async为false，defer为true，那么脚本会在页面解析完毕后才执行（有defer的时候，js脚本的下载并不会影响文档的解析，脚本在页面解析完后执行，这个时候脚本再执行完毕后，才构建好DOM，所以一定是先于DOMContentLoad事件的）

如果async和defer都为false，那么脚本会在页面解析中，停止页面解析，立刻下载并且执行，形成block阻塞。

设 置defer和async后，两者的加载（下载）都不阻塞页面渲染（parse），但是async是下载后就立即执行，所以会在parse完毕前执行，这 个执行过程会阻塞页面渲染（怕有dom操作），而defer是一定不会阻塞的，因为它执行的时候，页面已经parse完毕（后面脚本执行，修改dom不算 进来）。

IE不支持DOMContentLoaded事件，检测doScroll来模拟（判断页面是否可以滚动）