谷歌浏览器战群雄 Google Chrome Showdown

google chrome

既然客栈已给IE7,Firefox 2/3,Opera 9和Safari for Windows等等浏览器做过评测,支持平等机会的我们没理由放过Google Chrome,这款10岁网络霸主的新beta产品。为增加娱乐性,我们决定通过各浏览器亲卫队最喜欢也最鄙视的大乱斗解决:Google Chrome 0.2 vs Firefox 3.0.1 vs Internet Explorer 7 vs Opera 9.52 vs Safari 3.1.2 for Windows!高潮迭起,请勿错过!1)

回归正题,相信浏览器爱好者们已经非常清楚几位老选手的底细了,这里只介绍新人“股沟鸽”的内涵配置。

Google Chrome (ver0.2.149.27)

  • 页面渲染引擎:WebKit/525.13(Safari 3.1.2使用WebKit/525.21)

  • 图像渲染引擎:Skia(Google自行开发,还缺乏部分功能,例如text-shadow和border-radius)2)

  • Javascript引擎:V8(Google自行研发,适合运行结构性强的JS代码) 3)

FF,IE,Opera和Safari的支持者,看清楚对手的嘴脸了吗?让我们进入第一个环节。

技术测试

中文网络上的用户体验实在是多如牛毛,个人感想到底没什么说服力,还是先上测试大餐对得起观众。

Javascript 引擎测试

Google Chrome浏览器内最前卫的莫过于他们独立开发的Javascript引擎:V8。在他们自己制作的速度测试上Chrome以超过Firefox 3和Opera 9.52数倍的成绩完成任务,更不用提众矢之的的IE7了。

然而V8的benchmark是否有足够代表性?Google有没有刻意夸大V8的实力呢?让我们用客栈自食其力的实证主义精神来判断。我们选择了如下几个Javascript引擎测试——

  • 来自mootools开发者的Slickspeed,测试浏览器运行主流JS库各种selector的速度。与DOM有关。

  • 来自Celtic Kane的JS Benchmark,测试运行简单对象,内置函数与DOM的速度。

  • 来自Google的V8 Benchmark,有大量的递归函数,纯粹JS引擎测试,无DOM。

  • 来自WebKit的SunSpider,测试各类函数运行,纯粹JS引擎测试,无DOM。

  • 来自PPK的DOM vs. innerHTML Benchmark,本用于研究不同元素生成方法的速度,这里用于测试浏览器的DOM渲染能力。

  • 来自Mozilla和jQuery开发者的Dromaeo V2,测试从内置函数到主流函数库等等实际浏览时会遇到的运算问题,包括大量有关DOM操作的测试。

Slickspeed

对于轻量级网站的JS代码开发者来说,如今几个主流JS库的速度决定着网站的速度,因此在JS库DOM最基本的组成部分——selector上下点功夫测试绝非奇怪之事。

slickspeed

详细测试数据

在该测试中Google Chrome并没有什么优势(和Firefox3相近),反而让传统的强者JavaScriptCore(Safari)和Opera的新引擎 Futhark拿到头彩。各位自行做测试就会发现,每款浏览器都有自己特别不擅长的selector模式,这和对应JS库的具体实现方式有关(因此不同浏览器的返回值出现分歧的selector也不同)。

JS Benchmark

只包含少数几个对象/函数的loop检查,缺乏实际应用性;测试Javascript引擎运算能力和特定的DOM。

jsspeed

详细测试数据

Google Chrome再次败阵,原因在于V8引擎就算对简单的函数构造也会毫不含糊的重复新建/修正“隐藏类”,导致速度大大减慢。使用内存字典搜索的Safari,Opera乃至Firefox会更快。

V8 Benchmark

v8bm

详细测试数据

回到Google自己制作的benchmark上,4个测试的统一特质:递归函数。只要指定类型的对象属性没有被更改过,V8就能再利用与之挂钩的隐藏类,直接生成machine code stack,免去耗时的搜索内存的步骤。V8 Benchmark就是在假设甚少对象属性变更的基础上设计的,因此对Google Chrome相当有利。

SunSpider

