浏览器的渲染过程及涉及到的缓存机制

Posted 2023-04-28

参考技术A

答：dns解析-》tcp链接-》发送HTTP请求-》服务器处理请求并且返回报文-》浏览器解析渲染页面-》链接结束

是一个将网址解析成IP 地址的过程。
首先从本地域名服务器中查找，如果找不到就继续向上根域名服务器查找，直到顶级域名，这个过程中存在dns优化有的环节。当查找资源时， 会先找缓存，（浏览器缓存-》系统缓存-》路由器缓存等等），也会根据机器的负载量和距离用户的位置进行dns负载均衡。

A.客户端发送syn到服务器要求连接
B.服务端向客户端发送ack
C.客户端收到ack并确认后，向服务端发送ack，连连接建立。

tcp连接建立之后，开始通过HTTP协议传输资源，根据情况判断是否使用HTTPS，HTTP包括请求行，请求报头，请求正文（post，put客户端向服务器传输数据的情况）。keepalive什么的可以在请求头里添加。

（此处涉及强制缓存和协商缓存， 为了先讲清楚浏览器渲染过程，我把他们放在文章末尾。）

服务端接到请求开始对tcp进行处理，对http进行解析，按照报文格式封装成HTTP request对象。响应报文码（1xx：请求已接受，2XX：成功，3xx：重定向，4xx：客户端错误，5xx：服务端错误）

边解析边渲染，首先解析html,构建dom树，然后解析css，构建cssom。

我思考过很久HTML和css谁先渲染。我的理解是，不一定，看位置了，如果dom构建的过程中遇到了css的link，那就会先去加载并构建cssom，这个过程不是一次性的。 css和同步的js文件都是阻塞DOM树渲染的，但不阻塞DOM解析， 直到js加载并且执行完毕。遇到阻塞的css也会延迟js的执行和dom构建。（因为js可能会修改dom或者cssom）,css同样，当cssom构建时，js也会停止被阻塞，等待cssom构建完成。

defer & async
1.正常模式
<script src="script.js"></script>
遇到这样的js标签，浏览器会立即加载并执行，不等待后续载入的文档元素。

2.async模式
<script async src="script.js"></script>
有async的js文件会和后续的DOM解析渲染并行执行，当js加载完成，立即执行，这时html解析暂停。因此不会按照标签引入顺序执行。

3.defer模式
<script defer src="script.js"></script>
有defer的js文件的加载，也会和文档的解析构建并行。这一点与async一致。
不同的是，defer的js文件加载完不会立即执行， 会等到所有文档解析完成后，DOMContentLoaded事件触发之前完成， 因此会按照引入顺序执行。

DOMContentLoaded & onload
DOM解析完（阻塞DOM的内容解析完，DOM才真正解析完）会触发DOMContentLoaded事件。如果在DOMContentLoaded之后引入css样式表，DOMContentLoaded可能无法获取样式表里的样式，此时DOM树已经构建完成，但外部css文件还没加载完成，这也是 css文件放在头部的原因 。

onLoad
页面的所有资源被加载以后触发onLoad事件，会在DOMContentLoaded之后触发。

这个过程中有两个重要的过成是回流和重绘。计算盒模型的大小位置还有解析颜色字体等 属性，这些都确定下来的时候开始repain，合成一个rendertree渲染树，render-tree中必须同时存在dom和cssom，浏览器开始布局并渲染到屏幕上。首次加载必然会经历回流和重绘的过程。

无论何时总会有一个初始化的页面布局伴随着一次绘制。（除非你希望你的页面是空白的:)）之后，每一次改变用于构建渲染树的信息都会导致以下至少一个的行为：

部分渲染树（或者整个渲染树）需要重新分析并且节点尺寸需要重新计算。这被称为重排。注意这里至少会有一次重排-初始化页面布局。

由于节点的几何属性发生改变或者由于样式发生改变，例如改变元素背景色时，屏幕上的部分内容需要更新。这样的更新被称为重绘。

重排和重绘代价是高昂的，它们会破坏用户体验，并且让UI展示非常迟缓。

