[译] 2019 前端性能优化年度总结 — 第六部分

时间 2019-11-06

原文原文链接

原文地址：Front-End Performance Checklist 2019 — 6

原文做者：Vitaly Friedman

译文出自：掘金翻译计划

本文永久连接：github.com/xitu/gold-m…

译者：子非

校对者：Ivocin，weibinzhu

让 2019 来得更迅速吧~ 你正在阅读的是 2019 年前端性能优化年度总结，始于 2016。php

[译] 2019 前端性能优化年度总结 — 第一部分

[译] 2019 前端性能优化年度总结 — 第二部分

[译] 2019 前端性能优化年度总结 — 第三部分

[译] 2019 前端性能优化年度总结 — 第四部分

[译] 2019 前端性能优化年度总结 — 第五部分

[译] 2019 前端性能优化年度总结 — 第六部分

内容目录

HTTP/2

52. 迁移到 HTTPS，而后启用 HTTP/2

随着 Google 推动更安全的 web 并最终全部的 HTTP 页面都被 Chrome 视为“不安全”，向 HTTP/2 环境转变已经不可避免。HTTP/2 如今已经获得了很好的支持；它没有任何大的改变；而且在大多数状况下，使用它会让你获得出色的性能表现。一旦在已经 HTTPS 运行了，你可使用 service workes 和 server push 获得巨大的性能提高（至少长期来看）。css

最终 Google 打算标记全部 HTTP 页面为非安全，并把 Chrome 标记失效 HTTPS 用的红色三角形做为 HTTP 的安全性指示器。（图像来源）html

最耗时的工做将会是迁移至 HTTPS，而且根据你的 HTTP/1.1 用户（使用过期操做系统和浏览器的用户）数量你不得不要考虑过期浏览器的性能优化而发送不一样构建的版本，这须要你采纳不一样的构建进程。注意：配置迁移和新的构建进程会很麻烦且耗时。在本文的余下内容中，我会假设你正在或已经迁移 HTTP/2。前端

53. 合适地部署 HTTP/2

为让资源经过 HTTP/2 传递须要对如今提供资源的方式进行部分修改。你须要在打包成一个大模块和并行加载许多小模块之间找到合适的平衡。最好的请求就是没有请求，然而目标是在首次快速分发资源和缓存之间找到一个好的平衡。android

一方面，你可能想避免资源全都合并在一块儿，而是把所有的接口分割成许多小的模块，把它们压缩为构建进程的一部分，经过 “侦查”途径引用并并行加载它们。一个文件的改变不须要从新加载所有样式或 JavaScript 。它还压缩解析时间并使每一个页面保持少许的资源负载。webpack

另外一方面，打包仍然是个问题。首先，压缩会受到影响。大模块压缩会受益于字典复用，而小的独立模块不会。是有一些标准来解决这个问题，可是目前还差得很远。第二，浏览器针对这种流程尚未作优化。例如，Chrome 会触发数量和资源数线性相关的进程间通信（IPC），这样大量的资源会消耗浏览器运行时。ios

为了得到使用 HTTP/2 的最佳效果，请考虑渐进式加载 CSS，这是来自 Chrome 成员 Jake Archibald 的建议。nginx

你能够尝试渐进加载式 CSS。实际上，自从 Chrome 69 开始，body 内的 CSS 已经再也不阻塞 Chrome 的渲染。显然，这样作不利于使用 HTTP/1.1 的用户，因此你可能须要为不一样的浏览器生成并提供不一样的构建，来做为你的调度进程一部分，事情会稍微更复杂一些。你可能会使用 HTTP/2 链接聚合来避免，它容许你利用 HTTP/2 使用域切分，但实际上并不容易作到，总之，它被不认为是最佳实践。git

该怎么作呢？若是你正在运行 HTTP/2，那么发送大约 6-10 个包 会是一个不错的折中方案（而且对于老旧浏览器也不会太糟糕）。须要试验和测试来为你的网站找到最佳的平衡。github

54. 你的服务器和 CDN 支持 HTTP/2 吗？

不一样的服务器和 CDN 可能可能对 HTTP/2 的支持不同。使用 TLS 速度快吗？来检查你的配置，或快速查找服务器的运行状况以及能够支持的功能。