sunspider

详细测试数据

SunSpider是一款相当出名的Javascript引擎性能测试,由于它囊括了各方面的纯引擎测试,是许多浏览器开发者的首选。Google Chrome二次夺冠,但这次它的领先幅度缩小很多,V8的杀手锏“隐藏类”为它在前四个部分(尤其是测试递归的controlflow)取得了决定性胜利,但在其他区域Chrome的优势明显较弱,甚至被其他浏览器反超。

DOM vs innerHTML

innerhtml

详细测试数据

这时我们猜测Google Chrome的弱点可能在于它DOM Manipulation的速度。遂选择了PPK制作的“内容生成”测试。简单的DOM测试证明Chrome的速度介乎Firefox 3与Opera 9.5之间,V8的优势在重复利用对象的JS运算上才能得到充分体现。

innerhtml2

IE7的数据有点惨不忍睹。

Dromaeo V2

最后这个测试围绕着Web 2.0时代进行,不管是内置函数还是外挂函数库,都少不了为DOM服务的,而DOM也是大多数浏览器最慢的部分。因此除了纯粹的引擎测试,Dromaeo V2还有大量的DOM和渲染被加入(IE7实在太慢,没法完成测试)。

dromaeo v2

详细测试数据

Chrome没能获得第一,但表现得比Firefox和Opera要稳定(后两者都有特别慢部分,导致得分偏低)。

引擎测试小结

Google Chrome的V8是个相当独特而优秀的引擎,它考虑到了Javascript代码开发的趋势,为复杂的JS框架/Web2.0服务量身定做。它目前问题是DOM渲染并不突出,这就好比欠了东风,让Chrome还是火不起来。对于国内的用户来说,Gears插件节省的页面读取时间或许比V8的优势明显得多,不过这是题外话了。

Flash插件,启动速度,内存与CPU占用

在网速较慢的中国,对Javascript运行速度的要求或许不如国外高(JS上争取到的1-2秒相对网速的缓慢不过是小巫见大巫);在国内,对Flash插件的兼容性,浏览器耗费内存与CPU的度或许才是用户最注重的项目。

Flash

Flash插件的好坏一直评判是浏览器流行程度的指标,IE的ActiveX插件始终比其他使用NPAPI插件的浏览器要快,这也是为什么IE还在嚣张的原因之一。

Google Chrome也和多数开源浏览器一样,使用npswf32.dll作为插件。有鉴于Safari for Windows是个电脑杀手,我们特别在意Flash插件与谷歌浏览器的资源消耗。

测试一号

Google Chrome vs 所有使用npswf32.dll的浏览器;我们使用禁用了ActiveX插件的IE7作为基准。

faceoff01

上图中的所有浏览器都打开了1个主窗口,5个标签页分别运行着纯文字页面、多图片页面、Javascript高需求页面、Flash影片页面和我们自己的标准站。结果是Chrome的多进程系统耗费最多内存,133MB;Safari以107MB紧随其后,Opera和Firefox只是使用了 80MB左右;没有Flash插件的IE7更是用了不到56MB。

faceoff02

接着我们关闭了使用Flash的页面,让浏览器自行释放内存。这时Safari for Windows的问题显露无遗:它无法释放Flash插件占用的内存,这也解释了用Safari上新浪网(Flash广告海)就假死的原因。所幸的是 Google Chrome并没有类似的问题,但它仍比其余两款浏览器使用更多的内存——Chrome为避免单一标签页崩溃就殃及整个浏览器的问题,将每个标签页的内存单独处理,间接导致内存占用增加。Firefox/Opera表现正常。

faceoff03

最后是将所有标签页关闭,清空缓存后的结果。Google Chrome的Sandbox表现相当出色,配合V8的垃圾回收,基本恢复热启动时的内存占用量;Firefox的内存管理不比Chrome逊色,也接近了冷启动时的初始值(30MB左右)。Opera 9.52的73MB可以接受,虽然远超过20MB的启动内存,但它在浏览页面的过程中一直只占用70~90MB内存的特性让我们猜测它有独特的内存管理。最后是Safari,呃,也就是如你所见了。值得一提的是IE7的内存也迅速降下来了,微软毕竟不是白吃饭的。

