页面白屏了两秒才出内容，你把接口时间、打包体积、图片大小挨个查了一遍，发现都没问题。最后打开 Performance 面板一看，主线程在 Recalculate Style 和 Layout 上卡了很久。这种问题光看网络瀑布图是查不出来的，得知道资源下完之后浏览器还要干哪几件事。这篇把渲染这条流水线从解析 HTML 一直走到 GPU 合成，讲清每一步在做什么、哪一步会被阻塞、以及重绘和回流到底卡在哪个环节。看完你再打开 Performance 面板，那些色块就能对上号了。
在本篇文章中，我们将从浅入深，和大家一起学习以下知识：
- 浏览器渲染的五个阶段分别在做什么，哪两步最耗时
- 解析器碰到
script标签时发生的四件事，defer和async的差别 - CSS 明明不改结构，为什么还是会阻塞渲染
Load和DOMContentLoaded的触发时机差在哪- 图层是怎么生成的，合成层的收益和代价各是什么
- 重绘和回流的触发条件，以及它们和 Event Loop 的关系
- 减少回流的几种具体写法，以及
will-change、content-visibility该怎么用
# 一、浏览器如何渲染网页
浏览器渲染一共有五步：
- 处理
HTML并构建DOM树。 - 处理
CSS构建CSSOM树。 - 将
DOM与CSSOM合并成一个渲染树。 - 根据渲染树来布局，计算每个节点的位置。
- 调用
GPU绘制，合成图层，显示在屏幕上
第四步和第五步是最耗时的部分，这两步合起来，就是我们通常所说的渲染。
下面这个交互演示可以配合着看，它把请求发出之后浏览器内部的流转过程按帧拆开了，比干读文字直观：
具体过程如下图所示：
这条流水线有个容易被忽略的前提，它不是只跑一次。
网页生成的时候至少会渲染一次，在用户访问的过程中还会不断重新渲染。重新渲染需要重复之前的第四步（重新生成布局）加第五步（重新绘制），或者只有第五步（重新绘制）。所以我们后面讲的性能优化，绝大部分功夫都花在「怎么让第二次以后的渲染少走几步」上。
有两条阻塞规则要先记住。
在构建 CSSOM 树时会阻塞渲染，直至 CSSOM 树构建完成。并且构建 CSSOM 树是一个十分消耗性能的过程，所以应该尽量保证层级扁平，减少过度层叠，越是具体的 CSS 选择器，执行速度越慢。
当 HTML 解析到 script 标签时，会暂停构建 DOM，完成后才会从暂停的地方重新开始。也就是说，如果你想首屏渲染得越快，就越不应该在首屏就加载 JS 文件。并且 CSS 也会影响 JS 的执行，只有当解析完样式表才会执行 JS，所以也可以认为这种情况下，CSS 也会暂停构建 DOM。
最后那句话很多人第一次看会觉得别扭，CSS 怎么会挡住 JS。原因在于 JS 里随时可能出现 getComputedStyle 这种读样式的调用，浏览器没法预知，只能保守处理：样式表没解析完，就不让脚本跑。这条规则带来的实际后果是，一个放在 <head> 里的慢 CSS，会连带把后面的同步脚本一起拖住。
# 二、浏览器渲染五个阶段
# 2.1 第一步：解析HTML标签，构建DOM树
在这个阶段，引擎开始解析 html，解析出来的结果会成为一棵 dom 树。dom 的目的至少有 2 个：
- 作为下个阶段渲染树状图的输入
- 成为网页和脚本的交互界面（最常用的就是
getElementById等等）
当解析器到达 script 标签的时候，发生下面四件事情：
html解析器停止解析- 如果是外部脚本，就从外部网络获取脚本代码
- 将控制权交给
js引擎，执行js代码 - 恢复
html解析器的控制权
由此可以得到第一个结论：
- 由于
<script>标签是阻塞解析的，将脚本放在网页尾部会加速代码渲染。 defer和async属性也能有助于加载外部脚本。defer使得脚本会在dom完整构建之后执行；async标签使得脚本只有在完全available才执行，并且是以非阻塞的方式进行的
这两个属性的区别我一开始也记混过，后来换了个角度就清楚了：它们的下载都是并行的，差别只在执行时机。defer 的脚本按文档里的书写顺序排队，等 DOM 解析完再依次执行，所以它适合有依赖关系的业务脚本；async 是谁先下完谁先执行，顺序完全不保证，它适合埋点、统计这类跟页面其它代码没关系的独立脚本。把有依赖的模块写成 async，线上会出现那种「十次里坏一次」的诡异报错，排查起来很费劲。
现代项目里还多了一个 type="module"，它默认就是 defer 的行为，不用再手动加属性。这块的写法比 2018 年那会儿舒服了不少。
# 2.2 第二步：解析CSS标签，构建CSSOM树
我们已经看到 html 解析器碰到脚本后会做的事情，接下来看 html 解析器碰到样式表会发生的情况。
js 会阻塞解析，因为它会修改文档（document）。css 不会修改文档的结构，如果这样的话，似乎看起来 css 样式不会阻塞浏览器 html 解析。但是事实上 css 样式表是阻塞的，阻塞是指当 cssom 树建立好之后才会进行下一步的解析渲染。
那为什么一个不改结构的东西也会挡住渲染呢？
因为渲染树需要 DOM 和 CSSOM 两份输入，缺一个就拼不出来。浏览器要是在 CSSOM 没建好之前就先画一版，用户会先看到一坨没有样式的裸 HTML，样式到位之后再整个跳一下。这个现象有个名字叫 FOUC，比多等几十毫秒难受得多，所以浏览器选择了等。
通过以下手段可以减轻 cssom 带来的影响：
- 将
script脚本放在页面底部 - 尽可能快地加载
css样式表 - 将样式表按照
media type和media query区分，这样有助于我们将css资源标记成非阻塞渲染的资源。 - 非阻塞的资源还是会被浏览器下载，只是优先级较低
第三条现在还很好用，写成 <link rel="stylesheet" href="print.css" media="print"> 这样，打印样式就不会挡住首屏了。另外还有一个 2018 年时还没普及的做法，把首屏必需的那几十行样式内联进 <head>，其余的用 rel="preload" 异步加载完再切成 stylesheet，能把阻塞时间压到接近零。这条思路我在 关键路径渲染优化 那篇里展开写过。
# 2.3 第三步：把DOM和CSSOM组合成渲染树（render tree）
这一步有个细节值得单独提。渲染树里只放要显示的节点，display: none 的元素连同它的子树压根不会进渲染树，而 visibility: hidden 的元素会进，只是画的时候是透明的。这个差别就是后面「用 visibility 替代 display: none」那条优化建议的根据，不是玄学。
# 2.4 第四步：在渲染树的基础上进行布局，计算每个节点的几何结构
布局（layout）负责定位坐标和大小，是否换行，以及各种 position、overflow、z-index 属性的处理。
这一步的成本跟渲染树的节点数直接相关，是全文里最容易变成性能瓶颈的地方。一个长列表渲染两千个 DOM，每次布局都要把这两千个节点的几何信息重算一遍。
# 2.5 调用 GPU 绘制，合成图层，显示在屏幕上
将渲染树的各个节点绘制到屏幕上，这一步被称为绘制（painting）。
绘制之后还有一步合成，浏览器把不同图层的位图交给 GPU 拼在一起输出到屏幕。这一步是我们后面讲合成层优化的落脚点，因为纯粹的合成不需要主线程参与，代价极低。
# 三、渲染优化相关
# 3.1 Load 和 DOMContentLoaded 区别
Load事件触发代表页面中的DOM、CSS、JS、图片已经全部加载完毕。DOMContentLoaded事件触发代表初始的HTML被完全加载和解析，不需要等待CSS、JS、图片加载
实际用的时候记一条就够：需要操作 DOM 的初始化逻辑挂 DOMContentLoaded，需要拿到图片真实尺寸的逻辑才挂 Load。有些页面里一张挂了的第三方图片就能把 Load 拖到几十秒，初始化逻辑要是绑在上面，页面就一直是死的。这个我踩过，排查了一下午最后发现是个统计像素的域名解析超时。
补一句上面第二条的边界。DOMContentLoaded 说的是不等图片，但它其实是要等阻塞渲染的样式表的，因为前面讲过样式表会挡住后面的同步脚本执行。写成「不等待 CSS」不够准确，实际行为是不等异步样式和图片，但会等 <head> 里的阻塞样式表。
# 3.2 图层
一般来说，可以把普通文档流看成一个图层。特定的属性可以生成一个新的图层。不同的图层渲染互不影响，所以对于某些频繁需要渲染的建议单独生成一个新图层，提高性能。但也不能生成过多的图层，会引起反作用。
通过以下几个常用属性可以生成新图层：
3D变换：translate3d、translateZwill-changevideo、iframe标签- 通过动画实现的
opacity动画转换 position: fixed
「不能生成过多」这句话原文一笔带过，这里得说清代价在哪。每一个合成层都要单独存一份位图，显存是实打实占掉的，一个全屏的合成层在高分屏上就是好几 MB。层多了之后，合成阶段本身也会变慢，甚至出现「层爆炸」，某个元素被提升之后，它后面所有跟它有重叠关系的元素会被连锁提升。DevTools 的 Layers 面板能直接看到当前有多少层、每层多大，怀疑有问题的时候打开它比猜准得多。
will-change 这个属性尤其容易用错。我见过直接写 * { will-change: transform } 的，那等于告诉浏览器「所有元素都要变」，浏览器只好挨个提升，内存直接爆掉。正确的用法是精准且短命：只写在真正会动的那个元素上，只写会变的那个属性，而且最好在动画开始前用 JS 加上、动画结束后移除。如果一个元素常年挂着 will-change，浏览器为它准备的那份优化资源就一直闲置着。
position: fixed 那条也要补个前提。它不是无条件提升合成层的，现在的 Chrome 只在页面确实可滚动的时候才会给固定定位元素单独开层，不滚动的页面上并不会。这类实现细节各浏览器各版本有出入，我只在 Chrome 的 Layers 面板上翻过，别的内核没逐个验证。
# 3.3 重绘（Repaint）和回流（Reflow）
重绘和回流是渲染步骤中的一小节，但是这两个步骤对于性能影响很大。
- 重绘是当节点需要更改外观而不会影响布局的，比如改变
color就称为重绘 - 回流是布局或者几何属性需要改变就称为回流
回流必定会发生重绘，重绘不一定会引发回流。回流所需的成本比重绘高得多，改变深层次的节点很可能导致父节点的一系列回流。
对着前面那条流水线看就清楚了。回流是从第四步重来，布局、绘制、合成一个都跑不掉；重绘是从第五步重来，跳过了布局。还有第三档更省的，只改 transform 和 opacity 这类合成属性，布局和绘制都跳过，直接进合成，这也是为什么动画一律推荐用 transform 而不是 top。
以下几个动作可能会导致性能问题：
- 改变
window大小 - 改变字体
- 添加或删除样式
- 文字改变
- 定位或者浮动
- 盒模型
很多人可能没注意到，重绘和回流其实和 Event Loop 有关：