我参考了 Pat Meenan 很是棒的 HTTP/2 优先级的研究和测试服务器的支持程度以肯定 HTTP/2 优先级。依据 Pat 的研究，为了让 HTTP/2 优先级能可靠地工做在 Linux 4.9 以及更新的内核上，推荐开启 BBR 堵塞控制和设置 tcp_notsent_lowat 为 16 KB（感谢 Yoav！）。Andy Davies 在多个浏览器上作了相似的 HTTP/2 优先级研究，CDN 和云托管服务。

TLS 速度快吗？容许你在切换到 HTTP/2 时检查你的服务器和 CDN 的配置 (大预览图)

55. OCSP Stapling 是否启用？

经过在你的服务器上启用 OCSP Stapling，能够加速 TLS 握手。建立在线证书状态协议（Online Certificate Status Protocol）（OCSP）是做为证书撤销列表（Certificate Revocation List）（CRL）协议的代替。两种协议都是用来检查 SSL 证书是否被撤销。然而，OCSP 协议不须要浏览器花费时间下载而后在列表中搜寻证书信息，所以能减小握手须要的时间。

56. 你采用 IPv6 了吗？

由于 IPv4 地址正在消耗殆尽而且主要的手机网络正在迅速接受 IPv6（美国已经达到 50% IPv6 采纳率），更新你的 DNS 为 IPv6 是一个不错的想法，这样在未来能够保持服务器安全稳固。只须要确认网络是否支持双栈 —— 它容许 IPv6 和 IPv4 同时工做。别忘了，IPv6 并不向后兼容。而且，研究代表得益于邻居发现（NDP）和路由优化， IPv6 使这些网站提速了 10 到 15%。

57. 是否使用 HPACK 压缩？

若是你在使用 HTTP/2，请确保检查你的服务器为 HTTP 响应头实现了 HPACK 压缩来减小没必要要的载荷。由于 HTTP/2 服务器都比较新，它们也许没有彻底支持设计规范，HPACK 就是一个例子，H2spec 是一个出色的（从技术上讲很详尽）检查工具。HPACK 的压缩算法确实使人印象深入，而且运行效果不错。

58. 确保你的服务器安全稳固

全部浏览器的 HTTP/2 实现都是运行在 TLS 之上，因此你可能想避免安全性警告或页面中的某些元素出错。请确保 HTTP 头在安全方面获得合适配置，消除已知的风险，而且检查你的证书。还有确保经过 HTTPS 加载全部的外部插件和跟踪脚本，没有跨站脚本而且已经合适地配置了 HTTP 严格传输安全头和内容安全策略头。

测试和监控

59. 你优化过你的审计流程吗？

可能听起来没什么大不了的，可是若是设置合适可能会减小你不少测试上的时间。请考虑使用 Tim Kadlec 的针对 WebPageTest 的 Alfred 工做流向 WebPageTest 公共实例来提交测试用例。

你也能够用 Google Spreadsheet 来驱动 WebPageTest 而且 Travis 使用 Lighthouse CI 安装了包含辅助工具，性能和 SEO 评分的测试或直接打包进 Webpack。

而且若是你须要快速调试东西但你的构建进程彷佛奇慢，记住“对于大部分 JavaScript 来讲移除空白符和 symbol mangling 可使被压缩代码大小减小 95% —— 并非精巧的代码转换。你能够简单的经过压缩使 Uglify 构建速度快 3 到 4 倍。”

经过使用 Lighthouse CI 在 Travis 中集成辅助性工具，性能和 SEO 评分测试对全部的合做开发者来讲都能显著提高开发新功能的效率。（图像来源）（大预览图）

60. 你测试过代理和过期的浏览器吗？

光测试 Chrome 和 Firefox 还不够。看看你的网站在代理浏览器和过期浏览器中的表现。例如在亚洲有着巨大的市场占有率（在亚洲多达 35%）的 UC 浏览器和 Opera Mini。评估平均网络速度以免在你的国家出现加载很是慢的状况。使用网络节流和模拟高分辨率设备测试。BrowserStack 很是不错，不过仍是要在真机上测试。

