作者：马雪琴、朱志玉

转发链接:

本文是性能优化清单系列第六篇，也是最后一篇，可以先看看前边的文章：2020前端性能优化清单（一）2020前端性能优化清单（二）2020前端性能优化清单（三）2020前端性能优化清单（四）2020前端性能优化清单（五）网络与 http/253. 启用 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）]。修剪，优化，推迟和延迟加载尽可能多的脚本，选取轻量级替代方案，并限制第三方脚本的影响。仅向具有 <script type="module"> 和module/nomodule 模式[73]的旧版本浏览器提供旧版本代码。尝试重新组合 CSS 规则并测试 body 内的 CSS。添加资源提示(resource hints)以提升页面加载速度，例如“dns-lookup”、“preconnect”、“prefetch”、“preload”、和“prerender”等。设置 Web 字体子集并异步加载，并利用 CSS 中的 font-display 实现快速的首次呈现。使用mozjpeg[74], guetzli[75], pingo[76] 和 SVGOMG[77]优化图像，并考虑使用图像 CDN 为 WebP 服务。检查 HTTP 缓存头和安全头是否设置正确。在服务器上启用 Brotli 压缩。（如果不可能，请不要忘记启用 Gzip 压缩。）只要服务器运行在 Linux 内核版本 4.9+上，就启用 TCP BBR 拥塞。如果可能，启用 OCSP stapling 和 IPv6。如果 HTTP/2 可用，则启用 HPACK 压缩，如果 HTTP/3 在 CDNs 上可用，则启用 HTTP/3。在 service worker 中缓存字体、样式、JavaScript 和图像等资源。探索避免 rehydration（客户端再次渲染）的方案，使用渐进式 hydration 和流服务器渲染您的 SPA。出发吧！

某些优化可能超出了您的工作或预算范围，或者考虑到您必须处理的遗留代码，这些优化可能过于简单。没关系！将此清单用作一般（希望是全面的）指南，并创建适用于您的情况的问题清单。但最重要的是，在优化之前测试和测量您自己的项目以确定问题。祝大家 2020 年有好成绩！

非常感谢 Guy Podjarny，Yoav Weiss，Addy Osmani，Artem Denysov，Denys Mishunov，Ilya Pukhalski，Jeremy Wagner，Colin Bendell，Mark Zeman，Patrick Meenan，Leonardo Losoviz，Andy Davies，Rachel Andrew，Anselm Hannemann，Barry Pollard，Patrick 哈曼（Hamann），吉迪恩·比泽（Gideon Pyzer），安迪·戴维斯（Andy Davies），玛丽亚·普罗斯韦尔尼纳（Maria Prosvernina），蒂姆·卡德尔茨（Ty Kadlec），雷伊·班戈（Rey Bango），马蒂亚斯·奥特（Matthias Ott），彼得·鲍耶（Peter Bowyer），菲尔·沃尔顿（Phil Walton），玛丽亚·佩拉尔塔（Mariana Peralta），佩皮真·桑德斯（Pepijn Senders），马克·诺丁汉，让·皮埃尔·文森特，菲利普·特利斯（Philipp Tellis），瑞安·汤森（Ryan Townsend），英格丽·伯格曼（Ingrid Bergman），穆罕默德·侯赛因（Mohamed Hussain） SH，JacobGroß，Tim Swalling，Bob Visser，Kev Adamson，Adir Amsalem，Aleksey Kulikov 和 Rodney Rehm 审阅本文，我们奇妙的社区也分享了从性能优化工作中获得的技术和经验教训，供大家使用。您们真了不起！

作者：马雪琴、朱志玉

转发链接: