浏览器内核和性能优化总结

浏览器内核和性能优化总结

---

对于当下主流浏览器，很多人并不清楚它们内核具体是什么，有何特点；有的人编写html和CSS代码时，乱写一通，殊不知错误的写法会消耗浏览器更多的性能，导致加载变慢。
我从网上找了很多资料，参考了很多文章，总结一下浏览器的内核，以及对其性能的优化。

文章参考：

http://www.cnblogs.com/qq313462961/p/6114085.html
http://www.cnblogs.com/ada-zheng/p/4308581.html

浏览器内核

定义

浏览器内核负责对网页语法进行解释并渲染。 通常所说的浏览器内核也就是浏览器所采用的渲染引擎和 JS 引擎。
渲染引擎决定了浏览器如何显示网页的内容以及页面的格式信息。JS 引擎则是解析 Javascript 语言，执行 javascript 语言来实现网页的动态效果。
不同的浏览器内核对网页编写语法的解释也有不同，因此同一网页在不同的内核的浏览器里的渲染效果也可能不同。

四大引擎内核：Trident，Gecko，Presto，Webkit

Trident内核

代表产品IE浏览器，又称其为IE内核，Trident是微软开发的一种排版引擎。

使用Trident渲染引擎的浏览器包括：IE、傲游、世界之窗浏览器、Avant、腾讯TT、Netscape 8、NetCaptor、Sleipnir、GOSURF、GreenBrowser和KKman等。

Gecko内核

代表作品Mozilla Firefox，Gecko是一套开放源代码的、以C++编写的网页排版引擎。

Gecko是最流行的排版引擎之一，仅次于Trident。使用Gecko渲染引擎的浏览器包括：Firefox、Netscape6至9。

Presto内核

代表作品OperaPresto，是由Opera Software开发的浏览器排版引擎，供Opera 7.0及以上使用。它取代了旧版Opera 4至6版本使用的Elektra排版引擎，该款引擎的特点就是渲染速度的优化达到了极致，然而代价是牺牲了网页的兼容性

Opera 在 2013 年 2 月宣布放弃 Presto，转用webkit引擎，Presto 内核的 Opera 浏览器版本永远的停留在了 12.17。在 Chrome 于 2013 年推出 Blink 引擎之后，Opera 也紧跟其脚步表示将转而使用 Blink 作为浏览器核心引擎

WebKit内核

代表作品Safari、Chrome ，主要用于Mac OS系统，它的特点在于源码结构清晰、渲染速度极快。缺点是对网页代码的兼容性不高，导致一些编写不标准的网页无法正常显示。

现在很多人错误地把 webkit 叫做 chrome内核，殊不知Webkit 的鼻祖其实是 Safari。

主要代表作品有Safari和Google的浏览器Chrome。

Chromium/Blink

Chromium引擎虽然是属于WebKit的分支，却把WebKit的代码梳理得可读性提高很多，所以以前可能需要一天进行编译的代码，现在只要两个小时就能搞定。因此Chromium引擎和其它基于WebKit的引擎所渲染页面的效果也是有出入的。

Chrome放弃Chromium引擎转而使用最新的Blink引擎（基于WebKit2——苹果公司于2010年推出的新的WebKit引擎），Blink对比上一代的引擎精简了代码、改善了DOM框架，也提升了安全性。

浏览器渲染原理

