前端性能 2021：网络、HTTP/2、HTTP/3

已发表: 2022-03-10
快速总结↬让2021年……快点！ 一份年度前端性能清单，包含您在当今 Web 上创建快速体验所需了解的所有内容，从指标到工具和前端技术。 自 2016 年以来更新。

目录

  1. 准备：计划和指标
  2. 设定切合实际的目标
  3. 定义环境
  4. 资产优化
  5. 构建优化
  6. 交付优化
  7. 网络、HTTP/2、HTTP/3
  8. 测试和监控
  9. 快速获胜
  10. 一切都在一页上
  11. 下载清单（PDF、Apple Pages、MS Word）
  12. 订阅我们的电子邮件通讯不要错过下一个指南。

网络、HTTP/2、HTTP/3

  1. 是否启用了 OCSP 装订？
    通过在您的服务器上启用 OCSP 装订，您可以加快 TLS 握手。 在线证书状态协议 (OCSP) 是作为证书撤销列表 (CRL) 协议的替代方案而创建的。 这两种协议都用于检查 SSL 证书是否已被吊销。

    但是，OCSP 协议不需要浏览器花时间下载然后搜索证书信息列表，因此减少了握手所需的时间。

  2. 您是否减少了 SSL 证书吊销的影响？
    在他关于“EV 证书的性能成本”的文章中，Simon Hearne 对常见证书进行了很好的概述，以及证书的选择可能对整体性能产生的影响。

    正如 Simon 所写，在 HTTPS 的世界中，有几种类型的证书验证级别用于保护流量：

    • 域验证(DV) 验证证书请求者是否拥有该域，
    • 组织验证(OV) 验证组织是否拥有该域，
    • 扩展验证(EV) 通过严格的验证来验证组织是否拥有该域。

    需要注意的是，所有这些证书在技术方面都是相同的。 它们仅在这些证书中提供的信息和属性上有所不同。

    EV 证书既昂贵又耗时，因为它们需要人工审核证书并确保其有效性。 另一方面，DV 证书通常是免费提供的——例如由 Let's Encrypt——一个开放的、自动化的证书颁发机构，它很好地集成到许多托管服务提供商和 CDN 中。 事实上，在撰写本文时，它为超过 2.25 亿个网站 (PDF) 提供支持，尽管它仅占页面的 2.69%（在 Firefox 中打开）。

    那么有什么问题呢？ 问题是EV 证书不完全支持上面提到的 OCSP 装订。 虽然装订允许服务器与证书颁发机构检查证书是否已被吊销，然后将此信息添加（“装订”）到证书中，而无需装订客户端必须完成所有工作，从而导致在 TLS 协商期间产生不必要的请求. 在连接不佳的情况下，这可能会导致显着的性能成本（1000 毫秒以上）。

    EV 证书对于 Web 性能来说并不是一个很好的选择，而且它们对性能的影响要比 DV 证书大得多。 为获得最佳 Web 性能，请始终提供 OCSP 装订的 DV 证书。 它们也比 EV 证书便宜得多，而且获得的麻烦更少。 好吧，至少在 CRLite 可用之前。

    显示在普通、压缩或两者的情况下沿站点 UDP 数据报的握手次数的图表
    压缩很重要：40-43% 的未压缩证书链太大而无法容纳 3 个 UDP 数据报的单个 QUIC 飞行。 （图片来源：）快速）（大预览）

    注意：使用 QUIC/HTTP/3，值得注意的是 TLS 证书链是一个可变大小的内容，它在 QUIC 握手中支配字节数。 大小在几百字节和超过 10 KB 之间变化。

    因此，在 QUIC/HTTP/3 上保持 TLS 证书很小很重要，因为大型证书会导致多次握手。 此外，我们需要确保证书被压缩，否则证书链将太大而无法容纳在单个 QUIC 飞行中。

    您可以在以下位置找到更多详细信息和指向问题和解决方案的方法：

    • EV 证书使 Web 变得缓慢且不可靠 作者 Aaron Peters，
    • SSL 证书吊销对 Web 性能的影响 by Matt Hobbs，
    • Simon Hearne 的 EV 证书的性能成本，
    • QUIC 握手是否需要快速压缩？ 通过帕特里克麦克马纳斯。
  3. 您采用 IPv6 了吗？
    因为我们的 IPv4 空间已经用完，而且主要移动网络正在迅速采用 IPv6（美国几乎达到了 50% 的 IPv6 采用阈值），所以最好将您的 DNS 更新为 IPv6，以防万一。 只需确保跨网络提供双栈支持——它允许 IPv6 和 IPv4 同时运行。 毕竟，IPv6 不是向后兼容的。 此外，研究表明，由于邻居发现 (NDP) 和路由优化，IPv6 使这些网站的速度提高了 10% 到 15%。
  4. 确保所有资产都通过 HTTP/2（或 HTTP/3）运行。
    随着谷歌在过去几年中推动更安全的 HTTPS 网络，切换到 HTTP/2 环境绝对是一项不错的投资。 事实上，根据 Web Almanac，64% 的请求已经在 HTTP/2 上运行。

    重要的是要了解 HTTP/2 并不完美并且存在优先级问题，但它得到了很好的支持； 而且，在大多数情况下，你会更好。

    提醒一句：HTTP/2 Server Push 正在从 Chrome 中删除，因此如果您的实现依赖于 Server Push，您可能需要重新访问它。 相反，我们可能正在研究 Early Hints，它已经作为实验集成在 Fastly 中。

    如果您仍然在 HTTP 上运行，最耗时的任务将是首先迁移到 HTTPS，然后调整您的构建过程以适应 HTTP/2 多路复用和并行化。 将 HTTP/2 引入 Gov.uk 是一个非常棒的案例研究，可以在此过程中通过 CORS、SRI 和 WPT 找到方法。 对于本文的其余部分，我们假设您正在切换到或已经切换到 HTTP/2。

