关于前端:输入-url-到页面展示发生了什么

整体上，能够分为以下几步：

1. DNS 域名解析；
2. 建设 TCP 连贯（三次握手）；
3. 发送 HTTP 申请；
4. 服务器解决申请；
5. 返回响应后果；
6. 敞开 TCP 连贯（四次握手）；
7. 浏览器解析 HTML；
8. 浏览器布局渲染；

1. DNS 域名解析

域名的构造

域名通过 . 拆分成几个局部，【残缺域名】从右到左顺次是：根域名、顶级域名、二级域名、三级域名 …

网址：https://www.baidu.com/
残缺域名：www.baidu.com.root
省略域名：www.baidu.com.

root 根域名，寰球的根域名都是root，因而根域名经常疏忽。
com 顶级域名，TLD(Top-Level Domains)。
baidu 二级域名，别名有：次级域名，用户 DNS 名称服务器，权威名称服务器
www 三级域名

为什么须要 DNS 解析域名为 IP 地址？

网络通讯须要相应的网络协议，大部分是基于 TCP/IP 协定，而 TCP/IP 协定是基于 IP 地址，所以计算机网络通信时只能辨认 IP 地址。因为用户很难记住每一个网站的 IP 地址，所以就呈现了“DNS 服务器”。

什么是 DNS ?

DNS 域名零碎就是将域名 (例如: www.baidu.com) 转换为 IP 地址。域名和 IP 地址是一一对应的。

DNS 解析形式

• 正向解析：将域名转换成对应的 IP 地址的过程, 它利用于在浏览器地址栏中输出网站域名时的情景。
• 反向解析：依据 IP 地址查找对应的注册域名，常常被一些后台程序应用, 用户看不到。

DNS 查问形式

• 客户端和浏览器，本地 DNS 之间的查问形式是 递归查问。
• 本地 DNS 服务器与根域及其子域之间的查问形式是 迭代查问。

域名解析记录

可查看域名解析记录

DNS 解析过程

解析过程如下：

第一步：查看浏览器缓存
用户通过浏览器浏览某网站后，浏览器会主动缓存该网站域名对应的 IP 地址，当用户再次拜访的时候，浏览器会从缓存中查找该域名对应的 IP 地址，如果有，实现域名解析，如果没有，进行下一步。

• 因为缓存不仅是有大小限度，而且还有工夫限度，所以存在域名对应的找不到的状况。
• 通过 chrome://net-internals/#dns 能够查看 chrome 的 DNS 缓存信息。

第二步：查找本机 hosts 文件
如果用户的浏览器中缓存中没有，零碎会去查找本人本地的 hosts 文件是否有这个域名与 IP 的映射关系，如果有，实现域名解析，如果没有，进行下一步。

• 关上 Finder 利用，按 Shift+Command+G 三个组合按键，输出 Hosts 文件的所在门路：/etc/hosts，即可查看本机 hosts。

前两步都是在本机上实现的，从第三步开始，才向近程 DNS 服务器发动解析域名的申请。

第三步：向 本地域名解析服务器 发动域名解析申请
如果在本机上没有实现域名解析，零碎会申请本地域名解析服务器进行解析，如果有，实现域名解析，如果没有，进行下一步。

• 本地域名解析服务器 个别都是本地区的域名服务器，比方连贯的校园网，那么域名解析零碎就在校园机房里，如果连贯的是电信、挪动或者联通的网络，那么本地域名解析服务器就在本地区，由各自的运营商来提供服务。

前三步是递归查问，后几步是迭代查问。

第四步：向 根域名解析服务器 发动域名解析申请
从本地域名解析服务器获取到根域名服务器对应的主机名，而后向 根域名服务器 发动解析申请。根域名服务器接管申请，返回所查域的顶级域名（gtld 域名）服务器地址。

第五步：向 顶级域名服务器 发动解析申请
本地域名解析服务器向 顶级域名服务器 发动解析申请，顶级域名服务器接管申请，返回二级域名服务器地址。

第六步：向 二级域名服务器 发动解析申请
本地域名解析服务器向 二级域名服务器 发动申请，二级域名服务器接管申请，返回 IP 地址给本地域名服务器。

