| 订阅 RSS

各浏览器对页面外部资源加载的策略

March 9th, 2011 | No Comments | 目录: Web

这个总结来源于一次优化的请求,最初某个页面的加载十分缓慢,load事件迟迟无法触发,因此希望可以通过对静态文件分域名等方式对页面的外部资源进行优化,拿得load事件尽可能早地触发。

于是我查看了页面的源码,并对外部资源进行了整理,基于下面2个理念画出了一个推测的瀑布图:

  • 浏览器对同一个域只能并发2个HTTP请求 – 网上盛传已久。
  • javascript文件的加载会阻塞浏览器其他资源的加载 – 同样网上盛传已久。

然而,当我看到各浏览器中实际的瀑布图时,我知道自己又犯了一个简单的错误:太过相信所谓的权威和大众的声音,而没有更早地进行实践来检验理论的正确性……

本篇文章就使用几种流行的浏览器,针对同一个页面的外部资源加载过程进行分析,推测各浏览器加载外部资源的策略、特征,并最后给予一定的比较和总结。

测试样例

测试的页面结构如下:

  • head
    • 1.css + 1.js
  • body
    • 1.jpg + 2.jpg + 2.js + 2.css + 3.jpg + 4.jpg + 3.css + 3.js + 5.jpg + 6.jpg

共12个外部资源,加上页面本身,一次完整的加载一共有13次HTTP GET请求。

针对每一个外部资源,服务器首先会休眠5秒的时间,随后再返回相应的内容,以方便查看整个外部资源的加载过程。

测试的浏览器如下:

  • IE6
  • IE8
  • Firefox3.6
  • Firefox4.0 beta12
  • Chrome 8
  • Opera 11

IE6

IE6的瀑布图非常传统,其特征有:

  • 各资源按照在HTML中出现的顺序进行加载。
  • javascript文件会阻塞其后所有资源的加载。
  • 最大并发HTTP连接数为2个。

可见网上盛传的2个“误区”都来自IE6统治浏览器市场的时代,针对IE6的优化太多太多,大家也就习惯性地将这些结论作为公理来使用了。

IE8

和IE6完全不同的瀑布图,其特点有:

  • 最大并发HTTP连接数为6个。
  • javascript文件已经不会阻塞其他资源的加载,甚至多个javascript文件可以一起加载,并且会保证执行的顺序。
  • 会分析HTML结构,优先下载script和link标签定义的外部资源。

Firefox3.6

和IE8的几乎完全一样:

  • 最大并发HTTP连接数为6个(可在about:config中修改)。
  • javascript文件不会阻塞其他资源的加载,多个javascript文件可以一起加载。
  • 会分析HTML结构,优先下载script和link标签定义的外部资源。

Firefox4 beta12

不知是因为设计理念上的不同,还是因为beta版未照顾到这一块,Firefox4反而退化了,和Firefox3.6的区别主要体现在对资源类型的处理上,Firefox4不再严格地优先下载script和link标签定义的外部资源,而是按照HTML结构中出现的顺序来进行加载。

Chrome8

Chrome自带的工具不能很清楚地表示各请求的开始时间,所以使用了Fiddler的瀑布图,从图上可以看出,Chrome也是比较特立独行的一位,其特点有:

  • 最大并发HTTP连接数为6。
  • head部分的资源会单独下载,且阻塞body中的其他资源的加载。
  • 会优先加载script和link标签定义的资源。

Opera11

先报怨一下,Dragonfly不怎么好用来着……Opera的资源加载也比较有特色,而且很难看出规律,只能大致总结一下:

  • 最大并发HTTP连接数为5(网上有说原先版本是4)。经过网友的指正,Opera的最大并发HTTP连接数默认为16,可在opera:config - Performance - Max Connections Server查看和修改。
  • javascript文件的加载会阻塞其他script和link标签定义的外部资源的加载,如图中的2.js。但不会阻塞图片等其他资源的加载,如图中的3.js。
  • 会一定程度上对资源的优先级进行优化,但由于javascript文件要阻止后续部分资源的加载,又为了充分利用最大HTTP连接数,因此不能严格先加载所有的script和link标签定义的资源,导致瀑布图上各类型资源有相互穿插,难寻规律。

总结

  • 抛开IE6不论的话,除非是在线相册之类外部资源非常多的页面,不然没必要去追求静态资源的分域名优化。
  • 针对IE6进行静态资源分域名优化时,要严格注意javascript文件对后续资源的阻塞,进行精确计算和设计后保证资源最完美地分域名存储,以提供最大并行度。
  • 鉴于Chrome对head部分的资源会独立加载,当head部分用不满6个HTTP并发数时,是否可以将资源移到body中呢?在body中的资源又会引起其他的问题,需要谨慎考虑。
  • Opera的行为比较怪异,似乎主动设计了一个很麻烦的算法,不过考虑到其占有率,就先放在一边吧……而且号称最快的浏览器的Opera,在加载javascript文件时竟然如此笨拙……
  • Firefox4 beta12的行为让人无法理解,看来要追踪RC版是否还存在这个问题,如果存在的话可以考虑找Mozilla报个问题了。