图表显示了从 2016 年 1 月 2 日到 2020 年 10 月 1 日桌面和移动设备中 HTTP/2 请求的时间序列
根据 Web Almanac 的数据，到 2020 年底，64% 的请求都通过 HTTP/2 提供服务——距离其正式标准化仅 4 年。 （图片来源：Web Almanac）（大预览）
  1. 正确部署 HTTP/2。
    同样，通过 HTTP/2 提供资产可以受益于对迄今为止提供资产的方式进行部分改革。 您需要在打包模块和并行加载许多小模块之间找到一个很好的平衡点。 归根结底，最好的请求仍然是没有请求，但是，目标是在快速首次交付资产和缓存之间找到一个很好的平衡点。

    一方面，您可能希望避免完全连接资产，而不是将整个界面分解为许多小模块，将它们作为构建过程的一部分进行压缩并并行加载。 一个文件的更改不需要重新下载整个样式表或 JavaScript。 它还最大限度地减少了解析时间，并使各个页面的有效负载保持在较低水平。

    另一方面，包装仍然很重要。 通过使用许多小脚本，整体压缩会受到影响，并且从缓存中检索对象的成本会增加。 大包的压缩将受益于字典重用，而单独的小包则不会。 有标准的工作来解决这个问题，但现在还很遥远。 其次，浏览器尚未针对此类工作流程进行优化。 例如，Chrome 会触发与资源数量成线性关系的进程间通信 (IPC)，因此包含数百个资源将产生浏览器运行时成本。

    使用渐进式 CSS 加载的 HTML 代码
    要使用 HTTP/2 获得最佳结果，请考虑逐步加载 CSS，正如 Chrome 的 Jake Archibald 所建议的那样。

    不过，您可以尝试逐步加载 CSS。 事实上，in-body CSS 不再阻碍 Chrome 的渲染。 但是有一些优先级问题，所以它不是那么简单，但值得尝试。

    您可以使用 HTTP/2 连接合并，它允许您在受益于 HTTP/2 的同时使用域分片，但在实践中实现这一点很困难，而且通常不被认为是好的做法。 此外，HTTP/2 和子资源完整性并不总是有效。

    该怎么办？ 好吧，如果你在 HTTP/2 上运行，发送大约6-10 个包似乎是一个不错的折衷方案（对于旧版浏览器来说还不错）。 试验和测量以找到适合您网站的平衡点。

  2. 我们是否通过单个 HTTP/2 连接发送所有资产？
    HTTP/2 的主要优点之一是它允许我们通过单个连接将资产发送到线路上。 然而，有时我们可能做错了什么——例如有一个 CORS 问题，或者错误配置了crossorigin属性，所以浏览器将被迫打开一个新连接。

    要检查所有请求是否使用单个 HTTP/2 连接，或者是否配置错误，请启用 DevTools → Network 中的“Connection ID”列。 例如，在这里，所有请求共享相同的连接 (286) — 除了 manifest.json，它打开一个单独的连接 (451)。

在 Chrome 浏览器中打开的 DevTools 的屏幕截图
所有请求共享相同的 HTTP/2 连接 (286) — 除了 manifest.json，它打开一个单独的 (451)。 通过iamakulov。 （大预览）
  1. 您的服务器和 CDN 是否支持 HTTP/2？
    不同的服务器和 CDN（仍然）以不同的方式支持 HTTP/2。 使用 CDN 比较来检查您的选项，或快速查看您的服务器的性能以及您期望支持的功能。

    请参阅 Pat Meenan 关于 HTTP/2 优先级（视频）的令人难以置信的研究，并测试服务器对 HTTP/2 优先级的支持。 根据 Pat 的说法，建议启用 BBR 拥塞控制并将tcp_notsent_lowat设置为 16KB，以便 HTTP/2 优先级在 Linux 4.9 内核及更高版本上可靠地工作（感谢 Yoav！ ）。 Andy Davies 对跨浏览器、CDN 和云托管服务的 HTTP/2 优先级进行了类似的研究。

    使用它时，请仔细检查您的内核是否支持 TCP BBR，并在可能的情况下启用它。 它目前用于 Google Cloud Platform、Amazon Cloudfront、Linux（例如 Ubuntu）。

  2. 是否正在使用 HPACK 压缩？
    如果您使用的是 HTTP/2，请仔细检查您的服务器是否为 HTTP 响应标头实施 HPACK 压缩，以减少不必要的开销。 一些 HTTP/2 服务器可能不完全支持该规范，HPACK 就是一个例子。 H2spec 是一个很棒的（如果技术上非常详细）工具来检查它。 HPACK 的压缩算法令人印象深刻，而且它确实有效。
  3. 确保服务器上的安全性是防弹的。
    HTTP/2 的所有浏览器实现都通过 TLS 运行，因此您可能希望避免出现安全警告或页面上的某些元素不起作用。 仔细检查您的安全标头是否设置正确，消除已知漏洞，并检查您的 HTTPS 设置。

    此外，确保所有外部插件和跟踪脚本都是通过 HTTPS 加载的，跨站点脚本是不可能的，并且 HTTP 严格传输安全标头和内容安全策略标头都已正确设置。

  4. 您的服务器和 CDN 是否支持 HTTP/3？
    虽然 HTTP/2 为 Web 带来了许多显着的性能改进，但它也留下了相当多的改进空间——尤其是 TCP 中的线头阻塞，这在具有严重数据包丢失的慢速网络上很明显。 HTTP/3 正在彻底解决这些问题（文章）。

    为了解决 HTTP/2 问题，IETF 与 Google、Akamai 和其他公司一起，一直在研究一种新协议，该协议最近被标准化为 HTTP/3。

    Robin Marx 已经很好地解释了 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，一个记录 HTTP/3 和 QUIC 协议的协作努力。 有多种语言版本，也有 PDF 格式。
    • Daniel Stenberg 使用 HTTP/3 提升 Web 性能。
    • 与 Robin Marx 合作的 QUIC 学术指南介绍了 QUIC 和 HTTP/3 协议的基本概念，解释了 HTTP/3 如何处理线头阻塞和连接迁移，以及 HTTP/3 如何被设计为常青树（感谢Simon ！）。
    • 您可以在 HTTP3Check.net 上检查您的服务器是否在 HTTP/3 上运行。

目录

  1. 准备：计划和指标
  2. 设定切合实际的目标
  3. 定义环境
  4. 资产优化
  5. 构建优化
  6. 交付优化
  7. 网络、HTTP/2、HTTP/3
  8. 测试和监控
  9. 快速获胜
  10. 一切都在一页上
  11. 下载清单（PDF、Apple Pages、MS Word）
  12. 订阅我们的电子邮件通讯不要错过下一个指南。