第七步：本地域名服务器缓存后果
本地域名服务器缓存解析后的后果，缓存工夫由工夫来管制。

第八步：返回解析后果给用户
解析后果将间接返回给用户，用户零碎将缓存该地址，缓存工夫由来管制，至此，解析过程完结。

解析域名命令，www.baidu.com 为例：

• 间接查看域名后果：nslookup www.baidu.com
• 查看整个解析过程：dig www.baidu.com +trace
  ​ 个别状况下，DNS 解析到别名就进行，并返回了具体的 IP 地址。如果想看到具体的地址，能够进一步对别名进行解析。

具体可查看：浅析 DNS 域名解析过程

2. 建设 TCP 连贯

TCP 是什么？

TCP/IP

计算机与网络设备之间如果要互相通信, 单方就必须基于雷同的规定（例如由哪一方先发动通信, 应用哪种语言进行通信, 怎么发送与接收数据，怎么完结通信等，不同的硬件，操作系统之间如何通信），这种规定称为协定 (protocol)。而 TCP/IP 是互联网相干各类协定族的总称。

TCP/IP 协定族按档次别离为：应用层，传输层，网络层，数据链路层，物理层。

传输层
该层为两台主机上的应用程序提供端到端的通信。传输层有两个传输协定：TCP (传输控制协议) 和 UDP (用户数据报协定)。

传输控制协议 TCP（Transmission Control Protocol）

• 是一种面向连贯的、牢靠的、全双工的、基于字节流的传输层通信协议。

用户数据报协定 UDP（User Datagram Protocol）

• UDP 在传送数据之前不须要先建设连贯，近程主机在收到 UDP 报文后，不须要给出任何确认。
• 尽管 UDP 不提供牢靠交付，但在某些状况下 UDP 确是一种最无效的工作形式（个别用于即时通信），比方：QQ 语音、QQ 视频、直播等等

TCP 报文段首部格局

• 源端口和目标端口：各占 2 个字节，别离是源端口和目标端口。IP 地址 + 端口号就能够确定一个地址。

• 序号 / 序列号（Sequense Number，seq）：在一个 TCP 连贯中传送的字节流中的每一个字节都按程序编号。该字段示意本报文段所发送的数据的第一个字节的序号。初始序号称为 Init Sequense Number, ISN。

  例如，一报文段的序号是 101，共有 100 字节的数据。这就表明：本报文段数据的第一个字节的序号是 101，最初一个字节的序号是 200。显然，下一个报文段的数据序号该当从 201 开始，即下一个报文段的序号字段值应为 201。

• 确认号 ack：冀望收到对方下一个报文段的第一个数据字节的序号。若确认号为 N，则表明：到序号 N-1 为止的所有数据都已正确收到。

保留位左边是 6 个管制位，用来阐明该报文段性质。

• 紧急位 URG：当 URG = 1 时，表明此报文段中有紧急数据，是高优先级的数据，应尽快发送，不必在缓存中排队。
• 确认 ACK：仅当 ACK = 1 时确认号字段才无效，当 ACK = 0 时确认号有效。TCP 规定，在连贯建设后所有传送的报文段都必须把 ACK 置为 1。
• 推送 PSH：当两个利用过程进行交互式的通信时，有时在一端的利用过程心愿在键入一个命令后立刻就能收到对方的响应。在这种状况下，TCP 就能够应用推送（push）操作。这时，发送方 TCP 把 PSH 置为 1，并立刻创立一个报文段发送进来。接管方 TCP 收到 PSH = 1 的报文段，就尽快地交付接管利用过程。而不必等到整个缓存都填满了后再向上交付。
• 复位 RST：当 RST = 1 时，表明 TCP 连贯中呈现了严重错误（如因为主机解体或其余起因），必须开释连贯，从新建设传输连贯。

• 同步 SYN：SYN = 1 示意这是一个连贯申请或连贯承受报文。

  当 SYN = 1 而 ACK = 0 时，表明这是一个连贯申请报文段。对方若批准建设连贯，则应在响应的报文段中使 SYN = 1 且 ACK = 1。

