浏览器中的页面是如何渲染生成的？

Question

DOM树：JavaScript 是如何影响 DOM 树构建的？

什么是 DOM

从网络传给渲染引擎的 HTML 文件字节流是无法直接被渲染引擎理解的，所以要将其转化为渲染引擎能够理解的内部结构 DOM。DOM 提供了对 HTML 文档结构化的表述。在渲染引擎中，DOM 有三个层面的作用。

• 从页面的视角来看，DOM 是生成页面的基础数据结构。
• 从 JavaScript 脚本视角来看，DOM 提供给 JavaScript 脚本操作的接口，通过这套接口，JavaScript 可以对 DOM 结构进行访问，从而改变文档的结构、样式和内容。
• 从安全视角来看，DOM 是一道安全防护线，一些不安全的内容在 DOM 解析阶段就被拒之门外了。

简言之，DOM 是表述 HTML 的内部数据结构，它会将 Web 页面和 JavaScript 脚本连接起来，并过滤一些不安全的内容。

DOM 树如何生成的

渲染引擎内部的**HTML解析器（HTMLParser）**模块将 HTML 字节流转换为DOM结构。

HTML解析器并不是等整个文档加载完后再解析的，而是网络进程加载了多少数据，HTML解析器便解析多少数据。

具体流程

• 网络进程接收到响应头后，会根据响应头中的 content-type 字段来判断文件的类型，比如 content-type 的值是“text/html”，那么浏览器就会判断这是一个 HTML 类型的文件，然后为该请求选择或者创建一个渲染进程。渲染进程准备好之后，网络进程和渲染进程之间会建立一个共享数据的管道，网络进程接收到数据后就往这个管道里面放，而渲染进程则从管道的另外一端不断地读取数据，并同时将读取的数据传给 HTML 解析器。
• 字节流 ==> DOM
  • 第一阶段，通过分词器将字节流转换为 Token。Token分为 Tag Token 和 文本Token，Tag Token又分为StartTag 和 EndTag
  • 第二阶段和第三阶段同步进行，需要将 Token 解析为 DOM 节点，并将DOM节点添加到DOM树中。
  • HTML 解析器维护了一个 Token 栈结构，该栈主要用来计算节点之间的父子关系，在第一个阶段中生成的 Token 会被按照顺序压到这个栈中。具体的处理规则如下所示：①如果压入到栈中的是 StartTag Token，HTML 解析器会为该 Token 创建一个 DOM 节点，然后将该节点加入到 DOM 树中，它的父节点就是栈中相邻的那个元素生成的节点。②如果分词器解析出来是文本 Token，那么会生成一个文本节点，然后将该节点加入到 DOM 树中，文本 Token 是不需要压入到栈中，它的父节点就是当前栈顶 Token 所对应的 DOM 节点。③如果分词器解析出来的是 EndTag 标签，比如是 EndTag div，HTML 解析器会查看 Token 栈顶的元素是否是 StarTag div，如果是，就将 StartTag div 从栈中弹出，表示该 div 元素解析完成。通过分词器产生的新 Token 就这样不停地压栈和出栈，整个解析过程就这样一直持续下去，直到分词器将所有字节流分词完成。
  • HTML 解析器开始工作时，会默认创建了一个根为 document 的空 DOM 结构

JavaScript 是如何影响 DOM 生成的

• 在HTML中内嵌 script 标签，当解析到 script 标签时，渲染引擎判断这是一段JavaScript脚本，此时 HTML解析器就会暂停DOM的解析，因为接下来的JavaScript可能要修改已经生成的DOM结构。
• 在HTML中引入外部JavaScript脚本，需要先下载这个脚本，JavaScript 文件的下载过程会阻塞 DOM 解析，而通常下载又是非常耗时的，会受到网络环境、JavaScript 文件大小等因素的影响。
• 不过Chrome 解析器做了很多优化，其中一个主要优化是预解析操作。当渲染引擎收到字节流之后，会开启一个预解析线程，用来分析 HTML 文件中包含的 JavaScript、CSS 等相关文件，解析到相关文件之后，预解析线程会提前下载这些文件。
• JS 线程会阻塞 DOM，但也有一些策略来规避：比如使用 CDN 来加速JavaScript文件的加载，压缩 JavaScript 文件体积。如果JavaScript文件中没有操作DOM相关的代码，可以将该JavaScript脚本设置为异步加载，通过 async 或 defer来标记代码。
• 使用 async 标志的脚本文件一旦加载完成，会立即执行；而使用了 defer 标记的脚本文件，需要在 DOMContentLoaded 事件之前执行。

