（译）2019年前端性能优化清单 — 下篇

• （译）2019年前端性能优化清单 — 上篇
• （译）2019年前端性能优化清单 — 中篇
• （译）2019年前端性能优化清单 — 下篇

目录

• HTTP/2
  • 52. 迁移到HTTPS，而后打开HTTP / 2
  • 53. 正确部署HTTP / 2
  • 54. 您的服务器和 CDN 是否支持 HTTP / 2
  • 55. 是否启用了 OCSP stapling
  • 56. 是否采用 IPv6
  • 57. 是否正在使用 HPACK 压缩
• 测试和监测
  • 58. 确保服务器上的安全性是防攻击的
  • 59. 您是否优化了审计和调试工做流程
  • 60. 您是否在代理浏览器和传统浏览器中测试过
  • 61. 您是否测试了辅助功能
  • 62. 您是否创建了连续监控
• 速效方案
• 动身吧！

HTTP/2

52. 迁移到HTTPS，而后打开HTTP / 2

随着 Google 向更安全的网络发展，并最终将 Chrome 中的全部 HTTP 网页认定为 不安全 的大环境下，迁移到 HTTP / 2环境 是不可避免的。HTTP / 2 从目前来看获得很好的支持， 并且，在大多数场景下，使用 HTTP/2 会让你大力出奇。一旦在 HTTPS 上运行，您能够在 service workers 和 server push 方面获得 显著的性能提高。

最终，谷歌计划将全部 HTTP 页面标记为不安全的，并将有问题的 HTTPS 的 HTTP 安全指示器更改成红色三角形。

最耗时的任务是 迁移到 HTTPS，不过这取决于你的 HTTP/1.1 用户量有多大（即便用旧版操做系统或浏览器的用户），你将不得不为旧版的浏览器性能优化发送不一样的构建版本，这须要你采用 不一样的构建流程。注意：开始迁移和新的构建过程可能会很棘手，并且耗费时间。接下来所讲的内容，都是针对以前切过 HTTP/2 环境或者如今正准备切 HTTP/2 环境（的读者）来展开的。

53. 正确部署HTTP / 2

再次强调一下，须要对现阶段正如何提供在你开始使用 HTTP/2 请求资源以前，须要搞清楚你之前是如何请求资源的。另外须要你在载入大模块以及并行载入小模块之间找到一个平衡点。最终，仍然是 最好的请求就是没有请求，然而咱们的目标是在快速传输资源和缓存之间找到一个好的平衡点。。

一方面，你可能想要避免合并全部资源，而是把整个界面分解成许多小模块，而后在构建过程当中压缩这些小模块，最后经过 scount approach 的方法 引用和并行加载这些小模块。这样的话，一个文件的更改就不须要从新下载整个样式表或 JavaScript。这样还能够 最小化解析时间，并将单个页面的负荷保持在较低的水平。

另外一方面，打包仍然很重要。首先， 压缩将让你受益。在压缩大文件的过程当中，借助目录重用的特色，达到优化性能的目的，而小的单独的文件则不会。有标准的工做来解决这个问题，但如今还远远不够。其次，浏览器还 没有为这种工做流优化。例如，Chrome 将触发 进程间通讯（IPCs），与资源的数量成线性关系，所以页面中若是包含数以百计的资源将会形成浏览器性能损失。

要想能达到 HTTP/2 的最佳使用效果，能够考虑使用 渐进加载CSS, Chrome 的 Jake Archibald 建议咱们这样作。

你能够尝试 渐进加载 CSS。事实上，因为 Chrome 69 版本，内部 CSS 再也不阻止 Chrome 渲染。显然，这种作法不利于 HTTP / 1.1 用户，因此你可能须要针对不一样的浏览器建立并发送该浏览器支持的 HTTP 协议报头，这还只是部署过程当中稍微复杂的地方。不过你可使用 HTTP/2 的 connection coalescing，他可让你在 HTTP/2 环境使用域名共享来避免这个问题，可是这个作法在实际的实践当中会比较困难。

那要怎么作呢？若是你运行在 HTTP/2 之上，发送 6-10 个包是个最理想的折中点（对传统浏览器也适用）。对于你本身的网站，你能够经过实验和测量来找到最佳的平衡点。

54. 您的服务器和 CDN 是否支持 HTTP / 2

不一样的服务器和 CDN 可能会以不一样的方式支持 HTTP / 2。快速使用 TLS 检查您的选项，或快速查找服务器的性能，或者您但愿看到能够支持的特性。

