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 年页面性能有大大的提升！