额外说明

渲染引擎还有一个安全检查模块叫 XSSAuditor，是用来检测词法安全的。在分词器解析出来 Token 之后，它会检测这些模块是否安全，比如是否引用了外部脚本，是否符合 CSP 规范，是否存在跨站点请求等。如果出现不符合规范的内容，XSSAuditor 会对该脚本或者下载任务进行拦截。

渲染流水线：CSS 如何影响首次加载时的白屏时间

• 前面说过，当渲染引擎接受到 HTML 文件字节流时，会先开启一个预解析线程，若遇到 js或css文件，就会提前下载这些数据。在构建完 DOM 之后，css文件还未下载完成之前，渲染流水线无事可做，因为下一步是合成布局树，而合成布局树需要CSSOM和DOM，所以这里要等待CSS加载结束并解析成CSSOM。
• 【渲染流水线为什么需要CSSOM】和HTML一样，渲染引擎也无法直接理解 CSS 文件内容，所以需要将其解析成渲染引擎能直接理解的结构即 CSSOM，作用有两个，**一是提供给 JavaScript 操作样式表的能力，二是为布局树的合成提供基础的样式信息。**这个CSSOM体现在DOM中就是 document.styleSheets。
• 在解析DOM过程中，如果遇到JavaScript脚本，则需要先暂停DOM解析去执行JavaScript，因为JavaScript有可能会修改当前状态下的DOM。不过在执行js脚本前，如果页面包含了外部css文件的引用，或通过style标签内置了css内容，那么渲染引擎还需要将这些内容转换为 CSSOM，因为js有修改CSSOM的能力，所以在执行js之前，还需要依赖CSSOM。也就是说CSS在部分情况下也会阻塞DOM的生成。

影响页面展示的因素以及优化策略

渲染流水线影响到了首次页面展示的速度，而首次页面展示的速度又直接影响到了用户体验。

发起 URL 请求，到首次显示页面内容，在视觉上经历了三个阶段：

• 第一个阶段：等请求发出去之后，到提交数据阶段，这时页面展示出来的还是之前页面的内容。这里在《宏观下的浏览器》第4部分解释了原因。
• 第二个阶段：提交数据之后渲染进程会创建一个空白页面，我们通常把这段时间称为解析白屏，并等待 CSS 文件和 JavaScript 文件的加载完成，生成 CSSOM 和 DOM，然后合成布局树，最后还要经过一系列的步骤准备首次渲染。
• 第三个阶段：等首次渲染完成之后，就开始进入完整页面的生成阶段了，然后页面会一点点被绘制出来。

第二个阶段的主要问题是白屏时间，如果白屏时间过久，就会影响到用户体验。为了缩短白屏时间，我们来挨个分析这个阶段的主要任务，包括了解析 HTML、下载 CSS、下载 JavaScript、生成 CSSOM、执行 JavaScript、生成布局树、绘制页面一系列操作。

通常情况下的瓶颈主要体现在下载 CSS 文件、下载 JavaScript 文件和执行 JavaScript。

所以要想缩短白屏时长，可以有以下策略：

• 通过内联 JavaScript、内联 CSS 来移除这两种类型的文件下载，这样获取到 HTML 文件之后就可以直接开始渲染流程了。
• 但并不是所有的场合都适合内联，那么还可以尽量减少文件大小，比如通过 webpack 等工具移除一些不必要的注释，并压缩 JavaScript 文件。
• 还可以将一些不需要在解析 HTML 阶段使用的 JavaScript 标记上 sync 或者 defer。
• 对于大的 CSS 文件，可以通过媒体查询属性，将其拆分为多个不同用途的 CSS 文件，这样只有在特定的场景下才会加载特定的 CSS 文件。

