浏览器如何工作

前言

最近在做web performance的improvement，浏览器性能的提升无非就是实现以下两个目标：

减少页面load的时间
提升页面交互的流畅性

但是以上两个目标又会经常被两个issue影响：

Network Latency：Load Time会被Latency影响
Network Latency是指浏览器将第一个请求发出（HTML 请求）到取回response所花时间。因此只要这个Network Latency越短，那么Load time就会越短
Browser Single Thread：交互的流畅性会因为浏览器是单线程

浏览器是单线程的，主线程要负责很多的工作，为了使交互更加流程，就必须减少主线程的responsibility。

但是主线程需要负责页面render以及用户交互这两个很重要的task，一旦主线程陷入了rerender的工作，那么就没有capacity去处理交互，导致页面交互不流畅。

浏览器render流程

当你在浏览器input一个URL，此时浏览器会经历三个阶段：

Connection Establish：和server建立安全连接
Parse：解析获取的HTML 文件
Render：将所有的node 绘制在页面上

Connection Establish

First Step： DNS Lookup

第一步找到URL所对应的IP地址（也就是HTML资源所在的server）。

如果输入的URL是https://example.com(域名), 并且你从来没有访问过这个域名，那么DNS Lookup就会开始，找到这个域名对应的IP地址。

你的浏览器会请求一个DNS Look服务，也就是发请求给Name server，这个server返回的response中包含IP地址。在第一个请求之后，这个IP地址会被浏览器cache一段时间，那么接下来发送给这个域名的请求可以直接冲cache中拿，而不需要给Name server发请求了。

我们需要为不同的域名进行DNS Look服务，这一部分可能会对web performance产生影响，尤其是对mobile如果你的页面上有很多来自不同域名的assets，当你使用mobile请求页面，那么DNS Look的请求需要先到cell tower，然后到phone company, 最后到达Name server，这会造成Network Latency。

image.png

Second Step： TCP Handshake

一旦浏览器获取到了IP地址，那么浏览器就会尝试和Server建立一个TCP Connection通过TCP三次握手协议。

Third Step： TLS Negotiation

通过HTTPS建立的安全连接，需要另一种handshake，我们把它叫做TLS negotiation。这个阶段是在开始实际数据传输之前，决定将使用哪种密码来加密通信，验证服务器。目的是为了建立一个安全的通信环境。

虽然这个过程会导致page load的时间增长，但是一个secure connection更重要。

Fourth Step： Send Request

上面几个步骤做完之后，现在浏览器和server之间已经建立一个安全的连接，这时候浏览器就可以和Server进行通信了。

这时候浏览器会代表User向server发请求，请求HTML文件render页面。

Note，这里有一个14kb rule的概念，如果想了解可以看Doc

Parsing

一旦HTML请求发出，浏览器接受到the first chunk of data(第一个TCP Packets), 就会立刻开始解析data, 然后尝试绘制页面。

Parse这个步骤就是将Response解析成DOM和CSSOM，然后用来绘制页面。

即使请求页面的HTML大于初始的14KB data packets，浏览器也会开始解析并尝试根据其数据来绘制页面，因此浏览器可能花费200ms获取到了第一个data packets，然后开始解析绘制页面，直到first packets处理完毕，之后浏览器才会扩大其congestion window 拥塞窗口并继续传递更多数据。

因此提升web performance，减少load time的一个重要方式就是：

在first 14kb的data packets中包含load当前页面所需要的所有data。假设你的load首屏需要15kb，那么就需要等待200ms先拿到first 14kb，解析然后render，但是由于数据不够，所以页面上仍然无法呈现内容，还需要再次等待200ms获取下一个1kb，然后再解析render，才能出现首屏的内容。

First Step： Building Dom Tree

将刚刚拿到的first packets of HTML file进行处理解析，然后构建DOM Tree。这个步骤是critical rendering path中的第一个步骤

Block Resource

浏览器parser会逐行解析HTML，根据遇到的HTML tag创建对应的DOM Node。但是一旦Parser遇到一些特殊类型的Tag，会做出不同的行为。

浏览器的资源主要分成两类：

non-blocking resource

不会阻塞HTML parse和render的resource。比如图片、字体。浏览器一旦parse到类似这样的资源，会发一个request去请求这些资源，但是会继续进行当前的parse工作，而不会受到这些资源的block。

blocking resource
blocking resource分为两种：
- parse block：会阻塞HTML的parse工作。比如script（without defer/async/pre scan）。浏览器在parse HTML的过程中，如果遇到script标签，并且标签上并没有async/defer的标签，那么就会立刻终止parse工作，发请求获取JS文件，并且会一直等待response回来，直接parse JS，直到JS文件parse完毕，才会重新开始执行HTML的parse工作。
- render block：会阻塞HTML的render工作。比如css（without pre-load）。css文件不会阻塞parser，如果浏览器在parse的过程中遇到link 标签，也只是fire一个request，而不会停止parse工作。但是在浏览器开始render之前，必须load css文件并且执行完毕生成CSSOM Tree。