k6 容许你写相似单元测试的性能测试用例。

61. 你测试过辅助工具的性能吗？

当浏览器开始加载页面，它建立 DOM，若是此时有例如屏幕阅读器的辅助技术在运行，它也会建立辅助树。屏幕阅读器必须查询辅助树来获取信息并让读者可用 —— 有时默认直接查询，有时是按需，而且它可能会消耗一些时间。

当讨论到快速到达可交互状态，一般咱们指用户能尽快经过点击连接或按钮来与页面交互的指标。这个概念与屏幕阅读器的有细微不一样。对于屏幕阅读器来讲，最快可交互时间是指当屏幕阅读器能够读出给定页面的导航而且使用者能够实际敲击键盘来交互时的时间过去了多少。

Léonie Watson 有一个在辅助性工具的性能方面使人眼界大开的讨论而且特别指出加载慢会致使屏幕阅读器阅读延迟。屏幕阅读器本是用来快速阅读并导航的，所以可能那些视力很差的用户会比视力好的用户缺乏耐心。

加载大页面和使用 JavaScript 操做 DOM 会致使屏幕阅读器语音延迟。请关注这些之前没注意到的地方，并测试全部可用的平台（Jaws，NVDA，Voiceover，Narrator，Orca）。

62. 是否创建持续监控？

对于快速无限制测试来讲持有一个 WebPagetest 实例老是很是受益的。一个相似 Sitespeed，Calibre 和 SpeedCurve 的可持续监控工具能自动报警，给你更详尽的性能画像。设置你本身的用户时间记录来测试和监控特殊业务指标。并请考虑加入自动性能回归警报来监控变化。

了解使用 RUM-solutions 来监控性能随时间的变化。对于像加载测试工具的自动化测试，你可使用 k6 和它的脚本 API。并了解 SpeedTracker，Lighthouse 和 Calibre。

速效方案

本文的清单至关全面，而且完成全部的优化须要至关一段时间。因此，若是你只有一小时但想得到巨大性能提高，你要怎么作？让咱们总结为 12 条易于实现的目标。显然，在你开始以前和完成以后，评估结果，包括在 3G 和有线网络链接下的渲染时间和 Speed Index。

评估实际经验和设置合适的目标。一个很好的目标是追求首次有意义的渲染时间 < 1 秒，同时 Speed Index < 1250 秒，慢速 3G 网络下首次可交互时间 < 5秒，TTI < 2 秒。针对渲染时间和首次可交互时间作优化。
为你的主要模板准备关键 CSS，并在放在页面的 head 标签内（预算应小于 14 KB）。对于 CSS/JS，使它们小于关键文件大小最大预算 gzipped 压缩后为 170 KB（未压缩为 0.7 MB）。
尽量地让更多的脚本分割，优化，defer 加载或者懒加载，检查轻量级的可选包并限制第三方包的大小。
使用 <script type="module"> 来让代码只对旧浏览器工做。
试着整个 CSS 规则并测试 in-body CSS。
使用更快的 dns-lookup，preconnect，prefetch 和 preload 来添加资源提示来加速分发。
给网络字体分组并异步加载，在 CSS 中利用 font-display 来加速首次渲染。
优化图片，并考虑为重要的页面（例如首页）使用 WebP。
检查 HTTP 头设置的缓存并确保已经被合适地设置。
在服务器上启用 Brotli 和 Zopfli 压缩。（若是不能，别忘了启用 Gzip 压缩。）
若是 HTTP/2 可用，启用 HPACK 压缩并开始监控 mixed-content 警告。开启 OSCP 压缩。
在 service worker 中缓存字体，样式，JavaScript 和图片等资源文件。

下载清单（PDF，Apple Pages）

记住这条清单，你应该就能应对各类前端性能方面的项目。请自由下载可打印版的 PDF 清单，同时为了供您按需定制清单还准备了可编辑的 Apple Pages 文档。

下载 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 对这篇文章的审阅，同时也感谢咱们无与伦比的社区，你们会分享从工做学到的，对每一个人都有用的优化技术和课程。大家真的是太棒了！