转载自:http://www.nowamagic.net/librarys/veda/detail/1077javascript
这个总结来源于一次优化的请求,最初某个页面的加载十分缓慢,load事件迟迟没法触发,所以但愿能够经过对静态文件分域名等方式对页面的外部资源进行优化,拿得load事件尽量早地触发。因而我查看了页面的源码,并对外部资源进行了整理,基于下面2个理念画出了一个推测的瀑布图:css
然而,当我看到各浏览器中实际的瀑布图时,我知道本身又犯了一个简单的错误:太过相信所谓的权威和大众的声音,而没有更早地进行实践来检验理论的正确性……java
本篇文章就使用几种流行的浏览器,针对同一个页面的外部资源加载过程进行分析,推测各浏览器加载外部资源的策略、特征,并最后给予必定的比较和总结。算法
测试的页面结构以下:浏览器
共12个外部资源,加上页面自己,一次完整的加载一共有13次HTTP GET请求。服务器
针对每个外部资源,服务器首先会休眠5秒的时间,随后再返回相应的内容,以方便查看整个外部资源的加载过程。并发
测试的浏览器以下:工具
IE6的瀑布图很是传统,其特征有:测试
可见网上盛传的2个"误区"都来自IE6统治浏览器市场的时代,针对IE6的优化太多太多,你们也就习惯性地将这些结论做为公理来使用了。优化
和IE6彻底不一样的瀑布图,其特色有:
和IE8的几乎彻底同样:
不知是由于设计理念上的不一样,仍是由于beta版未照顾到这一块,Firefox4反而退化了,和Firefox3.6的区别主要体如今对资源类型的处理上,Firefox4再也不严格地优先下载script和link标签订义的外部资源,而是按照HTML结构中出现的顺序来进行加载。
Chrome自带的工具不能很清楚地表示各请求的开始时间,因此使用了Fiddler的瀑布图,从图上能够看出,Chrome也是比较特立独行的一位,其特色有:
先报怨一下,Dragonfly不怎么好用来着……Opera的资源加载也比较有特点,并且很难看出规律,只能大体总结一下:
抛开IE6不论的话,除非是在线相册之类外部资源很是多的页面,否则不必去追求静态资源的分域名优化。
针对IE6进行静态资源分域名优化时,要严格注意javascript文件对后续资源的阻塞,进行精确计算和设计后保证资源最完美地分域名存储,以提供最大并行度。
鉴于Chrome对head部分的资源会独立加载,当head部分用不满6个HTTP并发数时,是否能够将资源移到body中呢?在body中的资源又会引发其余的问题,须要谨慎考虑。
Opera的行为比较怪异,彷佛主动设计了一个很麻烦的算法,不过考虑到其占有率,就先放在一边吧……并且号称最快的浏览器的Opera,在加载javascript文件时居然如此笨拙……
Firefox4 beta12的行为让人没法理解,看来要追踪RC版是否还存在这个问题,若是存在的话能够考虑找Mozilla报个问题了。
对各浏览器加载外部资源的策略的掌握,是WPO的基本元素,虽然一直想当一个WPO的专家,却在这方面迟迟不肯实践,实在有愧于本身的理想……