• 终止 FIN：当 FIN = 1 时，表明此报文段的发送发的数据已发送结束，并要求开释运输连贯。

如何建设客户端与服务器的 TCP 连贯？

TCP 连贯的建设采纳客户 - 服务器模式：被动发动连贯建设的叫做客户，被动期待连贯建设的叫做服务器。进行三次握手，建设 TCP 连贯。

所谓三次握手 (Three-way Handshake) 是指建设一个 TCP 连贯时，须要客户端和服务器总共发送 3 个包。

进行’三次握手‘的次要作用就是为了确认单方的接管能力和发送能力是否失常、指定本人的初始化序列号(Init Sequense Number, ISN) 为前面的可靠性传输做筹备。

三次握手具体过程如下：

SYN：是否是连贯申请 / 接管报文段；
seq：发送的第一个字节的序号；
ACK：是否是确认报文段；
ack：确认号。心愿收到的下一个数据的第一个字节的序号；

第一次握手 (SYN=1, seq=x)
客户端向服务端发送一个 SYN 报文（SYN = 1）。报文指定客户端的初始化序列号 ISN(x)，即 seq = x，示意本报文段所发送的数据的第一个字节的序号。

• SYN 报文发送结束后，客户端进入 SYN_SENT 状态，期待服务端确认。
• 客户端不能确认任何；
  服务器确认了：对方发送失常，本人接管失常；

第二次握手 (SYN=1, ACK=1, seq=y, ack=x+1)
服务端收到客户端的 SYN 报文，对 SYN 报文进行确认，并向客户端发送 SYN + ACK 报文。报文指定服务端的初始化序列号 ISN(y)，即 seq = y，同时会把客户端的 x+1（ISN + 1）作为确认号 ack 的值，示意曾经收到了客户端发来的的 SYN 报文，心愿收到的下一个数据的第一个字节的序号是 x + 1。

• 这个报文段发送结束后，服务端进入 SYN_RECV 状态。
• 客户端确认了：本人发送、接管失常，对方发送、接管失常；
  服务器确认了：对方发送失常，本人接管失常；

第三次握手 (ACK=1, seq=x+1, ack=y+1)
客户端收到服务端的 SYN + ACK 报文，会向服务器发送 ACK 报文。把服务器的 y + 1(ISN + 1)作为 ack 的值，示意曾经收到了服务端发来的的 SYN 报文，心愿收到的下一个数据的第一个字节的序号是 y + 1，并指明此时客户端的序列号 seq = x + 1（初始为 seq = x，所以第二个报文段要 +1）

• 这个报文段发送结束后，客户端和服务端都进入 ESTABLISHED (连贯胜利)状态，此时实现 TCP 的三次握手。
• 客户端确认了：本人发送、接管失常，对方发送、接管失常；
  服务器确认了：本人发送、接管失常，对方发送、接管失常；

在三次握手过程中，通信单方的状态有：

CLOSED：没有连贯状态。初始客户端和服务器都是处于 CLOSED 状态。
LISTEN：收听状态，侦听来自远方 TCP 端口的连贯申请。
SYN-SENT：同步已发送，在发送连贯申请后期待匹配的连贯申请。
SYN-RCVD：同步收到。服务端被动关上后, 接管到了客户端的 SYN 并且发送了 ACK 时的状态。
ESTABLISHED：连贯已建设，能够数据传输。

三次握手的生活版：

客户端：“你好，在家不？”— SYN
服务端：“在的，你来吧。”— SYN + ACK
客户端：“好嘞。”— ACK

• 第三次握手的时候，是能够携带数据的。第一次、第二次握手相对不能够携带数据 。简略来说，申请连贯 / 接管 即 SYN = 1 的时候不能携带数据。
• 现实状态下，TCP 连贯一旦建设，在通信单方中的任何一方被动敞开连贯之前，TCP 连贯都将被始终放弃上来。
• 当一端为建设连贯而发送它的 SYN 时，它会为连贯抉择一个初始序号。ISN 随工夫而变动，因而每个连贯都将具备不同的 ISN。如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因而 ISN 是动静生成的。

