【51CTO精选译文】本文从技术和用户体验的角度，一一介绍了影响浏览器速度的因素，以及如何判定一个浏览器是否快速。本文作者Evan Martin是Google Chrome项目的开发者，文章来自他的个人博客，与Google官方并无关系。以下为原文编译：
所谓快速的浏览器，到底是什么意思？事实上这是个挺困难的问题。我在最近的Ubuntu开发者峰会上被邀请谈谈这方面的问题，并写下这篇文章进行补充。
基准测试
很多人会先想到基准测试。科技媒体喜爱基准测试，因为基准测试提供了数字，可以用来描绘美丽的对比图。然而从本质上而言，基准测试衡量的都是十分具体的参数，仅能用来模仿用户可能将经历的过程。浏览器最重要的基准测试就是JavaScript基准测试，然而虽然没人会否认JavaScript的重要性，但JavaScript毕竟不是大多数简单网页加载速度的决定性因素。我认为现在针对JavaScript引擎所作的改进主要是为了未来将被创建的站，比如这个JavaScript NES模拟器。当然了，像是Gmail这样大大得利于快速JS引擎的站也不算少了。
通过JavaScript基准测试得出的结论往往是令人乏味的，比如：“Wine实现的Mozilla比Linux编译的Mozilla快，所以Mozilla并不重视Linux”。JavaScript基准测试就是能够得出这样缺乏引导性的结论，而事实是，浏览器对于JavaScript的实现代码在各个平台上都是几乎完全一样的！上面这个测试的速度差很可能来自编译器质量的不同，所以Mozilla遇到的差别在其他跨平台浏览器上应该也能够看到。这样的评论从各个层面来看都是十分无聊的。第一，该结论毫无依据；第二，JavaScript基准测试从设计而言和平台毫无瓜葛；最后，这些基准测试甚至没有针对每个平台特有的代码进行测试。
新的基准测试正尝试覆盖JavaScript之外的内容。Dromaeo是个不错的例子，这个测试有一部分是针对DOM的。不过，我们要小心第三方的基准测试！对于Dromaeo还好，它的作者John比其他大多数浏览器开发者对Web开发的理解要来的更深入；但对其他人我就不怎么放心了。写一个看起来不错的性能测试并不难，但它测试的不一定是有用的东西。好比说，SunSpider 0.9.1发布声明中就有一段内容，有关测试框架与能源管理之间交互的一个bug。要知道，这个bug涉及到的作者是一个经验丰富的浏览器开发者，而不是随便哪个Web开发爱好者。
周期计时
一个更好的测量方法可能是观察浏览器从头至尾加载一个真实的网页的性能，这个过程包含了JavaScript引擎以及其他部件的工作：HTML解析，字体测量等等。我们和Mozilla（我想其他浏览器厂商应该也都有）都有针对本地页面的测试工具。对于第三方测试者而言，通过使用这些工具来测试比较浏览器的加载速度是很自然的选择，唯一的不同在于他们的测试对象是真实的网页（如Yahoo主页），其测试结果也往往是有版权而无法公开的（就我所知，我们的测试页都被设为隐私；而我在Mozilla也只找到这样一个页面）。
为了使测试数据可以重现，通常的测试方式都是从本地读取一个页面文件，而不是从网络上读取加载（51CTO编者注：记得Google那个切土豆的视频么？有细心的网友发现视频中的测试页面是本地地址，这实际上是浏览器速度测试的通用做法）。目前讨论的基准测试当中，还没有一个将网络速度包含在测试因素内。这是一个遗憾，因为这是个很有趣的领域。比如说，不同的浏览器如何使用不同的单个host连接限制，或者Chrome如何在启动时进行DNS预读取（这个DNS预读取的行为事实上比任何Web渲染或JS处理造成的影响都要大。你可以在Chrome中输入about:dns进行进一步了解）。
网速之外，仍然有其它影响浏览器性能的环节，比如网络协议层以及缓存。我记得在Chrome开发前期，Mike还是Nagle曾经发现过一个网络层的bug，这个bug造成Chrome读取网页的速度迟于IE。上面所有的这些测试都无法呈现出这个bug的效果。另外从某种角度而言，将像素呈现在屏幕之上所花费的时间也可以算作一个环节。Gmail的加载更是一个疯狂的多重过程，这个过程在例常的JavaScript和呈现的步骤之外还包含了好几次重新导向、进度条等部分；而就我所知，似乎还没有哪个测试是针对Gmail的加载速度而进行的。
#p#
秒表
所有的测试在本质上都是虚幻的，并不能代表真正的浏览过程。人们终于意识到这一点似乎是从微软发布IE8开始，当时微软的基准测试声称IE8是最快的浏览器。基准测试的某一项叫做“我们付钱雇了一些志愿者仔细的看，他们说我们是最快的”，然而不幸的是，而这一项测试的结果无论动机如何纯洁，都无法使大多数人接受。事实上，这样的测试比任何一种性能基准测试都更接近于我们的目标，但糟糕的是，这种测试的结果数据完全无法重现。也许浏览器开发者们会针对这点进行优化？
心理作用和Jank
人们称一个浏览器为快速的原因不仅是上面提到的这些。从可测量的数字到模糊的秒表测试，我可以确认一点：比测试性能更重要的是，用户感觉你快不快。下面我来讲讲这几个和网页无关的有趣因素。
其中一个叫做UI延迟（我们称之为jank）。当你在地址栏里输入的时候，浏览器的反应快么？创建新标签页的时候呢？Peter曾经就此做过一次演讲，虽然我没看，但应该是十分深入的一次课程。在对Ubuntu开发者演讲时我也十分希望强调此点，那就是即使你的应用能够在一秒之内呈现上千页面，一个小小的问题仍会让用户感觉你的应用很慢（比如Ubuntu的软件包更新工具在这方面我觉得就做的很糟）。我觉得这才是我们在性能上“超越”Mozilla，以及我们在Linux上日益流行的最大原因。当然，这是一个很难量化的因素。
减少jank的一个很好的例子就是Chrome中自动完成的实现。当你输入URL时，我们从您的浏览历史中提取URL的自动完成，以及相似地址的推荐。当你按下Enter键时，我们让Chrome进行了同步自动完成，以确保你进入的地址正是你所看到的地址。当然这也便意味着我们不能从磁盘读取数据，因为从磁盘读取的过程会令自动完成有所延时。因此我们的做法是，将整个自动完成的数据在浏览器启动时加载到内存当中（相比你的所有浏览历史，这部分数据并不是很大）。
启动
另一个有关性能的环节和上面所有的因素几乎完全没有关系，那就是启动速度。我在之前的演讲中提到了GNOME的计算器，不过他们现在已经修复了这个问题。好在类似的问题很多，比如Ubuntu的菜单也是，我每次都要数到5才能弹出菜单。对于Chrome的启动我写过十分详细的技术文档，从基准测试和适应低配系统等两个方面阐述。现在我们来看看为什么这十分重要。
我相信一个应用的启动速度确立了用户对其性能的期待。事情总是这样的：用户认为你很快总是要比你事实上快不快来的重要。当你的启动速度和轻量级应用一样快时，用户会觉得他们在使用一个轻量级应用，尽管事实并非如此（事实上，任何一个可以呈现页面的浏览器都是庞大的应用，包括我们的Chrome）。比如说，即使到今天我还是习惯时不时的使用vi编辑器，因为emacs启动实在太慢了。我甚至没有意识到我在下意识的拒绝使用emacs。
当然，快速的启动意味着在启动时做更少的工作，因此整个代码都需要进行仔细的工程。
结论
在Chrome工作三年，我从中学到的一大原则就是：如果你没有考虑某个性能，那么这项性能必然会退步。这是软件开发的一个自然现象，因为我们总是在为应用添加而非减少东西。因此，我们使用buildbots来为所有的性能测试创建图表（该页面巨大，当心浏览器崩溃）。每个退步的性能项都会变红，这事经常发生，然后我们就要修改代码。
总之一句话：基准测试仅仅在你了解该测试的技术细节时才有他的用处。如果你并非一个浏览器开发者，那么身为一个“专业人士”，我要说的是，自己打开网页尝试一下才是判断哪个浏览器最快的最佳方法。
原文：http://neugierig.org/software/chromium/notes/2010/05/fast.html
【51CTO.com译稿，合作站点转载请注明原文译者和出处。】
【编辑推荐】
