前端页面解析过程&性能分析
DOM树
根据 W3C 的 HTML DOM 标准，HTML 文档中的所有内容都是节点（共12个Node类），主要节点例举如下：
整个文档是一个文档节点，
每个 HTML 元素是元素节点
HTML 元素内的文本是文本节点
每个 HTML 属性是属性节点
注释是注释节点
当浏览器接收到服务器响应来的HTML文档后，会遍历文档节点，生成DOM树。html文档解析生成解析树即dom树，是由dom元素及属性节点组成，树的根是document对象
CCSOM规则树
DOM和CSSOM是相互独立的结构。CSSOM是一个建立在web页面上的 CSS 样式的映射，它和DOM类似，但是只针对CSS而不是HTML。CSSOM将样式表中的规则映射到页面对应的元素上。
HTML解析顺序：
不同浏览器细节会有不同，总体而言：
根据html代码
自上而下进行构建download、parseHTML/parseCSS/executeJS、layout、paint都在不同线程中。
parseHTML/parseCSS并行，共同完成后才会layout生成渲染树，进而paint渲染。执行JS会重新回到layout阶段。遇到script文件加载／执行会阻塞后面dom树的构建（javascript可能会改变dom树）
改进：针对上文说的脚本阻塞文档解析，主流浏览器如Chrome和FireFox等都有一些优化，比如在执行脚本时，开启另一个线程解析剩余的文档以找出并加载其他的待下载外部资源（不改变主线程的DOM树，仅优化加载外部资源）。
遇到css文件则会阻塞渲染树的构建，即dom树依然继续构建（因为并行，且不影响dom的结构）
JavaScript下载后可以通过DOM API修改DOM，通过CSSOM API可以修改样式作用域Render Tree。每次修改会造成Render Tree的重新布局和重绘。
关键渲染路径
关键渲染路径是指浏览器从最初接收请求来的HTML、CSS、javascript等资源，然后解析、构建树、渲染布局、绘制，最后呈现给客户能看到的界面这整个过程。
所以浏览器的渲染过程主要包括以下几步：
解析HTML生成DOM树。
解析CSS生成CSSOM规则树。
将DOM树与CSSOM规则树合并在一起生成渲染树。
遍历渲染树开始布局，计算每个节点的位置大小信息。
将渲染树每个节点绘制到屏幕。
渲染阻塞
当浏览器遇到一个 script 标记时，DOM 构建将暂停，直至脚本完成执行，然后继续构建DOM。每次去执行JavaScript脚本都会严重地阻塞DOM树的构建，如果JavaScript脚本还操作了CSSOM，而正好这个CSSOM还没有下载和构建，浏览器甚至会延迟脚本执行和构建DOM，直至完成其CSSOM的下载和构建。
所以，script 标签的位置很重要。实际使用时，可以遵循下面两个原则：
CSS 优先：引入顺序上，CSS 资源先于 JavaScript 资源。
JS置后：我们通常把JS代码放到页面底部，且JavaScript 应尽量少影响 DOM 的构建。
当解析html的时候，会把新来的元素插入dom树里面，同时去查找css，然后把对应的样式规则应用到元素上，查找样式表是按照从右到左的顺序去匹配的。
例如： div p {font-size: 16px}，会先寻找所有p标签并判断它的父标签是否为div之后才会决定要不要采用这个样式进行渲染）。
所以，我们平时写CSS时，尽量用id和class，千万不要过渡层叠。
构建渲染树
通过DOM树和CSS规则树我们便可以构建渲染树。浏览器会先从DOM树的根节点开始遍历每个可见节点。对每个可见节点，找到其适配的CSS样式规则并应用。
渲染树构建完成后，每个节点都是可见节点并且都含有其内容和对应规则的样式。这也是渲染树与DOM树的最大区别所在。渲染树是用于显示，那些不可见的元素当然就不会在这棵树中出现了，譬如。除此之外，display等于none的也不会被显示在这棵树里头，但是visibility等于hidden的元素是会显示在这棵树里头的。
渲染树布局
布局阶段会从渲染树的根节点开始遍历，然后确定每个节点对象在页面上的确切大小与位置，布局阶段的输出是一个盒子模型，它会精确地捕获每个元素在屏幕内的确切位置与大小。
渲染树绘制
在绘制阶段，遍历渲染树，调用渲染器的paint()方法在屏幕上显示其内容。渲染树的绘制工作是由浏览器的UI后端组件完成的。
reflow与repaint：
根据渲染树布局，计算CSS样式，即每个节点在页面中的大小和位置等几何信息。HTML默认是流式布局的，CSS和js会打破这种布局，改变DOM的外观样式以及大小和位置。这时就要提到两个重要概念：replaint和reflow。
replaint：屏幕的一部分重画，不影响整体布局，比如某个CSS的背景色变了，但元素的几何尺寸和位置不变。
reflow： 意味着元件的几何尺寸变了，我们需要重新验证并计算渲染树。是渲染树的一部分或全部发生了变化。这就是Reflow，或是Layout。
所以我们应该尽量减少reflow和replaint，我想这也是为什么现在很少有用table布局的原因之一。
display:none 会触发 reflow，visibility: hidden属性并不算是不可见属性，它的语义是隐藏元素，但元素仍然占据着布局空间，它会被渲染成一个空框，所以visibility:hidden 只会触发 repaint，因为没有发生位置变化。
有些情况下，比如修改了元素的样式，浏览器并不会立刻 reflow 或 repaint 一次，而是会把这样的操作积攒一批，然后做一次 reflow，这又叫异步 reflow 或增量异步 reflow。
有些情况下，比如 resize 窗口，改变了页面默认的字体等。对于这些操作，浏览器会马上进行 reflow。
重排和重绘
网页生成的时候，至少会渲染一次。用户访问的过程中，还会不断重新渲染。
以下三种情况，会导致网页重新渲染。
修改DOM
修改样式表
用户事件（比如鼠标悬停、页面滚动、输入框键入文字、改变窗口大小等等）
重新渲染，就需要重新生成布局和重新绘制。前者叫做"重排"（reflow），后者叫做"重绘"（repaint）。
需要注意的是， "重绘"不一定需要"重排" ，比如改变某个网页元素的颜色，就只会触发"重绘"，不会触发"重排"，因为布局没有改变。但是， "重排"必然导致"重绘" ，比如改变一个网页元素的位置，就会同时触发"重排"和"重绘"，因为布局改变了。
对于性能的影响
重排和重绘会不断触发，这是不可避免的。但是，它们非常耗费资源，是导致网页性能低下的根本原因。
提高网页性能，就是要降低"重排"和"重绘"的频率和成本，尽量少触发重新渲染。
前面提到，DOM变动和样式变动，都会触发重新渲染。但是，浏览器已经很智能了，会尽量把所有的变动集中在一起，排成一个队列，然后一次性执行，尽量避免多次重新渲染。
div.style.color = 'blue'; div.style.marginTop = '30px';复制代码
上面代码中，div元素有两个样式变动，但是浏览器只会触发一次重排和重绘。
如果写得不好，就会触发两次重排和重绘。
div.style.color = 'blue'; var margin = parseInt(div.style.marginTop); div.style.marginTop = (margin + 10) + 'px';复制代码
上面代码对div元素设置背景色以后，第二行要求浏览器给出该元素的位置，所以浏览器不得不立即重排。
一般来说，样式的写操作之后，如果有下面这些属性的读操作，都会引发浏览器立即重新渲染。
offsetTop/offsetLeft/offsetWidth/offsetHeight
scrollTop/scrollLeft/scrollWidth/scrollHeight
clientTop/clientLeft/clientWidth/clientHeight
getComputedStyle()
所以，从性能角度考虑，尽量不要把读操作和写操作，放在一个语句里面。
// bad div.style.left = div.offsetLeft + 10 + "px"; div.style.top = div.offsetTop + 10 + "px"; // good var left = div.offsetLeft; var top = div.offsetTop; div.style.left = left + 10 + "px"; div.style.top = top + 10 + "px";复制代码
一般的规则是：
样式表越简单，重排和重绘就越快。
重排和重绘的DOM元素层级越高，成本就越高。
table元素的重排和重绘成本，要高于div元素
提高性能的九个技巧
有一些技巧，可以降低浏览器重新渲染的频率和成本。
第一条是上一节说到的，DOM 的多个读操作（或多个写操作），应该放在一起。不要两个读操作之间，加入一个写操作。
第二条，如果某个样式是通过重排得到的，那么最好缓存结果。避免下一次用到的时候，浏览器又要重排。
第三条，不要一条条地改变样式，而要通过改变class，或者csstext属性，一次性地改变样式。
// bad var left = 10; var top = 10; el.style.left = left + "px"; el.style.top = top + "px"; // good el.className += " theclassname"; // good el.style.cssText += "; left: " + left + "px; top: " + top + "px;";复制代码
第四条，尽量使用离线DOM，而不是真实的网面DOM，来改变元素样式。比如，操作Document Fragment对象，完成后再把这个对象加入DOM。再比如，使用 cloneNode() 方法，在克隆的节点上进行操作，然后再用克隆的节点替换原始节点。
第五条，先将元素设为display: none（需要1次重排和重绘），然后对这个节点进行100次操作，最后再恢复显示（需要1次重排和重绘）。这样一来，你就用两次重新渲染，取代了可能高达100次的重新渲染。
第六条，position属性为absolute或fixed的元素，重排的开销会比较小，因为不用考虑它对其他元素的影响。
第七条，只在必要的时候，才将元素的display属性为可见，因为不可见的元素不影响重排和重绘。另外，visibility : hidden的元素只对重绘有影响，不影响重排。
第八条，使用虚拟DOM的脚本库，比如React等。
第九条，使用 window.requestAnimationFrame()、window.requestIdleCallback() 这两个方法调节重新渲染（详见后文）。
思考1：JavaScript为什么要放在HTML文档的底部？
通常来说，浏览器对于Javascript的运行有两大特性：
载入后马上执行 执行时会阻塞页面后续的内容（包括页面的渲染、其它资源的下载） 原因：当引用了JS的时候，浏览器发送1个js request就会一直等待该request的返回。因为浏览器需要1个稳定的DOM树结构，而JS中很有可能有代码直接改变了DOM树结构，比如使用 document.write 或 appendChild ,甚至是直接使用的location.href进行跳转，浏览器为了防止出现JS修改DOM树，需要重新构建DOM树的情况，所以 就会阻塞其他的下载和呈现。
于是，如果有多个js文件被引入，那么对于浏览器来说，这些js文件被被串行地载入，并依次执行。因为javascript可能会来操作HTML文档的DOM树，所以，浏览器一般都不会像并行下载css文件那样并行下载js文件，因为这是js文件的特殊性造成的。所以，如果你的javascript想操作后面的DOM元素，基本上来说，浏览器都会报错说对象找不到。因为Javascript执行时，后面的HTML被阻塞住了，DOM树时还没有后面的DOM结点。所以程序也就报错了。基本上来说，head里的script 标签会阻塞后续资源的载入以及整个页面的生成。如果把JavaScript放在页面顶部，下载和解析JavaScript的时间里面，dom迟迟得不到解析和渲染，浏览器一直处于白屏，所以把JavaScript文件放在页面底部更有利于页面快速呈现。所以，你知道为什么有很多网站把javascript放在网页的最后面了，要么就是动用了window.onload或docmuemt ready之类的事件。
defer和async 首先，async和defer对于内联JavaScript都是无效的
defer ：设置了defer的script外链文件，在下载js文件期间不会阻塞HTML的解析，而且等js下载完毕时若HTML还没解析完毕，js会等到HTML文档解析完毕后再执行。如果有多个js下载文件，那么执行时也是按照顺序执行。也就是说，有 defer，加载后续文档元素的过程将和 script.js 的加载并行进行（异步），但是 script.js 的执行要在所有元素解析完成之后，DOMContentLoaded事件触发之前完成。 async：设置了async的script外链文件，在下载js文件期间不会阻塞HTML的解析，但是js下载完毕之后就会立即执行，无论现在HTML是否正在解析。也就是说，有 async，加载和渲染后续文档元素的过程将和 script.js 的加载与执行并行进行（异步）。 总而言之， defer是“渲染完再执行”，async是“下载完就执行”。
思考二：Css为什么要放在HTML文档的标签内
如果把css文件引用放在HTML文档的底部，浏览器为了防止无样式内容闪烁，会在css文件下载并解析完毕之前什么都不显示，这也就会造成白屏现象。（但是在firefox浏览器中测试，会出现样式闪烁，这也算是不同浏览器的权衡吧，要么等css全解析完一起显示，要么先显示然后css解析完再重新画上新样式） 当css文件放在head中时，虽然css解析也会阻塞后续dom的渲染，但是在解析css的同时也在解析dom，所以等到css解析完毕就会逐步的渲染页面了。
简单过程：
Web页面运行在各种各样的浏览器当中，浏览器载入、渲染页面的速度直接影响着用户体验
简单地说，页面渲染就是浏览器将html代码根据CSS定义的规则显示在浏览器窗口中的这个过程。先来大致了解一下浏览器都是怎么干活的：
1. 用户输入网址（假设是个html页面，并且是第一次访问），浏览器向服务器发出请求，服务器返回html文件；
2. 浏览器开始载入html代码，发现标签内有一个标签引用外部CSS文件；
3. 浏览器又发出CSS文件的请求，服务器返回这个CSS文件；
4. 浏览器继续载入html中部分的代码，并且CSS文件已经拿到手了，可以开始渲染页面了
5. 浏览器在代码中发现一个标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码；
6. 服务器返回图片文件，由于图片占用了一定面积，影响了后面段落的排布，因此浏览器需要回过头来重新渲染这部分代码；
7. 浏览器发现了一个包含一行Javascript代码的 script 标签，赶快运行它
8. Javascript脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个（style.display=”none”）。 杯具啊，突然就少了这么一个元素，浏览器不得不重新渲染这部分代码；
9. 终于等到了的到来，浏览器泪流满面……
10. 等等，还没完，用户点了一下界面中的“换肤”按钮，Javascript让浏览器换了一下标签的CSS路径；
11. 浏览器召集了在座的各位 们，“大伙儿收拾收拾行李，咱得重新来过……”，浏览器向服务器请 求了新的CSS文件，重新渲染页面。
javascript 代码运行分两个阶段：
1.预解析阶段
把所有的函数定义提前，所有的变量声明提前，变量的赋值不提前（预处理会跳过执行语句，只处理声明语句，同样也是按从上到下按顺序进行的。包括变量和函数在内的所有声明都会在任何代码被执行前首先被处理。即使声明是在调用的下方进行的，但浏览器仍然先声明再调用（执行），这个现象叫做“提升”。所以，即便一个函数的声明在下方，在前面仍然可以正常执行这个函数。赋值或其他逻辑运算是在执行阶段进行的，在预处理阶段会被忽略。
2.执行阶段—从上到下执行（按照js运行机制）
总结
不论是内联还是外链js都会阻塞后续dom的解析和渲染
对于一个HTML文档来说，不管是内联还是外链的css，都会阻碍后续的dom渲染，但是不会阻碍后续dom的解析。
如何加快HTML页面加载速度
1.页面减肥
a. 页面的肥瘦是影响加载速度最重要的因素。
b. 删除不必要的空格、注释。
c. 将inline的script和css移到外部文件。
d. 可以使用HTML Tidy来给HTML减肥，还可以使用一些压缩工具来给JavaScript减肥。
2.减少文件数量：
a. 减少页面上引用的文件数量可以减少HTTP连接数。
b. 许多JavaScript、CSS文件可以合并最好合并。
3.减少域名查询：
a. DNS查询和解析域名也是消耗时间的，所以要减少对外部JavaScript、CSS、图片等资源的引用，不同域名的使用越少越好。
4.缓存重用数据：
a. 对重复使用的数据进行缓存。
5.优化页面元素加载顺序：
a. 首先加载页面最初显示的内容和与之相关的JavaScript和CSS，然后加载HTML相关的东西，像什么不是最初显示相关的图片、flash、视频等很肥的资源就最后加载。
6.减少inline JavaScript的数量：
a. 浏览器parser会假设inline JavaScript会改变页面结构，所以使用inline JavaScript开销较大。
b. 不要使用document.write()这种输出内容的方法，使用现代W3C DOM方法来为现代浏览器处理页面内容。\
7.使用现代CSS和合法的标签：
a. 使用现代CSS来减少标签和图像，例如使用现代CSS+文字完全可以替代一些只有文字的图片。\8.
b. 使用合法的标签避免浏览器解析HTML时做“error correction”等操作，还可以被HTML Tidy来给HTML减肥。
8.Chunk your content：
a. 不要使用嵌套table，而使用非嵌套table或者div。将基于大块嵌套的table的layout分解成多个小table，这样就不需要等到整个页面（或大table）内容全部加载完才显示。
9.指定图像和table的大小：
a. 如果浏览器可以立即决定图像或table的大小，那么它就可以马上显示页面而不要重新做一些布局安排的工作。
b. 这不仅加快了页面的显示，也预防了页面完成加载后布局的一些不当的改变。
c. image使用height和width。
性能分析
Chrome Performance 页面性能分析指南
Performance介绍
首先在新的无痕窗口打开网页，打开Chrome DevTools 切换到 Performance 下可以看到以下画面
上图1、3区域按钮可以用来触发性能数据记录，黑色按钮可以记录交互阶段的性能数据，圆形箭头按钮用来记录加载阶段的性能数据。
上图2区域 可以设置当前页面的网络加载速度与cpu运算速度。
下面我们点击黑色按钮来生成一份交互阶段的性能报告
第一部分：概览
这里最主要是整体的界面渲染的时候，每个时间段执行的事件顺序，通过上图我们就能知道我们每个时间段（精确到毫秒）都做了什么，当鼠标放上去的时候，我们还可以大图的形式去查看我们每个时间段界面的渲染情况，Performance 就会将几个关键指标，诸如页面帧速 (FPS)、CPU 资源消耗、网络请求流量、V8 内存使用量 (堆内存) 等，按照时间顺序做成图表的形式展现出来。
第二部分：性能面板
性能面板主要包括以下几部分
1.Network 这里我们可以直观的看到资源加载的顺序与时长
2.Interactions 用来记录用户交互操作，比如点击鼠标、输入文字、动画等
3.Timings 用来记录一些关键的时间节点在何时产生的数据信息，诸如 FP、FCP、LCP 等
4.Main 是Performance工具中比较重要的部分，记录了渲染进程中主线程的执行记录，点击main可以看到某个任务执行的具体情况
5.Compositor 合成线程的执行记录，用来记录html绘制阶段 (Paint)结束后的图层合成操作
6.Raster 光栅化线程池，用来让 GPU 执行光栅化的任务
7.GPU GPU进程主线程的执行过程记录，如 可以直观看到何时启动GPU加速…
Memory 选项，在勾选后，就会显示该折线图，通过该图可以看出我们在不同的时间段的执行情况。我们可以看到页面中的内存使用的情况，比如 JS Heap(堆)，如果曲线一直在增长，则说明存在内存泄露，如果相当长的一段时间，内存曲线都是没有下降的，这里是有发生内存泄露的可能的。
通过对性能面板各个部分的分析与问题定位，可以更深刻的理解浏览器是如何工作的
第三部分：Summary（性能摘要）
它是一个用来统计在我们检测性能的时间范围内，都做了哪些事情：
Loading ：加载时间
Scripting ：js计算时间
Rendering ：渲染时间
Painting ：绘制时间
Other ：其他时间
Idle ：浏览器闲置时间
Performance实践
下面举例来说明一下性能面板的使用，在无痕窗口下点击自动重启页面，并记录整个页面加载的过程，然后来分析结果～
网络&&白屏
性能面板，有很多很多的参数，我们要看一些比较常见的。首先看白屏时间和网络加载情况，如下图\
上图，我们可以看几点信息：
本次页面加载的白屏时间约为 150 ms
从网络资源加载情况来看，图片没有启用 http2，因此每次可以同时加载的图片数有限，未被加载的图片有等待过程
资源的加载时间也可以看到
另外，我们可以看一下资源加载有没有空白期，虽然上图没有，但是如果资源加载之间存在空白期，说明没有充分利用资源加载的空闲时间，可以调整一下。
火焰图
火焰图，主要在 Main 面板中，是我们分析具体函数耗时最常看的面板，我们来看一下，如图：
首先，面板中会有很多的 Task，如果是耗时长的 Task，其右上角会标红，这个时候，我们可以选中标红的 Task，然后放大，看其具体的耗时点。
放大后，这里可以看到都在做哪些操作，哪些函数耗时了多少,这里代码有压缩，看到的是压缩后的函数名。然后我们点击一下某个函数，在面板最下面，就会出现代码的信息，是哪个函数，耗时多少，在哪个文件上的第几行等。这样我们就很方便地定位到耗时函数了。
同时也可以查看 Main 指标分析代码里面是否存在强制同步布局等操作，分析出来这些原因之后，我们可以有针对性地去优化我们的程序
时间线&&内存情况
在 Timings 的区域，我们可以看到本次加载的一些关键时间，分别有：
FCP: First Contentful Paint
LCP: Largest Contentful Paint
FMP: First Meaningful Paint
DCL: DOMContentLoaded Event
L: Onload Event
我们可以选区(选择从白屏到有内容的区域，代表本次的页面加载过程)，可以对照着看一下上面的时间，截图如下：
蓝色：网络通信和HTML解析
黄色：JavaScript执行
紫色：样式计算和布局，即重排
绿色：重绘
Loading事件
| 事件 | 描述 |
|---|---|
| Parse HTML | 浏览器执行HTML解析 |
| Finish Loading | 网络请求完毕事件 |
| Receive Data | 请求的响应数据到达事件，如果响应数据很大（拆包），可能会多次触发该事件 |
| Receive Response | 响应头报文到达时触发 |
| Send Request | 发送网络请求时触发 |
Scripting事件
| 事件 | 描述 |
|---|---|
| Animation Frame Fired | 一个定义好的动画帧发生并开始回调处理时触发 |
| Cancel Animation Frame | 取消一个动画帧时触发 |
| GC Event | 垃圾回收时触发 |
| DOMContentLoaded | 当页面中的DOM内容加载并解析完毕时触发 |
| Evaluate Script | A script was evaluated. |
| Event | js事件 |
| Function Call | 只有当浏览器进入到js引擎中时触发 |
| Install Timer | 创建计时器（调用setTimeout()和setInterval()）时触发 |
| Request Animation Frame | A requestAnimationFrame() call scheduled a new frame |
| Remove Timer | 当清除一个计时器时触发 |
| Time | 调用console.time()触发 |
| Time End | 调用console.timeEnd()触发 |
| Timer Fired | 定时器激活回调后触发 |
| XHR Ready State Change | 当一个异步请求为就绪状态后触发 |
| XHR Load | 当一个异步请求完成加载后触发 |
Rendering事件
| 事件 | 描述 |
|---|---|
| Invalidate layout | 当DOM更改导致页面布局失效时触发 |
| Layout | 页面布局计算执行时触发 |
| Recalculate style | Chrome重新计算元素样式时触发 |
| Scroll | 内嵌的视窗滚动时触发 |
Painting事件
| 事件 | 描述 |
|---|---|
| Composite Layers | Chrome的渲染引擎完成图片层合并时触发 |
| Image Decode | 一个图片资源完成解码后触发 |
| Image Resize | 一个图片被修改尺寸后触发 |
| Paint | 合并后的层被绘制到对应显示区域后触发 |
另外，我们可以看到页面中的内存使用的情况，比如 JS Heap(堆)，如果曲线一直在增长，则说明存在内存泄露。如果Nodes和Listeners不断增加说明可能存在重复添加节点或者事件的情况。
最下方就是页面的一个整体耗时概况，如果 Scripting 时间过长，则说明 js执行的逻辑太多，可以考虑优化js，如果渲染时间过长，则考虑优化渲染过程，如果空闲时间过多，则可以考虑充分利用起来，比如把一些上报操作放到页面空闲时间再上报等。
作者：前端宇宙
链接：https://juejin.cn/post/7039335097278922788