对各浏览器加载外部资源的策略的掌握,是WPO的基本元素,虽然一直想当一个WPO的专家,却在这方面迟迟不愿实践,实在有愧于自己的理想……

最后,如果有哪位朋友了解Opera对资源加载的具体策略的,还请提供一下,以便有更清晰地认知,谢谢~!

来源:http://www.otakustay.com/browser-strategy-loading-external-resource/

追求神乎其技的程式设计之道(番外篇)

February 23rd, 2011 | 1 Comment | 目录: 个人

我的学习过程

还记得小时候我和我弟上过一个奇特的数学补习班,叫做「功文数学」。他们的「教学」方法非常特别,不像一般的教室会有一个老师在讲台上教课,而是每个人会拿到一叠数学题目,每一面都有数个计算问题,像是「10 x 2 = ?」这样的问题。每次去功文的任务就是把那一叠题目写完,写得越快的人就可以越早回家。那些题目说来没什么意思,从头到尾全都是计算问题,难度从最基本的加减乘除,一直到微积分都有。每次写完题目后,会有个类似老师的角色,拿出解答本帮你对答案,打上成绩。如果在那老师能应付的范围内,他可能还会跟你说说哪里犯错了,下次多加油之类的,但如果到了国高中程度的问题时,老师的作用就只剩对答案而已了。

我之所以说这个补习班很奇妙,原因就在于这个教学过程中,讲求的是大量的计算和自我学习的能力。我从加减乘除开始,一路这样写到了微积分,写到后来那边的老师也没办法批改了,干脆把解答本拿给我们看,让我们自己看解答学。起初我还觉得这个补习班挺不错的,只要我做得越快就能越早回家,对小孩子来说是个很好的诱因。而且因为大量的训练,让我的计算能力变得非常好,国小国中时的数学考试我都不用准备也能很快写完交卷。但后来我开始觉得不太对劲,很多题目我虽然知道怎么算,但我其实不懂为什么要这么算,或是这么算的意义是什么。可是台湾的考试也不管这个,反正你只要能得到答案,根本没人在意过程是怎样。

功文数学的这套方法对训练计算能力而言很有帮助,因为计算就是需要大量的练习才能变快变好。但问题是,计算能力再好,也是只能算已经定义清楚的问题(也就是考卷上的问题),而无法发现新问题并定义问题。

在我高中开始参加程式比赛后,我用了我熟悉的这套方法训练自己的程式能力,自己一个人大量的找题目练习。每天从早练到晚,即使没有人教我也觉得很正常,因为我从小就是这样自学起来的。这样练了一年后,我能飞快的写程式和解题,看到熟悉的题型就能马上开始敲键盘,但同时我也开始觉得写程式变成一种机械化的过程:看题,解题,写程式,看题,解题,写程式…。跟我从小做数学似乎没两样。

我开始觉得无趣。即使我程式写得再快再好,也只是解出一个别人设计好的问题而已。

心中的声音不断的说:「为什么我要做别人早就知道答案的问题?」

我想要做没有人做过的事,看到没有人看到的问题,再亲手解决这些问题。

当我开始这么想的时候,我正在一边学着做科展。科展全名是科学展览,意味着要做点跟科学有关的事来展览。以前的文章提过,我高三时梦想着要让电脑自己写程式,我觉得这是一件没人做过的事,非常酷,所以我就一直专注在这件事上(其实当时就有很多人在做这种研究了,只是我不知道而已)。但从一开始到我被选上去美国参加国际科展时,我都一直不觉得这件事科学在哪,顶多说是一个工程(或工艺)作品。但选上代表后是有些好处的,台大的欧阳明教授给了我一些指引,让我知道「科学方法」得测量和量化这个作品的结果,才有客观的数据可以知道它的作用,进而跟其他相似作品比较好坏,也因此我才开始对「做研究」这件事有点概念。(到这时我才想起来,小时候虽然有做一些物理化学实验,但从没人跟我说过这些实验是有一套标准的方法和流程的,当然也没人跟我说这件事的价值所在。)

虽然做科展挺有趣的,但同时我也对科学感到失望 – 因为我意识到科学方法没办法帮助我们发明新东西,只能用来评估和检验已知事物的好坏。至于所谓的创新科学研究,也是得先提出一个假设 (hypothesis),然后再用这套标准方法去验证它是否成立。但到底要假设什么事情呢?科学可没办法告诉你。