Web页面运行在各种各样的浏览器当中，浏览器载入、渲染页面的速度直接影响着用户体验简单地说，页面渲染就是浏览器将html代码根据CSS定义的规则显示在浏览器窗口中的这个过程。先来大致了解一下浏览器都是怎么干活的：
　　1. 用户输入网址（假设是个html页面，并且是第一次访问），浏览器向服务器发出请求，服务器返回html文件；
　　2. 浏览器开始载入html代码，发现标签内有一个标签引用外部CSS文件；
　　3. 浏览器又发出CSS文件的请求，服务器返回这个CSS文件；
　　4. 浏览器继续载入html中部分的代码，并且CSS文件已经拿到手了，可以开始渲染页面了；
　　5. 浏览器在代码中发现一个标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码；
　　6. 服务器返回图片文件，由于图片占用了一定面积，影响了后面段落的排布，因此浏览器需要回过头来重新渲染这部分代码；
　　7. 浏览器发现了一个包含一行Javascript代码的< script >标签，赶快运行它；
　　8. Javascript脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个（style.display=”none”）。杯具啊，突然就少了这么一个元素，浏览器不得不重新渲染这部分代码；
　　9. 终于等到了的到来，浏览器泪流满面……
　　10. 等等，还没完，用户点了一下界面中的“换肤”按钮，Javascript让浏览器换了一下标签的CSS路径；
　　11. 浏览器召集了在座的各位，“大伙儿收拾收拾行李，咱得重新来过……”，浏览器向服务器请求了新的CSS文件，重新渲染页面。

　
说到页面为什么会慢？那是因为浏览器要花时间、花精力去渲染，尤其是当它发现某个部分发生了点变化影响了布局，需要倒回去重新渲染，内行称这个回退的过程叫reflow。

reflow几乎是无法避免的。现在界面上流行的一些效果，比如树状目录的折叠、展开（实质上是元素的显示与隐藏）等，都将引起浏览器的 reflow。鼠标滑过、点击……只要这些行为引起了页面上某些元素的占位面积、定位方式、边距等属性的变化，都会引起它内部、周围甚至整个页面的重新渲染。

reflow问题是可以优化的，我们可以尽量减少不必要的reflow。比如开头的例子中的图片载入问题，这其实就是一个可以避免的reflow——给图片设置宽度和高度就可以了。这样浏览器就知道了图片的占位面积，在载入图片前就预留好了位置。

另外，有个和reflow看上去差不多的术语：repaint，中文叫重绘。 如果只是改变某个元素的背景色、文字颜色、边框颜色等等不影响它周围或内部布局的属性，将只会引起浏览器repaint。repaint的速度明显快于 reflow（在IE下reflow要比repaint 更缓慢）。

从浏览器的渲染原理分析CSS性能

加载页面时浏览器的具体工作流程：

1、解析HTML以重建DOM树：渲染引擎开始解析HTML文档，转换树中的标签到DOM节点，它被称为“内容树”。

2、构建渲染树：解析CSS（包括外部CSS文件和样式元素），根据CSS选择器计算出节点的样式，创建另一个树 ——— 渲染树。

3、布局渲染树: 从根节点递归调用，计算每一个元素的大小、位置等，给每个节点所应该出现在屏幕上的精确坐标。

4、绘制渲染树（Painting the render tree） : 遍历渲染树，每个节点将使用UI后端层来绘制。

主要的流程就是：构建一个dom树，页面要显示的各元素都会创建到这个dom树当中，每当一个新元素加入到这个dom树当中，浏览器便会通过css引擎查遍css样式表，找到符合该元素的样式规则应用到这个元素上。

注意了：css引擎查找样式表，对每条规则都按从右到左的顺序去匹配。

对此，在CSS书写过程中，总结出如下性能提升的方案：

1.避免使用通配规则 : *{…} 计算次数惊人！非常影响性能。
2.尽量少的去对标签进行选择，使用class 和 id属性.
3.不要去用标签限定ID或者类选择符 如：ul#nav,应该简化为#nav
4.尽量少的去使用后代选择器，降低选择器的权重值 后代选择器的开销是最高的，尽量将选择器的深度降到最低，最高不要超过三层，更多的使用类来关联每一个标签元素
5.考虑继承 ，了解哪些属性是可以通过继承而来的，然后避免对这些属性重复指定规则

总而言之，使用尽可能短的匹配规则去匹配元素。

总结

选用高效的选择符，可以减少页面的渲染时间，从而有效的提升用户体验。也许当你想让渲染速度最高效时，你可能会给每个独立的标签配置一个ID，然后用这些ID写样式。那的确会超级快，也超级荒唐！这样的结果是语义极差，后期的维护也是难到了极点。

但说到底，CSS性能这东西对于小的项目来讲可能真的是微乎其微的东西，提升可能也不是很明显，但对于大型的项目肯定是有帮助的。而且一个好的CSS书写习惯和方式能够帮助我们更加严谨的要求自己。