通过以上策略就能缩短白屏展示的时长了，不过在实际项目中，总是存在各种各样的情况，这些策略并不能随心所欲地去引用，所以还需要结合实际情况来调整最佳方案。

分层和合成机制：为什么CSS动画比JavaScript高效

显示器如何显示图像的

• 每个显示器都有固定的刷新频率，通常是 60HZ，也就是每秒更新 60 张图片，更新的图片都来自于显卡中一个叫前缓冲区的地方，显示器所做的任务很简单，就是每秒固定读取 60 次前缓冲区中的图像，并将读取的图像显示到显示器上。
• 显卡的职责就是合成新的图像，并将图像保存到后缓冲区中，一旦显卡把合成的图像写到后缓冲区，系统就会让后缓冲区和前缓冲区互换，这样就能保证显示器能读取到最新显卡合成的图像。通常情况下，显卡的更新频率和显示器的刷新频率是一致的。但有时候，在一些复杂的场景中，显卡处理一张图片的速度会变慢，这样就会造成视觉上的卡顿。

帧 VS 帧率

• 当你通过滚动条滚动页面，或者通过手势缩放页面时，屏幕上就会产生动画的效果。之所以你能感觉到有动画的效果，是因为在滚动或者缩放操作时，渲染引擎会通过渲染流水线生成新的图片，并发送到显卡的后缓冲区。
• 大多数设备屏幕的更新频率是 60 次 / 秒，这也就意味着正常情况下要实现流畅的动画效果，渲染引擎需要每秒更新 60 张图片到显卡的后缓冲区。
• 我们把渲染流水线生成的每一副图片称为一帧，把渲染流水线每秒更新了多少帧称为帧率，比如滚动过程中 1 秒更新了 60 帧，那么帧率就是 60Hz（或者 60FPS）。
• 为了解决动画卡顿问题，就要解决每帧生成时间过久的问题，为此 Chrome 对浏览器渲染方式做了大量的工作，其中最卓有成效的策略就是引入了分层和合成机制。分层和合成机制代表了当今最先进的渲染技术。

如何生成一帧图像

任意一帧的生成方式，有重排、重绘和合成三种方式。

这三种方式的渲染路径是不同的，通常渲染路径越长，生成图像花费的时间就越多。比如重排，它需要重新根据 CSSOM 和 DOM 来计算布局树，这样生成一幅图片时，会让整个渲染流水线的每个阶段都执行一遍，如果布局复杂的话，就很难保证渲染的效率了。而重绘因为没有了重新布局的阶段，操作效率稍微高点，但是依然需要重新计算绘制信息，并触发绘制操作之后的一系列操作。相较于重排和重绘，合成操作的路径就显得非常短了，并不需要触发布局和绘制两个阶段，如果采用了 GPU，那么合成的效率会非常高。

Chrome 如何实现合成操作

三个词概括：分层、分块、合成

分层和合成

为什么引入分层和合成

通常页面的组成是非常复杂的，有的页面里要实现一些复杂的动画效果，比如点击菜单时弹出菜单的动画特效，滚动鼠标滚轮时页面滚动的动画效果，当然还有一些炫酷的 3D 动画特效。如果没有采用分层机制，从布局树直接生成目标图片的话，那么每次页面有很小的变化时，都会触发重排或者重绘机制，这种“牵一发而动全身”的绘制策略会严重影响页面的渲染效率。

在这个过程中，将素材分解为多个图层的操作就称为分层，最后将这些图层合并到一起的操作就称为合成。所以，分层和合成通常是一起使用的。

Chrome怎么实现分层与合成

• 在渲染流水线中，分层体现在生成布局树后，渲染引擎会根据布局树的特点将其转换为层树（Layer Tree），层树是渲染流水线后续流程的基础结构。
• 层树中的每个节点都对应着一个图层，下一步的绘制阶段就依赖于层树中的节点。
• 绘制阶段其实并不是真正地绘出图片，而是将绘制指令组合成一个列表
• 有了绘制列表之后，就需要进入光栅化阶段了，光栅化就是按照绘制列表中的指令生成图片。每一个图层都对应一张图片，合成线程有了这些图片之后，会将这些图片合成为“一张”图片，并最终将生成的图片发送到后缓冲区。
• 这就是一个大致的分层、合成流程。
• 需要重点关注的是，合成操作是在合成线程上完成的，这也就意味着在执行合成操作时，是不会影响到主线程执行的。这就是为什么经常主线程卡住了，但是 CSS 动画依然能执行的原因。