参考 Pat Meenan 对 HTTP / 2优先级 和 测试服务器支持HTTP / 2优先级 的的研究。根据 Pat 的说法，建议启用 BBR 拥塞控制并将其设置 tcp_notsent_lowat 为 16KB 以进行 HTTP / 2 优先级排序，以便在 Linux 4.9 内核及更高版本上可靠地运行（感谢Yoav！）。Andy Davies对跨浏览器，CDN和云托管服务的 HTTP / 2优先级 进行了相似的研究。

TLS还快吗?容许您在切换到HTTP/2时检查服务器和CDNs选项。

55. 是否启用了 OCSP stapling

经过 在您的服务器上启用 OCSP stapling，能够加快 TLS 握手速度。在线证书状态协议（OCSP）做为证书撤销列表（CRL）协议的替代方案。两种协议都用于检查 SSL 证书是否已被撤销。可是，OCSP 协议不要求浏览器花时间下载而后在列表中搜索证书信息，所以减小握手所须要的时间。

56. 是否采用 IPv6

因为咱们的 IPv4空间不足，而主要移动网络正在迅速采用 IPv6（美国已经达到了 50％ 的 IPv6 采用率阈值），所以最好 将DNS更新为IPv6 以保证将来的防范。只需确保经过网络提供双栈支持 - 它容许 IPv6 和 IPv4 同时并行运行。毕竟，IPv6 不是向后兼容的。此外，有 研究代表，正是由于 IPv6 自带 NDP 以及路由优化，因此才可以让网站的载入速度提高 10% 到 15%。

57. 是否正在使用 HPACK 压缩

若是您使用的是 HTTP / 2，请仔细检查您的服务器是否为 HTTP 响应标头 实施HPACK压缩，以减小没必要要的开销。因为 HTTP / 2 服务器相对较新，它们可能不彻底支持规范，就好比 HPACK。H2spec 是一个用来检查的很好的工具，他压缩算法 很是有效。

58. 确保服务器上的安全性是防攻击的

HTTP / 2 的全部浏览器实现都经过 TLS 运行，所以您可能但愿页面避免出现安全警告或者是页面上的某些交互没法正常实现。这时候您须要仔细检查您的 安全标头是否设置正确以及证书，来消除已知漏洞 。另外，请确保经过HTTPS加载全部外部插件和跟踪脚本，没法进行跨站点脚本编写，而且网站已经正确设置了 HTTP严格传输安全标头 和 内容安全策略标头。

测试和监测

59. 您是否优化了审计和调试工做流程

从字面上来看这可能不是什么影响性能的大问题，但在触手可及的地方设置合适的设置可能会为给您节省大量的测试时间。能够考虑使用 Tim Kadlec 的 WebPageTest 中的 Alfred Workflow 将测试提交给 WebPageTest 的公共实例。您还能够从 Google电子表格中驱动WebPageTest ，并将可访问性，性能和 SEO 分数归入您使用 Lighthouse CI 的 Travis 设置或 直接使用Webpack。

使用 Lighthouse CI 将 可访问性，性能和SEO分数 集成到 Travis 设置中，能够突出显示新功能对全部贡献开发人员的性能影响。

60. 您是否在代理浏览器和传统浏览器中测试过

仅仅在 Chrome 和 Firefox 浏览器进行测试是不够的。咱们还须要了解网站在代理浏览器和旧版浏览器中的工做方式。例如，UC 浏览器 和 Opera Mini ，这些浏览器 在亚洲占有很大的市场份额 （ 高达35％ ）。测量您感兴趣的国家/地区的 平均互联网速度，以免出现重大意外状况。测试网络节流，并仿真一个高 DPI 设备。BrowserStack 很不错，但也要在实际设备上测试。

k6 容许您编写单元测试 - 相似的性能测试。

61. 您是否测试了辅助功能

当浏览器开始加载页面时，它构建一个DOM，若是有像屏幕阅读器这样的辅助技术在运行，它还会建立一个可访问性树。而后屏幕阅读器会经过查询可访问性树来检索信息并使其对用户可用 —— 这有时是默认的，有时是按需的。

咱们所说的快速交互时间，一般指的是用户经过点击连接和按钮与页面交互的速度。当屏幕阅读器的上下文略有不一样的时候，快速交互时间意味着屏幕阅读器能够在页面显示导航，到屏幕阅读器上的用户能够用键盘与页面进行交互所需的时间。

莱内·沃森（LéonieWatson） 在 易访问性性能方面 作了一次大开眼界的 演讲，特别是慢加载对屏幕阅读器发布延迟的影响。屏幕阅读器习惯于快节奏的公告和快速导航，所以可能这个辅助功能可能不适用于视力正常的用户。

使用 JavaScript 脚本进行大页面和 DOM 操做会致使屏幕阅读器公告延迟。几乎每一个平台(Jaws、NVDA、画外音、旁白、Orca)均可以使用屏幕阅读器进行一些检测和测试，这是一个相对未开发的领域。

