作者：马雪琴、朱志玉
转发链接: https://mp.weixin.qq.com/s/rPnRfsIlGwAZIm2yNAdUzg
本文是性能优化清单系列第六篇，也是最后一篇，可以先看看前边的文章：
网络与 http/2
53. 启用 OCSP stapling 了吗？
通过在服务器上启用 OCSP stapling[2]，可以加快 TLS 握手的速度。联机证书状态协议（OCSP）被创建为证书吊销列表（CRL）协议的替代品。两种协议都用于检查 SSL 证书是否已被吊销。但是，OCSP 协议不需要浏览器花时间下载和搜索证书信息列表，因此减少了握手所需的时间。
54. 适配 IPv6 了吗?
由于IPv4 地址空间即将耗尽[3]，并且主要的移动网络都在迅速采用 IPv6(美国的 IPv6采用率[4]已经达到 50%)，所以最好将DNS 更新到 IPv6[5] 以备不时之需。IPv6 不向后兼容，最好确保对双协议栈网络的支持(dual-stack)——允许 IPv6 和 IPv4 同时运行。此外， 研究表明[6] ，由于邻居发现(NDP)和路由优化，IPv6 使这些网站的速度提高了 10 - 15%。
55. 确保所有资源都在 HTTP/2 上运行。
在过去几年中，随着谷歌向更加安全的 HTTPS 网站推进[7]，切换到 HTTP/2 环境[8] 无疑是一项不错的投资。实际上，根据 Web Almanac，54%的请求已经在 HTTP/2 上运行了[9]。
很重要的一点是要理解HTTP/2 不是完美的，[10]并且存在优先级问题[11]，但是它 得到了很好的支持[12]。而且，在大多数情况下，您最好使用它。
如果您仍在使用 HTTP，首先要耗费大量时间迁移到 HTTPS[13]，然后调整构建过程来适应 HTTP/2 复用和并行化。对于本文的其余部分，我将假定您正在切换到或已经切换到 HTTP/2。
根据 Web Almanac，2019 年底有 54%的请求是通过 HTTP/2 服务的，而这距离正式标准化只有 4 年时间。(图片来源:*Web Almanac*[14])
56. 正确地部署 HTTP/2。
同样，通过 HTTP/2 来提供资源服务[15]可以从到目前为止对资源提供方式的部分改造中受益。您需要在合并模块和并行加载许多小模块之间找到一个很好的平衡。归根结底，最好的请求还是没有请求[16]，然而，我们的目标是在资源的快速首次交付和缓存之间找到一个完美的平衡。
一方面，您可能希望避免将资源文件全部串联起来，而不是将整个界面分解为许多小模块，将它们压缩为构建过程的一部分并并行加载。一个文件的更改不需要重新下载整个样式表或 JavaScript。它还可以最大程度地减少解析时间[17]，并使单个页面的有效负载较低。
另一方面，打包仍然很重要[18]。通过使用许多小脚本，
会影响整体压缩。大包的压缩将受益于字典复用，而小的独立包则不会。目前还没有标准方案来解决这个问题。其次，浏览器尚未针对此类工作流程进行优化。例如，Chrome 会触发与资源数量成线性关系的进程间通信[19]（IPC），因此资源数量过大将导致浏览器运行时成本增加。
pic
为了达到 HTTP/2 的最佳效果，请考虑渐进式加载 CSS[20]，这是 Chrome 的 Jake Archibald 建议的。
您可以尝试渐进式加载 CSS[21]。实际上，body 内部的 CSS 不再阻止 Chrome 的渲染[22]。但是存在一些优先级问题，[23]因此它不是那么简单，但是值得尝试。
您可以不使用HTTP/2 连接合并[24]，它允许您受益于 HTTP/2 的同时使用域分片，但是在实践中很难做到这一点，而且一般来说，这不是一个好习惯。同样，HTTP/2 和子资源完整性(Subresource Integrity)并不总是起作用[25]。
怎么办？好吧，如果您使用的是 HTTP/2，发送大约6-10 个软件包似乎是一个不错的折中方案（对于旧版浏览器来说也不算太糟）。进行实验和测量为您的网站找到适合的平衡。
57. 您的服务器和 CDN 支持 HTTP/2 吗？
不同的服务器和 CDN 对 HTTP/2 的支持不同。使用
TLS 快乐吗？[26]检查您的选项，或快速检查服务器的运行情况以及您希望支持的功能。请参考 Pat Meenan 对 HTTP/2 优先级[27]（视频[28]）的极好的研究，并测试服务器对 HTTP/2 优先级的支持[29]。根据 Pat 的说法，建议启用 BBR 拥塞控制并将 tcp_notsent_lowat 设置为 16KB，以便 HTTP/2 优先级在 Linux 4.9 内核和更高版本上可靠地工作（感谢，Yoav！）。Andy Davies 对跨浏览器、CDN 和云托管服务的[30] HTTP/2 优先级进行了类似的研究。
运行时，请仔细检查您的内核是否支持 TCP BBR，并在可能的情况下启用它。它目前被用于 Google Cloud Platform，Amazon Cloudfront[31]，Linux[32]（例如Ubuntu[33]）上。
58. 您的服务器和 CDN 是否支持基于 QUIC 的 HTTP（HTTP/3）？
如果您喜欢冒险或前沿，则可能要检查服务器或 CDN 是否支持基于 QUIC 的 HTTP[34]（也称为HTTP/3）。尽管 HTTP/2 进行了重大改进，但是在网络速度慢或不可靠（大量数据包丢失）的情况下，它的性能并不是特别好。
为了解决这个问题，Google 一直在研究Google QUIC[35]，这是 Chrome 目前用于许多 Google 服务的协议。然后，Google 在 2015 年将许多学习成果带到了 IETF，IETF现在正在标准化[36]。
QUIC 和 HTTP / 3 越来越好，越来越“无懈可击”：具有更快的握手，更好的加密技术，更可靠的独立流，如果客户机与服务器之间曾经有连接，则使用 0-RTT。但是，这会占用大量 CPU 资源（对于相同带宽，CPU 使用量是 2-3 倍），UDP 堆栈未优化，并且硬件和 TLS 层存在一些未解决的问题。
HTTP / 3 有望在2020 年初[37]作为标准发布。Chrome 和 Safari 确认他们已经有了内部实现，并且在 Chrome Canary[38]和Firefox Nightly 中提供了 HTTP/3[39]。一些CDN 已经支持 QUIC 和 HTTP / 3[40]。Apache、nginx 或 IIS 都还不支持它，但到 2020 年可能会有所改变。
pic
TLS 快乐吗？[41]您可以在切换到 HTTP/2 时检查服务器和 CDN 的选项。
59. 正在使用 HPACK 压缩吗？
如果您使用的是 HTTP/2，请仔细检查您的服务器是否为 HTTP 响应标头实现了 HPACK 压缩[42]，以减少不必要的开销。由于 HTTP /2 服务器相对较新，因此它们可能不完全支持该规范，HPACK 就是一个例子。H2spec[43]是一个很棒的（如果技术上非常详细）用于检查的工具[44]。HPACK 的压缩算法令人印象深刻[45]，而且很有效[46]。
60. 确保您服务器的安全性是“无懈可击”的。
所有浏览器的 HTTP/2 实现都基于 TLS，因此您可能要避免安全警告或页面上的某些元素不起作用。仔细检查您的安全标头设置是否正确[47]，消除已知漏洞[48] 并检查 HTTPS 设置[49]。另外，请确保所有外部插件和跟踪脚本都通过 HTTPS 加载，不能有跨站点脚本，并且HTTP 严格传输安全头[50]和内容安全策略头[51]都已设置正常。
测试和模拟
61. 您优化了审计工作流程吗？
这听起来可能不是什么大事，您轻而易举就可以设置正确，并可能因此节省大量的测试时间。考虑使用 Tim Kadlec 的 Alfred 工作流[52]来提交一个测试到 WebPageTest 的公共实例。事实上，WebPageTest 有许多模糊的特性，所以请花点时间学习如何阅读 WebPageTest 瀑布视图图表[53]，以及如何阅读 WebPageTest 连接视图图表[54]，以更快地诊断和解决性能问题。
你也可以用一个谷歌电子表格驱动 WebPageTest[55]，并可以使用 Lighthouse CI 把可访问性，性能和搜索引擎优化分数[56]导入到你的 Travis 设置，或直接导入 Webpack[57] 。
如果您需要快速调试某些东西，但是您的构建过程却看起来非常慢，那么请记住，“对于大多数 JavaScript 来说，在压缩代码中去除空白和符号错误占了减少大小的 95%的工作[58]。”你可以简单地禁用压缩来将构建速度提高 3 到 4 倍。”
使用 with Lighthouse CI 将可访问性、性能以及 SEO 得分 集成到 Travis 设置中，就能给所有开发者表示出新特性带来的性能影响
62. 您在代理浏览器和传统浏览器中测试过吗?
在 Chrome 和 Firefox 中测试是不够的。请了解您的网站在代理浏览器和传统浏览器中的工作方式。例如，UC 浏览器和 Opera Mini 在亚洲占有相当大的市场份额[59](高达 35%)。对你感兴趣的国家的平均网速进行测量[60]，以避免未来出现大的意外。使用网络节流进行测试，并模拟高 dpi 设备。BrowserStack[61] 非常适合在远程真实设备上进行测试，并且至少在你的办公室里安装一些真实的设备作为补充——这是值得的。
k6 可以帮助我们像写性能测试一样写单元测试
63. 您是否测试了可访问性的影响?
当浏览器开始加载一个页面时，它会构建一个 DOM，如果有一个辅助技术（如屏幕阅读器）在运行，它还会创建一个可访问性树。然后，屏幕阅读器必须查询可访问性树来检索信息并使其对用户可用 — 有时是默认的，有时是按需的。有时需要一些时间。
当我们说到交互的快速响应时，通常我们指的是用户通过点击链接和按钮与页面交互的速度。屏幕阅读器略有不同。在这种情况下，快速的交互时间意味着在屏幕阅读器能够在给定的页面上显示导航以及屏幕阅读器用户能够实际敲击键盘进行交互之前所需要的时间。
Leonie Watson 就可访问性性能，特别是缓慢加载对屏幕阅读器发布延迟的影响，发表了令人大开眼界的演讲[62]。屏幕阅读器用户习惯于快节奏的公告和快速导航，因此可能比视力正常的用户更缺乏耐心。
使用 JavaScript 的大页面和 DOM 操作将导致屏幕阅读器通知延迟。这是一个尚未开发的领域，需要一些关注和测试，因为屏幕阅读器在每个平台上都是可用的（Jaws, NVDA, Voiceover, Narrator, Orca）。
64. 是否建立了持续监控?
拥有 WebPagetest[63] 的私有实例对于快速和无限的测试总是有益的。然而，一个带有自动警报功能的连续的监控工具，如 Sitespeed[64], Calibre[65] 和 SpeedCurve[66]，可以让你更详细地了解情况。设置您自己的用户计时标记来度量和监视特定的业务指标。此外，可以考虑添加自动性能回归警报[67]来监视其随时间的变化。
考虑使用 RUM 解决方案来监视性能随时间的变化。对于自动化的单元测试类负载测试工具，您可以使用 k6[68] 及其脚本 API。此外，看看 SpeedTracker[69], Lighthouse[70] 和Calibre[71]。
速成方案
这个列表非常全面，完成所有的优化可能需要很长时间。所以，如果您只有一个小时的时间来取得显著的进步，您会怎么做呢？让我们把它浓缩成
15 个容易实现的目标。显然，在开始之前以及完成之后，要测量结果，包括开始渲染时间和在 3G 网络上进行交互的时间。- 衡量实际经验并制定适当的目标。一个好的目标是：可视区域渲染<1 s，页面渲染<3s，慢速 3G 的可操作时间<5s，重复访问的可交互时间(TTI) <2s。优化首屏渲染时间和交互时间。
- 为您的主模板准备关键的 CSS，并将其包含在页面的中。对于 CSS / JS，关键文件大小控制在预算范围内。[最大为压缩后 170KB[72]（解压缩后约 0.7MB）]。
- 修剪，优化，推迟和延迟加载尽可能多的脚本，选取轻量级替代方案，并限制第三方脚本的影响。
- 仅向具有