一些重排可能开销更大。想象一下渲染树，如果你直接改变body下的一个子节点，可能并不会对其它节点造成影响。但是当你给一个当前页面顶级的div添加动画或者改变它的大小，就会推动整个页面改变-听起来代价就十分高昂。

浏览器一直致力于减少这些消极的影响，浏览器会创建一个变化的队列，浏览器可以向队列添加或变更这些变化，在一个特定的时间或达到一定的数量时，执行一次重排或重绘，通过这种方式，多次重排或重绘会整合起来最终减少重排或重绘的次数，以节省浏览器渲染的开销。

所以 ，同时set和get样式是非常糟糕的做法

看到的一个答案，有可能是这个原因，但是我不确定。
开发环境会把css都打包到js里，所以要等js加载好了才有样式，因此会出现这种情况；但是在生产环境下，css会生成css文件，并插入到<style />里，因此就不会出现这种情况了。

两个优化点：css先加载，js后加载
js尽量不要修改dom树。

以下是我在OneNote的笔记，粘贴过来就会变成图片没有找到好的办法。
强制缓存和协商缓存是http请求这一步的内容。

DOM的解析渲染过程

获取到html文件

第一步当用户在url中输入网址时

1. 浏览器会检查缓存中有没有这个域名对应的解析过的IP地址，如果缓存中有，这个解析过程就结束。

2. 如果在本地没有找到对应的ip地址，就到本地域名服务器中去找。

3. 如果本地域名服务器没找到就向根域名服务器发起请求去找。

第二步：找到IP地址后浏览器和服务器建立连接(属于传输层，涉及TCP，UDP协议，TCP的三次握手和松手过程，TCP支持的应用协议主要有：Telnet、FTP、SMTP等；UDP支持的应用层协议主要有：NFS（网络文件系统）、SNMP（简单网络管理协议）、DNS（主域名称系统）、TFTP（通用文件传输协议）等。)

第三步： 浏览器发起HTTP(属于五层网络模型中的应用层，涉及HTTP协议，TODO: 《图解HTTP》)请求（属于五层模型中的应用层），服务器发送回HTTP报文。 
接下来就会释放TCP链接。

构建DOM树

由于浏览器采用自上而下的方式解析，在遇到这两种元素时都会阻塞浏览器的解析，直到外部资源加载并解析或执行完毕后才会继续向下解析html。对于样式与脚本的先后顺序同样也会影响到浏览器的解析过程，究其原因主要在于：script脚本执行过程中可能会修改html界面（如document.write函数）；DOM节点的CSS样式会影响js的执行结果。

DOM树创建完成后DOMContentLoaded事件即触发，这时候可以用过script来操作DOM节点。

构建呈现树

HTML解析完毕后，开始构建呈现树RenderTree，这一步的主要工作在于将css样式应用到DOM节点上，WebKit内核将这一过程称为附着，其他浏览器有不同的概念。对前端工程师而言这个过程会涉及到CSS层叠问题。

呈现树的每一个节点即为与其相对应的DOM节点的CSS框，框的类型与DOM节点的display属性有关，block元素生成block框，inline元素生成inline框。每一个呈现树节点都有与之相对应的DOM节点，但DOM节点不一定有与之相对应的呈现树节点，比如display属性为none的DOM节点，而且呈现树节点在呈现树中的位置与他们在DOM树中的位置不一定相同，比如float与绝对定位元素。

布局

呈现树之后进入“布局”处理阶段，也就是为每个节点分配一个应出现在屏幕上的确切坐标。

为达到更好的用户体验，呈现引擎会力求尽快将内容显示在屏幕上。它不必等到整个 HTML 文档解析完毕之后，就会开始构建呈现树和设置布局。在不断接收和处理来自网络的其余内容的同时，呈现引擎会将部分内容解析并显示出来。

绘制

在绘制阶段，系统会遍历呈现树，并调用呈现器的“paint”方法，将呈现器的内容显示在屏幕上。绘制工作是使用用户界面基础组件完成的。