这个步骤的最终产物就是DOM Tree，但是由于script标签会block DOM Tree的构建，因此这个步骤的性能瓶颈通常都是script标签。因此我们可以采取：

给script标签加上defer/async，使得script不会再阻塞parse，并且会等到DOM生成之后再执行
使用pre-load，减少主线程等待JS response回来的时间。<link rel="preload" href="main.js" as="script">

At the meantime: Preload scanner

浏览器本身具有同时发出多个请求的能力，因此出现了pre scanner

当主线程在忙着构建DOM Tree的时候，Preload scanner（不会占据主线程）会parse当前HTML文件，遇到高优先级的资源（如：css、js、font），会提前发请求获取资源，这些资源的请求可以同时发出，并且不会影响主线程的工作。

多亏Preload scanner，我们不需要等到主线程parse到某一个JS文件时才发出请求获取JS。

Preload scanner会在后台执行发请求的操作，因此当主线程parse到某一个资源的时候，很有可能这个资源已经download完毕，或者正在download。

Second Step: Building CSSOM Tree

处理css文件，构建CSSOM Tree。这个步骤是非常非常快的，因此提升performance通常不会考虑这一步，因为这个步骤甚至都没有DNS Lookup费时。这个步骤是critical rendering path中的第二个步骤

Render

render step包含style, layout, paint, compositing步骤，也就是将上一个步骤产生的CSSOM以及DOM render在页面上。

First step： Building Render Tree

这个步骤就是将DOM Tree和CSSOM Tree进行combine，最终生成Render Tree。这步骤是critical rendering path中的第三步。

浏览器的主线程会遍历DOM Tree中的所有可视Node，最终生成Render Tree。对于那些不会展示在页面上的Node都会不会出现在最终的render Tree中，比如<head> 或者{display: none}，请注意{visibility: hidden}这种node会出现在render tree中，因为这种node虽然不显示但是会占据空间。

Second Step： Layout

这步骤就是根据上一步骤产生的Render Tree, 计算render tree上每一个node的宽度高度以及在页面上的位置。这步骤是critical rendering path中的第四步。

Reflow 也是计算页面的layout，也就是第一次Layout之后的任何重新Layout都被叫做reflow。一个节点的reflow会重新计算这个node的宽高和position，也会触发他的子孙节点以及兄弟节点的reflow。 reflow之后一定会发生repaint。 reflow是非常昂贵的操作，很费时间，但是又很容易被触发，因此提升performance的一个方式就是尽量减少reflow。下面有一些方式可以提升：

在mobile browser中使用viewport meta tag

提前给mobile的browser设置好viewport，这样页面第一次在mobile browser做layout的时候，就可以直接使用你设置好的viewport布局而不需要再次reflow

给Images预设高宽

页面在第一次做layout的时候，你的image可能还没有拿回来，本身应该放置image的地方没有任何宽高，但是一旦image回来，就需要做reflow，因为image肯定有宽高，会导致其他所有元素的布局都需要重新计算，这种reflow是非常影响浏览器性能的。

我们可以给img标签设置宽高，这样image回来之后，不会导致image周围的其他的元素reflow。

Third Step： Paint

这个步骤就是将render tree上的所有node绘制到浏览器上。第一次的paint被叫做the first meaningful paint。这步骤是critical rendering path中的第五步。

为了确保scroll或者animation的流畅，因此所有reflow和repain的工作必须在小于16ms完成。

在看一个动画的时候，只有每16ms变化一次画面，对于人眼而言，才不会感觉有卡顿

Interactivity

当页面绘制完毕，onLoad event被触发之后，看似主线程就完全空闲下来了。但事实上不是这样的，一些被延迟执行的JS文件，可能会在时候被执行，也就意味着主线程会忙着执行JS文件。因此根本没有闲工夫处理scroll touch 等交互操作，在用户角度就好像页面卡了。

Time to Interactive(TTI)指代的是页面上的第一个请求发出（HTML请求）到页面可以和用户交互所用的时间。是一个重要的web performance的measurement metric，这个值越小，也就意味着对用户而言，页面就是越早的可用。这个值最好小于50ms。

如果主线程一直忙于解析，编译和执行JavaScript，则该主线程将不可用，因此无法及时（少于50ms）响应用户交互。

这一部分就是尽量减少主线程的使用。

Doc

https://developer.mozilla.org/en-US/docs/Web/Performance/How_browsers_work