62. 您是否创建了连续监控

有一个 WebPagetest 私人的实例老是有利于快速和无限的测试。可是，一个带有自动性能回归警报报的连续监视工具 （如 Sitespeed， Calibre 和 SpeedCurve ） 将会给您提供更详细的性能描述。设置您本身的用户计时标记来度量和监视特定的业务度量。同时，考虑添加自动化性能回归警报来监控随着时间而发生的变化。

使用 RUM 解决方案来监视性能随时间的变化。对于自动化的类单元测试的负载测试工具，您可使用 k6 脚本 API。此外，能够了解下SpeedTracker，Lighthouse 和 Calibre。

速效方案

此列表很是全面，按照这个清单完成全部优化可能须要一段时间。那么，若是你只有1小时的时间来得到重大改进，你会怎么作？让咱们把这个清单归结为 12个低挂的水果。显然，在开始以前和完成以后，测量结果是包括在3G和电缆链接上开始渲染时间和速度指数。

1. 测量实际环境的体验并设定适当的目标。一个好的目标是：第一次有意义的绘制 < 1 s，速度指数（Speed Index） < 1250，在慢速的 3G 网络上的交互 < 5s，对于重复访问，TTI < 2s。优化渲染开始时间和交互时间。
2. 为主模板准备关键CSS，并将其包含在 <head> 页面中。（您的预算为14 KB）。对于CSS / JS，文件大小不超过 170KB gzipped（0.7MB解压缩）。。
3. 尽量多地减小代码量，优化，推迟和延迟加载脚本，检查轻量级备选方案并限制第三方脚本的影响。
4. 仅将遗留代码提供给旧版浏览器 <script type="module">。
5. 尝试从新组合CSS规则并测试体内 CSS。
6. 添加资源提示以加快交付速度，使用 dns-lookup，preconnect，prefetch 和 preload。
7. 分离 Web 字体并异步加载它们，并在 CSS 中快速使用字体显示渲染。
8. 优化图像，并考虑将 WebP 用于关键页面（例如登陆页面）。
9. 检查是否正确设置了 HTTP 缓存头和安全头。
10. 在服务器上启用 Brotli 或 Zopfli 压缩。 （若是都行不通，那就用 Gzip 压缩。）
11. 若是HTTP / 2可用，请启用 HPACK 压缩，并开始监视混合内容警告。启用 OCSP 装订。
12. 若是可能，在服务工做缓存中缓存诸如字体，样式，JavaScript 和图像之类的资源。

下载优化性能清单（PDF，Apple Pages）

结合这个性能优化清单，您就已经为任何类型的前端性能项目作好了准备。请随意下载该清单的打印版PDF，以及一个可编辑的苹果页面文档，以定制您须要的清单：

• 下载清单PDF （PDF，166 KB）
• 下载Apple Pages中的清单 （.pages，275 KB）
• 下载MS Word中的清单 （.docx，151 KB）

若是您须要替代方案，还能够查看 Dan Rublic 的 前端性能优化清单，Jon Yablonski 的 设计师的 Web 性能优化表 和 FrontendChecklist。

动身吧！

某些优化可能超出了您的工做或预算范围，或者考虑到您必须处理的遗留代码，可能只是过分杀伤。不要紧！使用这份性能优化清单做为一个通用（但愿是全面的）指南，并建立适一个用于您本身的应用场景的问题清单。但最重要的是，在优化以前要先测试而且监测您本身的项目。最后，祝愿你们在 2019 年页面性能有大大的提高！

很是感谢 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，Patrick Hamann，Andy Davies，Tim Kadlec，Rey Bango，Matthias Ott，Peter Bowyer，Phil Walton，Mariana Peralta，Philipp Tellis，Ryan Townsend，Ingrid Bergman，Mohamed Hussain S H，Jacob Groß，Tim Swalling，Bob Visser，Kev Adamson，Adir Amsalem，Aleksey Kulikov和Rodney Rehm对这篇文章的校对，一样也感谢咱们出色的社区，分享了他们在性能优化工做中学习到的技术和经验，供你们使用。大家真正的很是了不得！

写在最后： 也许这是你看的翻译的最烂的文章（我不在意，哈哈），开个玩笑。译文确定会有不少或大或小的错误，还请阅读过的大佬多多帮忙指正，我会在看到评论的第一时间把内容更正过来，但愿能把这篇译文愈来愈完美化！最后，仍是但愿这份前端性能优化清单能给你们的工做带来必定的帮助，让你们写的页面性能可以更上一层楼，工做更上一层楼，薪水更上一层楼！不甚感激！