3. 发送 HTTP 申请

TCP 连贯建设后，浏览器就能够基于 HTTP/HTTPS 协定向服务器发送 GET 申请获取网页信息。

HTTP 是什么

全称：超文本传输协定（HyperText Transfer Protocol）
HTTP 是一种可能获取像 HTML、图片等网络资源的通信协定（protocol），是应用层协定，其报文分为申请报文和响应报文。
当客户端申请一个网页时，先通过 HTTP/HTTPS 协定将申请的内容封装在申请报文之中，服务器收到该申请报文后依据协定标准进行报文解析，而后向客户端返回响应报文。

申请报文的构造

申请行 ：申请办法（Method）+ 空格 + 对立资源标识符（URI）+ 空格 + HTTP 版本 + CR LF。
申请头 ：字段名 + 冒号 + 值 + CR LF。
空行 ：CR LF。代表所有对于申请的头部信息曾经发送结束。
申请体：不是所有的申请都有一个 body，由用户自定义增加。例如获取资源的申请：GET，HEAD，DELETE 和 OPTIONS，通常它们不须要 body。有些申请将数据发送到服务器以便更新数据：常见的的状况是 POST 申请（蕴含 HTML 表单数据）。

关上百度，申请报文如下：

为什么浏览器里申请报文里没有申请体？

因为为了开发人员不便，浏览器把申请体放到了 Request Headers 下方的 Request Payload / QueryString / FormData 里。三者区别可查看：Request Payload 是什么

申请办法

4. 服务器解决申请

服务器承受到申请，解析申请头。
如果头部有缓存相干信息如 if-none-match 与 if-modified-since，则验证缓存是否无效，若无效则返回状态码为 304，若有效则从新返回资源，状态码为 200。
如果没有缓存，间接返回资源。

5. 返回响应后果

服务器解决完申请，以响应报文的格局向客户端做出响应。

响应报文的构造

状态行 ：HTTP 版本 + 空格 + 状态码 + 空格 + 状态码形容 + CR LF。
响应头 ：字段名 + 冒号 + 值 + CR LF。
空行 ：CR LF，代表所有对于申请的头部信息曾经发送结束。
响应体：不是所有的响应都有 body，由用户自定义增加。响应状态码 (如 201 或 204) 的响应，通常不会有 body。

响应状态码

状态代码由服务器收回，以响应客户端对服务器的申请。
1xx（信息）– 收到申请，持续解决
2xx（胜利）– 申请已胜利接管与解决
3xx（重定向）– 须要采取进一步措施能力实现申请
4xx（客户端谬误）– 申请蕴含谬误的语法或无奈满足
5xx（服务器谬误）– 服务器无奈满足显著无效的申请

6. 敞开 TCP 连贯

为了防止服务器与客户端单方的资源占用和损耗，当单方没有申请或响应传递时，任意一方都能够发动敞开申请。敞开 TCP 连贯，须要四次挥手。
所谓四次挥手 是指敞开一个 TCP 连贯时，须要客户端和服务器总共发送 4 个包。

四次挥手具体过程如下：

FIN：是否是终止报文段；
seq：发送的第一个字节的序号；
ACK：是否是确认报文段；
ack：确认号。心愿收到的下一个数据的第一个字节的序号；

刚开始单方都处于ESTAB-LISHED 状态，假如是客户端先发动敞开申请：

第一次挥手 (FIN=1, seq=u)
客户端发送一个申请终止连贯 FIN 报文。报文中会指定一个初始序列号 seq = u（ISN），并进行再发送数据，被动敞开 TCP 连贯。

• 发送 FIN 报文后，客户端处于 FIN_WAIT1 状态，期待服务端的确认。

第二次挥手 (ACK=1, seq=v, ack=u+1)
服务端收到 FIN 报文后，会发送 ACK 报文。报文中会指定一个初始序列号 seq = v（ISN），并把客户端的 u+1（ISN+1）作为 ack 的值，表明曾经收到客户端的报文。

