Front-End Performance Checklist 2021[1]
https://www.smashingmagazine….
前端性能优化（一）：筹备工作 [2]
前端性能优化（二）：资源优化 [3]
前端性能优化（三）：构建优化 [4]
前端性能优化（四）：传输优化[5]
一、基本概念
1、Transport Layer Security (TLS)[6]
平安传输层协定，一种加密协议，是已弃用的安全套接字层（SSL）的后继协定，旨在提供计算机网络上的通信安全性。该协定的多种版本宽泛用于电子邮件，即时消息传递和 IP 语音等应用程序中，但它在 HTTPS 中作为平安层的应用依然是最常见。
TLS 是 IETF 规范，最早于 1999 年定义，以后版本是 TLS 1.3，于 2018 年 8 月定义。TLS 建设在网景公司开发的晚期 SSL 标准（1994、1995、1996）的根底上，用于在他们的网页浏览器增加 HTTPS 协定。
TLS 协定的次要目标是在两个或多个通信计算机应用程序之间提供隐衷和数据完整性。它运行在 Internet 的应用层中，它自身由两层组成：TLS 记录协定 和TLS 握手协定。
这里介绍次要介绍TLS 握手协定。
TLS 握手是启动应用 TLS 加密的通信会话的过程。在 TLS 握手期间，两个通信方替换音讯以互相确认，彼此验证，确立它们将应用的加密算法，并就会话密钥达成共识。TLS 握手是 HTTPS 工作原理的根底局部。
每当用户通过 HTTPS 导航到网站，并且浏览器首先开始查问网站的源站服务器时，都会进行 TLS 握手。每当其余任何通信应用 HTTPS（包含 API 调用和 HTTPS 上的 DNS 查问）时，也会产生 TLS 握手。
通过 TCP 握手关上 TCP 连贯后，将产生 TLS 握手。
在 TLS 握手过程中，客户端和服务器一起执行以下操作：
● 指定将要应用的 TLS 版本（TLS 1.0、1.2、1.3 等）● 决定将要应用哪些明码套件（一组用于建设平安通信连贯的加密算法。（加密算法是对数据执行的一组数学运算，以使数据显得随机。）宽泛应用的明码套件有多种，而且 TLS 握手的一个重要组成部分就是对这个握手应用哪一明码套件达成一致意见。）● 通过服务器的公钥和 SSL 证书颁发机构的数字签名来验证服务器的身份
● 生成会话密钥，以在握手实现后应用对称加密
2、Certificate revocation list (CRL)
证书撤消列表（CRL）正是顾名思义。这是一个很大的列表，其中蕴含已撤销证书的序列号。每个 CA 都会定期更新此列表，并且该列表与浏览器共享。能够设想，网络上有很多证书，因而将有很多被撤消的证书。因而，这个清单将持续增长。值得庆幸的是，过期的证书也不会被撤销，因为也没有必要，而且它们的序列号常常从 CRL 的文件中删除。
要应用该列表，浏览器必须残缺下载该列表，并循环浏览每个序列号以查看并查看他们正在查看的特定证书是否已被撤消。这会破费工夫和资源，这可能会减慢 TLS 握手的速度。如果浏览器无奈更新 CRL，会产生什么？是否只是假如已发送的证书尚未被撤消，而后依照失常的心愿进行解决，以确保它没有问题？（这称为“软失败”）。鉴于绝大多数证书没有被撤消，“软失败”的确是惟一可行的抉择。可怜的是，“软失败”策略具备重大的安全漏洞。“软故障”的解决形式齐全取决于所应用的浏览器。
3、Online Certificate Status Protocol (OCSP)
OCSP 是用于获取 X.509 数字证书的撤消状态的 Internet 协定。该协定合乎互联网标准规范，文档 RFC6960 对其进行了具体地形容。OCSP 协定的产生是用于在公钥基础设施（PKI）体系中 代替证书撤消列表（CRL）来查问数字证书的状态，OCSP 克服了 CRL 的次要缺点：必须常常在客户端下载以确保列表的更新。通过 OCSP 协定传输的音讯应用 ASN.1 的语义进行编码。音讯类型分为“申请音讯”和“响应音讯”，因而致 OCSP 服务器被称为 OCSP 响应端。
有些 Web 浏览器应用 OCSP 来验证 HTTPS 证书。
OCSP 与 CRL 两种协定均用于查看 SSL 证书是否已被撤消，与 CRL 相比：
● OCSP 响应蕴含的内容更少，缩小了网络累赘和客户端资源。● 因为 OCSP 响应须要解析的内容更少，客户端提供的用于解析音讯的库函数更简略。● OCSP 向发动响应方公开了一个特定的网络主机在特定时刻所应用的特定证书。因为 OCSP 并不强制加密该证书，因而信息可能被第三方拦挡。当用户申请证书的有效性时，OCSP 申请将发送到 OCSP 响应程序。这将应用受信赖的证书颁发机构查看特定证书，并以 ”good”，”revoked” 或 ”unknown” 作为 OCSP 响应返回。有效载荷很小，不须要遍历大量已撤销的证书序列。
OCSP 还存在许多问题：
● 查看须要与 OCSP 响应器的 TCP 连贯 - 这种网络开销须要破费工夫能力建设，并减少了 SSL 协商的提早。● OCSP 减慢了 TLS 握手的速度 -SSL 协商无奈齐全实现，直到收到 OCSP 响应器的响应为止。（之前提到过一个后备性能：“软失败”）● OCSP 响应程序有时可能会失败 - 如果浏览器没有响应会怎么？它能够自觉地信赖证书依然无效（“软失败”），也能够终止连贯（“硬失败”）。● 隐衷问题 - 通过与响应者分割，浏览器透露了用户正在拜访 CA 的网站。听起来像是一种潜在的办法，能够在网上跟踪他们不意识或抉择退出的人。在 Web 性能瀑布中，咱们能够看到 OCSP 响应破费的工夫，这能够看作是在连贯的 TLS 协商期间产生的一个或两个（或更多）申请。上面的图片显示了针对 PayPal.com 以 3G 速度运行的网页测试。OCSP 从新验证查看简直破费了整整一秒钟的工夫，超过了 TTFB 的一半用于响应，占整个响应的 42%。
这种成果在高提早连贯上更为显著。这里的等待时间不仅取决于网络连接，还取决于用户与 OCSP 服务之间的间隔。
OCSP 响应通常有效期为 7 天，因而基本上只有首次访问者能够感触到这种影响。
更多更粗疏的理解，请浏览The impact of SSL certificate revocation on web performance[8]。
4、OCSP stapling
OCSP 是一种办法，该办法容许客户端（如 Web 浏览器）通过与证书颁发机构查看证书是否被撤消来确保证书无效。OCSP stapling 容许 Web 服务器在服务器端执行此验证，并发送带有证书的验证。客户无需装订就能够进行验证。
OCSP 申请的问题在于每个用户的每个浏览器都必须收回这些申请（假如浏览器进行了查看）。听起来这是十分节约的策略。而 OCSP stapling 让网站服务器定期检查其本身证书的 OCSP 状态（该证书已加密签名，以便能够验证其有效性），而后，它能够在 TLS 握手期间将此查看的响应与证书同时发送到浏览器。这样，用户浏览器会在 TLS 握手期间获取所需的撤消信息，因而无需向 OCSP 响应者收回独自的申请。
可怜的是，OCSP stapling 不能解决所有问题。当服务器装订一个响应时，它只会将响应扩大到一个“级别”。因而，你能够装订叶子证书查看（站点证书），但不能装订整个链。因而，在申请中 root OCSP 响应者对两头证书的查看依然可见。值得注意的是，罕用的两头证书将在站点之间缓存，因而其影响可能不会听起来那么大。然而在 Firefox 中，两头证书的缓存会带来一些隐衷方面的隐患（目前还没有看到对于 Chrome 的任何相似报告）。
5、Head-of-Line blocking 队头阻塞（HOL 阻塞）[9]
对头阻塞就是当单个（慢）对象阻止其余 / 追随对象获得停顿时。这里的内容次要摘自[9]，举荐浏览。
一个很好的事实比喻是一家只有一个结账柜台的杂货店。一位购买大量商品的客户最终可能会耽搁他们前面的每个人，因为以先进先出的形式为客户提供服务。另一个例子是只有一条车道的高速公路。这条路上的一次车祸最终可能会长工夫梗塞整个通道。因而，即便是“头部”的单个问题也能够“阻塞”整个“线”。
HTTP/1.1 中的 HOL 阻塞
在这种状况下，浏览器通过 HTTP/1.1 申请了简略的 script.js 文件（绿色），图中显示了服务器对该申请的响应。咱们能够看到 HTTP 方面自身很简略：它只是在纯文本文件内容或“无效负载”之前间接增加一些文本“标头”（红色）。而后将标头 + 有效载荷向下传递到底层 TCP（橙色），以便理论传输到客户端。在这个例子中，假如咱们无奈将整个文件放入 1 个 TCP 数据包中，并且必须将其分成两局部。
留神：实际上，在应用 HTTPS 时，在 HTTP 和 TCP 之间还有另一个平安层，通常应用 TLS 协定。然而，为了分明起见，咱们在这里省略了它。
如果咱们还会申请 style.css，体现如下：
接收者应用 Content-Length 标头来理解每个响应的完结地位和另一个响应的开始地位（在咱们的简化示例中，script.js 有 1000 个字节，而 style.css 只有 600 个字节）。
设想一个场景，其中 JS 文件比 CSS 大得多（比方 1MB 而不是 1KB）。在这种状况下，CSS 必须在整个 JS 文件下载之前期待，即便它小得多，能够更早地解析 / 应用。更间接地将其可视化，应用 large_script.js 的数字 1 和 style.css 的数字 2，咱们将失去如下内容：
11111111111111111111111111111111111111122这个问题的“真正”解决方案是采纳多路复用。如果咱们能够将每个文件的无效负载切成较小的块或“块”，则能够在网上混合或“交织”这些块：为 JS 发送一个块，为 CSS 发送一个块，而后再次为 JS 发送一个块，依此类推。直到文件下载结束。应用这种办法，较小的 CSS 文件将更早下载（并可用），而只会提早较大的 JS 文件一点点。用数字可视化咱们会失去：
12121111111111111111111111111111111111111然而遗憾的是，因为协定假如的一些根本限度，这种多路复用在 HTTP/1.1 中是不可能的。要了解这一点，咱们甚至不须要持续查看大 vs 小资源场景，因为它曾经在咱们的示例中显示了两个较小的文件。思考下图，其中咱们为两个资源只插入了 4 个块：
这里的次要问题是 HTTP/1.1 是一个纯文本协定，它只在无效负载的后面附加标头。它没有进一步辨别单个（大块）资源。
让咱们用一个例子来阐明这一点，如果咱们尝试它会产生什么。在上图中，浏览器开始解析 script.js 的标头，并冀望追随 1000 字节的无效负载（内容长度）。然而，它只接管 450 个 JS 字节（第一个块），而后开始读取 style.css 的标头。它最终将 CSS 标头和第一个 CSS 块解释为 JS 的一部分，因为这两个文件的有效载荷和标头只是纯文本。更蹩脚的是，它在读取 1000 个字节后进行，最终停在第二个 script.js 块的两头地位。此时，它没有看到无效的新标头，必须抛弃 TCP 数据包 3 的其余部分。而后浏览器将它认为是 script.js 的内容传递给 JS 解析器，但因为它不是无效的 JavaScript，而失败：
function first() { return "hello";}
HTTP/1.1 200 OK
Content-Length: 600
.h1 {font-size: 4em;}
func同样，你能够说有一个简略的解决方案：让浏览器查找 HTTP / 1.1 {statusCode} {statusString} \ n 模式以查看何时启动新的标头块。这可能实用于 TCP 数据包 2，但会在数据包 3 中失败：浏览器如何晓得绿色 script.js 块在哪里完结，紫色 style.css 块开始在哪里？
这是 HTTP/1.1 协定设计形式的根本限度。如果你只有一个 HTTP/1.1 连贯，则必须始终残缺地传递资源响应，而后能力切换到发送新资源。如果较早的资源创立迟缓（例如从数据库查问中填充的动静生成的 index.html），或者如上所述，如果较早的资源很大，这可能会导致重大的 HOL 阻塞问题。
这就是浏览器开始为通过 HTTP/1.1 加载的每个页面关上多个并行 TCP 连贯（通常为 6 个）的起因。这样，申请能够散布在这些独自的连贯上，并且不再有 HOL 阻塞。也就是说，除非每页有超过 6 个资源……这当然很常见。这就是在多个域（img.mysite.com、static.mysite.com 等）和内容交付网络 (CDN) 上“分片”你的资源的做法的起因。当每个独自的域取得 6 个连贯时，浏览器将为每个页面加载总共关上多达 30 个 TCP 连贯。这无效，但有相当大的开销：建设一个新的 TCP 连贯可能很低廉（例如在服务器的状态和内存方面，以及设置 TLS 加密的计算）并且须要一些工夫（特地是对于 HTTPS 连贯，因为 TLS 须要本人的握手）。
基于 TCP 的 HTTP/2 中的 HOL 阻塞
HTTP/1.1 的 HOL 阻塞问题，其中一个大的或慢的响应会提早它前面的其余响应。这次要是因为该协定实质上是纯文本的，并且在资源块之间不应用分隔符。作为一种变通方法，浏览器会关上许多并行 TCP 连贯，这既不高效也不可扩大。
因而，HTTP/2 的指标十分明确：通过解决 HOL 阻塞问题，使咱们能够回到单个 TCP 连贯。换句话说：咱们心愿启用资源块的正确复用。这在 HTTP/1.1 中是不可能的，因为无奈分别一个块属于哪个资源，或者它在哪里完结而另一个开始。HTTP/2 通过在资源块之前事后增加称为帧的小管制音讯，十分优雅地解决了这个问题。这能够在下图看到：
HTTP/2 在每个块的后面搁置了一个所谓的数据帧。这些 DATA 帧次要蕴含两个要害的元数据。第一：以下块属于哪个资源。每个资源的“字节流”都被调配了一个惟一的编号，即流 ID。第二：上面的块有多大。该协定还有许多其余帧类型，下图还显示了 HEADERS 帧。这再次应用流 id 来批示这些标头属于哪个响应，以便标头甚至能够从它们的理论响应数据中分离出来。
它首先解决 script.js 的 HEADERS 帧，而后解决第一个 JS 块的 DATA 帧。从蕴含在 DATA 帧中的块长度，浏览器晓得它只延长到 TCP 数据包 1 的开端，并且它须要寻找从 TCP 数据包 2 开始的全新帧。它的确在那里找到了款式的 HEADERS。css。下一个 DATA 帧的流 ID (2) 与第一个 DATA 帧 (1) 不同，因而浏览器晓得这属于不同的资源。TCP 数据包 3 也是如此，其中数据帧流 ID 用于将响应块“多路合成”到其正确的资源“流”。
通过“构建”单个音讯，HTTP/2 因而比 HTTP/1.1 灵便得多。它容许通过交织资源块来在单个 TCP 连贯上以多路复用形式发送许多资源。它还解决了在第一个资源迟缓的状况下的 HOL 阻塞：服务器能够简略地在期待 index.html 的同时开始为其余资源发送数据，而不是期待生成数据库反对的 index.html。
HTTP/2 办法的一个重要后果是，咱们忽然也须要一种形式让浏览器与服务器通信，它心愿单个连贯的带宽如何跨资源分配。换句话说：应该如何“调度”或交织资源块。如果咱们再次用 1 和 2 将其可视化，咱们会看到对于 HTTP/1.1，惟一的抉择是 11112222（咱们称之为程序）。然而，HTTP/2 有更多的自在：
偏心复用（例如两个渐进式 JPEG）：12121212
加权复用（2 的重要性是 1 的两倍）：221221221
反向程序调度（例如 2 是一个要害的 Server Pushed 资源）：22221111
局部调度（流 1 停止且未残缺发送）：112222
TCP HOL blocking
HTTP/2 只解决了 HTTP 级别的 HOL 阻塞，咱们能够称之为“应用层”HOL 阻塞。然而，在典型的网络模型中，还有其余层须要思考。
HTTP 位于顶部，但首先由平安层的 TLS 反对，而后又由传输层的 TCP 承载。这些协定中的每一个都应用一些元数据包装来自其下层的数据。例如，TCP 数据包标头被增加到咱们的 HTTP(S) 数据中，而后将其放入 IP 数据包等中。这容许在协定之间进行绝对整洁的拆散。这反过来有利于它们的可重用性：像 TCP 这样的传输层协定不用关怀它正在传输的数据类型（可能是 HTTP，可能是 FTP，也可能是 SSH，谁晓得呢），IP 对 TCP 和 UDP 都能够失常工作。
尽管咱们和浏览器都晓得咱们正在获取 JavaScript 和 CSS 文件，但即便是 HTTP/2 不（须要）晓得这一点。它只晓得它正在解决来自不同资源流 ID 的块。然而，TCP 甚至都不晓得它正在传输 HTTP！TCP 所晓得的只是它曾经取得了一系列字节，它必须从一台计算机到另一台计算机。为此，它应用肯定最大大小的数据包，通常约为 1450 字节。每个数据包只跟踪它携带的数据的哪一部分（字节范畴），因而能够按正确的程序重建原始数据。
换句话说，两层之间的视角不匹配：HTTP/2 看到多个独立的资源字节流，而 TCP 只看到一个不通明的字节流。如上图的 TCP 数据包 3：TCP 只晓得它正在携带它正在传输的任何字节 750 到字节 1599。另一方面，HTTP/2 晓得数据包 3 中实际上有两个独立资源的两个块。（留神：实际上，每个 HTTP/2 帧（如 DATA 和 HEADERS）的大小也是几个字节。为简略起见，为了使数字更直观，这里没有计算额定的开销或此处的 HEADERS 帧。）
所有这些仿佛都是不必要的细节，直到你意识到 Internet 从根本上是一个不牢靠的网络。在从一个端点到另一个端点的传输过程中，数据包可能并且的确会失落和提早。这正是 TCP 如此受欢迎的起因之一：它在不牢靠的 IP 之上确保了可靠性。它通过从新传输失落数据包的副原本非常简单地做到这一点。
如何导致传输层的 HOL 阻塞呢？上图中：如果 TCP 数据包 2 在网络中失落，但数据包 1 和数据包 3 的确以某种形式达到，会产生什么？请记住，TCP 不晓得它正在承载 HTTP/2，它只晓得它须要按程序传送数据。因而，它晓得数据包 1 的内容能够平安应用并将这些内容传递给浏览器。然而，它看到数据包 1 中的字节和数据包 3 中的字节之间存在间隙（数据包 2 适宜），因而还不能将数据包 3 传递给浏览器。TCP 将数据包 3 保留在其接收缓冲区中，直到它接管到数据包 2 的重传正本（这至多须要往返服务器 1 次），而后它能够以正确的程序将这两个数据包传递给浏览器。换句话说：失落的数据包 2 是 HOL 阻塞数据包 3！
可能还不分明为什么这是一个问题，所以让咱们通过查看上图中 HTTP 层的 TCP 数据包外部理论内容来深刻开掘。咱们能够看到 TCP 数据包 2 仅携带流 id 2 的数据（CSS 文件），并且数据包 3 承载流 1（JS 文件）和流 2 的数据。在 HTTP 级别，咱们晓得这两个流是独立的，并且由 DATA 帧分明地描绘出。因而，实践上咱们能够完满地将数据包 3 传递给浏览器，而无需期待数据包 2 达到。浏览器将看到流 id 1 的 DATA 帧，并且可能间接应用它。只有流 2 必须被搁置，期待数据包 2 的重传。这将比咱们从 TCP 办法中取得的办法更无效，后者最终会阻塞流 1 和流 2。
另一个例子是数据包 1 失落，但收到 2 和 3 的状况。TCP 将再次阻止数据包 2 和 3，期待 1。然而，咱们能够看到，在 HTTP/2 级别，流 2（CSS 文件）的数据齐全存在于数据包 2 和 3 中，并且没有必须期待数据包 1 的重传。浏览器能够完满地解析 / 解决 / 应用 CSS 文件，但卡在期待 JS 文件的从新传输。
总之，TCP 不理解 HTTP/ 2 的独立流这一事实意味着 TCP 层 HOL 阻塞（因为失落或提早的数据包）也会导致 HOL 阻塞 HTTP！
如果咱们依然有 TCP HOL 阻塞，为什么还要应用 HTTP/2？次要起因是尽管网络上的确会产生丢包，但依然绝对较少。特地是在高速有线网络上，丢包率约为 0.01%。即便在最差的蜂窝网络上，在实践中也很少会看到高于 2% 的速率。这与数据包失落和抖动（网络中的提早变动）通常是突发的事实相结合。2%的数据包失落率并不意味着每 100 个失落的数据包中总会有 2 个数据包（例如 nr42 和 nr96 数据包）。在实践中，它可能更像是在总共 500 个失落的间断数据包中失落了 10 个（比方数据包编号为 255 到 265）。这是因为数据包失落通常是由网络门路中路由器中的内存缓冲区临时溢出引起的，这些缓冲区开始抛弃它们无奈存储的数据包。重要的是：TCP HOL 阻塞是实在存在的，但它对 Web 性能的影响比 HTTP/1.1 HOL 阻塞要小得多，简直能够保障每次都会命中，并且也会受到 TCP HOL 阻塞的影响！
正如咱们之前看到的，这实际上并不是它的理论工作形式，因为 HTTP/1.1 通常会关上多个连贯。这使得 HTTP/1.1 不仅能够缓解 HTTP 级别的问题，还能够缓解 TCP 级别的 HOL 阻塞。因而，在某些状况下，单个连贯上的 HTTP/2 很难比 6 个连贯上的 HTTP/1.1 更快甚至一样快。这次要得益于 TCP 的“拥塞管制”机制。这里就不多介绍了。
基于 QUIC 的 HTTP/3 中的 HOL 阻塞
目前为止咱们理解到的内容如下：
● HTTP/1.1 有 HOL 阻塞，因为它须要残缺地发送它的响应并且不能复用它们
● HTTP/2 通过引入批示每个资源块属于哪个“流”的“帧”来解决这个问题
● 然而，TCP 不晓得这些独自的“流”，只是将所有视为 1 个大流
● 如果一个 TCP 数据包失落，所有起初的数据包都须要期待它的重传，即便它们蕴含来自不同流的无关数据。TCP 具备传输层 HOL 阻塞。这里，咱们还需解决 TCP 的问题。解决方案很简略：咱们“只须要”让传输层晓得不同的、独立的流！这样，如果一个流的数据失落，传输自身就晓得它不须要阻止其余流。
只管该解决方案在概念上很简略，但在实践中施行起来却十分艰难。因为各种起因，不可能扭转 TCP 自身以使其具备流感知能力。抉择的代替办法是以 QUIC 模式实现全新的传输层协定。为了使 QUIC 能够在互联网上理论部署，它运行在不牢靠的 UDP 协定之上。然而，十分重要的是，这并不意味着 QUIC 自身也不牢靠！在很多方面，QUIC 应该被视为 TCP 2.0。它包含 TCP 的所有个性（可靠性、拥塞管制、流量管制、排序等）的最佳版本等等。QUIC 还齐全集成了 TLS（参见之前 HTTP 层级的图）并且不容许未加密的连贯。因为 QUIC 与 TCP 如此不同，这也意味着咱们不能仅仅在它之上运行 HTTP/2，这就是创立 HTTP/3 的起因。
咱们察看到让 QUIC 理解不同的流非常简单。QUIC 的灵感来自 HTTP/2 的成帧办法，并且还增加了本人的框架；在这种状况下是 STREAM 帧。之前在 HTTP/2 的 DATA 帧中的流 ID 当初被下移到 QUIC 的 STREAM 帧中的传输层。这也阐明了如果咱们想应用 QUIC，咱们须要一个新版本的 HTTP 的起因之一：如果咱们只是在 QUIC 之上运行 HTTP/2，咱们将有两个（可能抵触的）“流层”。HTTP/3 取而代之的是从 HTTP 层中删除了流概念（它的 DATA 帧没有流 ID）并从新应用底层的 QUIC 流。
留神：这并不意味着 QUIC 忽然晓得 JS 或 CSS 文件，甚至它正在传输 HTTP；像 TCP 一样，QUIC 应该是通用的可重用协定。它只晓得存在能够独自解决的独立流，而不用晓得其中到底是什么。
当初咱们理解了 QUIC 的 STREAM 帧，也很容易看出它们如何帮忙解决下图的传输层 HOL 阻塞：
与 HTTP/2 的数据帧十分类似，QUIC 的 STREAM 帧独自跟踪每个流的字节范畴。这与 TCP 造成比照，TCP 只是将所有流数据附加到一个大 blob 中。像以前一样，让咱们思考如果 QUIC 数据包 2 失落而 1 和 3 达到，将会产生什么状况。与 TCP 相似，数据包 1 中流 1 的数据能够间接传递给浏览器。然而，对于数据包 3，QUIC 能够比 TCP 更智能。它查看流 1 的字节范畴，发现此 STREAM 帧齐全跟在流 id 1 的第一个 STREAM 帧之后（字节 450 跟在字节 449 之后，因而数据中没有字节间隙）。它也能够立刻将该数据提供给浏览器进行解决。然而，对于流 id 2，QUIC 的确看到了一个间隙（它还没有收到字节 0-299，那些在失落的 QUIC 数据包 2 中）。它将始终放弃该 STREAM 帧，直到 QUIC 数据包 2 的重传达到为止。再次将其与 TCP 进行比照，它也将数据流 1 的数据阻止在数据包 3 中！
在数据包 1 失落但 2 和 3 达到的另一种状况下也会产生相似的状况。QUIC 晓得它已收到流 2 的所有预期数据，并将其传递给浏览器，仅保留流 1。咱们能够看到，对于这个示例，QUIC 的确解决了 TCP 的 HOL 阻塞！
不过，这种办法有几个重要的结果。最有影响的一个是 QUIC 数据可能不再以与发送时完全相同的程序传送到浏览器。对于 TCP，如果您发送数据包 1、2 和 3，它们的内容将齐全依照该程序传送到浏览器（这就是首先导致 HOL 阻塞的起因）。然而对于 QUIC，在下面第二个例子中，数据包 1 失落了，浏览器首先看到数据包 2 的内容，而后是数据包 3 的最初局部，而后（重传）数据包 1，而后是数据包 3 的第一局部. 换句话说：QUIC 在单个资源流中保留排序，但不再跨单个流。
这是须要 HTTP/3 的第二个也是能够说是最重要的起因，因为事实证明，HTTP/2 中的几个零碎十分依赖 TCP 跨流的齐全确定性排序。例如，HTTP/2 的优先级零碎通过传输扭转树数据结构布局的操作来工作（例如，将资源 5 增加为资源 6 的子项）。如果这些操作的利用程序与发送程序不同（当初能够通过 QUIC 实现），则客户端和服务器可能会以不同的优先级状态完结。HTTP/2 的头压缩零碎 HPACK 也会产生相似的事件。事实证明，将这些 HTTP/2 零碎间接适应 QUIC 十分艰难。因而，对于 HTTP/3，一些零碎应用齐全不同的办法。例如，QPACK 是 HTTP/3 的 HPACK 版本，容许在潜在的 HOL 阻塞和压缩性能之间进行自我抉择的衡量。HTTP/2 的优先级零碎甚至被齐全删除，可能会被 HTTP/3 的简化版本所取代。所有这一切都是因为，与 TCP 不同，QUIC 并不能齐全保障先发送的数据也先收到。
所有这些都在 QUIC 和从新构想的 HTTP 版本上工作，只是为了打消传输层 HOL 阻塞。
QUIC 和 HTTP/3 真的齐全打消了 HOL 阻塞吗？
QUIC 保留单个资源流内的排序。这意味着咱们依然有一种 HOL 阻塞的模式，即便在 QUIC 中：如果单个流中存在字节间隙，则流的前面局部仍会卡住，直到该间隙变为 填充。
QUIC 的 HOL 阻塞删除仅在有多个资源流同时处于活动状态时才无效。
真正的问题是：咱们多久会遇到多个并发流？
正如 HTTP/2 所解释的，这能够通过应用适当的资源调度程序 / 多路复用办法进行配置。流 1 和流 2 能够发送 1122、2121、1221 等，并且浏览器能够应用优先级零碎指定它心愿服务器遵循的计划（对于 HTTP/3 依然如此）。因而浏览器可能会说：嘿！我留神到此连贯失落大量数据包。我将让服务器以 121212 模式而不是 111222 模式向我发送资源。这样，如果 1 的单个数据包失落，2 依然能够获得停顿。然而，问题在于 121212 模式（或相似模式）对于资源加载性能通常不是最佳的。
咱们晓得，浏览器须要接管整个 JS 或 CSS 文件能力理论执行 / 利用它（尽管一些浏览器曾经能够开始编译 / 解析局部下载的文件，但他们依然须要期待它们实现能力理论应用它们）。然而，为这些文件大量复用资源块最终会提早它们：
With multiplexing (slower):
---------------------------
Stream 1 is only ready to be used here
▼
12121212121212121212121212121212
▲
Stream 2 is done downloading here
Without multiplexing/sequential (faster for stream 1):
------------------------------------------------------
Stream 1 is done downloading here and can be used much earlier
▼
11111111111111111122222222222222
▲
Stream 2 is still done here咱们有两个互相矛盾的最佳性能倡议：
● 从 QUIC 的 HOL 阻塞移除中获利：发送多路复用资源 (12121212)
● 为确保浏览器能够尽快解决外围资源，请按程序发送资源（11112222）很难说哪种办法更好，因为丢包模式很难预测。
正如咱们下面探讨的，数据包失落通常是突发的和成组的。这意味着咱们下面的 12121212 示例曾经过于简化了。下图给出了一个更实在的概览。在这里，咱们假如咱们在下载 2 个流（绿色和紫色）时有 8 个失落的数据包的单次突发：
在上图的第一行，咱们看到了（通常）对资源加载性能更好的程序状况。在这里，咱们看到 QUIC 的 HOL 阻塞打消的确没有多大帮忙：失落后接管到的绿色数据包无奈被浏览器解决，因为它们属于经验了失落的同一流。尚未收到第二个（紫色）流的数据，因而无奈对其进行解决。
第二行，其中（偶尔！）8 个失落的数据包都来自绿色流。这意味着最初收到的紫色数据包当初 – 能够 – 由浏览器解决。然而，如前所述，如果它是一个 JS 或 CSS 文件，如果有更多紫色数据到来，浏览器可能不会从中受害太多。所以在这里，咱们从 QUIC 的 HOL 阻塞移除中取得了一些益处（因为紫色没有被绿色阻塞），但可能以整体资源加载性能为代价（因为多路复用导致文件稍后实现）。
最初一行简直是最坏的状况。8 个失落的数据包散布在两个流中。这意味着两个流当初都被 HOL 阻塞：不是因为它们在期待对方，就像 TCP 的状况一样，而是因为每个流依然须要本人排序。
在这种状况下，HOL 阻塞预防和资源加载性能之间的衡量可能是值得的。然而，损失模式很难预测。它不会总是 8 个数据包。它们将不会总是雷同的 8 个数据包。
一方面，数据包失落在许多网络类型上通常绝对较少，无奈看到 QUIC 的 HOL 阻塞移除带来的太大影响。另一方面，无论应用 HTTP/2 还是 HTTP/3，逐包复用资源（上图的底行）对于资源加载性能都十分不利。
二、启用 OCSP stapling
基于基本概念咱们晓得，通过在服务器上启用 OCSP stapling，不须要浏览器花工夫下载而后在列表中搜寻证书信息，能够放慢 TLS 握手的速度。
stapling 容许服务器向证书颁发机构查看证书是否已被撤销，而后将此信息（”staple”）增加到证书中，而无需装订客户端必须实现所有工作，从而导致 TLS 协商期间产生不必要的申请。在连贯不良的状况下，这可能会导致显著的性能老本（1000ms +）。
三、缩小 SSL 证书撤消的影响
建设网站连贯的过程是一个简单的过程。首先，浏览器必须将域名转换为 IP 地址（DNS 查找），一旦找到，它就必须通过传输控制协议（TCP）与服务器协商连贯。最初，如果该站点是通过 HTTPS 服务的（约占 Web 申请的 83%），则浏览器须要与服务器协商加密连贯（通过传输层安全性（TLS）），TLS 的最初一个阶段波及数字证书。有三种次要类型的证书：
● Domain Validation (DV)：验证证书申请者领有该域
● Organisation Validation (OV)：验证组织有治理域的权力，以及作为法人实体存在的组织。● Extended Validation (EV)：验证领有对域管理权的控制权，是作为法人实体存在的组织，以及来自 CA 的验证代理还将进行验证查看。以上三个证书在技术上都是完全相同的。它们都是 X.509 公钥证书。惟一的区别是证书中蕴含的内容。如您所料，EV 证书将蕴含更多信息，并设置了不同的属性以区别于 DV / OV 证书。例如，EV 证书具备不同的主题，该主题标识法人实体而不是域。
证书颁发机构（CA）是受信赖的组织，一旦你（或你的公司）满足上述条件，就会颁发证书。它们是浏览器（用户）和服务器（网站）之间的受信赖的第三方。与服务器通信时，咱们要确保他们是他们所说的人。这是通过实现后面提到的验证过程之一来实现的。
DV 证书仅要求你证实本人领有域：应用 DNS 记录，重定向或 Web 服务器上的文件。此过程能够齐全自动化。EV 和 OV 证书须要一些手动干涉，并在续订时进行进一步查看。
EV 证书 [7] 低廉且耗时，因为它们须要人工查看证书并确保其有效性。另一方面，DV 证书通常是收费提供的，例如 由 Let’s Encrypt 提供 - 一个凋谢的主动证书颁发机构，已很好地集成到许多托管服务提供商和 CDN 中。
EV 证书的性能挑战是它们不能齐全反对 OCSP stapling。
EV 证书不是进步网络性能的现实抉择，与 DV 证书相比，它们对性能的影响更大。为了获得最佳的 Web 性能，请始终提供 OCSP stapling 的 DV 证书。它们也比 EV 证书便宜得多，并且省去了麻烦。至多要等到 CRLite 可用为止。
请留神，必须在 TLS 终结点端点（例如，防火墙或 CDN）上启用 OCSP stapling，能力在 DV 和 OV 证书上应用它。能够应用 Qualys SSL Server Test 来查看以后证书。
TLS 握手不是收费的[8]，这一点很重要。工夫和资源用于建设平安连贯。通常须要 2 -RTT 来建设此加密的隧道（取决于服务器设置），然而如果证书大小很大，则可能会更多。如果服务器反对 TLSv1.3，则在某些状况下能够在 1 -RTT 甚至 0 -RTT 中建设连贯。
例如，假如咱们的假如服务器应用 2 -RTT 建设此加密隧道，而咱们的用户应用的是 3G 连贯的挪动设施。3G 连贯的最小 RTT 可能约为 300 毫秒。因而，建设加密隧道至多须要 600 毫秒，这甚至没有思考 DNS 查找，连贯协商和任何网络拥塞。这就是在新的 HTTPS 世界中，传输控制协议（TCP）连贯的价格甚至更高的起因。值得庆幸的是，QUIC 已创立了一个新的应用用户数据报协定（UDP）的 Internet 传输协定，无望解决此问题。
四、适配 IPv6
因为 IPv4 地址空间行将耗尽，并且次要挪动网络正在迅速采纳 IPv6（美国采用率简直达到了 50%），因而最好将 DNS 更新为 IPv6 以被不时之需。IPv6 不向后兼容，最好确保对双协定栈网络的反对(dual-stack)—它容许 IPv6 和 IPv4 同时运行。此外，钻研表明，因为街坊发现 (NDP) 和路由优化，IPv6 使这些网站的速度进步了 10%-15%。
五、确保所有资源都在 HTTP/2(或 HTTP/3)上运行
1996 年公布的 HTTP/1.0 定义了基于文本的应用程序协定，容许客户端和服务器替换音讯以申请资源。每个申请 / 响应都须要一个新的 TCP 连贯，这引入了开销。TCP 连贯应用拥塞控制算法来最大化传输中的数据量。对于每个新连贯，此过程都须要工夫。这种“慢启动”意味着并非所有可用带宽都被立刻应用。
1997 年，HTTP/1.1 被引入，通过增加 ”keep-alives” 来容许 TCP 连贯重用，旨在升高连贯启动的总成本。随着工夫的推移，一直进步的网站性能预期导致须要并发申请。HTTP/1.1 只能在前一个响应实现后申请另一个资源。因而，必须建设额定的 TCP 连贯，以缩小放弃流动连贯的影响并进一步减少开销。
HTTP/2 于 2015 年公布，是一种基于二进制的协定，它引入了客户端和服务器之间双向流的概念。应用这些流，浏览器能够最佳地利用单个 TCP 连贯来同时多路复用多个 HTTP 申请 / 响应。HTTP/2 还引入了一个优先级计划来管制这种多路复用；客户端能够发出请求优先级的信号，容许在其余资源之前发送更重要的资源。
在过来几年中，随着谷歌向更加平安的 HTTPS 网站推动，切换到 HTTP/ 2 环境无疑是一项不错的投资。去年对 HTTP Archive 数据的分析表明，超过 50% 的申请应用了 HTTP/2，能够看出，2020 年持续线性增长；当初 64%的申请都通过 HTTP / 2 进行了解决。
http/ 2 基本上是无缝降级的，只有你的服务器反对并开启了，你的网站或利用无需做任何扭转。
留神，尽管 HTTP/2 在其正式标准中不要求应用加密，但每个实现 HTTP/2 的次要浏览器都只实现了对加密连贯的反对，并且没有次要浏览器致力于反对未加密连贯上的 HTTP/2。
（一）HTTP/ 2 要害概念
HTTP/2 具备以下要害概念：
● Binary format（二进制格局）● Multiplexing（多路复用）● Flow control（流量管制）● Prioritization（优先排序）● Header compression（头部压缩）● Push
二进制格局 示意将 HTTP/ 2 音讯包装为预约义格局的帧，从而使 HTTP 音讯更易于解析，并且不再须要扫描换行符。这对安全性更好，因为以前版本的 HTTP 存在许多破绽。这也意味着能够 多路复用 HTTP/2 连贯，不同流的不同帧能够在同一连贯上发送而不会互相烦扰，因为每个帧都蕴含流标识符及其长度。多路复用容许更无效地应用单个 TCP 连贯，而无需关上额定连贯的开销。现实状况下，咱们会为每个域关上一个连贯——甚至为多个域！
领有独自的流的确会带来一些复杂性以及一些潜在的益处。HTTP/2 须要 Flow Control 来容许不同的流以不同的速率发送数据，而以前，在任何工夫只有一个响应在传输，这是由 TCP 流量管制在连贯级别管制的。同样，Prioritization容许同时发送多个申请，但最重要的申请会占用更多带宽。
HTTP/ 2 引入了两个新概念：Header Compression和 HTTP/2 Push。出于平安起因，标头压缩 容许更无效地发送这些基于文本的 HTTP 标头，应用 HTTP/2 特定的 HPACK 格局。HTTP/2 Push容许发送多个响应来响应一个申请，使服务器可能在客户端意识到它须要资源之前“推送”资源。Push 应该解决性能变通方法，即必须将 CSS 和 JavaScript 等资源间接内联到 HTML 中，以避免在申请这些资源时阻止页面。应用 HTTP/2，CSS 和 JavaScript 能够保留为内部文件，但与初始 HTML 一起推送，因而它们立刻可用。后续的页面申请不会推送这些资源，因为它们当初会被缓存，因而不会节约带宽。
（二）HTTP/ 2 的问题
1、Head-of-Line blocking 队头阻塞（HOL 阻塞）[9]
咱们在基本概念曾经介绍了，这里就不说了。
2、推送
Push 试图防止期待浏览器 / 客户端下载 HTML 页面，解析该页面，而后才发现它须要额定的资源（例如样式表），而这些资源又必须被获取和解析以发现更多的依赖项（例如字体）。所有的工作和往返都须要工夫。通过服务器推送，实践上，服务器能够一次发送多个响应，防止额定的往返。
可怜的是，在应用 TCP 拥塞管制时，数据传输开始十分迟缓，以至于在屡次往返充沛进步传输速率之前，并非所有资产都能够推送。因为客户端解决模型尚未齐全达成统一，因而浏览器之间也存在实现差别。例如，每个浏览器都有不同的推送缓存实现。
另一个问题是服务器不晓得浏览器曾经缓存的资源。当服务器试图推送不须要的货色时，客户端能够发送一个 RST_STREAM 帧，然而当这产生时，服务器很可能曾经发送了所有数据。这节约了带宽，并且服务器失去了立刻发送浏览器理论须要的货色的机会。有人提议容许客户端将其缓存状态告诉服务器，但这些都存在隐衷问题。即便没有这个问题，如果没有正确应用推送，也会存在其余潜在问题。例如，推送大图像并因而阻止发送要害的 CSS 和 JavaScript，导致网站比基本不推送更慢！
事实证明，HTTP/ 2 推送比最后构想的更难无效应用。其中一些起因是 HTTP/ 2 推送工作形式的复杂性以及由此导致的施行问题。
3、优先级
因为 HTTP/2 响应能够拆分为许多独自的帧，并且能够多路复用来自多个流的帧，因而服务器交织和传送帧的程序成为要害的性能思考因素。一个典型的网站由许多不同类型的资源组成：可见内容（HTML、CSS、图像）、利用程序逻辑 (JavaScript)、广告、用于跟踪站点应用状况的剖析以及营销跟踪信标。理解浏览器的工作原理后，能够定义资源的最佳排序，从而带来最快的用户体验。最佳和非最佳之间的差别可能很大——性能晋升高达 50% 或更多！
HTTP/2 引入了优先级的概念，以帮忙客户端与服务器沟通它认为应该如何实现多路复用。每个流都被调配了一个权重（流应该调配多少可用带宽），可能还有一个父流（应该首先传递的另一个流）。因为 HTTP/2 优先级模型的灵活性，以后所有浏览器引擎都实现了不同的优先级策略，但没有一个是最佳的，这并不奇怪。
服务器端也存在问题，导致许多服务器执行优先级排序很差或基本没有执行。在 HTTP/1.x 的状况下，将服务器端发送缓冲区调得尽可能大，除了减少内存应用（用内存换 CPU）外，没有任何毛病，这是进步 web 服务器吞吐量的无效办法。这对于 HTTP/ 2 而言并非如此，如果有新的、更重要的资源的申请进来，在 TCP 发送缓冲区中的数据无奈从新确定优先级。对于 HTTP/ 2 服务器，最佳发送缓冲区大小是充分利用可用带宽所需的最小数据量。这容许服务器在收到更高优先级的申请时立刻响应。
大缓冲区混同（从新）优先级的问题也存在于网络中，它被称为“缓冲区收缩（bufferbloat）”。网络设备宁愿缓冲数据包，也不愿在呈现短暂突发时抛弃它们。然而，如果服务器发送的数据多于客户端的门路能够耗费的数量，则这些缓冲区会填满。这些曾经“存储”在网络上的字节限度了服务器提前发送更高优先级响应的能力，就像一个大的发送缓冲区一样。为了尽量减少缓冲区中保留的数据量，应应用最新的拥塞控制算法，例如 BBR。
4、负载平衡
应用 HTTP/1.1，大多数浏览器限度到给定源的并发连接数，通常 4 - 8 个，并且连贯必须在单个连贯上串行解决。这意味着 HTTP/1.1 浏览器无效地限度了对该源的并发申请数量，这意味着咱们用户的浏览器会限度对咱们服务器的申请并放弃咱们的流量顺畅。
而 HTTP/ 2 的多路复用，浏览器当初能够通过单个连贯同时发送所有 HTTP 申请。从 Web 客户端的角度来看，这很棒。实践上，客户端应该更快地取得它须要的所有资源，因为它不再须要在收回额定申请之前期待服务器的响应。然而，在实践中，多路复用大大增加了咱们服务器的压力。首先，因为他们接管的是大批量的申请，而不是更小、更扩散的批次。其次，因为应用 HTTP/2，申请都是一起发送的——而不是像 HTTP/1.1 那样交织发送——所以它们的开始工夫更靠近，这意味着它们都可能超时。
解决方案：
● 在负载均衡器上节流
最显著的解决方案是让负载均衡器限度对应用服务器的申请，因而从应用服务器的角度来看，流量模式相似于应用 HTTP/1.1 时的流量模式。所需的难度级别取决于你的根底构造。例如，AWS ALB 没有任何机制来限度负载均衡器的申请（至多目前没有）。即便应用 HAProxy 和 Nginx 等负载均衡器，正确地进行节流也很辣手。如果你的负载均衡器不反对限度，你依然能够在负载均衡器和应用程序服务器之间搁置一个反向代理，而后在其中进行限度。
● 从新构建应用程序以更好地解决尖峰申请
另一个（兴许更好）的抉择是更改应用程序，以便它能够解决来自承受 HTTP/ 2 流量的负载均衡器的流量。依据应用程序，这可能波及向应用程序引入或调整排队机制，以便它能够承受连贯，但一次只能解决无限数量的连贯。当咱们切换到 HTTP/2 时，咱们实际上曾经有了一个排队机制，然而因为之前的一些代码决策，咱们没有正确限度并发申请解决。如果你对申请进行排队，则应留神不要在客户端期待响应超时后处理申请——无需节约不必要的资源。
5、upgrade 头
Upgrade 头长期以来始终是 HTTP 的一部分。在 HTTP/1.x 中，Upgrade 容许客户端应用一种协定发出请求，但表明它反对另一种协定（如 HTTP/2）。如果服务器也反对提供的协定，它会以状态 101（替换协定）进行响应，并持续以新协定答复申请。如果没有，服务器会在 HTTP/1.x 中响应申请。服务器能够在响应中应用 Upgrade 头来宣传他们对不同协定的反对。
服务端申请头 upgrade 应用不正确：当服务端反对 HTTP/ 2 时，带上该头心愿应用更好的协定，比方在 HTTP/1.1 上应用 HTTP/2，然而因为 HTTP/ 2 须要运行在 HTTPS 上，应用该 header 十分无限。
更蹩脚的是，服务器谬误地发送了 upgrade 头。这可能是因为反对 HTTP/ 2 的后端服务器正在发送该头，而后仅反对 HTTP/1.1 的边缘服务器自觉地将其转发给客户端。当启用 mod_http2 但未应用 HTTP/ 2 时，Apache 会收回 upgrade 头，如果 nginx 实例位于 Apache 实例之前，即便 nginx 不反对 HTTP/2，nginx 实例也会欢快地转发此头。这种虚伪广告会导致客户端尝试（但失败）依照倡议应用 HTTP/2。
在关上 HTTP/ 2 之前，请确保你的应用程序能够解决这些差别。HTTP/ 2 的流量模式与 HTTP/1.1 不同，你的应用程序可能是专门为 HTTP/1.1 模式设计的，无论是否无意。HTTP/ 2 有很多益处，但它也有一些问题。
（三）QUIC 与 HTTP/3
QUIC 是一种运行在 UDP 之上的新传输协定。它提供了与 TCP 相似的性能，例如牢靠的按序交付和拥塞管制，以防止网络泛滥。
QUIC 通过将 HTTP/2 的流带入传输层并执行每个流的失落检测和重传来解决 HOL 阻塞问题。
HPACK 标头压缩已被 QPACK 取代，QPACK 容许手动调整压缩效率与 HOL 阻塞危险的衡量，并且优先级划分零碎已由更简略的优先级零碎取代。
QUIC 的另一个益处是，即便底层网络发生变化，它也可能迁徙连贯并使它们放弃活动状态。一个典型的例子就是所谓的“停车场问题”。假如您的智能手机已连贯到工作场合的 Wi-Fi 网络，而你刚刚开始下载大文件。当你来到 Wi-Fi 范畴时，你的手机会主动切换到全新的 5G 蜂窝网络。应用一般的旧 TCP，连贯会中断并导致中断。但 QUIC 更聪慧；它应用连贯 ID，对网络变动更强壮，并提供被动连贯迁徙性能，让客户端能够不间断地切换。
TLS 曾经用于爱护 HTTP/1.1 和 HTTP/2。然而，QUIC 与 TLS 1.3 深度集成，爱护 HTTP/3 数据和 QUIC 数据包元数据，例如数据包编号。以这种形式应用 TLS 能够进步最终用户的隐衷和安全性，并使继续的协定演变更加容易。联合传输和加密握手意味着连贯建设只须要一个 RTT，而 TCP 起码须要两个，最坏的状况是四个。在某些状况下，QUIC 甚至能够更进一步，将 HTTP 数据连同它的第一条音讯一起发送，这被称为 0-RTT。这些疾速的连贯设置工夫无望真正帮忙 HTTP/3 超过 HTTP/2。
（四）其余
正告：HTTP/2 服务器推送正在从 Chrome 中删除，因而如果你的实现依赖于服务器推送，你可能须要从新拜访它。相同，咱们可能会关注 Early Hints[10]，它们曾经作为试验集成到 Fastly 中。
六、正确地部署 HTTP/2
通过 HTTP/2 来提供资源服务能够从到目前为止对资源提供形式的局部革新中受害。你须要在合并模块和并行加载许多小模块之间找到一个很好的均衡。归根结底，最好的申请还是没有申请，然而，咱们的指标是在资源的疾速首次交付和缓存之间找到一个完满的均衡。
一方面，你可能心愿防止将资源文件全副串联起来，而不是将整个界面合成为许多小模块，将它们压缩为构建过程的一部分并并行加载。一个文件的更改不须要从新下载整个样式表或 JavaScript。它还能够 最大水平地缩小解析工夫，并使单个页面的无效负载较低。
另一方面，打包依然很重要。通过应用许多小脚本，会影响整体压缩。大包的压缩将受害于字典复用，而小的独立包则不会。
当咱们将资产宰割得太细时，咱们有时会错过一个毛病：压缩率。一般来说，较小的资产不会像较大的资产那样压缩。事实上，如果某些资产太小，某些服务器配置将防止齐全压缩它们，因为没有理论收益。
须要思考的不仅仅是 JavaScript。以 SVG 精灵为例。就这些资产而言，捆绑仿佛更为理智。特地是对于大型精灵集。针对 223 个图标的十分大的图标集进行了根本测试。在一次测试中，提供了图标集的精灵版本。在另一种状况下，将每个图标作为独立资产。在应用 SVG sprite 进行的测试中，图标集的总大小仅代表不到 10 KB 的压缩数据。在应用非捆绑资产的测试中，雷同图标集的总大小为 115 KB 的压缩数据。即便应用多路复用，在任何给定连贯上也无奈比 10 KB 更快地提供 115 KB 的服务。个性化图标的压缩不足以补救差别。
HTTP/2.0 具备先进的流量控制技术，如多路复用。这意味着您能够应用单个连贯下载数十个 JavaScript 文件，并并行下载它们。忽然，“独自的 JS 文件”办法的“毛病”列清空了。
随着越来越多的浏览器反对 HTTP/2.0（占寰球所有浏览器的 60% 以上），你会冀望反对将 JavaScript 打包抛在后面，转而间接提供 JavaScript 源文件。
对于反对 HTTP/2.0 的客户端，从基于包的计划转变为间接提供 JavaScript 源文件的计划，咱们发现：性能变得更糟。有两个起因：
● 因为压缩品质升高，咱们提供了更多字节
● 服务器有无法解释的提早服务数十个 JS 文件
除了减少带宽之外，不应用打包时咱们的网络服务器在服务数百个 JavaScript 源文件时的次优行为，会减少提早。
Chrome 会触发与资源数量成线性关系的 过程间通信（IPC）[11]，因而资源数量过大将导致浏览器运行时成本增加。
不过，你能够尝试 逐渐加载 CSS[12]。事实上，in-body CSS 不再阻止 Chrome 的渲染。然而有一些优先级问题，所以它不是那么简略，但值得尝试。
in-body CSS 体现如下：
● Chrome 和 Safari：发现 <link rel =“stylesheet”> 后立刻进行渲染，直到加载所有发现的样式表后才渲染。这通常会导致 <link> 上方未出现的内容被阻止。但 从 Chrome 69 开始，in-body CSS 不再阻止 Chrome 渲染。
● Firefox：<link rel=”stylesheet”> 在头部阻止渲染，直到所有发现的样式表都加载结束。注释中的 <link rel=”stylesheet”> 不会阻止出现，除非头部中的样式表曾经阻止出现。这可能会导致无款式内容 (FOUC) 闪动。因为 Firefox 并不总是阻止注释中的链接出现，因而咱们须要略微解决一下以防止 FOUC。值得庆幸的是，这非常简单，因为 <script> 阻止了解析，而且还期待加载待处理的样式表（脚本元素必须非空能力工作，一个空格就足够了。）：
<link rel="stylesheet" href="/article.css" />
<script></script>
<main>…</main>● IE/Edge：在加载样式表之前阻止解析器，但容许出现 <link> 上方的内容。
为什么 CSS 对性能如此重要？
● 浏览器在构建渲染树之前无奈渲染页面；● Render Tree 是 DOM 和 CSSOM 的组合后果；● DOM 是 HTML 加上任何须要对其操作的阻塞性 JavaScript；● CSSOM 是针对 DOM 利用的所有 CSS 规定。● 应用 async 和 defer 属性很容易使 JavaScript 非阻塞；● 使 CSS 异步要艰难得多；● 所以要记住的一个很好的教训法令是，你的页面只会以最慢的样式表的速度出现。确定开始渲染所需的所有款式（通常是首屏所有款式所需的款式），将它们内联到文档 <head> 的 <style> 标签中，并异步加载要害门路之外的残余样式表。
防止在 CSS 文件中应用 @import。如果应用它，运行门路如下：
● 下载 HTML；● HTML 申请 CSS；（这里是咱们心愿可能结构渲染树的中央，然而；）● CSS 申请更多的 CSS；● 构建渲染树。鉴于以下 HTML：
<link rel="stylesheet" href="all.css" />all.css 的内容是：
@import url(imported.css);咱们最终失去了这样的瀑布：
通过简略地将其展平为两个 <link rel=”stylesheet” /> 和零 @imports 即可解决这个问题。
另外，如果以后正在下载任何 CSS 时，在其之后的任何同步 <script> 都不会执行。
<link rel="stylesheet" href="app.css" />
<script>
var script = document.createElement('script');
script.src = "analytics.js";
document.getElementsByTagName('head')[0].appendChild(script);
</script>
它的瀑布流如下：
如果你的 <script>…</script> 块不依赖于 CSS，请将它们放在样式表上方。
总的来说就是：将任何非 CSSOM 查问 JavaScript 放在 CSS 之前；在 CSS 之后搁置任何 CSSOM 查问 JavaScript。
你能够防止应用 HTTP/2 连贯合并（不同浏览器对不同域名之间的连贯体现不统一），它容许你在从 HTTP/2 中受害的同时应用域分片，但在实践中实现这一点很艰难，并且通常不被认为是好的做法。此外，HTTP/2 和子资源完整性并不总是存在（有趣味的能够浏览HTTP/2 and Subresource Integrity don’t always get on[13]）。
该怎么办？好吧，如果你通过 HTTP/2 运行，发送大概 6 到 10 个包仿佛是一个不错的斗争（对于传统浏览器来说还不错）。试验和掂量，为你的网站找到适合的平衡点。
七、检测是否通过单个 HTTP/ 2 连贯发送所有资源
HTTP/2 的次要长处之一是它容许咱们通过单个连贯发送资源。然而，有时咱们可能做错了什么——例如 呈现 CORS 问题，或配置了 crossorigin 属性，因而浏览器将被迫关上新连贯。
要查看所有申请是否应用单个 HTTP/2 连贯，或者某些内容配置谬误，请启用 DevTools → Network 中的“Connection ID”列。例如，在这里，所有申请共享雷同的连贯 (286)——除了 manifest.json，它关上一个独自的连贯 (451)。
八、你的服务器和 CDN 反对 HTTP/2 吗？
不同的服务器和 CDN（依然）以不同的形式反对 HTTP/2。应用 CDN 比拟 [14] 查看你的选项，或疾速查看你的服务器的性能以及你能够预期反对的性能。
请参阅 Pat Meenan 对于 HTTP/2 优先级 [15]（ 视频 [16]）和 测试服务器对 HTTP/2 优先级的反对 [17] 的令人难以置信的钻研。依据 Pat 的说法，倡议启用 BBR 拥塞管制并将 tcp_notsent_lowat 设置为 16KB，以便 HTTP/2 优先级在 Linux 4.9 内核及更高版本上牢靠地工作（这能够在 /etc/sysctl.conf 中实现，如下）。Andy Davies 对跨浏览器、CDN 和云托管服务的 HTTP/2 优先级 [18] 进行了相似的钻研。
在此期间，请仔细检查你的内核是否反对 TCP BBR 并在可能的状况下启用它。它目前在 Google Cloud Platform、Amazon Cloudfront、Linux（如 Ubuntu）上应用。
// /etc/sysctl.conf
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
net.ipv4.tcp_notsent_lowat = 16384（一）浏览器和申请优先级
优先级计划：
● 依照在 HTML 中列出的程序加载类似的资源（脚本、图像、款式）。● 先加载 styles/CSS，因为在款式实现之前内容无奈显示。● 下一个加载阻塞脚本 /JavaScript 因为阻塞脚本会阻止浏览器挪动到 HTML 中的下一条指令，直到它们被加载和执行。● 加载图像和非阻塞脚本（异步 / 提早）。字体是一种非凡状况，因为须要它们在屏幕上绘制文本，但浏览器在理论筹备将文本绘制到屏幕之前不会晓得它须要加载字体。所以他们发现的很晚。因而，一旦它们被发现，它们通常会被赋予十分高的优先级，但直到加载过程的相当晚才晓得。
Chrome 还对以后浏览器视口中可见的图像（屏幕上可见的页面的一部分）利用了一些非凡解决。一旦利用了款式并布局了页面，它将为可见图像赋予更高的优先级，并按从大到小的程序加载它们。
（二）HTTP/1.x 优先级
应用 HTTP/1.x，到服务器的每个连贯一次只能反对一个申请（实际上无论如何，因为没有浏览器反对流水线），并且大多数浏览器一次最多会关上 6 个到每个服务器的连贯。浏览器保护它须要的内容的优先级列表，并在连贯可用时向每个服务器发出请求。当发现高优先级的内容时，它会被移到列表的后面，并在下一个连贯可用时申请它。
（三）HTTP/2 优先级
应用 HTTP/2，浏览器应用单个连贯，申请在连贯上作为独自的“流”进行多路复用。一旦发现申请，所有申请都会连同一些优先级信息一起发送到服务器，以使服务器晓得响应的首选程序。而后由服务器尽最大致力首先提供最重要的响应，而后是较低优先级的响应。当一个高优先级的申请进入服务器时，它应该立刻跳到低优先级的响应之前，甚至是两头响应。HTTP/2 实现的理论优先级计划容许并行下载，它们之间具备加权和更简单的计划。目前最简略的办法是将其视为资源的优先级排序。
大多数反对优先级排序的服务器都会发送具备可用数据的最高优先级响应的数据。然而，如果最重要的响应比低优先级响应的生成工夫更长，服务器可能最终会开始为低优先级响应发送数据，而后在高优先级响应可用时中断其流。这样，它能够避免浪费可用带宽和线头阻塞，而迟缓的响应会阻止其余所有。
在最佳配置中，在具备大量其余流的忙碌连贯上检索最高优先级资源的工夫与在空连贯上检索它的工夫雷同。实际上，这意味着服务器须要可能立刻中断所有其余响应的响应流，而无需额定的缓冲来提早高优先级响应（除了网络上传输中放弃连贯的最小数据量之外）充分利用）。
（四）Internet 上的缓冲区
适度缓冲简直是 HTTP/2 的克星，因为它间接影响服务器灵便响应优先级变动的能力。在服务器和浏览器之间存在数兆字节的缓冲并不常见，它通常比大多数网站都大。实际上，这意味着响应将依照它们在服务器上可用的程序传递。要害资源（例如文档的 <head> 中的字体或渲染阻止脚本）被兆字节的低优先级图像提早并不常见，对于终端用户来说，这意味着出现页面的提早数秒甚至数分钟。
（五）TCP 发送缓冲区
服务器和浏览器之间的第一层缓冲在服务器自身。操作系统保护一个 TCP 发送缓冲区，服务器将数据写入该缓冲区。一旦数据进入缓冲区，操作系统就会依据须要传送数据（在发送数据时从缓冲区中提取数据，并在缓冲区须要更多数据时向服务器发送信号）。大缓冲区还缩小了 CPU 负载，因为它缩小了服务器必须对连贯执行的写入量。
发送缓冲区的理论大小须要足够大，以保留已发送到浏览器但尚未确认的所有数据的正本，以防数据包失落且某些数据须要从新传输。缓冲区太小会阻止服务器将连贯带宽最大化到客户端（这是长距离下载迟缓的常见起因）。在 HTTP/1.x（以及许多其余协定）的状况下，数据以已知程序批量交付，并且将缓冲区调整为尽可能大除了内存应用减少之外没有其余毛病（用内存换 CPU）。减少 TCP 发送缓冲区大小是减少 Web 服务器吞吐量的无效办法。
对于 HTTP/2，大发送缓冲区的问题在于它限度了服务器在高优先级响应可用时调整它在连贯上发送的数据的灵活性。将响应数据写入 TCP 发送缓冲区后，它已超出服务器的管制范畴，并已承诺按写入程序进行传递。
HTTP/2 的最佳发送缓冲区大小是充分利用浏览器的可用带宽所需的起码数据量（每个连贯都不同，即便是单个连贯也会随工夫变动）。实际上，你会心愿缓冲区稍大一些，以便在服务器收到须要更多数据的信号和服务器写入额定数据之间留出一段时间。
（六）TCP_NOTSENT_LOWAT
TCP_NOTSENT_LOWAT 是一个套接字选项，容许配置发送缓冲区，使其始终为最佳大小加上固定的附加缓冲区。你提供了一个缓冲区大小 (X)，这是除了充分利用连贯所需的最小大小之外的额定大小，它会动静调整 TCP 发送缓冲区，使其始终比以后连贯拥塞窗口大 X 字节 . 拥塞窗口是 TCP 堆栈对须要在网络上传输以充分利用连贯的数据量的预计。
值 16,384 (16K) 已被证实是一个很好的均衡，其中连贯被充分利用，而额定的 CPU 开销能够忽略不计。这意味着在更高优先级的响应能够中断并传送之前，最多将缓冲 16KB 的低优先级数据。
（七）Bufferbloat 缓冲收缩
除了在服务器上缓冲之外，服务器和浏览器之间的网络连接还能够充当缓冲。对于网络设备来说，越来越广泛的状况是领有大缓冲区来排汇发送速度快于接管方耗费数据的数据。这通常称为缓冲收缩。tcp_notsent_lowat 它基于以后拥塞窗口，这是对所需的最佳运行数据量的预计，但不肯定是理论最佳运行数据量。
网络中的缓冲区有时可能十分大（兆字节），并且它们与 TCP 通常应用的拥塞控制算法的交互十分差。大多数经典的拥塞控制算法通过观察数据包失落来确定拥塞窗口。一旦数据包被抛弃，它就会晓得网络上有太多数据，并从那里开始缩减。应用 Bufferbloat 时，该限度被人为进步，因为缓冲区正在排汇超出连贯饱和所需的额定数据包。后果，TCP 堆栈最终计算出一个拥塞窗口，该窗口峰值比理论所需的大小要大得多，而后在缓冲区饱和并且数据包被抛弃并反复循环时降落到显著更小。
TCP_NOTSENT_LOWAT 应用计算的拥塞窗口作为它须要应用的发送缓冲区大小的基线，因而当底层计算错误时，服务器最终会失去比理论须要大得多（或小得多）的发送缓冲区。
能够将 Bufferbloat 视为游乐园中的一条线路。具体来说，其中一条线路是在排队的人很少的状况下间接上车，然而一旦线路开始建设，它们就能够让你通过波折的迷宫。靠近游乐设施，它看起来离游乐设施的入口不远，但事件可能会变得十分蹩脚。
Bufferbloat 十分类似。当数据进入网络的速度比链接能够反对的速度慢时，所有都很好而且很快。
一旦数据进入的速度超过它能够收回的速度，门就会被翻转，数据就会通过缓冲区的迷宫来保留它，直到它能够被发送。从入口到线路，看起来一切正常，因为网络正在排汇额定的数据，但这也意味着当你要发送高优先级数据时，曾经排汇的低优先级数据的队列很长，它别无选择，只能跟在队伍的前面：
（八）BBR 拥塞管制
BBR 是 Google 的一种新拥塞控制算法，它应用数据包提早的变动来模仿拥塞，而不是期待数据包抛弃。一旦它看到数据包须要更长的工夫来确认，它就会假如它曾经饱和连贯并且数据包曾经开始缓冲。因而，拥塞窗口通常十分靠近放弃连贯充分利用同时防止缓冲区收缩所需的最佳值。
BBR 也偏向于整体性能更好，因为它不须要丢包作为探测正确拥塞窗口的一部分，并且也偏向于对随机丢包做出更好的反馈。
回到游乐园线，BBR 就像让每个人携带一张他们用来测量等待时间的 RFID 卡。一旦等待时间看起来变慢，入口处的人就会加快他们让人们进入队列的速度。
通过这种形式，BBR 基本上能够使线路尽可能快地挪动，并避免应用迷宫式线路。当持有疾速通行证的客人达到（高优先级申请）时，他们能够跳入疾速挪动的队伍并间接跳上车。
TCP_NOTSENT_LOWAT 和 BBR 的组合将网络上的缓冲量减少到相对最小值，对应用 HTTP/2 的终端用户取得良好性能至关重要。 对于 NGINX 和其余没有实现本人的缓冲区限度的 HTTP/2 服务器来说尤其如此。
九、应用 HPACK 压缩
如果你正在应用 HTTP/2，请仔细检查你的服务器是否对 HTTP 响应头施行 HPACK 压缩 以缩小不必要的开销。某些 HTTP/2 服务器可能不齐全反对该标准，例如 HPACK。H2spec 是一个很好的（用于 HTTP/2 实现的一致性测试工具）工具来查看它。HPACK 的压缩算法十分令人印象粗浅，而且很无效。
HPACK 压缩
HTTP/2 反对一种新的专用头压缩算法，称为 HPACK。它应用这三种压缩办法：
● 动态字典：蕴含 61 个罕用头字段的预约义字典，其中一些具备预约义值。● 动静字典：连贯期间遇到的理论头列表。这本词典的大小无限，当增加新条目时，旧条目可能会被逐出。● 霍夫曼编码：动态霍夫曼编码可用于编码任何字符串：名称或值。此代码是专门为 HTTP 响应 / 申请头计算的 - ASCII 数字和小写字母被赋予较短的编码。可能的最短编码长度为 5 位，因而可实现的最高压缩比为 8:5（或小 37.5%）。当 HPACK 须要以 name:value 格局对头进行编码时，它会首先查看动态和动静词典。如果存在全名：值，它将简略地援用字典中的条目。这通常须要一个字节，在大多数状况下两个字节就足够了，整个头以单个字节编码。
当 HPACK 无奈匹配字典中的整个头时，它会尝试查找具备雷同名称的头。大多数风行的头名称都存在于动态表中，例如：content-encoding，Cookie 和 etag。其余的可能是反复的，因而呈现在动静表中。例如，Cloudflare 为每个响应调配一个惟一的 cf-ray 标头，只管此字段的值始终是不同的，但能够重复使用该名称。
如果找到了名称，则在大多数状况下能够再次用一或两个字节示意，否则名称将应用原始编码或霍夫曼编码进行编码：两者中较短的一个。头的值也是如此。
咱们发现仅应用 Huffman 编码就能够节俭近 30% 的头大小。
只管 HPACK 进行字符串匹配，但攻击者要找到标头的值，他们必须猜想整个值，而不是应用 DEFLATE 匹配可能的渐进办法，容易受到 CRIME 的攻打。
HPACK 为 HTTP 申请头提供的收益比响应头更大。因为申请头中的反复水平更高，申请头失去更好的压缩。
十、确保你服务器的安全性是“无懈可击”的
HTTP/2 的所有浏览器实现都在 TLS 上运行，因而你可能心愿防止平安正告或页面上的某些元素不起作用。仔细检查你的平安头是否设置正确（应用securityheaders.com），打消已知破绽（如：open source software (OSS)，应用Snyk[19]），并查看你的 HTTPS 设置（应用www.ssllabs.com/ssltest/）。
此外，请确保所有内部插件和跟踪脚本都是通过 HTTPS 加载的，跨站点脚本是不可能的，并且 HTTP 严格传输平安头 和内容安全策略头 均已正确设置。
（一）HTTP 严格传输平安头
HTTP 严格传输平安（也称为 HSTS）是一种可选的平安加强性能，由 Web 应用程序通过应用非凡响应头指定。一旦受反对的浏览器收到此头，该浏览器将阻止通过 HTTP 向指定域发送任何通信，而是通过 HTTPS 发送所有通信。它还能够避免浏览器上的 HTTPS 点击提醒。
该标准已于 2012 年底由 IETF 作为 RFC 6797（HTTP 严格传输平安 (HSTS)）公布。
（二）内容安全策略头
新的 Content-Security-Policy HTTP 响应标头通过申明许加载哪些动静资源来帮忙升高古代浏览器上的 XSS 危险。
尽管它次要用作 HTTP 响应标头，但你也能够通过元标记利用它。
留神：家喻户晓，同时领有 Content-Security-Policy 和 X-Content-Security-Policy 或 X-Webkit-CSP 会导致某些版本的浏览器出现意外行为。请防止应用已弃用的 X-* 标头。
想理解更多，可浏览Content Security Policy Reference[20]，具体介绍了有哪些可配置的，以及解释。
十一、你的服务器和 CDN 反对 HTTP/ 3 吗？
尽管 HTTP/2 为 Web 带来了许多显着的性能改良，但它也留下了相当多的改良空间——尤其是 TCP 中的队头阻塞，这在具备大量数据包失落的慢速网络上很显著。HTTP/3 正在彻底解决这些问题。
为了解决 HTTP/2 问题，IETF 与 Google、Akamai 和其余公司一起，始终致力于开发一种新协定，该协定最近已标准化为 HTTP/3。
HTTP/3 在性能方面与 HTTP/2 十分类似，但在底层，它的工作形式十分不同。HTTP/3 提供了许多改良：更快的握手、更好的加密、更牢靠的独立流、更好的加密和流量管制。一个显著的区别是 HTTP / 3 应用 QUIC 作为传输层，QUIC 数据包封装在 UDP 图的顶部，而不是 TCP。
QUIC 将 TLS 1.3 齐全集成到协定中，而在 TCP 中它是分层的。在典型的 TCP 堆栈中，咱们有一些往返工夫的开销，因为 TCP 和 TLS 须要进行各自独立的握手，然而应用 QUIC，它们能够在一次往返中组合并实现。因为 TLS 1.3 容许咱们为后续连贯设置加密密钥，从第二个连贯开始，咱们曾经能够在第一次往返中发送和接管应用层数据，这称为“0-RTT”。
此外，HTTP/2 的头压缩算法及其优先级零碎被齐全重写。此外，QUIC 反对通过每个 QUIC 数据包头中的连贯 ID 将连贯从 Wi-Fi 迁徙到蜂窝网络。大多数实现是在用户空间实现的，而不是内核空间（就像 TCP 那样），所以咱们应该期待协定在将来一直倒退。
这所有都会有很大的不同吗？可能是的，尤其是对挪动设施上的加载工夫有影响，而且还会影响咱们向最终用户提供资源的形式。在 HTTP/2 中，多个申请共享一个连贯，在 HTTP/3 中申请也共享一个连贯但独立流，因而抛弃的数据包不再影响所有申请，只会影响一个流。
这意味着，尽管应用一个大型 JavaScript 包，当一个流暂停时，资产的解决会减慢，但当多个文件并行流 (HTTP/3) 时，影响将不那么显著。所以打包依然很重要。
HTTP/3 仍在进行中。Chrome、Firefox 和 Safari 曾经实现了。一些 CDN 曾经反对 QUIC 和 HTTP/3。2020 年末，Chrome 开始部署 HTTP/3 和 IETF QUIC，实际上所有 Google 服务（Google Analytics、YouTube 等）都曾经在 HTTP/3 上运行。LiteSpeed Web Server 反对 HTTP/3，但 Apache、nginx 或 IIS 尚不反对，但它可能会在 2021 年迅速扭转。
底线：如果你能够抉择在服务器和 CDN 上应用 HTTP/3，那么这样做可能是一个十分好的主见。次要益处将来自同时获取多个对象，尤其是在高提早连贯上。咱们还不确定，因为在该畛域没有进行太多钻研，但初步后果十分有心愿。
如果您想更深刻地理解协定的细节和劣势，能够从以下几个很好的终点进行查看：
● HTTP/3 Explained[21]：记录 HTTP / 3 和 QUIC 协定，有多种语言版本，也有 PDF 格局。● 与 Daniel Stenberg 一起应用 HTTP/3 晋升 Web 性能[22]。● An Academic's Guide to QUIC with Robin Marx[23] 介绍了 QUIC 和 HTTP/3 协定的基本概念，解释了 HTTP/3 如何解决队头阻塞和连贯迁徙，以及 HTTP/3 如何设计为 evergreen。● HTTP3Check.net[24]：查看你的服务器是否在 HTTP/3 上运行。欢送关注我的集体公众号：
参考文献：
Front-End Performance Checklist 2021[1]：https://www.smashingmagazine….
前端性能优化（一）：筹备工作 [2]：https://mp.weixin.qq.com/s/QD…
前端性能优化（二）：资源优化 [3]：https://mp.weixin.qq.com/s/Yb…
前端性能优化（三）：构建优化 [4]：https://mp.weixin.qq.com/s/sp…
前端性能优化（四）：传输优化[5]：https://mp.weixin.qq.com/s/Iq…
Transport Layer Security[6]：https://en.wikipedia.org/wiki…
The Performance Cost of EV Certificates[7]：https://simonhearne.com/2020/…
The impact of SSL certificate revocation on web performance[8]：https://nooshu.github.io/blog…
Last-Mile Latency：https://hpbn.co/primer-on-lat…
Head-of-Line blocking[9]：https://github.com/rmarx/holb…
103 Early Hints[10]：https://www.fastly.com/blog/b…
inter-process communications (IPCs) [11]：https://www.chromium.org/deve…
CSS and Network Performance[12]：https://csswizardry.com/2018/…
HTTP/2 and Subresource Integrity don’t always get on[13]：https://nooshu.github.io/blog…
CDN Comparison[14]：https://cdncomparison.com/
Optimizing HTTP/2 prioritization with BBR and tcp_notsent_lowat[15]：https://blog.cloudflare.com/h…
HTTP/2 Prioritization – Velocity 2019[16]：https://www.youtube.com/watch…
http2priorities[17]：https://github.com/pmeenan/ht…
Tracking HTTP/2 Prioritization Issues[18]：https://github.com/andydavies…
Snyk[19]：https://www.smashingmagazine….
Content Security Policy Reference[20]：https://content-security-poli…
HTTP/3 Explained[21]：https://http3-explained.haxx.se/
Leveling Up Web Performance With HTTP/3[22]：https://cloudflare.tv/event/2…
An Academic’s Guide to QUIC[23]：https://www.youtube.com/watch…
HTTP3Check.net[24]：https://http3check.net/