分块

如果说分层是从宏观上提升了渲染效率，那么分块则是从微观层面提升了渲染效率。

通常情况下，页面的内容都要比屏幕大得多，显示一个页面时，如果等待所有的图层都生成完毕，再进行合成的话，会产生一些不必要的开销，也会让合成图片的时间变得更久。

因此，合成线程会将每个图层分割为大小固定的图块，然后优先绘制靠近视口的图块，这样就可以大大加速页面的显示速度。不过有时候， 即使只绘制那些优先级最高的图块，也要耗费不少的时间，因为涉及到一个很关键的因素——纹理上传，这是因为从计算机内存上传到 GPU 内存的操作会比较慢。

为了解决这个问题，Chrome 又采取了一个策略：在首次合成图块的时候使用一个低分辨率的图片。比如可以是正常分辨率的一半，分辨率减少一半，纹理就减少了四分之三。在首次显示页面内容的时候，将这个低分辨率的图片显示出来，然后合成器继续绘制正常比例的网页内容，当正常比例的网页内容绘制完成后，再替换掉当前显示的低分辨率内容。这种方式尽管会让用户在开始时看到的是低分辨率的内容，但是也比用户在开始时什么都看不到要好。

如何利用分层技术优化代码

在写 Web 应用的时候，你可能经常需要对某个元素做几何形状变换、透明度变换或者一些缩放操作，如果使用 JavaScript 来写这些效果，会牵涉到整个渲染流水线，所以 JavaScript 的绘制效率会非常低下。

这时你可以使用 will-change 来告诉渲染引擎你会对该元素做一些特效变换，CSS 代码如下：

.box {will-change: transform, opacity;}

这段代码就是提前告诉渲染引擎 box 元素将要做几何变换和透明度变换操作，这时候渲染引擎会将该元素单独实现一帧，等这些变换发生时，渲染引擎会通过合成线程直接去处理变换，这些变换并没有涉及到主线程，这样就大大提升了渲染的效率。这也是 CSS 动画比 JavaScript 动画高效的原因。

所以，如果涉及到一些可以使用合成线程来处理 CSS 特效或者动画的情况，就尽量使用 will-change 来提前告诉渲染引擎，让它为该元素准备独立的层。但是凡事都有两面性，每当渲染引擎为一个元素准备一个独立层的时候，它占用的内存也会大大增加，因为从层树开始，后续每个阶段都会多一个层结构，这些都需要额外的内存，所以你需要恰当地使用 will-change。

页面性能：如何系统地优化页面

所谓页面优化，其实就是要让页面更快地显示和响应。

通常一个页面有三个阶段**：加载阶段、交互阶段和关闭阶段**。

• 加载阶段，是指从发出请求到渲染出完整页面的过程，影响到这个阶段的主要因素有网络和 JavaScript 脚本。
• 交互阶段，主要是从页面加载完成到用户交互的整合过程，影响到这个阶段的主要因素是 JavaScript 脚本。
• 关闭阶段，主要是用户发出关闭指令后页面所做的一些清理操作。

加载阶段

图片、音频、视频等文件就不会阻塞页面的首次渲染；而 JavaScript、首次请求的 HTML 资源文件、CSS 文件是会阻塞首次渲染的，因为在构建 DOM 的过程中需要 HTML 和 JavaScript 文件，在构造渲染树的过程中需要用到 CSS 文件。

这些能阻塞网页首次渲染的资源称为关键资源，基于关键资源，可以细化出三个影响页面首次渲染的核心因素。

• 关键资源个数
• 关键资源大小
• 请求关键资源需要多少个 RTT（Round Trip Time）。RTT 就是这里的往返时延。它是网络中一个重要的性能指标，表示从发送端发送数据开始，到发送端收到来自接收端的确认，总共经历的时延。

总的优化原则就是减少关键资源个数，降低关键资源大小，降低关键资源的RTT次数