上大学后,我看到当时处在黄金时代的MIT Media Lab所产出的许多创新研究成果,也开始接触到设计(design)这个领域。我发现Media Lab的人大多有跨领域的背景,像是设计师+电机工程师、或是音乐家+软体工程师,他们常看到别人看不到的问题,并提出简单又优雅的解决方法。我以前一直以为做设计的人讲求的是美术天份,但后来深入了解后才发现这是个大误会。设计的目的是解决问题,跟程式设计师其实没两样,只是用的工具是纸笔或模型罢了。(但一个好的设计通常也都很「美」就是了)

虽然如此,设计师和工程师也有很大的不同。设计师对四周环境和日常生活很敏感,常常得在生活中注意各种细节的不完美之处。但工程师成天泡在电脑中,而且很善于使用其实很难用的介面和程式(像Linux、vi、command line、还有各种程式语言),甚至引以为傲,日子久了也就不觉得这些东西有什么问题。泡在程式码中的工程师也一样,如果习惯了和前人或其他人的大便码相处,久了也就不觉得臭了。

发现这些现象后,我开始学着跳脱出原本习惯的一切,开始注意生活周遭的各种细节,思考为什么这个东西当初要这样设计、这样做有什么好处和坏处、有没有更好的方式之类的问题。之后,当我习惯观察细节后,慢慢察觉到我习惯用的软体、工具、环境、程式语言,处处都是设计后的结果,而且充满可以改进和创新的空间。这些东西都不是没来由的产物,而是经过某些人思考过后的结果,甚至是经过好几轮的演化结果。可惜平常在学习或教学的时候,很少人会提到这些歷史渊源和演化过程,以至于这些设计都变成理所当然的存在。但如果我们能仔细观察平常的事物,进一步思考就会发现很多设计都是为了因应当初时空环境的限制,而这些限制现在不一定存在了,所以我们就会有发挥的空间。

眼光拉远后,能看到的问题更多了。到了这个阶段,能力强的人会觉得能解决的问题也很多。但上天给每个人的时间是一样多的,这时重要的事情反而又变成:「找出最重要、最根本的问题来解决,而不要被众多的小问题和小机会所分心,才能产生最大的影响力」。

回顾我的学习过程,我会觉得每一个阶段都是一块基石,一块块往上叠以后才会具备该有的能力和经验做下一阶段的事情。举例来说,要是我一开始没投入程式比赛的练习累积足够的实作能力,之后我就没办法随心所欲的写出我想写的程式,也没办法参加科展体会做没人做过的事有多么有趣。之后我可能就会一昧沉浸在钻研各种流行技术中,或是眼高手低说得一嘴好主意但却做不出什么来。

虽然学习是一步一步往上走的,但过程中每件事都有反面的效应,让我不知道是不是做别的选择会更好。像是我觉得功文数学浪费了我太多时间在数学计算上,而限制了我在其他方面的发展,但同时它也让我养成靠自己学习的习惯;参加程式竞赛也有类似的效应,虽然增强了我的程式能力,但也让我错过正常的高中生活和课程(虽然说到目前为止没有觉得有什么负面影响)。

无论如何,我相信在成长的过程中适当的大量练习是必要的。异数(Outliers: The Story of Success)一书的作者Gladwell说要精通一件事情至少需要一万小时的练习,我相信这是真的。我在高中为了比赛所做的练习起码就超过五千小时,上大学后轻易就超过一万小时,但其实我也不觉得我真的精通了什么。经过大量的练习,本来很难的技巧或技术都会变成一种本能,可以很自然的使用它来从事更高阶的应用或是建构更复杂的技术。没有这些基础,也就很难站在更高的地方看得更远想得更多,我也不会走在现在的道路上。

来源:http://blog.vgod.tw/2011/02/23/divine-code-extra/

Tags:

用户体验的十个基本法则

August 27th, 2008 | 2 Comments | 目录: UI/UE

Andreas Pfeiffer写的WHY FEATURES DON’T MATTER ANYMORE: THE NEW LAWS OF DIGITAL TECHNOLOGY,从用户体验角度强调了功能并不在重要,重要的在于用户对产品或服务的体验,并列出十大法则,10 fundamental rules for the age of user experience technology。

在这个时代里10个基本法则是:

1、更多的功能并不好
More features isn’t better, it’s worse;

2、增加功能不会让事情更容易
You can’t make things easier by adding to them;

3、让用户迷惑是毁掉业务的终级手段
Confusion is the ultimate deal-breaker;

4、风格很关键
Style matters;

5、只有在一项功能可以提升用户体验时才加上它
Only features that provide a good user experience will be used;

6、任何需要学习的功能都只会吸引一小部分用户
Any feature that requires learning will only be adopted by a small fraction of users;

7、无用的功能不止是无用,它会破坏易用性
Unused features are not only useless, they can slow you down and diminish ease of use;

8、用户不会关心技术,他们只想知道产品能做什么
Users do not want to think about technology: what really counts is what it does for them;

9、忘掉关键功能,关注最重要的用户体验
Forget about the killer feature. Welcome to the age of the killer user-experience;

10、简洁很难,因此少就是多
Less is difficult, that’s why less is more。

Tags: