了解浏览器背后的运行机制

了解浏览器背后的运行机制就是了解浏览器的内核，现在市面上主流浏览器的内核名称分别如下：

chrome: blink内核
Opera: blink内核
Safari: webkit内核
FireFox: Gecko内核
IE: Trident内核

** 注：blink内核其实是基于webkit内核衍生出的一个新分支 **

获取到的HTML/CSS/JS资源经过浏览器内核的处理生成图像呈现在浏览器上，那么下面我们就详细说说浏览器内核在拿到资源之后是经过哪些处理来生成我们最终所看到的页面。

浏览器内核主要的功能模块

浏览器在处理资源的过程中是由多个模块协同工作的，主要关注下面几个模块：

HTML解析器：解析HTML文件，最终输出DOM树
CSS解析器：解析CSS文件，最终输出样式层叠表
图层布局计算模块：布局计算每个对象的大小和位置
视图绘制模块：将图层布局计算模块的结果形成像素并绘制到屏幕上
js模块：编译和执行js

浏览器渲染过程

解析HTML：执行所有的加载逻辑，在解析HTML的过程中发出渲染页面所需的所有请求。
计算样式：解析CSS文件，生成层叠样式表并于HTML结合生成渲染树(:before,:after这样的伪类是在该过程中生成的)
计算图层布局：精确计算所有DOM节点的大小以及在页面中的位置
绘制图层：在这一步浏览器会根据上一步结果将各个图层转化成像素，并对所有媒体文件进行解码
整合图层，生成页面：浏览器合成所有图层，将数据由cpu传递给GPU进行图像的绘制。

上面整个过程就是浏览器渲染页面的主要过程，在这个过程中主要是按顺序生成了下面几棵树：

DOM树：DOM树是浏览器解析HTML，将HTML标签抽象成的一颗树。
CSS树：CSS树是浏览器解析CSS，根据内容生成的一颗树，生成CSS树是和DOM树并行的。
Render树：是由DOM树和CSS树相整合，形成的一颗渲染树。
布局渲染树：浏览器根据Render树递归计算，确定DOM树上每个节点的位置和大小形成的一颗布局渲染树。
绘制渲染树：GPU根据布局渲染树结果进行图像绘制形成的一颗树。

基于渲染过程的CSS优化

在渲染过程这部分内容我们了解到在渲染过程中会根据CSS来形成CSS树，那么能在这个过程中做哪些优化呢？在说明CSS优化的方法之前先介绍一下CSS的解析规则。

我们在编写css的过程中，一般是从左到右去进行编写，比如我们想给类名为test_parent下的p标签去增加样式的时候，一般会这样写：

.test_parent p {
    font: 16px/20px Microsoft YaHei;
}

但是这样些会造成很大的性能问题，为什么呢？因为浏览器在解析CSS的过程中对于声明是从右往左进行匹配的。对于上面这种写法浏览器的做法会先找到DOM树中的所有标签为p的节点，然后再去这些p节点中去找哪些p节点的父节点的类为test_parent。由于p节点在我们的页面中可能会有很多很多，这样就导致寻找的过程会变长。

从上面的内容中我们就可以得出第一个CSS优化的思路，优化css声明的编写，有下面几种优化方式：

1. 不使用通配符*，因为通配符会让浏览器去遍历树节点中的每一个节点。
1. 尽量少使用标签选择器，用类选择去代替
1. 减少嵌套，因为嵌套的层级越深，浏览器遍历的层级就越深

介绍完css选择器的优化之后，我们再来回想一下上面的渲染过程，页面形成的过程中一颗重要的树Render树是由DOM树和CSS树合力生成的，那么如果没有CSS树Render树也就不会形成，更不必谈最终的页面了，所以第二个优化思路就是尽快让CSS树去形成，而CSS树的形成是浏览器解析CSS文件生成的，那么为了让CSS树形成，我们可以采取下面的方式去优化：

尽早的去加载CSS文件，也就是我们平常将所有的CSS文件放在head标签中去加载。

至此我们已经对CSS树的形成和Render树的形成做了优化，那么CSS还有可优化的点吗？答案是有的，在上述的渲染过程中在Render树后面还形成了一棵布局渲染树，那么在这棵树的形成过程中我们能做哪些优化呢？布局渲染树是浏览器根据Render树去计算每个DOM节点的大小以及所在页面中的位置，这些计算是依赖我们编写的css声明，比如：

.wrap {
    position: relative;
    height: 100px;
    background-color: #ff0000;
}

为了能够让浏览器快速的计算节点的位置和大小我们应该遵循CSS的声明顺序：

显隐属性：display || visibility(如果display:none，浏览器就不会去计算大小和位置了)
定位属性：position、top、left、bottom、right、z-index、float、clear(这些属性影响了节点的位置，越早去些，浏览器越早去计算)
盒模型：width、height、padding、margin、border(这些属性影响了节点的大小，越早写的化，浏览器可以越早去计算)
排版：line-height、text-align、font等
视觉：color、background-color等

至此关于CSS的优化已经结束了，下面来说说渲染过程中JS的一些优化

基于渲染过程的JS优化

看到这我们会发现上面很少提及JS，不是JS不重要哈，是在渲染过程中JS基本上不需要，那么为什么要提及JS呢，因为JS会阻塞HTML的解析，比如下面这段代码

<body>
    <div>js之前的html</div>
    <script>
       console.log('js执行了');
    </script>
    <div>js之后的html</div>
</body>

浏览器解析时，遇到上面的js时浏览器会把控制权交给js引擎，这时浏览器就会停止DOM树的解析。这样就延迟了DOM树的生成。那么对于这种情况我们有哪些优化呢？

1.将js放在最后去编写或者引用，这也是我们经常去做的。
2.合理的使用async和defer引入js

async和defer的作用：

async：异步加载，加载成功之后立马执行，也就是说script标签中增加async会使js在加载过程中不会阻止dom的解析
defer：异步加载，等HTML加载完成之后再执行。

来源：oschina

链接：https://my.oschina.net/sunwenhao/blog/3207138

标签

webkit

blink

opera

gecko

Trident

从浏览器内部运行机制看性能优化

了解浏览器背后的运行机制

浏览器内核主要的功能模块

浏览器渲染过程

基于渲染过程的CSS优化

基于渲染过程的JS优化