前端性能优化-输入URL后全过程&&页面渲染机制&&DOM生成过程(转)

发表于 2022-08-31 更新于 2022-10-09 分类于性能优化阅读次数： 186 Changyan： 0 本文字数： 7.6k 阅读时长 ≈ 7 分钟

前端性能优化，很大一部分工作就是首屏加载和渲染的优化，要进行这项工作，首先就需要了解浏览器在输入URL到呈现页面之间都做了哪些工作，哪些步骤有哪些需要注意的事项和优化手段。

输入URL后的全过程

一般会经历以下几个过程：

首先，在浏览器地址栏中输入URL；
浏览器先查看浏览器缓存-系统缓存-路由器缓存，如果缓存中有，会直接在屏幕中显示页面内容。若没有，则跳到第三步操作；
在发送HTTP请求前，需要域名解析(DNS解析)，解析获取相应的IP地址；
浏览器向服务器发起TCP连接，与浏览器建立TCP三次握手；
握手成功后，浏览器向服务器发送HTTP请求，请求数据包；
服务器处理收到的请求，将数据返回至浏览器；
浏览器收到HTTP响应；
读取页面内容，浏览器渲染，解析HTML源码，并请求HTML代码中的资源(如JS、CSS、图片等）；
断开TCP连接；
浏览器对页面进行渲染呈现给用户；
AJAX查询。

其中，步骤2的具体过程是：

浏览器缓存：浏览器会记录DNS一段时间，因此，只是第一个地方解析DNS请求；
操作系统缓存：如果在浏览器缓存中不包含这个记录，则会使系统调用操作系统，获取操作系统的记录(保存最近的DNS查询缓存)；
路由器缓存：如果上述两个步骤均不能成功获取DNS记录，继续搜索路由器缓存；
ISP缓存：若上述均失败，继续向ISP搜索。

页面渲染机制

HTML的加载

HTML是一个网页的基础，下载完成后解析。

其他静态资源加载

HTML顺序加载，其中JS会阻塞后续DOM和资源加载，如果代码里引用了外部的CSS文件，那么在执行JS之前，还需要等待外部的CSS文件下载完成，并解析生成CSSOM对象之后，才能执行JS脚本。
浏览器会使用prefetch对引用的资源提前下载。
如果script标签没有设置defer或async属性，HTML的解析会停下来，浏览器会立即加载并执行指定的脚本，等JS下载完执行结束后才继续解析HTML，以防止JS修改已经完成的解析结果。
遇到有设置async属性的script标签，加载和渲染后续文档元素的过程将和JS的加载与执行并行进行（下载异步，执行同步，加载完就执行）。
遇到有设置defer属性的script标签，加载后续文档元素的过程将和JS的加载并行进行（异步），但是JS的执行要在所有元素解析完成之后，DOMContentLoaded事件触发之前完成。

DOM树构建

在HTML解析的同时，解析器会把解析完成的结果转换成DOM对象，再进一步构建DOM树。

CSSOM树构建

CSS下载完之后对CSS进行解析，解析成CSS对象，然后把CSS对象组装起来，构建CSSOM树。

渲染树构建

当DOM树和CSSOM树都构建完之后，浏览器根据这两个树构建一棵渲染树。

布局计算

渲染树构建完成以后，浏览器计算所有元素大小和绝对位置。

渲染

布局计算完成后，浏览器在页面渲染元素。经过渲染引擎处理后，整个页面就显示出来。
构建DOM树->构建渲染树->布局渲染树：计算盒模型位置和大小->绘制渲染树。

DOM

什么是 DOM

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

从页面的视角来看，DOM 是生成页面的基础数据结构。

从 JS 脚本视角来看，DOM 提供给 JS 脚本操作的接口，通过这套接口，JS 可以对 DOM 结构进行访问，从而改变文档的结构、样式和内容。
从安全视角来看，DOM 是一道安全防护线，一些不安全的内容在 DOM 解析阶段就被拒之门外了。
概述：DOM 是表述 HTML 的内部数据结构，它会将 Web 页面和 JS 脚本连接起来，并过滤一些不安全的内容。

DOM 树如何生成

HTML 解析器

在渲染引擎内部，有一个叫HTML 解析器（HTMLParser）的模块。

HTML 解释器的工作就是将网络或者本地磁盘获取的 HTML 网页和资源从字节流解释成 DOM 树结构。

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

网络进程接收到响应头之后，会根据响应头中的 content-type 字段来判断文件的类型，比如 content-type 的值是text/html，那么浏览器就会判断这是一个 HTML 类型的文件，然后为该请求选择或者创建一个渲染进程。渲染进程准备好之后，网络进程和渲染进程之间会建立一个共享数据的管道，网络进程接收到数据后就往这个管道里面放，而渲染进程则从管道的另外一端不断地读取数据，并同时将读取的数据“喂”给 HTML 解析器。

字节流转换为`DOM`

字节流转换为 DOM 需要三个阶段：

第一个阶段，通过分词器将字节流转换为 Token。
后续的第二个和第三个阶段是同步进行的，需要将 Token 解析为 DOM 节点，并将 DOM 节点添加到 DOM 树中。

HTML 解析器维护了一个Token 栈结构，该 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>
   <body>
      <div>1</div>
      <div>test</div>
   </body>
</html>

这段代码以字节流的形式传给了 HTML 解析器，经过分词器处理，

解析出来的第一个 Token 是 StartTag HTML，解析出来的 Token 会被压入到栈中，并同时创建一个 HTML 的 DOM 节点，将其加入到 DOM 树中

这里需要补充说明下，HTML 解析器开始工作时，会默认创建了一个根为 document 的空 DOM 结构，同时会将一个 StartTag document 的 Token 压入栈底。然后经过分词器解析出来的第一个 StartTag HTML Token 会被压入到栈中，并创建一个 HTML 的 DOM 节点，添加到 document 上，如下图所示

解析到StartTag `HTML`时的状态

然后按照同样的流程解析出来 StartTag body 和 StartTag div，其 Token 栈和 DOM 的状态如下图所示：

解析到StartTag div时的状态

接下来解析出来的是第一个 div 的文本 Token，渲染引擎会为该 Token 创建一个文本节点，并将该 Token 添加到 DOM 中，它的父节点就是当前 Token 栈顶元素对应的节点，如下图所示：

解析出第一个文本`Token`时的状态

再接下来，分词器解析出来第一个 EndTag div，这时候 HTML 解析器会去判断当前栈顶的元素是否是 StartTag div，如果是则从栈顶弹出 StartTag div，如下图所示

元素弹出`Token`栈示意图

按照同样的规则，一路解析，最终结果如下图所示：

最终解析结果

JS 是如何影响DOM生成的

内嵌JS

例子：

<html>
<body>
    <div>1</div>
    <script>
      let div1 = document.getElementsByTagName('div')[0]
      div1.innerText = 'Hello Mulianju~'
    </script>
    <div>test</div>
</body>
</html>

我在两段 div 中间插入了一段 JS 脚本，这段脚本的解析过程就有点不一样了。script标签之前，所有的解析流程还是和之前介绍的一样，但是解析到script标签时，渲染引擎判断这是一段脚本，此时 HTML 解析器就会暂停 DOM 的解析，因为接下来的 JS 可能要修改当前已经生成的 DOM 结构。

通过前面 DOM 生成流程分析，我们已经知道当解析到script脚本标签时，其 DOM 树结构如下所示：

`DOM`树

这时候 HTML 解析器暂停工作，JS 引擎介入，并执行script标签中的这段脚本，因为这段 JS 脚本修改了 DOM 中第一个 div 中的内容，所以执行这段脚本之后，div 节点内容已经修改为 Hello Mulianju~ 了。脚本执行完成之后，HTML 解析器恢复解析过程，继续解析后续的内容，直至生成最终的 DOM。

引入JS文件

除了在页面中直接内嵌 JS 脚本之外，我们还通常需要在页面中引入 JS 文件，这个解析过程就稍微复杂了些，如下面代码：

1
2
3

//foo.js
let div1 = document.getElementsByTagName('div')[0]
div1.innerText = 'Hello Mulianju~'

<html>
<body>
    <div>1</div>
    <script type="text/javascript" src='foo.js'></script>
    <div>test</div>
</body>
</html>

执行到 script 标签时，暂停整个 DOM 的解析，执行 JS 代码，不过这里执行 JS 时，需要先下载这段 JS 代码。这里需要重点关注下载环境，因为JS 文件的下载过程会阻塞 DOM 解析，而通常下载又是非常耗时的，会受到网络环境、JS 文件大小等因素的影响。

Chrome 浏览器做了很多优化，其中一个主要的优化是预解析操作。当渲染引擎收到字节流之后，会开启一个预解析线程，用来分析 HTML 文件中包含的 JS、CSS 等相关文件，解析到相关文件之后，预解析线程会提前下载这些文件。

再回到 DOM 解析上，我们知道引入 JS 线程会阻塞 DOM，不过也有一些相关的策略来规避，比如使用 CDN 来加速 JS 文件的加载，压缩 JS 文件的体积。

另外，如果 JS 文件中没有操作 DOM 相关代码，就可以将该 JS 脚本设置为异步加载，通过 async 或 defer 来标记代码，使用方式如下所示：

1
2
3

<script async type="text/javascript" src='foo.js'></script>

<script defer type="text/javascript" src='foo.js'></script>

async 和 defer 虽然都是异步的，不过还有一些差异：

使用 async 标志的脚本文件一旦加载完成，会立即执行；
而使用了 defer 标记的脚本文件，需要在 DOMContentLoaded 事件之前执行。

或者将 script 元素放在 body 元素后面。

引入CSS文件

引入外部CSS样式表

外链式

1	<link type="text/css" rel="stylesheet" href="要引入的css文件的路径"/>

导入式

1
2
3

<style type="text/css">
   @import URL('要导入的css文件的路径');
</style>

link和import导入外部样式区别:

加载顺序
当一个页面被加载的时候（就是被浏览者浏览的时候），link引用的CSS会同时被加载，而@import引用的CSS 会等到页面全部被下载完再被加载。所以有时候浏览@import加载CSS的页面时开始会没有样式。
使用DOM控制样式差别
当使用JS控制DOM去改变样式的时候，只能使用link标签，因为@import不是DOM可以控制的.

一个例子:

<html>
   <head>
      <link type="text/css" rel="stylesheet" href="要引入的css文件的路径"/>
   </head>
   <body>
      <div>1</div>
      <script>
         let div1 = document.getElementsByTagName('div')[0]
         div1.innerText = 'Hello Mulianju~' // 需要 DOM
         div1.style.color = 'red'  // 需要 CSSOM
      </script>
      <div>test</div>
   </body>
</html>

JS 代码出现了 div1.style.color = 'red' 的语句，它是用来操纵 CSSOM 的，所以在执行 JS 之前，需要先解析 JS 语句之上所有的 CSS 样式。所以如果代码里引用了外部的 CSS 文件，那么在执行 JS 之前，还需要等待外部的 CSS 文件下载完成，并解析生成 CSSOM 对象之后，才能执行 JS 脚本。

JS 引擎在解析 JS 之前，是不知道 JS 是否操纵了 CSSOM 的，所以渲染引擎在遇到 JS 脚本时，不管该脚本是否操纵了 CSSOM，都会执行 CSS 文件下载，解析操作，再执行 JS 脚本。

JS 脚本是依赖样式表的，这又多了一个阻塞过程。

JS 会阻塞 DOM 生成，而样式文件又会阻塞 JS 的执行，所以在实际的工程中需要重点关注 JS 文件和样式表文件，使用不当会影响到页面性能的。

CSS 不会阻塞 DOM 的解析，但会阻塞 DOM 渲染。
JS 阻塞 DOM 解析，但浏览器会”偷看”DOM，预先下载相关资源。
浏览器遇到<script>且没有defer或async属性的标签时，会触发页面渲染，因而如果前面CSS资源尚未加载完毕时，浏览器会等待它加载完毕在执行脚本。

拓展-CSS优化

CSS对渲染过程的影响

CSS加载不会阻塞DOM树的解析
CSS加载会阻塞DOM树的渲染
CSS加载会阻塞后面JS语句的执行，而JS又会阻塞DOM树的解析

应该尽可能的提高CSS加载速度，比如可以使用以下几种方法:

使用CDN(因为CDN会根据你的网络状况，替你挑选最近的一个具有缓存内容的节点为你提供资源，因此可以减少加载时间)；
对CSS进行压缩(可以用很多打包工具，比如webpack、gulp等，也可以通过开启gzip压缩)；
合理的使用缓存(设置cache-control，expires，以及E-tag都是不错的，为了在文件更新后保证能拿到最新的文件，通常在打包的时候文件名字后面加一个版本号)；
减少HTTP请求数，将多个CSS文件合并，或者是干脆直接写成内联样式(内联样式的一个缺点就是不能缓存)。

CSS异步加载

通过 JS 动态插入 link 标签来异步载入 CSS 代码

var myCSS = document.createElement( "link" );
myCSS.rel = "stylesheet";
myCSS.href = "mystyles.css";
document.head.insertBefore( myCSS, document.head.childNodes[ document.head.childNodes.length - 1 ].nextSibling );

利用 link 上的 media 属性

1	media // 属性规定被链接文档将显示在什么设备上。

取值：

screen        // 计算机屏幕（默认）。
tty           // 电传打字机以及类似的使用等宽字符网格的媒介。
tv            // 电视机类型设备（低分辨率、有限的滚屏能力）。
projection    // 放映机。
handheld      // 手持设备（小屏幕、有限带宽）。
print         // 打印预览模式/打印页面。
braille       // 盲人点字法反馈设备。
aural         // 语音合成器。
all           // 适用于所有设备。

将它设置为和用户当前浏览器环境不匹配的值，比如：media="print"，甚至可以设置为一个完全无效的值 media="jscourse" 之类的。浏览器就会认为这个 CSS 文件优先级非常低，就会在不阻塞的情况下进行加载。最后为了让 CSS 规则生效，再将 media 值改对。

1	<link rel="stylesheet" href="cssfile.css" media="jscourse" onload="this.media='all'">

利用规范中新增加的 rel="preload"

通过 preload 属性值就是告诉浏览器这个资源文件随后会用到，请提前加载好。但是这只是加载，所以你看当它加载完毕后，还是需要将 rel 值改回去，这才能让 CSS 生效。

看上去和第二种方法差不多，但是呢，语义上更加好一些。另外就是你仔细点就会发现 as="style"这个属性，所以 preload 不仅仅可以用在 CSS 文件上，而是可以用在绝大多数的资源文件上。比如：JS 文件

1	<link rel="preload" href="scriptfile.js" as="script">

然后要用的时候，就创建一个 script 标签指向它：

1
2
3

var script = document.createElement("script");
script.src = "scriptfile.js";
document.body.appendChild(script);

这个时候浏览器就直接从缓存中拿这个文件了，不会再发请求了，因为此前已经加载好了。

转载自:

输入URL后全过程&&页面渲染机制&&DOM生成过程

本文永久链接: https://www.mulianju.com/performance-after-enter-url/