• 【减少关键资源个数】：将 JavaScript 和 CSS 改成内联的形式；如果 JavaScript 代码没有 DOM 或者 CSSOM 的操作，则可以改成 async 或者 defer 属性；对于 CSS，如果不是在构建页面之前加载的，则可以添加媒体取消阻止显现的标志。这样它们就变成了非关键资源。
• 【减少关键资源大小】：压缩 CSS 和 JavaScript 资源，移除 HTML、CSS、JavaScript 文件中一些注释内容
• 【减少关键资源RTT次数】：搭配前面两种方式；使用CDN 来减少每次 RTT 时长

交互阶段

谈交互阶段的优化，其实就是在谈渲染进程渲染帧的速度，因为在交互阶段，帧的渲染速度决定了交互的流畅度。

交互阶段通常是由 JavaScript 触发交互动画。

优化方式

• 减少 JS 脚本执行时间：将一次执行的函数分解为多个任务，使每次执行时间不要太久；采用 Web Workers。
• 避免强制同步布局：所谓强制同步布局是指 JavaScript 强制将计算样式和布局操作提前到当前的任务中。为了避免强制同步布局，我们可以调整策略，在修改 DOM 之前查询相关值。
• 避免布局抖动：所谓布局抖动，是指在一次 JavaScript 执行过程中，多次执行强制布局和抖动操作。
• 合理利用CSS合成动画：合成动画是直接在合成线程上执行的，这和在主线程上执行的布局、绘制等操作不同，如果主线程被 JavaScript 或者一些布局任务占用，CSS 动画依然能继续执行。
• 避免频繁的垃圾回收，尽量优化存储结构，尽可能避免小颗粒对象的产生。

虚拟DOM

DOM 缺陷

不断地去修改 DOM 树，每次操作 DOM 渲染引擎都需要进行重排、重绘或者合成等操作，因为 DOM 结构复杂，所生成的页面结构也会很复杂，对于这些复杂的页面，执行一次重排或者重绘操作都是非常耗时的，这就给我们带来了真正的性能问题。

所以我们需要有一种方式来减少 JavaScript 对 DOM 的操作，这时候虚拟 DOM 就上场了。

虚拟DOM

虚拟DOM做的事：将页面改变的内容应用到虚拟 DOM 上，而不是直接应用到 DOM 上。变化被应用到虚拟 DOM 上时，虚拟 DOM 并不急着去渲染页面，而仅仅是调整虚拟 DOM 的内部状态，这样操作虚拟 DOM 的代价就变得非常轻了。在虚拟 DOM 收集到足够的改变时，再把这些变化一次性应用到真实的 DOM 上。

虚拟DOM运行流程：

• 创建阶段：首先依据 JSX 和基础数据创建出来虚拟 DOM，它反映了真实的 DOM 树的结构。然后由虚拟 DOM 树创建出真实 DOM 树，真实的 DOM 树生成完后，再触发渲染流水线往屏幕输出页面。
• 更新阶段：如果数据发生了改变，那么就需要根据新的数据创建一个新的虚拟 DOM 树；然后 React 比较两个树，找出变化的地方，并把变化的地方一次性更新到真实的 DOM 树上；最后渲染引擎更新渲染流水线，并生成新的页面。

从双缓存和MVC模型两个视角谈虚拟DOM

1. 双缓存

在开发游戏或者处理其他图像的过程中，屏幕从前缓冲区读取数据然后显示。但是很多图形操作都很复杂且需要大量的运算，比如一幅完整的画面，可能需要计算多次才能完成，如果每次计算完一部分图像，就将其写入缓冲区，那么就会造成一个后果，那就是在显示一个稍微复杂点的图像的过程中，你看到的页面效果可能是一部分一部分地显示出来，因此在刷新页面的过程中，会让用户感受到界面的闪烁。

而使用双缓存，可以让你先将计算的中间结果存放在另一个缓冲区中，等全部的计算结束，该缓冲区已经存储了完整的图形之后，再将该缓冲区的图形数据一次性复制到显示缓冲区，这样就使得整个图像的输出非常稳定。

在这里，你可以把虚拟 DOM 看成是 DOM 的一个 buffer，和图形显示一样，它会在完成一次完整的操作之后，再把结果应用到 DOM 上，这样就能减少一些不必要的更新，同时还能保证 DOM 的稳定输出。

