2021 年前端性能：测试和监控

已发表: 2022-03-10

快速总结↬让2021年……快点！一份年度前端性能清单，包含您在当今 Web 上创建快速体验所需了解的所有内容，从指标到工具和前端技术。自 2016 年以来更新。

测试和监控

您是否优化了审计工作流程？
这听起来可能没什么大不了的，但是触手可及的正确设置可能会为您节省大量测试时间。考虑使用 Tim Kadlec 的 Alfred Workflow for WebPageTest 向 WebPageTest 的公共实例提交测试。事实上，WebPageTest 有许多晦涩难懂的功能，因此请花时间学习如何阅读 WebPageTest 瀑布视图图表以及如何阅读 WebPageTest 连接视图图表以更快地诊断和解决性能问题。
您还可以从 Google 电子表格驱动 WebPageTest，并使用 Lighthouse CI 将可访问性、性能和 SEO 分数整合到您的 Travis 设置中，或者直接整合到 Webpack 中。

看看最近发布的 AutoWebPerf，这是一个模块化工具，可以自动收集来自多个来源的性能数据。例如，我们可以在您的关键页面上设置每日测试，以捕获来自 CrUX API 的现场数据和来自 PageSpeed Insights 的 Lighthouse 报告的实验室数据。
如果你需要快速调试一些东西，但你的构建过程似乎非常慢，请记住“空白删除和符号修改占大多数 JavaScript 缩小代码大小减少的 95%——而不是复杂的代码转换。你可以只需禁用压缩即可将 Uglify 构建速度提高 3 到 4 倍。”

GitHub 的 Pull Request 通知的屏幕截图，说明需要审核并且在成功解决检查之前阻止合并 — 使用 Lighthouse CI 将可访问性、性能和 SEO 分数集成到 Travis 设置中，将突出新功能对所有贡献的开发人员的性能影响。（图片来源）（大预览）

您是否在代理浏览器和旧版浏览器中进行了测试？
在 Chrome 和 Firefox 中进行测试是不够的。查看您的网站在代理浏览器和旧版浏览器中的工作方式。例如，UC 浏览器和 Opera Mini 在亚洲拥有重要的市场份额（在亚洲高达 35%）。测量您感兴趣的国家/地区的平均互联网速度，以避免未来出现重大意外。使用网络限制进行测试，并模拟高 DPI 设备。 BrowserStack 非常适合在远程真实设备上进行测试，并且还可以在您的办公室中至少使用一些真实设备来补充它——这是值得的。

您是否测试过 404 页面的性能？
通常，当涉及到 404 页时，我们不会三思而后行。毕竟，当客户端请求服务器上不存在的页面时，服务器将响应 404 状态代码和相关的 404 页面。它没有那么多，不是吗？
404 响应的一个重要方面是发送到浏览器的实际响应正文大小。根据 Matt Hobbs 对 404 页面的研究，绝大多数 404 响应来自丢失的网站图标、WordPress 上传请求、损坏的 JavaScript 请求、清单文件以及 CSS 和字体文件。每次客户请求不存在的资产时，他们都会收到 404 响应——而且该响应通常是巨大的。

确保检查和优化 404 页面的缓存策略。我们的目标是仅在浏览器需要 HTML 响应时才向浏览器提供 HTML，并为所有其他响应返回一个小的错误负载。根据 Matt 的说法，“如果我们在源之前放置一个 CDN，我们就有机会在 CDN 上缓存 404 页面响应。这很有用，因为没有它，点击 404 页面可能会被用作 DoS 攻击向量，通过强制源服务器响应每个 404 请求，而不是让 CDN 以缓存版本响应。”
404 错误不仅会损害您的性能，而且还会影响流量，因此最好在您的 Lighthouse 测试套件中包含 404 错误页面，并随着时间的推移跟踪其分数。
您是否测试过 GDPR 同意提示的性能？
在 GDPR 和 CCPA 时代，依靠第三方为欧盟客户提供选择加入或退出跟踪的选项已变得很普遍。但是，与任何其他第三方脚本一样，它们的性能可能会对整个性能工作产生相当大的破坏性影响。
当然，实际同意可能会改变脚本对整体性能的影响，因此，正如 Boris Schapira 所指出的，我们可能想要研究一些不同的 Web 性能配置文件：
- 完全拒绝同意，
- 同意被部分拒绝，
- 完全同意。
- 用户尚未对同意提示采取行动（或提示被内容阻止程序阻止），
通常 cookie 同意提示不应该对 CLS 产生影响，但有时会产生影响，因此请考虑使用免费和开源选项 Osano 或 cookie-consent-box。
一般来说，值得研究弹出窗口的性能，因为您需要确定鼠标事件的水平或垂直偏移量，并正确定位弹出窗口相对于锚点的位置。 Noam Rosenthal 在文章 Web 性能案例研究：维基百科页面预览（也可作为视频和会议纪要）中分享了 Wikimedia 团队的学习成果。
您是否保留了性能诊断 CSS？
虽然我们可以包括各种检查以确保部署非性能代码，但通常快速了解一些可以轻松解决的容易实现的成果是有用的。为此，我们可以使用 Tim Kadlec 出色的性能诊断 CSS（灵感来自 Harry Roberts 的片段，该片段突出显示延迟加载的图像、未调整大小的图像、旧格式图像和同步脚本。
例如，您可能希望确保首屏上方的图像不会被延迟加载。您可以根据需要自定义片段，例如突出显示未使用的网络字体，或检测图标字体。一个很棒的小工具，可以确保在调试过程中可以看到错误，或者只是快速审核当前项目。
```
/* Performance Diagnostics CSS */ /* via Harry Roberts. https://twitter.com/csswizardry/status/1346477682544951296 */ img[loading=lazy] { outline: 10px solid red; }
```

您是否测试过对可访问性的影响？
当浏览器开始加载页面时，它会构建一个 DOM，如果有像屏幕阅读器这样的辅助技术在运行，它还会创建一个可访问性树。然后，屏幕阅读器必须查询可访问性树以检索信息并将其提供给用户——有时是默认的，有时是按需提供的。有时这需要时间。
在谈论快速交互时间时，通常我们指的是用户可以通过单击或点击链接和按钮与页面交互的速度指标。屏幕阅读器的上下文略有不同。在这种情况下，快速交互时间意味着屏幕阅读器可以在给定页面上宣布导航并且屏幕阅读器用户可以实际敲击键盘进行交互之前经过了多少时间。

Leonie Watson 就可访问性性能发表了令人大开眼界的演讲，特别是缓慢加载对屏幕阅读器公告延迟的影响。屏幕阅读器习惯于快节奏的公告和快速导航，因此可能比有视力的用户更没有耐心。
使用 JavaScript 进行的大页面和 DOM 操作将导致屏幕阅读器公告延迟。几乎每个平台（Jaws、NVDA、Voiceover、Narrator、Orca）上都有一个相当未开发的领域，可以使用一些注意力和测试作为屏幕阅读器。
是否设置了持续监控？
拥有 WebPagetest 的私有实例总是有利于快速和无限制的测试。但是，具有自动警报的持续监控工具（如 Sitespeed、Calibre 和 SpeedCurve）可以让您更详细地了解您的表现。设置您自己的用户计时标记来衡量和监控特定于业务的指标。此外，考虑添加自动性能回归警报以监控随时间的变化。

研究使用 RUM 解决方案来监控性能随时间的变化。对于自动化的类似单元测试的负载测试工具，您可以使用 k6 及其脚本 API。另外，请查看 SpeedTracker、Lighthouse 和 Calibre。

2021 年前端性能：测试和监控

目录

测试和监控

目录