【每日十分钟前端】浏览器2，浏览器解析渲染页面流程，HTML解析、CSS解析、布局绘制等

Critical Rendering Path，CRP，网页的关键渲染路径。
指的是浏览器从请求HTML、CSS、Javascript文件开始，到将它们最终以像素输出到屏幕上这一过程。

大致步骤为：

1、解析HTML文本，构建DOM。

2、解析CSS，构建CSSOM（CSS规则树）。

3、合并DOM树和CSSOM，构建渲染树Render-Tree。

4、布局Layout/Reflow，负责各元素尺寸、位置的计算。

5、绘制Paint/Repaint，绘制页面像素信息，展示到屏幕上。

上面过程并非一次进行，存在一定的交叉。

提高网页加载速度，就要在第一次加载的时候让元素尽快显示在屏幕上，而不是等所有元素全部准备就绪后再显示。

补充：
浏览器的解析是自上而下开始的，会先解析HTML，直到遇到外部样式和外部脚本（没有async、defer属性时），会阻塞浏览器的解析，大致为：
html解析 → 外部样式、脚本加载 → 外部样式执行 → 外部脚本执行 → html继续解析

解析HTML文本，构建DOM

HTML内容Bytes → 单个字符characters → 标记tokens → 对象objects → DOM树

DOM，document Object Model，文档对象模型。

解析由两部分组成：分词与构建树。

1、浏览器到得到html后，第一步就是将HTML解析成许多符号序列标记tokens，每个token都有自己的含义和规则集，也就是分词过程。

2、分词的结果是得到一堆的tokens，此时把他们转化为对象，这些对象分别定义他们的属性和规则。

3、将对象组合成为一棵树（DOM元素+属性节点）。（不同标签之间的关系就像是一个树形结构一样）

补充：

这个过程是循序渐进的。
我们假设一个HTML非常大，一次传输（RTT）后只能的到一部分，浏览器得到这部分后就会开始构建DOM，并不会等到整个文档都就位后才开始渲染。从而加快构建过程，从顶部向下构建，后面的构建不会对前面的造成影响。

解析CSS，构建CSSOM（CSS规则树）

CSS内容Bytes → characters → tokens → objects → CSSOM

CSS Object Model，对象模型，构建过程类似DOM。

当HTML解析到<link>标签时，会请求对应的CSS文件，当CSS文件就绪时便开始解析它，如果遇到行内style时则直接解析。这个可以跟构建DOM同时进行。

如果是外部样式，CSSOM的构建必须要获得一份完整的CSS文件。因为CSS文件包含大量的样式，后面的会覆盖前面的，如果提前构建CSSOM就很容易获得错误的结果。

即为：

1、如果是内联样式，CSSOM构建包含在解析HTML过程中。
2、如果是外部样式，包含在解析CSS样式表过程中。
3、如果没有设置样式，使用默认样式，包含在解析HTML过程中。

补充：

渲染优化，在不考虑引入Javascript的情况下：

DOM即使构建完成也需要等CSSOM构建完成，才能经过一个完整渲染过程并呈现画面。
此时有一个优化就是，尽早构建出 CSSOM：

（1）、html文档中的<style>或者<link>标签应该放在<head>里并尽早发现被解析。
（2）、减少第一次请求的 CSS 文件大小。
（3）、甚至可以将最重要部分的CSS规则以<style>标签发在<head>里，无需网络请求。

合并DOM树和CSSOM，构建渲染树Render-Tree

当DOM和CSSOM都有了之后，浏览器就要开始构建渲染树了。

此时不需要全部构建，只需要构建需要显示在屏幕上的部分。
一般来说渲染树和DOM树一一对应，但不是严格意义上的一一对应，因为有一些不可见元素的DOM（比如<head>、<meta>、display:none等），是不需要构建。

步骤：

（1）、浏览器从DOM树开始，遍历每一个“可见”节点。
（2）、对于每一个“可见”节点，在CSSOM上找到匹配的样式并应用。
（3）、生成渲染树。

补充：

1、CSS匹配规则为从右向左

浏览器是给可见节点找对应规则。
（jQuery选择器是使用一个规则去找对应的节点，这样从左到右或许更快。）
对于前者，一个CSS文件中或许有上千条规则，而且对于当前节点来说，大多数规则是匹配不上的，如果从右开始匹配（也是从更精确的位置开始），能更快排除不合适的大部分节点。而如果从左开始，只有深入了才会发现匹配失败，如果大部分规则层级都比较深，就比较浪费资源了。

2、讲述到为止，DOM不阻塞渲染树的构建，CSSOM阻塞。

布局Layout

这一步也称为Reflow，回流。

目前已经得到了元素的自身信息，但是还不知道它在浏览器视口中的位置和大小。这一过程主要就是定位坐标和大小、是否换行、各种position、overflew、z-index属性等，最终输出元素的盒模型（box-model）

回流，意味着元素的内容、结构、位置或尺寸发生变化，需要重新计算样式和渲染树。

渲染Paint

这一步也称为Repaint，重绘。

浏览器将每一个节点以像素显示在屏幕上，即将图像绘制出来。

这一过程需要的时间与文档大小、css应用样式的数量与复杂度、设备自身有关，例如，对简单的颜色进行paint是简单的，但是对box-shadow进行paint是复杂的。

重绘，意味着元素发生的改变只是影响元素的一些外观之类的情况（背景色，边框颜色，文字颜色等）（没有几何信息），此时只需要应用新样式绘制这个元素就可以了。

补充：

回流一定伴随着重绘，重绘可以单独出现。

引入JavaScript

有以下几个特点：

1、阻塞浏览器的解析，HTML构建DOM时候，发现一个外部脚本时，需等待脚本下载完成并执行后才会继续解析HTML。

2、浏览器的优化，在下载脚本的时候（脚本阻塞情况时），也会继续下载其他资源，只是脚本并行下载的优化，之后必须等这个脚本执行完毕后才能继续接下来的解析。

3、defer与async，如果使用异步脚本（加上defer或async属性的脚本），可以等到解析完毕后执行脚本。
<script src="" async />

补充：

1、JavaScript执行会被CSSOM构建阻塞，也就是JavaScript必须等到CSSOM构建完成后才会执行。

2、async，异步执行。
异步下载完成后就会执行，不确保执行顺序，一定在onload前，但不确定在DOMContentLoaded事件的前或后。
即，无需阻塞DOM，在对Script执行网络请求期间可以继续构建DOM，直到拿到Script之后再去执行。

3、defer，延迟执行。
在浏览器看起来的效果像是脚本放在了body后面一样。
不同的浏览器优化效果不一样，按规范应该在DOMContentLoaded事件前，实际上也可能在它后面。
即，将该Script的网络请求优先级降低，先执行别的，延长响应时间。

遇到图片类资源

直接异步下载，不会阻塞解析，下载完毕后直接用图片替换原有的src的地方。

浏览器接收到图片字节后，便开始渲染了，而不是等到整张图片接收完成后。

Loaded 和 DOMContentLoaded

（1）、load事件触发时，页面上的所有DOM、样式表、脚本、图片都已经加载完成了。

（2）、DOMContentLoaded事件触时，仅DOM加载完成，不包含样式、图片、异步脚本的加载完成情况。