2. MVC模式

MVC 是一个非常重要且应用广泛的模式，因为它能将数据和视图进行分离，在涉及到一些复杂的项目时，能够大大减轻项目的耦合度，使得程序易于维护。

MVC 的整体结构比较简单，由模型、视图和控制器组成，其核心思想就是将数据和视图分离，也就是说视图和模型之间是不允许直接通信的，它们之间的通信都是通过控制器来完成的。通常情况下的通信路径是视图发生了改变，然后通知控制器，控制器再根据情况判断是否需要更新模型数据。当然还可以根据不同的通信路径和控制器不同的实现方式，基于 MVC 又能衍生出很多其他的模式，如 MVP、MVVM 等，不过万变不离其宗，它们的基础骨架都是基于 MVC 而来。

在分析基于 React 或者 Vue 这些前端框架时，我们需要先重点把握大的 MVC 骨架结构，然后再重点查看通信方式和控制器的具体实现方式，这样我们就能从架构的视角来理解这些前端框架了。比如在分析 React 项目时，我们可以把 React 的部分看成是一个 MVC 中的视图，在项目中结合 Redux 就可以构建一个 MVC 的模型结构，如下图所示：

在该图中，我们可以把虚拟 DOM 看成是 MVC 的视图部分，其控制器和模型都是由 Redux 提供的。其具体实现过程如下：

• 图中的控制器是用来监控 DOM 的变化，一旦 DOM 发生变化，控制器便会通知模型，让其更新数据；
• 模型数据更新好之后，控制器会通知视图，告诉它模型的数据发生了变化；
• 视图接收到更新消息之后，会根据模型所提供的数据来生成新的虚拟 DOM；
• 新的虚拟 DOM 生成好之后，就需要与之前的虚拟 DOM 进行比较，找出变化的节点；
• 比较出变化的节点之后，React 将变化的虚拟节点应用到 DOM 上，这样就会触发 DOM 节点的更新；
• DOM 节点的变化又会触发后续一系列渲染流水线的变化，从而实现页面的更新。

渐进式网页应用（PWA）：它究竟解决了Web应用的哪些问题？

浏览器的三大进化路线：第一个是应用程序 Web 化；第二个是 Web 应用移动化；第三个是 Web 操作系统化；

PWA，全称 Progressive Web App，即渐进式网络应用。

渐进式

• Web应用开发者角度：PWA 提供了一个渐进式的过渡方案，让 Web 应用能逐步具有本地应用的能力。采取渐进式可以降低站点改造的代价，使得站点逐步支持各项新技术，而不是一步到位。
• 技术角度：PWA 技术也是一个渐进式的演化过程，在技术层面会一点点演进，比如逐渐提供更好的设备特性支持，不断优化更加流畅的动画效果，不断让页面的加载速度变得更快，不断实现本地应用的特性。

对PWA的定义：它是一套理念，渐进式增强 Web 的优势，并通过技术手段渐进式缩短和本地应用或者小程序的距离

Web应用 VS 本地应用

• • Web应用缺少离线使用能力
  • Web应用缺少消息推送能力
  • Web 应用缺少一级入口

针对以上 Web 缺陷，PWA 提出了两种解决方案：通过引入 Service Worker 来试着解决离线存储和消息推送的问题，通过引入 manifest.json 来解决一级入口的问题。

Service Worker

Service Worker 解决的是离线存储和消息推送的问题。

主要思想是在页面和网络之间增加一个拦截器，用来缓存和拦截请求。

在没有安装 Service Worker 之前，WebApp 都是直接通过网络模块来请求资源的。安装了 Service Worker 模块之后，WebApp 请求资源时，会先通过 Service Worker，让它判断是返回 Service Worker 缓存的资源还是重新去网络请求资源。一切的控制权都交由 Service Worker 来处理。

Service Worker设计思路：

1. 架构

“让其运行在主线程之外”就是 Service Worker 来自 Web Worker 的一个核心思想。

2. 消息推送

3. 安全

必须要使用 HTTPS，Service Worker 还需要同时支持 Web 页面默认的安全策略、储入同源策略、内容安全策略（CSP）等