测试二号

将Flash ActiveX插件与npswf32.dll平行对比,Google Chrome vs IE7的战斗。参照浏览器为Firefox 3。

faceoff04

同样的环境中,IE7果然比Google Chrome少占用内存,算上IE与explorer.exe共用的内存,谷歌的浏览器还是超出10MB有余。

faceoff05

faceoff06

作为对比,以上分别是在浏览无Flash页面和热启动时的内存监视,Firefox和IE7的内存占用都与Chrome相近……可预见今后浏览器性能大战的获胜条件将少不了来自Flash插件的良好支持。

小结

我们认为Google Chrome对Flash插件的支持达到或超过了Firefox/Opera的水准,代价是运行时的内存耗费比较大;另一方面Flash的ActiveX插件版仍有绝对的性能优势,有鉴于Google扼杀AIR和Sliverlight的决心,我们不认为Adobe会特别关照Google Chrome。

启动速度

准确测试有难度,只凭我们的观察为准。

冷启动耗时:Opera 9.52 < Google Chrome 0.2 < Safari 3.1.2 « IE7 < Firefox 3.0.1

热启动耗时:Google Chrome 0.2 =< Opera 9.52 =< Safari 3.1.2 < Firefox 3.0.1 < IE7

内存和CPU

为排除Flash插件和Chrome多进程的干扰,我们选择之前使用过的Dromaeo V2测试,因为它很耗CPU和内存,而且无需Flash支持。结果如下——

normalcpu

首先是空闲时的内存占用,220MB。

chromecpu

Google Chrome一度使用接近400MB内存,因为Sandbox的关系单个进程(标签页)的CPU占用不会到50%以上。双核使用不平均的问题估计在实际浏览中不明显。

firefoxcpu

Firefox的CPU分配很平均,减低了单独CPU的压力,但在CPU吃紧时会影响到其他程序的运行。Firefox 3在Javascript上的内存管理已经有长足进步,最多时只使用200MB内存,没有发现leak(这些JS库也有避免内存溢出的预防措施)。

operacpu

Opera是相当奇怪的浏览器,它在运行JS时基本只使用一个CPU(会完全占用,即50%),我相信这是它速度较慢的原因。它在运行繁重JS时的内存占用较高,一度上升到450MB。我们的Opera 9.52在渲染Dromaeo V2页面时有bug,所以无法判断这个测试的准确性。

safaricpu

Safari for Windows 3.1.2的内存管理很糟,全无下调的趋势,最后停滞在500MB;相反它运行JS时的CPU占用率很低,我们甚至可以开个Winamp听歌兼用 Thunderbird收发邮件。另外别忘了,JavaScriptCore在本测试轻松获胜。

小结

Google Chrome用内存换速度做法在beta阶段会很受欢迎,相信不少人会成为Chrome的用户;而它的快速启动和每个进程只占用5~15%的CPU的特性,也比其他浏览器更为讨好(在我们的系统上没发现稳定性问题);但要作为用户每天使用的浏览器,Google Chrome还需要考虑得更多。

使用体验

Google Chrome的不少独特设计都是双刃剑,我们会从多方面考虑。

菜单

menu

Chrome是5款浏览器中唯一一款完全没有顶部菜单的,这对于熟悉浏览器通用快捷键的用户来说是亮点(例如Ctrl+B的收藏夹/书签,Ctrl+H的浏览历史等等),对于没这么擅长浏览器操作,喜欢通过顶部菜单寻找功能的用户来说则是烦恼。我们估计早期换用Chrome的用户会相当喜欢这种设计(这种设计类似IE7隐藏菜单栏后的设计)。

另外由于没有顶部菜单,Chrome不得不将所有功能置入右侧仅有的两个菜单按钮里,目前的还不算拥挤,今后Chrome功能增多时该怎么办,还需开发者挖空心思去解决。

标签页

Google Chrome的标签页与地址栏的位置关系与大多数浏览器相反,处于最顶部。习惯了各种标签页设计的我们并不觉得陌生,加上Chrome的标签页操作和其他浏览器几乎一致,早期使用者不应感到特别不适。