• 报文发送后，服务端处于 CLOSE_WAIT 状态。
• 此时的 TCP 处于半敞开状态，客户端到服务端的连贯开释。客户端收到服务端的确认后，进入 FIN_WAIT2 状态，期待服务端收回的连贯开释报文段。

第三次挥手 (FIN=1, ACK=1, seq=w, ack=u+1)
如果服务端也想断开连接（没有要向客户端收回的数据），和客户端的第一次挥手一样，发送 FIN 报文，且指定一个序列号 w，并把客户端的 u+1（ISN+1）作为 ack 的值，表明曾经收到客户端的报文。

• 报文发送后，服务端处于 LAST_ACK 的状态，期待客户端的确认。

第四次挥手 (ACK=1, seq=u+1, ack=w+1)
客户端收到 FIN 报文后，会发送 ACK 报文。并指定一个序列号 u+1, 把服务端的 w +1 作为 ack 的值。

• 报文发送后，客户端处于 TIME_WAIT 状态，期待 2MSL 才会变成 CLOSED 状态。

在四次握手过程中，通信单方的状态有：

FIN-WAIT-1：期待近程 TCP 的连贯中断请求，或先前的连贯中断请求的确认；
CLOSE-WAIT：期待从本地用户发来的连贯中断请求；
FIN-WAIT-2：从近程 TCP 期待连贯中断请求；
LAST-ACK：期待原来发向近程 TCP 的连贯中断请求的确认；
TIME-WAIT：期待足够的工夫以确保近程 TCP 接管到连贯中断请求的确认；

四次挥手的生活版：

客户端：“兄弟，我这边没数据要传了，咱敞开连贯吧。”— FIN + seq
服务端：“收到，我看看我这边有木有数据了。”— ACK + seq + ack
服务端：“兄弟，我这边也没数据要传你了，咱能够敞开连贯了。”– FIN + ACK + seq + ack
客户端：“好嘞。”— ACK + seq + ack

为什么须要期待 2MSL 后才会进入 CLOSED 状态？

2MSL：一个报文的来回工夫

这样做的目标是 确保服务端收到客户端发送的 ACK 报文。如果服务端在规定工夫内没有收到客户端发来的 ACK 报文的话，服务端会从新发送 FIN 报文给客户端，客户端再次收到 FIN 报文之后，就晓得之前的 ACK 报文失落，会再次发送 ACK 报文给服务端。服务端收到 ACK 报文之后，就敞开连贯了，处于 CLOSED 状态。

为什么要四次挥手？

因为 TCP 的 半敞开 （half-close）个性，TCP 提供了连贯的一端在完结它的发送后还能接管来自另一端数据的能力。任何一方都能够在数据传送完结后收回连贯开释的告诉，待对方确认后进入 半敞开状态 。当另一方也没有数据再发送的时候，则收回连贯开释告诉，对方确认后就 齐全敞开 了 TCP 连贯。
艰深的来说，两次握手就能够开释一端到另一端的 TCP 连贯，齐全开释连贯一共须要四次握手。

7. 浏览器解析 HTML

服务器返回 HTML — 响应头和数据后，浏览器的 渲染引擎 开始解析 HTML。

渲染引擎解析主流程

渲染引擎通过解析 HTML，生成 DOM 树，解析 CSS，生成 CSSOM 树，而后把 DOM 树和 CSSOM 树联合在一起构建渲染树。

构建 DOM 树

HTML 解析器的工作是将 HTML 标记解析成 DOM 树，波及到 tokenization 和树的结构。

• HTML 标记包含开始和完结标记，以及属性名和值。
• DOM 树形容了文档的内容。<html> 元素是第一个标签也是文档树的根节点。树反映了不同标记之间的关系和层次结构。嵌套在其余标记中的标记是子节点。DOM 节点的数量越多，构建 DOM 树所需的工夫就越长。
• DOM 树构建是增量的。

构建 CSSOM 树

CSS 解析器会将 CSS 文件解析成 CSSOM 树。浏览器将 CSS 规定转换为能够了解和应用的款式映射，遍历 CSS 中的每个规定集，依据 CSS 选择器创立具备父、子和兄弟关系的节点树。

