Chrome&IE&Firefox性能和标准评测
来源：互联网 发布：大数据成功案例 编辑：程序博客网 时间：2024/04/26 07:16
- I. 前言
看见CSDN的介绍，觉得应该在某些点上进行更正或者更深入的介绍，当然这个也并不是说CSDN现有的评测不准确，个人觉得CSDN现有的评测总的来说确实不错，下面的内容尽可能的详细介绍相关的评测内容。
国内浏览器的烽烟四起，或许对于我们这一代网民，一般是能够通过Google或者Baidu去回顾第一代的浏览器大战的细节。没有经历，但是从那段历史中，我们可以找到很多对我们有意义的东西。最近也一直在考虑，我们需要一款什么样的浏览器，中国的互联网民又需要一款什么样的浏览器，一直想通过做产品的心态去理解，可是我发现我还是无法抓到Key Point。我不否认CSDN的介绍文章中提到的现代的浏览器所要具备的一些特性--JavaScript引擎的执行性能、DOM模型节点的操作、CSS选择器性能、Web标准和HTML5的支持能力、浏览器的安全性。器性能的核心考察点。
3）CSS渲染和CSS选择器
显而易见，浏览器构建了DOMTree还需要展示，那么基于Dom Tree之上的RenderTree的性能也应该是我们考察的点，同时对于CSS Selector提供的接口进行Dom节点的查找也是前端开发者经常关注的一些点，因此也把这个纳入我们的评测之中。
4）网络库性能
Net Lib其实是我自己定义的一个统称，对于IE、Firefox、Chrome来说，都有自己的网络库。通常情况下，我们认为这个跟服务器有关，跟我们自己的网速有关，显然这个理解没错，我只想补充下，跟浏览器也有关。
5）页面加载时间（Page Load）
其实我想说的是我们是否可以从web前端开发者的角度去考虑这个问题，有些我们可能需要从普通的互联网用户的角度去考虑，另外我们也需要从整个生态系统中去追寻一些有意思的东西。在浏览器内核层面的评测上采用CSDN的线路，并针对该四个维度在最新的HTML5的新功能中，还句话说，对用户来说，其实不关心v8快还是TraceMonkey快，是CFnetwork快还是wininet快。所以以下力图通过加载我们常见的页面来判断究竟是哪个浏览器更，有时还有360、Sogou等浏览器上测试，同样的工作，完全是重复的劳动，又没有什么技术含量在其中......从最开始的各玩各的，到现在大家都往标准上靠，虽是在做做些补充，希望这样的评测能够让更多的朋友感兴趣。 - II. 评测的内容
A. 浏览器的性能
对于Web开发者来说，基于应用TraceMonkey, Chrome为V8，大家其实可以忽略这些名字，因为我们更多的是关注这些引擎之中的一些，比如哪一个引擎执行JavaScript快，哪一个引擎实现的ECMAScript标准更完整等。
2）DOM Tree
浏览器承担解析html任务，对于web开发者来说，更多的是采用js来实现对DOM节点的控制，那么简单的理解，浏览器的HTML Tokenization ，以及构建Dom Tree也是浏览 在前面的4点钟，划分为net、dom、js、css等，但是很多情况下，，换然不同的API接口支持，但是快。
6）浏览器的资源占用
我们经常会有一种感觉，打开XXX浏览器后，我电脑好卡，对于客户端的软件，其实也应该去关心它们对系统资源的整体占用情况，比如我的内存被吃了多少，CPU被占了多少。 - B. Web标准和HTML5的支持
很多时候跟我们的前端开发的同学沟通起来，说到跨浏览器的差异化问题时，都很头疼，为了一个功能往往也写N多兼容性的代码块；当然更多的时候是听到QA同学的抱怨，嚓，开发写的脚本得在IE6、IE7、IE8、IE9、Chrome、Firefox总体是往着好的方向发展。对于HTML5的支持，我觉得更是一种态度，一种开放的态度，一种推动行业发展的态度等。 - III. 评测的对象和硬件环境
展开评测前，首先必须明确两点，评测对象和评测软硬件环境 - A. 评测对象
浏览器名称
Internet Explorer
8.0.6001.18702
Chrome
14.0.835.186
Firefox
7.0.1
- 目前主流的做内核的有IE、Chrome、firefox、opera、safari，因opera和safari的市场占有率有限制，因此不纳入评测对象中，同时因为国内的双核或者单核的浏览器厂商都是用的IE的Trident内核和Chrome的webkit内核，虽然在webkit内核上有的浏览器厂商做了改进，但是该改进只是很小的一些部分，因此也不将它们列到评测之中。
-
- B. 评测硬件环境
硬件软件
数据
操作系统
WinXP 32位
CPU
Intel Core i3 2.13Ghz
内存
3G
硬件类型
笔记本
- 受测试的硬件环境的限制，只在这个平台上进行测试。
-
- IV. JavaScript引擎性能
现在的web应用，越来越多的依赖javascript脚本来实现，而且各浏览器内核厂商也不停的在JavaScript引擎上做非常大的改进，在大多数情况下，关于浏览器的评测，我们会采用一些benchmark，Google的性能测试benchmark有V8（http://v8.googlecode.com/svn/data/Sunspider，由Webkit开发的纯JavaScript性能测试平台，平台主要是通过复杂的算法和大量的数组循环等建立的测试平台。测试用例，还包括自己开发的测试用例，用例设计思想总体跟Sunspider相差不大。
Google V8，目前最新版本的Google V8是Suite 6，是由Google的Google V8性能评测benchmark - 总结：柱形状越高越好，从上图可以看出，在google的V8性能评测benchmark中，chrome是遥遥领先于IE和Firefox的，V8的性能整体优于IE和Firefox的JavaScript引擎。
- 注：在IE8执行过程中，会弹出“是否停止运行此脚本”的对话框。这是因为在JScript中，对于长期运行的脚本，默认的statements是5 million，因此需要针对性的修改注册表信息，详细方法参见http://support.microsoft.com/kb/175500
- Sunspider性能评测benchmark
-
总结：柱形越低越好，从图中可以看出，在webkit的sunspider性能benchmark中，chrome也是领先于IE和Firefox，IE和Chrome的差距非常的大。- Kraken性能评测benchmark
-
总结：虽然已经针对性的改了IE可以接受的最大的statement，但是执行过程中IE任然会长时间的假死，在此放弃在IE上的测试。同时在该项的测试中，chrome也处于领先的地位。- Peacekeeper性能评测benchmark
-
总结：该项也是Chrome领先。- JSBenchmark性能评测benchmark
-
总结：该项也是Chrome遥遥领先。- 从Sunspider、Kraken、Google V8、JSBe
- 在
- sum = 0;
- nchmark、Peacekeeper的执行结果看来，IE的Jscript执行效率比较低，Chrome采用的V8引擎执行效率比较高。
- 很显然，通过以上的benchmark的评测，我们获得了各浏览器的JavaScript引擎的性能数据，基于这些数据我们也比较清晰的浏览器内核层面上，提供了哪些上层的API给web开发者调
- var file;
for (var i = 0; file = fileList[i]; i++) {
sum += file
}
- 以下是选取的几个点进行ElementById
116667
5580894
4688747
getElementsByName
42832
4540056
3727369
getElementsByTagName
47832
3649011
3727369
getElementsByCl测试的结果（更完整的test suite需要构建） - 测试项
IE
Chrome(ops/s)
Firefox
getassName
47352
4540056
2674716
for loop
0.37
50611946
29021539
JSON.parse
235429
311500
61691
Function
42480
86268
30113
recursion
30
311
119
- 通过情况，我们没有更多的时间投入到更多API的性能优化中。
- 显然，这个时候其实我们更想了解前端开发者应用哪些API比较频繁，针对这些应用频繁的API进行更深入的优化，比针对所有的API都进行深度优化可能效果来得更好。
-
比如，使用频率最高的indexOf- 测试项
IE
Chrome
Firefox
indexOf
466
8213
11945
- 总结：从以上的评测可以看出，在benchmark上和各API接口测试框架上的评测来看，Chrome都领先于其他的浏览器，虽然在使用频度最高的接口上略落后于Firefox（可能与评测环境相关），但是整体的性能还是非常突出的，大赞V8引擎。
- V. Dom Tree性能
W3C标准组织定义了HTML的语法规范，当前的final版本是HTML4，同时HTML5正在进行中，HTML5标准的完成估计也是猴年马月了，太多不确定的因素在影响整个标准的制定核执行。并且浏览器内核厂商也并未完全按照标准去实现，之后的标准的评测中会解释。 - 为什么要考虑Dom parsing的性能呢？先看一下一份微软关于IE8的统计分析数据。
-
在整个浏览器的解析处理网页的过程中，解析 HTML、构建DOM Tree等也是相对比较耗时的。针对该部分的评测，采用Dormaeo（http://dromaeo.com/）评测组件，该评测组件是由Firefox开发提供。- Dormaeo性能评测数据
- 测试项
IE
Chrome(runs/s)
Firefox
Dom Attributes
17.52
314.71
260.84
Dom Modification
21.5
157.08
123.47
Dom Query
NA
5859.88
4646.96
Dom Traversal
NA
196.09
114.51
总计
NA
673.54
507.72
- 如果在某个页面设计大量的某种tag呢？如nontroppo性能评测数据http://nog/timer/csstest.html
- 测试项
IE(ms)
Chrome(ms)
Firefox
nontroppo
31
12
39
- 总结
- 从Dormaeo和nontroppo的评测结果看来，Chrome都是领先于其他浏览器的。
- 题外话：不管我们设计如何有针对性的测试用例，可是浏览器的应用场景是经常用的网站，更多的时候可能需要对现有的Top Site进行统计分析，虽然可能不同的Web前端开发者的思路不一样，导致开发的网页效果千差万别，但是从统计分析中还是可以发现很多有价值的地方。比如一个页面的page size是多少？诸如此类的已方便定义更有效的数据结果等。以及接下来的页面加载时间的评测。
-
-
- VI. CSS渲染和选择器
在这部分呢，评测主要关注浏览器的渲染引擎怎么处理CSS，进行渲染。评测采用的测试组件为taskspeed（ slickspeed），其实严格意义上来说，taskspeed和slickspeed是用来测试常用框架的选择器性能，在此呢也借用测下浏览器选择器的性能。 - Taskspeed的评测结果
- Jquery1.4.1
Prototype
YUI
ie
4048
10707
4325
chrome
630
598
549
firefox
563
759
535
- 通过以上的test suite我们对比发现了这些框架在进行CSS Selector时的性能以及在各个浏览器上执行的效果，IE依旧最差，firefox与chrome基本持平。
- 另外再自己构建测试用例，出发点是构建成千上万的Div标签、然后设置标签的CSS属性等，测试包含5个方面，基本的样式、标签、类选择器、child和descendant，详细见以下结果数据。
- 测试项
IE(ms)
Chrome(ms)
Firefox(ms)
baseline
421
558
535
Tag
344
531
464
Class
297
546
394
Child
375
4
359
524
447
- 总结：Chrome在这项评测中并没有优势。
- 虽然我们通过构建测试用例来进行了评测，但是往往对于通常的网页可能没有那么多的Dom节点和CSS属性或者选择器的应用。引用一份统计数据：
- Web Site
# CSS Rules
#DOM Elements
AOL 2289
1628
eBay
305
588
Facebook
28
1038
886
MySpace
932
444
Wikipedia
795
1333
Yahoo!
800
564
YouTube
82erage
10331
817
av
923
- 从以上数据可以发现，真实的网站所应用到的DOM或者CSS远比我们设计的测试用例来的简单。
- 再引用David Hyatt（Safari和Webkit的架构师，在firefox工作）的一句话
- The sad truthabout CSS3 selectors is that they现并不优异，但是事实上我们的网页中也不会有测试用例设计中的变态情况，呵呵….也借用那句话，关注按selector的性能就不要用了。貌似WebCore在排版渲染上略显不 really shouldn’t be used at all if you careabout page performance. Decorating your markup with classes and ids andmatching purely on those while avoiding all uses of sibling, descendant andchild selectors will actually make a page perform significantly better in allbrowsers.
- 总结：虽然Chrome在CSS 的selector中的表足呀。
- VII. 网络库
不同的浏览器采用了不同的网络库，关于网络库在整个浏览器的过程中的重要性，本来是有份统计数据的，目前找不到，见谅:)。那么从yahoo的Yslow中我们可见一斑，以下是Yslow的23条规则： - 1. MinimizeHTTP Requests
- 2. Usea Content Delivery Network
- 3. Avoidempty src or href
- 4. Addan Expires or a Cache-Control Header
- 5. GzipComponents
- 6. PutStyleSheets at the Top
- 7. PutScripts at the Bottom
- 8. AvoidCSS Expressions
- 9. MakeJav
- figureETags
- 15. 21. AvoidFilters
- 22. DoNot Scale Images in HTML
- 23. Makefavicon.ico Small and
- aScript and CSS External
- 10. ReduceDNS Lookups
- 11. MinifyJavaScript and CSS
- 12. AvoidRedirects
- 13. RemoveDuplicate Scripts
- 14. Con Cacheable
- Studies have shown that web pageresponse time can be improved by 25% to 50% by following these rules.
- 关于网络的性能，其实通过一些常见的工具就可以做些简单的比较，Firefox的firebug, Chrome的Web Inspector，IE的Devtool。当然，本身由于每个插件是在不同的浏览器上使用的，所以通过不同的工具和方法所获得的数据也不太具有可比较性，纯参考。本想将网络过程中的DNS解析、请求时间、响应时间等写个统一的工具测下，目前还是先放弃，当然也有部分原因是自己对这块本身的了解不是很深入，待有时间再收拾呗。
- UA profile评测http://stevesouders.com/ua/indexold.php
- 测试项
IE
Chrome
Firefox
服务器的连接数
10
6
6
最大连接数
30
28
30
是
是
并行样式表
是
是
是
并行样式表和内联脚本
否
是
- 总结：在这个上面firefox做得最好的了，当然这其
如果我们把以上的内容进行汇总处理的话，其实就是浏览器的页面加载时间。我们对浏览器进行分模块的测试，获得各个模块的一个整体的评测数据，然而浏览器处理的过程并不是一个串行的过程，那么简单的来说，从开始输入url到页面实并不能严格说明IE的网络库最差或Firefox的网络库最好，只能说在一些尽可能优化性能的地方Firefox和Chrome都在努力去做。 -
-
- VIII. 页面加载时间（Page Load Time）显示完成应该是我们所需要的结果，见以下的详细数据：
- URL List
IE首次加载
IE二次加载
Chrome首次加载
Chrome
687.5
http://wen
312.5
312.5
390.625
http://top.baidu.com/
2531.25
2562.5
1015.625
1343.75
2281.25
1796.875
http://dict.baidu.com/
1171.875
1109.375
125
140.625
140.625
140.625
33
http://www.163. 6140.625
3156.25
http://www.google.com.hk/
1609.375
1046.875
2812.5
1859.375
4625
4015.625
http://www.ifeng.com/
5109.375
2843.75
2250
1937.5
656.25
2703.125
http://www.xinhuanet.com/
3156.25
2859.375
2093.75
2343.75
3187.5
2484.375
- 为了保证数据的准确性总结：跟我们的直观感受应该比较贴近，Chrome在加载网页的速度方面，都是领先的。
- IX. 资源占用
节省资源以达到更好的用户体验对浏览器来说很重要，但是因为Chrome、IE、Firefox的进程模型不一致，而且目前的硬件资源充分的条件下，这些现在也都不是问题了，但还是从资源占用情况上简IE
Chrome
Firefox
- IE CPU
-
-
Chrome CPU-
-
-
- Firefox CPU
-
-
-
-
2） 浏览器启动时IO读写情况- Browser
IO
IE
Chrome
Firefox
- 3） 浏览器启动时Hard Fault
- Browser
Hard Fault
IE
Chrome
Firefox
- 总结：其实没什么个人觉得还是先需要从ACID3和HTML5Test来解释下。
- 先说ACID3（http://acid3.acidtests.org/），官网
- )
- · DOM2Traversal (NodeIterator, TreeWalker)
- · DOM2Views (defaultView)
- · ECMAScript
- · HTML4(<object>, <iframe>, …)
- · HTTP(Content-Type, 404, …)
- · MediaQueries
- · Selectors(:lang, :nth-child(), combinators, dynamic changes, …)
- · XHT), hsla(), …)
- · CSS3 UI(‘cursor’)
- · data:URIs
- · SVG (SVGAnimation, SVG Fonts, …)
- Note：The main part of test is automatedthrough JavaScript, a sort of test harness that runs 100 subtests. Getting ascore of 100 is not the same as passing Acid3 – a common misconce.createElement('t4')); var callCount = 0; var filterFunctions = [ function (node) { expect(1, node, doc.body);
- 上列的一堆测试对象
- · DOM2 Core
- · DOM2Events
- · DOM2 HTML
- ML 1.0
- · CSS2(@font-face)
- · CSS2.1(‘inline-block’, ‘pre-wrap’, parsing…)
- · CSS3Color (rgba(
- · DOM2Range…return true; }, // filter 0 function (node) { expect(3, node, t1); return true; }, // filter 1 function (node) { expect(5, node, t2); return true; }, // filter 2 function (node) { expect(7, node, t3); doc.body.removeChild(t4); return true; }, // filter 3 function (node) { expect(9, node, t4); retur true; }, // filter 4 function (node) { expect(11, node, t4); doc.body.removeChild(t4); return 2 /* REJECT */; }, // filter 5
- function (node) { expect(12, node, t3); return true; }, // filter 6
- function (node) { expect(14, node, t2); doc.body.removeChild(t2); return true; }, // filter 7
- function (node) { expect(16, node, t1); return true; },
- ption, orperhaps an oversimplification.ACID3的测试用例function () { // test 2: Removing nodes during iteration var count = 0; var expect = function(n, node1, node2) { count += 1; assert(n == count, "reached expectation " + n + " when expecting expectation " + cnount); assertEquals(node1, node2, "expectation " + count + " failed"); }; var doc = getTestDocument(); var t1 = doc.body.appendChild(doc.createElement('t1')); var t2 = doc.body.appendChild(doc.createElement('t2')); var t3 = doc.body.appendChild(doc.createElement('t3')); var t4 = doc.body.appendChild(doc// filter 8
- ];
- var i = doc.createNodeIterator(doc.documentElement.lastChild, 0xFFFFFFFF, function (node) { return filterFunctions[callCount++](node); }, true);
- // * B 1 2 3 4
- expect(2, i.nextNode(), doc.body); // filter 0
- // [B] * 1 2 3 4
- expect(4, i.nextNode(), t1); // filter 1
- // B [1] * 2 3 4
- expect(6, i.nextNode(), t2); // filter 2
- // B 1 [2] * 3 4
- expect(8, i.nextNode(), t3); // filter 3
- // B 1 2 [3] *
- doc.body.appendChild(t4);
- // B 1 2 [3] * 4
- expect(10, i.nextNode(), t4); // filter 4
- // B 1 2 3 [4] *
- expect(13, i.previousNode(), t3); // filters 5, 6
- expect(15, i.previousNode(), t2); // filter 7
- expect(17, i.previousNode(), t1); // filter 8
- // B [1] * 3
- return 1;
- },
url: 'http://www.w3.org/TR/webstorage/#the-localstorage-attribute', - passed: 'localStorage' in window && window.localStorage != null,
- value: 5
- });
- 从以上的测试用例中我们可以看出，测试用例中只是判断window对象是否有localStorage属性。但是如果你上W3C官网搜一下，其实提供的接口远比这个来得复杂。
-
- interface Storage { readonly attribute unsigned longlength; DOMString?key(unsigned long index); getter DOMString getItem(DOMString key); setter creator void setItem(DOMString key, DOMStringvalue); deleter void removeItem(DOMString key); void clear();};
- 通过以上的解释可以发现， IE
Chrome
Firefox
支持度
NA
427/11029
164/11029
- 关于HTML5的标准测试用例如Web Storage
- IE
-
Chrome-
Firefox-
总结：部分的测试用例不能对外公开- XI. 总结
针对于主流浏览器的内核的性能和对标准的支持性进行了评测，总结下优势 - 1. 快。V8引擎，图形库、渲染引擎都很快，反正是各种快…..
- 2. 良好的标准支持的支持，使得很多开发者慢慢的从Firefox上转移。
- 5. 简洁。说实话，我个人非常喜欢Chrome的简洁的界面，用户体验感觉很好。
-
- 当然有这些优势，也存在一些劣势或者缺陷需要进一步改进。
- 1. 用户定位。第一次装完Chrome后，发现都不知道改怎么去设置，所以基于目前国内大量小白用户的基础上，我不是很看好Chrome在国内的市场。真的要想在国内打开更多的市场，建议还是专门为国内的用户改一套通俗的UI，但是这在google的全球推广策略中，肯定是不可接受的。只能说，chrome会抢走Firefox的大量用户，但是对IE的或者国内其他的浏览器用户基本没有办法，以上纯属个人观点。
- 2. 网银