此外,Chrome从Safari身上学会了经典的标签页/新窗口互换技能,两款浏览器都能将标签页拖成新窗口,也允许新窗口之前互换标签页;Google Chrome可以将新窗口逐个恢复成标签,Safari则有融合所有窗口为一个的功能。

导航/地址栏

这大概是任何浏览器最显眼的部分,Chrome的设计没啥特别,一键添加书签的功能也与Firefox3雷同。另外Chrome的地址栏为减少页面欺骗,会突出显示页面的所在域名;IE8也已加入这种显示。

莫名其妙的是右侧箭头——Google假设用户知道如何输入地址,却不知道地址栏可以回车确认?这明显是为IE6的最初级用户设计的。

边侧栏和状态栏

Google Chrome没有边侧栏,他们的书签只使用顶部空间,类似其他浏览器的书签栏;其他功能均使用整个标签页。它亦没有状态栏,链接会以渐入渐出的方式在右下角提示;可预见今后的插件控制是个问题。

此外Google Chrome是不会完整显示长页面标题的,这可能会造成一定困扰。

有趣的新功能

以下是我们没能在其他浏览器找到的新功能,他们不一定都有用,但至少给用户耳目一新的感觉。

内置任务管理器

taskmanager

不少浏览器都有自己的内存/CPU占用/带宽检测功能,但Google Chrome是第一个提供内置GUI任务管理器的浏览器。对于浏览器性能痴迷者来说是一大喜事。

搜索定位

searchanchor

一般的浏览器只会在页面上高亮(通常是黄色)搜索文字,Google Chrome更进一步,在右侧滚动条上显示搜索关键词出现的大概位置,这对于长页面和Ctrl+U的代码浏览器来说很有帮助。

hidden

隐身窗口的幽默感

隐身窗口并不是Google的创意,基本所有浏览器都有控制Cookie,密码和浏览历史加载的方法,Chrome只是将这个功能作为重要功能摆上台罢了(Google Chrome缺乏用户的管理和保护,对于公共浏览器来说提供隐身窗口功能是满足基本需要)。不过隐身窗口的对自己解释却给我们网络小公司的幽默感,让人暂时忘记了站在浏览器身后的渐渐满口官腔,越发渴求利益的Google。

明显弱项

  1. 缺乏高级书签管理,就算能导入书签还是不好用。

  2. 长页面的文字选取很慢,说起来,页面滚动也不怎么流畅。

  3. 默认保护过强,当页面有链接指向或图片来自受感染的域名,该页面也会被禁止。

  4. 无可切换全屏模式。

  5. 任何杀广告的插件,用本地proxy过滤不算;谷歌在这方面一点都不急。

  6. 通过GUI禁用特定插件,而不是要用快捷方式的启动参数。

  7. 清除浏览数据时不会记忆上次的选项。

Google Chrome FAQ

Google Chrome虽然是开源,缺乏记录的部分却很多,这里我们把客栈整理到的信息归纳一下。

关于隐私

Chrome与Google服务器通信的方式很多——

由于Google拥有的用户信息已经多得吓人,随着他们逐渐变味的隐私保护4),让人不禁怀疑Chrome是否成为Google的开源后门,为此我们也专门去看看了源码的解释。

rlz.dll

这个位于0.2.149.27(版本号)文件夹下的dll负责记录/发送Google合作产品的信息(通过访问特定的注册表位置),目前它只会每间隔 24小时发送Chrome自身的升级情况,首页和默认搜索是否为Google等信息到Google的服务器;至于今后rlz是否会发展到收集其他 Google软件的信息,只能拭目以待(代码设计预留了扩展空间)。

由于rlz会用这些注册表信息生成一条字符串,并在默认Google搜索时加入到查询语法中(rlz=),也让人怀疑Google是否在收集用户习惯,即便Google声称这些信息不能用于分辨用户身份。

rlz.dll并非浏览器进程必须的库,可以移除

Metric_Service

这个服务并不是Google的原创,它一直是Firefox的官方扩展之一,只是不包括在下载包之中罢了。Google Chrome借用了Mozilla的Browser Metrics代码,打造了自己的Metric_Service,将收集到的信息发送到这个地址(直接访问会出现无效SSL证书的问题,强行接受证书就可以看到使用以下namespace的XML回应)

http://www.mozilla.org/metrics

这符合Mozilla官方的数据规格。按照Mozilla自己的说法,这个服务可以收集从浏览器设置,安装插件,特定URL到硬件设备等等基本信息,某种程度上是对用户隐私的侵犯。因此Chrome不用安装Google Toolbar也能达到统计用户使用数据的目的。

目前Metric Service可以通过禁止Chrome发送统计信息和崩溃报告来阻止(在高级选项中)。

搜索建议(Omnibox)

只要不关闭搜索建议,并使用Google为默认搜索引擎,Chrome就会尝试建议关键词,这是通过向Google服务器提交信息得到的结果,自然也会让Google得到你输入的关键词(即便没有回车输入)。

搜索建议可到“选项”的“基本信息”的默认搜索中关闭

其他

Google Chrome会定时更新不安全网站列表,下载拼写检查字典等等……

另外,跟随Google Chrome一起安装的Google Update会长期进驻系统(作为Win32服务),定时检查软件更新和提供一键安装的功能;没有正常的反安装功能,移除该程序比较困难。

使用免安装版Chrome可以省去移除GoogleUpdate的麻烦

关于移动版

制作绿色/免安装版Google Chrome非常简单,只需要复制位于以下文件夹的所有内容即可。

Documents and Settings\username\Local Settings\Application Data\Google\Chrome\

制作Portable(可携带版)的Google Chrome比较麻烦,由于Google Chrome缺乏用户管理,目前它的默认用户被锁定在

Documents and Settings\username\Local Settings\Application Data\Google\Chrome\User Data\

必须新建快捷方式,加入–user-data-dir参数来设置用户账户的位置。 5)

或者等待专业人员编译使用相对路径的Chrome。

关于谷歌的计谋

google

普遍认为Google Chrome的目的首先是打击IE的市场份额,让Google在提升基于Javascript的服务的复杂性时少些阻碍。6) 7)

让Google花这么多人力去开发新浏览器的理由有不少。

减缓AIR和Sliverlight的崛起

javascript毫无疑问当今Web 2.0时代的网络服务的重要组成部分,以提供网络服务吸纳用户的Google绝对希望这种趋势维持下去。无论JS作为客户端语言的路还有多长,V8引擎的出现必定会掀起又一次浏览器JS引擎提速战,这对javascript的延年益寿很有帮助。

相同道理,javascript的持续流行将打击其他商业化产品,例如Adobe的AIR和微软的Sliverlight。网络服务还要依赖装机量为生有很大的风险,当大多数网站都选择了javascript,对AIR和Sliverlight的普及自然造成影响。

至于今后javascript是否能成为主方向,就得看标准的发展和Google Gears的应用范围了。

对微软的将军抽车

微软讨厌今天的javascript,这是毫无疑问的,它灭了vbscript占领网络的美梦,还老是给IE带来负面新闻。但Google Chrome将成为微软的下一个心病——如果微软选择维持IE8的JS引擎速度,则Chrome的傻瓜设计有可能对IE今后的市场占有率造成严重打击;即便他们将JS引擎速度提升到Chrome的水准,和Google打浏览器大战,也会间接帮助了Google的网络服务(尤其是和MS Office与Live服务争锋相对的服务,Google Docs,GMail等等)。

和Google Chrome对战这并非微软的意愿,他们最大的市场——企业局域网,并不需要这么平凡的浏览器升级。

为保IE和Office这些老将不死,微软的车——“漫长的开发期”和“践踏网络标准”两张王牌必须倒下,微软也将不得不在网络上与Google决胜。

真正的“云”,是用户群