• CSS 是渲染阻塞的：浏览器会阻塞页面渲染直到它执行了所有的 CSS。
• DOM 和 CSSOM 是两棵树，它们是独立的数据结构。

解决脚本和样式表

阻塞渲染

“阻塞渲染”仅是指浏览器是否须要暂停网页的首次渲染，直至该资源准备就绪。

JavaScript 脚本

通过 <script> 标签能够向 html 插入 JavaScript 脚本。JavaScript 是一种运行在浏览器中的动静语言。

脚本的默认执行工夫

JavaScript 脚本在文档的哪儿插入，就在哪儿执行。当 HTML 解析器遇到一个 <script> 标签时，它会暂停构建 DOM，将控制权移交给 JavaScript 引擎；等 JavaScript 引擎运行结束，浏览器会从中断的中央复原 DOM 构建。

脚本与其余资源的依赖关系

JavaScript 不仅能够读取和批改 DOM 属性，还能够读取和批改 CSSOM 属性。所以造成了 JavaScript 与 DOM、CSSOM 之间很强的依赖关系，从而可能导致浏览器在解决以及在屏幕上渲染网页时呈现大幅提早。

• 脚本在文档中的地位很重要，倡议放在文档底部。
• JavaScript 执行过程中依赖 CSSOM，直至 CSSOM 就绪才会继续执行。

例如：运行一个 将 span 元素的 display 属性从 none 更改为 inline 的脚本

• 如果浏览器尚未实现 DOM 树的构建，而在此时运行脚本，不存在 span 标签，脚本运行失败。
• 如果浏览器尚未实现 CSSOM 树的下载和构建，而在此时运行脚本，就会呈现竞态问题。此时浏览器将提早脚本执行和 DOM 构建，直至其实现 CSSOM 的下载和构建。这样对性能不利。

扭转脚本默认行为的办法

• defer: 立刻下载，提早执行

加载和渲染后续文档元素的过程将和脚本的加载并行进行（异步），然而脚本的执行会在所有元素解析实现之后。脚本总会依照申明程序执行。

<script defer="defer" src="example.js"></script>

• async: 异步脚本

加载和渲染后续文档元素的过程将和脚本的加载与执行并行进行（异步），然而脚本加载后马上执行，会阻塞 HTML 的解析。脚本下载后立刻执行，不肯定依照申明程序执行。

<script async="async" src="example.js"></script>

async 和 defer 属性仅仅对外联脚本起作用，在 src 不存在时会被主动疏忽。

样式表

CSS 是阻塞渲染的资源，这意味着浏览器将不会渲染任何已解决的内容，直至 CSSOM 树构建结束。所以须要将它尽早、尽快地下载到客户端，以便缩短首次渲染的工夫。

优化样式表下载

通过应用媒体查问，咱们能够依据特定用例（比方显示或打印），也能够依据动静状况（比方屏幕方向变动、尺寸调整事件等）申明样式表，只有符合条件时，浏览器会优先下载并执行此 css 样式表。（无论是否有媒体查问，浏览器都会下载 CSS 资源，只不过不阻塞渲染的资源优先级较低）

<link href="style.css" rel="stylesheet">
<link href="style.css" rel="stylesheet" media="all">
<link href="portrait.css" rel="stylesheet" media="orientation:portrait">
<link href="print.css" rel="stylesheet" media="print">

• 第一个申明阻塞渲染，实用于所有状况。
• 第二个申明同样阻塞渲染:“all”是默认类型。第一个申明和第二个申明是等效的。
• 第三个申明具备动静媒体查问，将在网页加载时计算。依据网页加载时设施的方向，portrait.css 可能阻塞渲染，也可能不阻塞渲染。
• 第四个只在打印网页时利用，因而网页首次在浏览器中加载时，它不会阻塞渲染。

实践上来说，利用样式表不会更改 DOM 树，所以没有必要期待样式表并进行文档解析。然而如果脚本在文档解析阶段申请款式信息，过后还没有加载和解析款式，对于这种状况，不同的浏览器有不同的解决方案：Firefox 在样式表加载和解析的过程中，会禁止所有脚本。WebKit 仅当脚本尝试拜访的款式属性可能受尚未加载的样式表影响时，它才会禁止该脚本。

