参考文章：不同内核浏览器的差异以及浏览器渲染简介 ,并根据目前浏览器发展情况进行了修改。
一、常见浏览器及其内核
| Web Browser |  Chrome
|
 IE
|
 FireFox
|
 Safari
|
 Opera
|
|---|---|---|---|---|---|
| Rendering Engine | Webkit-Blink | Trident | Gecko | Webkit | Presto/Blink |
微软的新一代浏览器Microsoft Edge，宣布打算采用Chromium开源项目开发桌面版的Microsoft Edge浏览器，详情见Microsoft Edge: Making the web better through more open source collaboration.
对此 个人表示喜大普奔，毕竟IE太难用了，开发的时候做兼容也是非常恶心，但是起码在5年内，IE兼容还是要写的啊(╥╯^╰╥)
二、什么是内核
浏览器最重要或者说核心的部分是“Rendering Engine”，可大概译为“解释引擎”，不过我们一般习惯将之称为“浏览器内核”。负责对网页语法的解释（如HTML、JavaScript）并渲染（显示）网页。
所以，通常所谓的浏览器内核也就是浏览器所采用的渲染引擎，渲染引擎决定了浏览器如何显示网页的内容以及页面的格式信息。
不同的浏览器内核对网页编写语法的解释也有不同，因此同一网页在不同的内核的浏览器里的渲染（显示）效果也可能不同，这也是网页编写者需要在不同内核的浏览器中测试网页显示效果的原因。
另一种关于内核的说明：维基百科(↓)
一、 排版引擎
排版引擎（layout engine），也称为浏览器引擎（web browser engine）、页面渲染引擎（rendering engine）或样版引擎，它是一种软件组件，负责获取标记式内容（如HTML、XML及图像文件等等）、整理信息（如CSS及XSL等），并将排版后的内容输出至显示器或打印机。
二、JavaScript引擎
顾名思义，JavaScript引擎就是用来渲染JavaScript的。
JavaScript引擎是一个专门处理JavaScript脚本的虚拟机，一般会附带在网页浏览器之中。
| JS引擎 | 应用程序(实现) |
|---|---|
| V8 | Google Chrome |
| SpiderMonkey | Mozilla Firefox |
| JavaScriptCore | Safari |
| Chakra (JScript引擎) | Internet Explorer |
| Chakra (JavaScript引擎) | Microsoft Edge |
| KJS | Konqueror |
三、浏览器渲染原理
Web页面运行在各种各样的浏览器当中，浏览器载入、渲染页面的速度直接影响着用户体验简单地说，页面渲染就是浏览器将html代码根据CSS定义的规则显示在浏览器窗口中的这个过程。
先来大致了解一下浏览器都是怎么干活的：
用户输入网址（假设是个html页面，并且是第一次访问），浏览器向服务器发出请求，服务器返回html文件；
浏览器开始载入html代码，发现<head>标签内有一个<link>标签引用外部CSS文件；
浏览器又发出CSS文件的请求，服务器返回这个CSS文件；
浏览器继续载入html中<body>部分的代码，并且CSS文件已经拿到手了，可以开始渲染页面了；
浏览器在代码中发现一个<img>标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码；
服务器返回图片文件，由于图片占用了一定面积，影响了后面段落的排布，因此浏览器需要回过头来重新渲染这部分代码；
浏览器发现了一个包含一行Javascript代码的<script>标签，赶快运行它；
Javascript脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个（style.display=”none”）。杯具啊，突然就少了这么一个元素，浏览器不得不重新渲染这部分代码；
终于等到了</html>的到来，浏览器泪流满面……
等等，还没完，用户点了一下界面中的“换肤”按钮，Javascript让浏览器换了一下<link>标签的CSS路径；
浏览器召集了在座的各位
<span><ul><li>们，“大伙儿收拾收拾行李，咱得重新来过……”，浏览器向服务器请求了新的CSS文件，重新渲染页面。
说到页面为什么会慢？那是因为浏览器要花时间、花精力去渲染，尤其是当它发现某个部分发生了点变化影响了布局，需要倒回去重新渲染，内行称这个回退的过程叫reflow。
reflow几乎是无法避免的。现在界面上流行的一些效果，比如树状目录的折叠、展开（实质上是元素的显示与隐藏）等，都将引起浏览器的 reflow。
鼠标滑过、点击……只要这些行为引起了页面上某些元素的占位面积、定位方式、边距等属性的变化，都会引起它内部、周围甚至整个页面的重新渲染。
通常我们都无法预估浏览器到底会reflow哪一部分的代码，它们都彼此相互影响着。
reflow问题是可以优化的，我们可以尽量减少不必要的reflow。
比如开头的例子中的<img>图片载入问题，这其实就是一个可以避免的reflow——给图片设置宽度和高度就可以了。
这样浏览器就知道了图片的占位面积，在载入图片前就预留好了位置。
另外，有个和reflow看上去差不多的术语：repaint，中文叫重绘。
如果只是改变某个元素的背景色、文字颜色、边框颜色等等不影响它周围或内部布局的属性，将只会引起浏览器repaint。
repaint的速度明显快于 reflow（在IE下需要换一下说法，reflow要比repaint 更缓慢） 雾 。
四、从浏览器的渲染原理讲CSS性能
我们主要根据浏览器的渲染原理对CSS的书写性能做一点改进（当然还有JS本篇文章暂不考虑，后面的文章会做介绍），下面让我们一起来揭开浏览器的渲染原理这一神秘的面纱吧：
最终决定浏览器表现出来的页面效果的差异是：渲染引擎 Rendering Engine（也叫做排版引擎），也就是我们通常所说的“浏览器内核”，负责解析网页语法（如HTML、JavaScript）并渲染、展示网页。相同的代码在不同的浏览器呈现出来的效果不一样，那么就很有可能是不同的浏览器内核导致的。
我们来看一下加载页面时浏览器的具体工作流程：
1、解析HTML以重建DOM树（Parsing HTML to construct the DOM tree ）：
渲染引擎开始解析HTML文档，转换树中的标签到DOM节点，它被称为“内容树”。
2、构建渲染树（Render tree construction）：
解析CSS（包括外部CSS文件和样式元素），根据CSS选择器计算出节点的样式，创建另一个树 —- 渲染树。
3、布局渲染树（Layout of the render tree）:
<wbr style="font-family: "Microsoft Yahei", sans-serif;">从根节点递归调用，计算每一个元素的大小、位置等，给每个节点所应该出现在屏幕上的精确坐标。
4、绘制渲染树（Painting the render tree）
<wbr style="font-family: "Microsoft Yahei", sans-serif;">: 遍历渲染树，每个节点将使用UI后端层来绘制。
主要的流程就是：构建一个dom树，页面要显示的各元素都会创建到这个dom树当中，每当一个新元素加入到这个dom树当中，浏览器便会通过css引擎查遍css样式表，找到符合该元素的样式规则应用到这个元素上。
注意了：css引擎查找样式表，对每条规则都按从右到左的顺序去匹配。
对此，在CSS书写过程中，总结出如下性能提升的方案：
- 避免使用通配规则 如 *{} 计算次数惊人！只对需要用到的元素进行选择
- 尽量少的去对标签进行选择，而是用class 如：#nav li{},可以为li加上nav_item的类名，如下选择.nav_item{}
- 不要去用标签限定ID或者类选择符 如：ul#nav,应该简化为#nav
- 尽量少的去使用后代选择器，降低选择器的权重值 后代选择器的开销是最高的，尽量将选择器的深度降到最低，最高不要超过三层，更多的使用类来关联每一个标签元素
- 考虑继承 了解哪些属性是可以通过继承而来的，然后避免对这些属性重复指定规则