我们曾经说过,任何用户信息对于Google来说都是宝贵的。随着互联网发展,要从用户得到涉及隐私的信息越来越难,随着各大开源浏览器的崛起,Google工具栏的吸引力日渐降低,Analytics则是以“站”为中心的服务,Google排名需要新的用户数据来填补这片空白。Google 的答案是发布开源浏览器,再次打开用户上缴个人信息的渠道,事实上,没什么比获得用户的第一手数据对排名和创新更价值了。

Google花费了不少心血,从开源的Firefox与Safari上习得了经典的技能,配合自己的名气,刚出炉就迅速抢占浏览器市场,也算是他们支持Mozilla多年得到的回报之一;今后Firefox的增长是否也会因为Chrome的出现而减缓,我们只能等待结果到来。

杂项

一些与谷歌浏览器有关的小知识8)

关于标签页

同网站打开的标签通常共享内存,这是为了让javascript能跨页面响应。同时Google Chrome并不能关闭标签页功能。

关于Google Update

安装Google Chrome时一并装入的Google Update还会在Firefox内加插一键更新的插件,如果你不喜欢Google这种走后门的做法,可到注册表的以下地方删除它。

HKEY_CURRENT_USER\Software\MozillaPlugins

HKEY_LOCAL_MACHINE\SOFTWARE\MozillaPlugins

删除@google的那个插件即可。

尾声

techmeme

Google Chrome的确是浏览器市场的一股新风,性能和操作简易性上已让不少人折服,再加上可总结为Hey, it’s from Google!的用户信任度,这热潮恐怕得再刮一阵。

至于客栈,我们已经习惯了Firefox的强大延展性,加上Chrome缺乏书签管理的这个弱势9),谷歌还不能成为我们首选。另一方面,别忘了Firefox 3.1和Safari 4都将各自有新的JS引擎,想超越V8并不困难10),而Opera 10和IE8的出炉又会给这场战斗带来更多不可预计的因素11) 12) 13)……Google还不能笑得太早。

暂时只有这么多,如果有什么新信息会继续加入。


1) 不使用IE8 beta2的主要原因是它的内存占用太夸张了。 – IE8 Beta 2 Fatter Than Firefox and XP

2) Flickr – Google Chrome vs Safari 3.1

3) V8 – Design Elements

4) Google and Privacy: A History

5) 谷歌浏览器 Google Chrome 免安装绿色版!

6) Mozilla’s Thoughts On Google’s Chrome

7) Inside Chrome: The Secret Project to Crush IE and Remake the Web

8) Google Chrome Tips and Pointers

9) 谷歌有“将功能留给网络服务,浏览器不应太复杂的解释” – A fresh take on the browser

10) JavaScript Performance Rundown

11) Beta Browser Speed Tests: Which Is Fastest?

12) Chrome Vs. IE 8

13) Google Chrome, Day 2


目前最有爱浏览器?

  • IE核心 (24%, 24 Votes)
  • FF核心 (51%, 50 Votes)
  • Opera (13%, 13 Votes)
  • Safari (3%, 3 Votes)
  • Chrome (8%, 8 Votes)
  • Mosaic (1%, 1 Votes)

Total Voters: 99

Loading ... Loading ...

原Wiki版地址(需要登录):Google Chrome « 捏它营 / NetaInn

难得写一篇与本人正业有关系的文章——你有权说“用某某浏览器的飘”,但你说的话将成为Akismet的Spam证供。

Author: 店长

The Master of BitInn

11 thoughts on “谷歌浏览器战群雄 Google Chrome Showdown”

  1. 不出所料,认真看此文的使用Firefox居多(见投票结果)。

    @ROCKY & lalala

    我们要写收费稿不会发在客栈,发在客栈的绝对不会变成收费稿。

    客栈使用CC许可,特别指定不可用于盈利;
    除此之外,只要你著名本文的出处,可随便引用/衍生。

    过去的一些文章也有门户和公司PR要求刊载,我们一概婉拒。

    @all

    我只是路过。

  2. 老实说FF最令我郁闷的是对页面的显示差异以及部分IE only的重要页面(例如某些恶心的网银),其次就是需要自行安排各类插件。我另可用开销大但是傻瓜的套壳浏览器,例如Maxthon之流……

Comments are closed.