构建渲染树

渲染树包含了内容和款式：DOM 和 CSSOM 树联合为渲染树。为了结构渲染树，浏览器查看每个节点，从 DOM 树的根节点开始，并为每个可见节点增加其 CSSOM 规定。

• 渲染树只蕴含了可见内容。头部（通常）不蕴含任何可见信息，因而不会被蕴含在渲染树中。如果有元素上有 display: none;，它自身和其后辈都不会呈现在渲染树中。
• 渲染树是和 DOM 树是绝对应的，但并非一一对应。非可视化的 DOM 元素不会插入渲染树中。

8. 浏览器渲染页面

布局

渲染树构建实现后，进入布局阶段，布局为每个节点调配一个应呈现在屏幕上的确切坐标，决定了每个元素的宽和高，以及节点之间的相关性。

• 布局性能受 DOM 影响，节点数越多，布局工夫越长。

绘制

布局实现后，进入绘制阶段，将各个节点绘制在屏幕上，其包含文本、色彩、图片、边框、暗影等任何可视局部。

• 绘制能够将布局后的元素合成为多个层。将内容晋升到 GPU 上的层（而不是 CPU 上的主线程）能够进步首次绘制和重绘性能。

  一些特定的属性和元素能够实例化一个层，包含 <video>和 <canvas>，任何 CSS 属性为 opacity、3D 转换、will-change 的元素等。这些节点将与子节点一起绘制到它们本人的层上。

• 层的确能够进步性能，然而它以内存治理为代价，因而不应作为 web 性能优化策略的一部分适度应用。
• 如果屏幕上的绘图被分解成数层，须要进行合成。

合成

当文档的各个局部以不同的层绘制，互相重叠时，必须进行合成，以确保它们以正确的程序绘制到屏幕上，并正确显示内容。

像素管道

浏览器运行单个帧的渲染流水线，称为像素管道。如果其中的一个或多个环节执行工夫过长用户就会感觉卡顿。像素管道是像素绘制到屏幕上的关键步骤，有如下五个过程：

JS/CSS —> Style —> Layout —> Paint —> Composite

JS/CSS：JS/CSS 代码变动。
Style：从新计算款式
Layout：从新计算布局
Paint：绘制
Composite：合成

目前大多数设施的刷新率都是 60 FPS，如果浏览器在交互的过程中每帧都放弃在 60 FPS 左右，用户就不会感到卡顿。从数学角度而言，每帧的估算约为 16.7 毫秒（1000 毫秒 / 60 帧 = 16.66 毫秒 / 帧）。如果频繁执行 JS 或者 JS 执行工夫过长会导致，超出每帧绘制工夫，那么就会造成卡顿，例如监听页面滑动，动画等

性能最差的像素管道版本：重排（reflow）

扭转了元素的几何属性（例如宽度、高度等），那么浏览器将查看所有元素，布局计算后“主动重排”页面。任何受影响的局部都须要从新绘制，而且最终绘制的元素需进行合成。

重排进行了像素管道的每一步，性能受到较大影响。

性能个别的像素管道版本：重绘（replaint）

扭转元素的背景图片、文字色彩或暗影等（元素的几何尺寸和地位不变），不影响页面布局，则会跳过 Layout 布局，间接进行绘制与合成。

性能最佳的像素管道版本：防止 Layout 和 Paint

应用只会触发 composite 的 CSS 属性，就能够防止 Layout 和 Paint。

罕用的只会触发 composite 的 CSS 属性有：transform，opacity，pointer-events（是否响应鼠标事件）、perspective（透视成果）、perspective-origin（perspective 的灭点）、cursor（指针款式）、orphans（设置当元素外部产生分页时必须在页面底部保留的起码行数（用于打印或打印预览））、widows（设置当元素外部产生分页时必须在页面顶部保留的起码行数（用于打印或打印预览））。

通过 csstriggers.com 查看每种 CSS 属性的更改是否会触发 Layout/Paint/Composite。