最快的浏览器

七大浏览器最新速度测试还是Chrome 5最快
51CTO参考了IE8所用的测试方法，对最新一批的七大浏览器进行了速度测试。

它们分别是：IE9 Preview 3、Firefox 4.0 Beta、Chrome 5 Stable、Opera 10.60、Safari 5、傲游3 RC、搜狗浏览器2。

这年头浏览器种类多，更新也快，每次有浏览器进行升级，都有国内外各大IT媒体放出各种各样的性能测试数据，柱状图满天飞。

目前，这些数据主要都是来自针对JavaScript引擎的基准测试；然而无论是微软还是Google，世界上大多数浏览器开发者都已经产生了一个共识：浏览器快不快，只有用户说了算；而用户所体验到的，从来都是整体的真实页面加载和显示的速度。

也就是说，无论这个浏览器的性能多好，只要用户觉得它慢，那它就是慢；就好像一个足球球员无论百米速度多快，身体有多强壮，如果在球场上没啥精彩表现，那球迷们也不会买账。

因此本次51CTO对最新这批浏览器的速度测试中，我们对性能基准测试不予考虑（最新的JavaScript基准测试可以参考这篇文章），而主要由页面整体加载时间作为决定因素。

测试方法
测试流程很简单：在同一台计算机上，启动浏览器，按照次序打开四个指定的网址，并对每一个网页的加载过程进行计时。

全部完毕之后，关闭浏览器。

然后，对其他的待测试浏览器重复同样的步骤。

一般来说，通过屏幕录像的方式是比较准确的，不过鉴于时间所限，本次测试采用了一个第三方的计时工具：Numion Stopwatch。

这个工具用JavaScript 编写，测试了浏览器从开始加载URL到发出“完成”信号这段时间的长度。

为了尽可能的排除外在不稳定因素对测试结果造成的影响，测试过程中遵循了一下几点事项：
◆关闭每个浏览器上的额外插件（如Firefox的Firebug或Chrome的Gmail Checker这种用户额外添加的插件。

Flash Player这种“必要”的AddOn则不用关闭）。

◆在测试过程中，关闭其他的应用程序，以免造成干扰。

◆预先在所有的浏览器中预读待测试的网址，使浏览器直接从缓存中读取页面。

视页面情况而定，预读的次数可能需要超过一次，直到测试数据稳定在一个最低值附近为止。

这是为了避免周边服务器上保存的网页缓存对测试结果造成误导。

测试环境
机型：Dell Inspiron 1525
操作系统：Windows Vista Home SP2
处理器：Intel(R) Pentium(R) Dual CPU T3200 @ 2.00GHz
内存：3GB
显卡：Mobile Intel 965 Express Chipset Family
测试对象
1.IE9 Preview 3（Force IE9 Document Mode）
2.Firefox 4.0 Beta（20100721Build，无插件）
3.Chrome Stable 5.0.375.86（无插件）
4.Opera 10.60（因无法建立连接，Opera Turbo未开启）
5.Safari 5.0
6.傲游3.0.15.300 RC3（Webkit模式）
7.搜狗浏览器2.0（Webkit模式）
测试网址
由于我们想要测试的是浏览器的页面元素渲染、页面内容排版、以及JavaScript执行的速度，因此我们选择的网站都是内容比较多、或者牵涉到大量JavaScript代码执行的网页。

以下为待测试网站列表：
◆51CTO首页（大量内容）：
◆新浪首页（大量内容，大量页面元素）：
◆淘宝首页（少量内容，大量页面元素）：
◆Google地图（大量JavaScript）：
测试结果
七大浏览器速度测试得分结果（分值越高越快）
本次的测试结果，Chrome 5.0、傲游3.0和搜狗浏览器2.0的得分相差不多，在四个网站的加载速度都颇为理想；其次是Opera 10.60，其在加载大量内容的页面时（51CTO首页和新浪首页）的表现并不如预期般流畅；IE9和Firefox 4在加载51CTO和新浪首页时的表现差不多，不过Firefox在加载淘宝首页上表现不佳；垫底的则是Safari 5，原因是新浪首页花费了它长达4.9秒的时间来加载。

具体测试情况和分数计算过程如下：
下面列出的是每个浏览器的测试用时以及分数计算。

分数计算采取最为简单的方法：速度= 距离/ 时间。

假设测试的四个站总共加载的内容为100，则每个浏览器的得分为100 / 总计时。

Google地图总计时得分
IE9 1.9s 2.9s 0.8s 0.8s 6.4s 15.6 Firefox 4 1.9s 2.2s 1.4s 1.3s 6.8s 14.7 Chrome 5 1.4s 1.2s 0.8s 0.9s 4.3s 23.3 Opera 10.60 1.9s 1.8s 0.9s 1.1s 5.7s 17.5 Safari 5 1.7s 4.9s 1.1s 1.2s 8.9s 11.2
傲游3.0 1.3s 1.5s 0.9s 1.3s 5.0s 20.0
搜狗浏览器2 1.2s 1.7s 0.9s 0.7s 4.5s 22.2
七大浏览器速度测试用时与得分
备注：在测试Google地图时，会随机遇到连接被重置现象，尤其是在Chrome、Safari、傲游、搜狗这四个基于Webkit的浏览器时，链接被重置的情况发生的十分频繁，可能会对测试数据造成一定的影响。

不过，我们已经尽可能多的重复每个网址的加载，误差已经缩减至最小。

另外，新浪首页在加载时往往有一、两个广告迟迟无法加载到的情况，但此时网页已经完全可以浏览并操作。

有些浏览器会不断地请求而导致迟迟无法发出加载完毕的信号（这在Opera 10.60中颇为明显），有些浏览器则很快就放弃加载，导致了加载速度较快的结果。

浏览器工作原理
网络好比跑道，浏览器自是赛车。

从打开浏览器，在浏览器地址栏中输入网址到页面显示完毕，当中都经历了哪些步骤，你了解吗？
简单的说，虽然影响页面加载速度最重要的因素是网络速度，但浏览器本身这个环节对于用户的速度体验而言也是至关重要的。

无论是DNS预读取的过程，还是浏览器内核对Web页面进行页面排版和渲染的过程，还是JavaScript引擎进行解析的过程，乃至于浏
览器本身的架构（单进程、多进程、多线程），都对用户感觉“快不快”有着很大影响。

所谓快速的浏览器到底是什么意思？
Evan Martin是Google Chrome项目的开发者，以下来自他的个人博客，与Google官方并无关系。

以下为原文编译：
所谓快速的浏览器，到底是什么意思？
基准测试
很多人会先想到基准测试。

科技媒体喜爱基准测试，因为基准测试提供了数字，可以用来描绘美丽的对比图。

然而从本质上而言，基准测试衡量的都是十分具体的参数，仅能用来模仿用户可能将经历的过程。

浏览器最重要的基准测试就是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的加载速度而进行的。

秒表
所有的测试在本质上都是虚幻的，并不能代表真正的浏览过程。

人们终于意识到这一点似乎是从微软发布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来为所有的性能测试创建图表（该页面巨大，当心浏览器崩溃）。

每个退步的性能项都会变红，这事经常发生，然后我们就要修改代码。

总之一句话：基准测试仅仅在你了解该测试的技术细节时才有他的用处。

如果你并非一个浏览器开发者，那么身为一个“专业人士”，我要说的是，自己打开网页尝试一下才是判断哪个浏览器最快的最佳方法。

原文：/software/chromium/notes/2010/05/fast.html。