浏览器内核
浏览器最重要或者说核心的东西是“Rendering Engine”，可以理解为解释引擎，一般称之为“浏览器内核”。负责对网页语法的解释(如HTML、JavaScript)并渲染(显示)网页。所以，通常所谓的浏览器内核也就是浏览器采用的渲染引擎，渲染引擎决定了浏览器如何显示网页的内容以及页面的格式信息。浏览器的内核很多，如果加上所有几乎没有人在用的非商业的免费内核，那么大约有10款以上甚至更多，不过通常我们比较常见的大约有四种：下面简单介绍一下。
Trident
IE浏览器使用的内核，该内核程序在1997年的IE4中首次被采用，是微软在Mosaic代码的基础之上修改而来的，并一直沿用至IE9。
Trident实际上是一款开放的内核，其接口设计的相当成熟，因此才有许多采用IE内核而非IE浏览器涌现(如Maxthon，The World ，TT，GreenBrower，AvantBrower)此外，为了方便人们也称之为IE内核。由于IE本身的垄断性而是Trident内核长期一家独大，微软很长的时间并没有更新Trident内核，这导致了两个后果：- Trident内核几乎与W3C标准脱节- Trident内核的大量BUG等安全性问题没有得到及时解决，然后加上一些致力于开源的开发者和一些学者公开认为IE浏览器不安全的观点，也有很多用户转向了其他浏览器，Firefox和Opera就是在这个时候兴起的。非Trident内核浏览器市场占有率大幅提高也致使许多网页开发人员开始注意网页标准和非IE浏览器的浏览问题。
Gecko
Netscape6开始采用的内核，后来的Mozilla Firefox采用了该内核，Gecko的优点在于代码完全公开，因此，其开发程序很高，全世界的程序员都可以为其增加代码，增加功能。因为这个开源的内核，因此受到了许多人们的青睐，Gecko内核浏览器也非常多，这也是Gecko内核虽然年轻但市场占有率能够迅速提高的重要原因。事实上，Gecko引擎的由来跟IE不无关系，前面说过IE没有使用W3C标准，这导致微软内部一些开发人员不满，他们当时已经停止更新了Netscape的一些员工创办了Mozilla，以当时的Mosaic内核为基础重新编译内核，于是开发出Gecko。不过事实上，Gecko内核浏览器仍然是Firefox用户最多，所以有时也会被称之为Firefox内核。此外，Gecko也是一个跨平台内核，可在Window、BSD、Linux和Mac OS中使用。
Presto
目前Presto采用的内核，该内核在2007年Opera7中首次被使用，该引擎的特点就是渲染速度的优化达到了极致，也是目前公认 浏览器速度最快得浏览器内核，而代价是牺牲了网页的兼容性。实际上，这是一个动态内核，与前面几个内核的最大区别就是在脚本的处理上，Presto有着天生的优势，页面全部或者部分都能够在回应脚本事件等情况下被重新解析。此外，该内核在执行JavaScript的时候有着最快的速度，根据在同等条件下测试，Presto内核执行同等的JavaScript所需时间仅是Trident和Gecko内核的约1/3，(Trident内核最慢)。那次测试的时候因为Apple机的硬件条件和普通PC机器不同，没有进行webcore内核测试。只可惜Presto是商业引擎，使用Presto引擎除了Opera浏览器之外，还有NDSBrower、Will Internet Channke、Nokia 770等网络浏览器，这很大程度上限制了Presto的发展。***
WebkitWebkit
引擎包含WebCore排版引擎及JavaScriptCore解析引擎，均是从KDE的KHTML及KJS引擎衍生而来，它们都是自由软件，在GPL条约下授权，同时支持BSD系统的开发。 所以Webkit也是自由软件，同时开放源代码。在安全方面不受IE、Firefox的制约，所以Safari浏览器在国内还是很安全的。限于Mac OS X使用不广泛和Safari浏览器曾经只是Mac OS X的专属浏览器，这个内核本身应该说市场范围并不大；但似乎根据最新的浏览器调查表明，该浏览器的市场甚至已经超过了Opera和Presto，这一方面是由于苹果转到X86架构之后的人气暴涨，另外也是因为Safari 3终于推出了Windows版的缘故吧。Mac下还有OmniWeb、Shiira等人气很高的浏览器。google也chrome也使用webkit作为内核。Webkit内核在手机上应用也十分广泛，例如Google手机的Gphone、Apple的iphone、Nokia’s Series 60 brower等所使用的Brower内核引擎，都是基于Webkit。
手机浏览器
手机浏览器内核目前微软的Trident在移动终端上主要为WP系统内置浏览器，Webkit内核的适用范围则较为广泛，Android原生浏览器、苹果的Safari、谷歌的Chrome(Android4.0使用)都是基于Webkit开源内核开发的。对于Android手机而言，使用率最高的就是Webkit内核，我们看到很多手机浏览器厂商都宣称有着自主内核，比如手机UC就号称采用了U3内核、而华为也经常标榜自己的天天浏览器采用了T9内核，事实上，他们都是基于开源内核Webkit进行二次开发的，并不是完全的自主内核。而在iOS以及WP7平台上，由于系统封闭，不允许除系统自带浏览器内核以外的浏览器内核进入，因此各家浏览器的开发均为在Safari或者IE内核的基础上进行二次开发，优化功能和自制UI。
JavaScript引擎
JavaScript引擎就是用来渲染JavaScript的。JavaScript的渲染速度越快，动态页面的展示也越快。Opera在JavaScript引擎的跑分上面一直都是很牛逼的，一般来说最新测试版之间PK，Opera基本都会夺冠。- chakra 查克拉，IE9启用的新的JavaScript引擎。- SpiderMonkey/TraceMonkey/JaegerMonkey SpiderMonkey应用在Mozilla Firefox 1.0-3.0，TraceMonkey应用在Mozilla Firefox 3.5-3.6版本，JaegerMonkey应用在Mozilla Firefox 4.0及后续的版本。- V8 应用与chrome- Nitro 应用于Safari 4及后续的版本。- Linear A/Linear B/Futhark/Carakan Linear A应用于Opera 4.0-6.1版本，Linear B应用于Opera 7.0～9.2版本，Futhark应用于Opera 9.5-10.2版本，Carakan应用于Opera 10.5及后续的版本。- KJS KHTML对应的JavaScript引擎。
出现了一些类似双核，三核的浏览器
balabala
tips- chrome/chromium
很多人都会说自己用的双核浏览器是Chrome/IE双核的，或者说是基于Chrome的。其实这种说法并不正确，因为Chrome本身并不开源，其它厂商是不能去定制Chrome的。能被修改、定制的是Chromium，Chrome的开源开发版本，代码和Build都提供下载。Chromium/Chrome两个单词都是铬，分别是拉丁文和英文，除了名字之外，很有很多不同，你可以自己对比一下。 Chromium一天最多可以更新十几二十个版本，实验性的新特性都会现在这里放出，但是Chromium本身其实并不稳定。 Chrome总共有四个更新分支：Canary、Dev、Beta、Stable，稳定性依次增强。
- 页面兼容性判断 在确保IE浏览器没有损坏的基础上，搭配一款非Trident内核的浏览器进行判断，如果可以的话，最好所有内核都配齐了。 控制变量就能找到问题所在，是浏览器本身的问题，还是页面编码有问题。对于用户来说就能更好地去选择自己该用什么浏览器访问什么页面，对于开发者来说应该要写出无差别代码。
- 这年头流行刷版本号 现在版本号最高的浏览器是Chrome，稳定版的版本号是14，也是现在主流浏览器里面诞生时间最短的，真是一个刷版本号高手。早期的Chrome版本更迭还会增加一些比较重要的新特性，比如扩展支持，现在的版本更迭基本上并没有伴随什么大的更新。现在很多伪高端用户就会整天追着第三方编译版本赶紧跟进版本号，但是其实真正的意义并不大。 多亏了Chrome的“提携”，今年Firefox也在猛刷版本号，年初还是3.x，现在正式版已经是7.0.1，每夜版已经到了10.0。Opera积累了多年才到11.50，测试版是12.0。IE的正式版是9，平台预览版是10。
浏览器渲染原理
Web页面运行在各种各样的浏览器当中，浏览器载入、渲染页面的速度直接影响着用户体验简单地说，页面渲染就是浏览器将html代码根据CSS定义的规则显示在浏览器窗口中的这个过程。
//浏览器渲染原理
1. 用户输入网址（假设是个html页面，并且是第一次访问），浏览器向服务器发出请求，服务器返回html文件；
2. 浏览器开始载入html代码，发现<head>标签内有一个<link>标签引用外部CSS文件；
3. 浏览器又发出CSS文件的请求，服务器返回这个CSS文件；
4. 浏览器继续载入html中<body>部分的代码，并且CSS文件已经拿到手了，可以开始渲染页面了；
5. 浏览器在代码中发现一个<img>标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码；
6. 服务器返回图片文件，由于图片占用了一定面积，影响了后面段落的排布，因此浏览器需要回过头来重新渲染这部分代码；
7. 浏览器发现了一个包含一行Javascript代码的<script>标签，赶快运行它；
8. Javascript脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个（style.display=”none”）。杯具啊，突然就少了这么一个元素，浏览器不得不重新渲染这部分代码；
9. 终于等到了</html>的到来，浏览器泪流满面……
10. 等等，还没完，用户点了一下界面中的“换肤”按钮，Javascript让浏览器换了一下<link>标签的CSS路径；
11. 浏览器召集了在座的各位<span><ul><li>们，“大伙儿收拾收拾行李，咱得重新来过……”，浏览器向服务器请求了新的CSS文件，重新渲染页面。
当它发现某个部分发生了点变化影响了布局，需要倒回去重新渲染，内行称这个回退的过程叫reflow。reflow几乎是无法避免的。现在界面上流行的一些效果，比如树状目录的折叠、展开（实质上是元素的显示与隐藏）等，都将引起浏览器的 reflow。鼠标滑过、点击……只要这些行为引起了页面上某些元素的占位面积、定位方式、边距等属性的变化，都会引起它内部、周围甚至整个页面的重新渲染。通常我们都无法预估浏览器到底会reflow哪一部分的代码，它们都彼此相互影响着。
尽量减少不必要的reflow
从浏览器的渲染原理讲
CSS性能最终决定浏览器表现出来的页面效果的差异是：渲染引擎Rendering Engine，也就是我们通常所说的“浏览器内核”，负责解析网页语法(如HTML、JavaScript)并渲染、展示网页。相同代码在不同浏览器呈现过来的效果也不一样，那么很有可能是不同的浏览器内核导致的。
flowst=>start: Parsing HTML to construct the DOM treeend=>end: painting the render treeop=>operation: Render tree construction od=>operation: Layout of the render treest->op->od->end
解析HTML以构建DOM树：渲染引擎开始解析HTML文档，转换树中的标签到DOM，它被称为内容树。构建渲染树：解析CSS(包括外部CSS文件和样式元素)，根据CSS选择器计算出节点样式，创建另一个树——渲染树。布局渲染树：从根节点递归调用，计算每一个元素的大小、位置等，给每个节点所应该出现在屏幕上的精确坐标。绘制渲染树：遍历渲染树，每个节点都将使用UI后端层来绘制。构建一个dom树，页面要显示的各个元素都会创建到这个dom树中，每一个新的元素加入到这个dom树中，浏览器便会通过css引擎查遍css样式表，找到符合该元素的样式规则应用到这个元素上。
css引擎查找样式表，对每条规则都按从右到左的顺序匹配
#nav li {}
认为浏览器会找到唯一id，然后找其下面的所有<li>元素实际上，浏览器是从右往左进行匹配的。相当于浏览器先遍历整个页面上的所有<li>元素，然后确定他的父元素的id是否为nav。
*{}
通配符*会匹配所有元素，浏览器必须遍历每一个元素。
ul#nav{} ul.nav{}
在页面中一个指定的ID只能对应一个元素，所以没有必要添加额外的限定符，而且这会使它更低效。同时也不要用具体的标签限定类选择符，而是要根据实际的情况对类名进行扩展。
ul li li li .nav_item{}
对于这样的选择器，选出来的东西，使用一个类关联这些元素。
提升方案：
- 避免使用通配规则，只需要对用到的元素进行选择
- 尽量少的去对标签进行选择，而是使用class
- 不要去使用标签限定ID或者类选择符- 尽量少的去使用后代选择器，降低选择器的权重值。后代选择器的开销是最高的，尽量少的去使用选择器，最好不要超过三层，更多的使用类来关联每个标签元素
- 考虑继承，了解哪些属性是可以继承，而不需要重复进行属性设置选用高效的选择符，可以减少页面的渲染时间，从而有效的提升用户体验。也许想到当渲染速度最高效时，可能会给每个独立标签配置一个ID，然后给这些ID配置样式，的确很快。但是这样做语意极差，后期特别难以维护。
