浏览器加载、渲染和解析过程黑箱简析

用 Fiddler 监控，在 IE6 下，资源下载顺序为：

很明显，下载顺序从上到下，文档流中先出现的资源先下载。在 IE8, Safari, Chrome 等浏览器下也类似。

Firefox 对下载顺序做了优化：

Firefox 会将 js, css 提前下载，而将图片等资源延迟到后面下载。

对于渲染，利用 Fiddler 将网速调慢，可以看到 css 下载后会马上渲染到页面，渲染和下载同步进行。js 的解析和运行，也类似。

对于 js 运行，以及页面加载相关事件的触发，特别做了测试。在 Firefox 下，打开测试页面：

[22:13:32.947] HTML Start[22:13:32.947] normal inline script run time[22:13:34.904] normal external script run time[22:13:35.775] [body] normal external script run time[22:13:35.789] [body end] normal external script run time[22:13:35.789] HTML End[22:13:35.791] deferred inline script run time[22:13:35.791] deferred external script run time[22:13:35.793] DOMContentLoaded[22:13:38.144] images[0] onload[22:13:38.328] images[1] onload[22:13:39.105] images[2] onload[22:13:39.105] images[3] onload[22:13:39.106] window.onload

很明显，JS 的运行严格按照文档流中的顺序进行。其中 deferred 的脚本会在最后运行（注：Firefox 3.5 开始支持 defer，而且支持得很完美）。

再来看下 IE8，结果如下：

[22:33:56.806] HTML Start[22:33:56.826] normal inline script run time[22:33:57.786] normal external script run time[22:33:57.812] deferred inline script run time[22:33:57.816] document.readyState = interactive[22:33:57.934] [body] normal external script run time[22:33:58.310] [body end] normal external script run time[22:33:58.310] HTML End[22:33:58.346] deferred external script run time[22:33:58.346] images[0].readyState = loading[22:33:58.346] images[0].readyState = complete[22:33:58.346] images[0] onload[22:33:58.361] doScroll[22:33:58.451] images[1].readyState = loading[22:33:58.479] images[1].readyState = complete[22:33:58.479] images[1] onload[22:33:58.794] images[2].readyState = loading[22:33:58.854] images[2].readyState = complete[22:33:58.854] images[2] onload[22:33:58.876] images[3].readyState = loading[22:33:58.876] images[3].readyState = complete[22:33:58.876] images[3] onload[22:33:58.887] document.readyState = complete[22:33:58.888] window.onload

可以看出，IE8 下，defer 只对 external 脚本有效，对 inline 脚本无效。另，与 DOMContentLoaded 最接近的是 doScroll. 这是 doScroll 被广泛用来模拟 DOMContentLoaded 的原因。小心：仅仅是模拟，细节上并不等价。

还可以得到一个有点意外的结果：放在 body 结束前的脚本，执行时，依旧最好放在 domready 事件中。无论在 Firefox 还是 IE 下，解析到 HTML End 时，并不代表 DOM 可以安全操作，特别是页面比较复杂时。

从上面数据中，也可以看出 YSlow 性能优化法则里，建议将样式置顶和脚本置底的根据。

有兴趣的可以进一步测试动态添加样式和脚本的情形，会稍有不同，但没有特别 surprise.

最后总结下：

页面资源的下载顺序是从上到下的，文档流中先出现的资源先下载（注：存在并发，具体请参考 UA Profiler）。当某一样式下载完成时，会立刻渲染到页面（体现了层叠样式表中层叠在渲染时的含义）。当某一脚本下载完成时，也会立刻解析和运行。脚本的运行严格按照文档流中的顺序进行，deferred 的脚本会在正常脚本运行之后运行（Firefox 和 IE 下）。

特别需要留意：脚本运行时，会暂停该脚本之下所有资源的下载（因为脚本可能改变文档流，甚至跳转页面，浏览器的暂停策略是合理的）。要小心内联脚本，经常会阻塞后续下载。

好了，废话不多说。以上结果，建议各位亲自测试，反复测试，疯狂测试，一直到眼花缭乱稀里糊涂恍然大悟继续糊涂为止……