2021 年前端性能：设定切合实际的目标

本指南得到了我们在 LogRocket 的朋友的大力支持，LogRocket 是一项结合前端性能监控、会话重放和产品分析的服务，可帮助您建立更好的客户体验。 LogRocket跟踪关键指标，包括。 DOM 完成、第一个字节的时间、第一个输入延迟、客户端 CPU 和内存使用情况。 立即免费试用 LogRocket。

目录

1. 准备：计划和指标
2. 设定切合实际的目标
3. 定义环境
4. 资产优化
5. 构建优化
6. 交付优化
7. 网络、HTTP/2、HTTP/3
8. 测试和监控
9. 快速获胜
10. 一切都在一页上
11. 下载清单（PDF、Apple Pages、MS Word）
12. 订阅我们的电子邮件通讯不要错过下一个指南。

设定切合实际的目标

1. 100 毫秒响应时间，60 fps。
   为了让交互感觉流畅，界面有 100 毫秒来响应用户的输入。 再长一点，用户就会认为应用程序滞后。 以用户为中心的性能模型 RAIL 为您提供了健康的目标：为了允许 <100 毫秒的响应，页面必须最迟在每 <50 毫秒后将控制权交还给主线程。 估计输入延迟告诉我们是否达到了该阈值，理想情况下，它应该低于 50 毫秒。 对于动画这样的高压点，能做的最好什么都不做，不能做的绝对最少。

   

   此外，每一帧动画应该在 16 毫秒内完成，从而达到每秒 60 帧（1 秒 ÷ 60 = 16.6 毫秒）——最好在 10 毫秒以下。 因为浏览器需要时间将新帧绘制到屏幕上，所以您的代码应该在达到 16.6 毫秒标记之前完成执行。 我们开始讨论 120fps（例如 iPad Pro 的屏幕以 120Hz 运行），Surma 已经介绍了一些 120fps 的渲染性能解决方案，但这可能不是我们目前正在关注的目标。

   对性能预期持悲观态度，但对界面设计持乐观态度并明智地使用空闲时间（检查 idlize、idle-until-urgent 和 react-idle）。 显然，这些目标适用于运行时性能，而不是加载性能。

2. FID < 100ms, LCP < 2.5s, TTI < 5s on 3G, 关键文件大小预算 < 170KB (gzipped)。
   虽然这可能很难实现，但一个好的最终目标是 Time to Interactive 低于 5 秒，而对于重复访问，目标是低于 2 秒（只有通过服务人员才能实现）。 以 2.5 秒以下的最大内容绘制为目标，并最大限度地减少总阻塞时间和累积布局偏移。 可接受的首次输入延迟低于 100 毫秒至 70 毫秒。 如上所述，我们考虑的基准是 200 美元的 Android 手机（例如 Moto G4），在慢速 3G 网络上，模拟 400ms RTT 和 400kbps 传输速度。

   我们有两个主要的限制因素，它们有效地形成了在网络上快速交付内容的合理目标。 一方面，由于 TCP 慢启动，我们有网络传输限制。 HTML 的前 14KB——10 个 TCP 数据包，每个 1460 字节，大约 14.25 KB，尽管不是字面意思——是最关键的有效负载块，也是预算中唯一可以在第一次往返中交付的部分（由于移动唤醒时间，这是您在 400 毫秒 RTT 时 1 秒内获得的所有数据）。

   

   （注意：由于 TCP 通常在很大程度上未充分利用网络连接，因此 Google 开发了 TCP 瓶颈带宽和 RRT（ BBR ），这是一种 TCP 延迟控制的 TCP 流量控制算法。专为现代网络设计，它可以响应实际的拥塞，而不是像 TCP 那样丢包，它明显更快，具有更高的吞吐量和更低的延迟——并且算法的工作方式不同。（谢谢，维克多，巴里！ ）

   另一方面，由于 JavaScript 解析和执行时间，我们对内存和 CPU 有硬件限制（我们稍后会详细讨论）。 为了实现第一段中所述的目标，我们必须考虑 JavaScript 的关键文件大小预算。 对于预算应该是多少（这在很大程度上取决于您的项目的性质），意见各不相同，但 170KB JavaScript gzip 的预算已经在中端手机上解析和编译需要 1 秒。 假设 170KB 在解压后扩展为该大小的 3 倍（0.7MB），这可能是 Moto G4/G5 Plus 上“体面”用户体验的丧钟。

   

   以 Wikipedia 网站为例，2020 年，在全球范围内，Wikipedia 用户的代码执行速度提高了 19%。 因此，如果您的年度网络性能指标保持稳定，这通常是一个警告信号，因为随着环境的不断改善，您实际上正在倒退（Gilles Dubuc 的博客文章中有详细信息）。

   如果您想瞄准东南亚、非洲或印度等成长型市场，您将不得不考虑一组截然不同的限制条件。 Addy Osmani 涵盖了主要的功能手机限制，例如低成本、高质量的设备、高质量网络的不可用和昂贵的移动数据——以及这些环境的PRPL-30 预算和开发指南。

   

   

   事实上，Google 的 Alex Russell 建议将 gzip 压缩后的 130-170KB 作为合理的上限。 在现实世界的场景中，大多数产品甚至都没有接近：今天的中位数捆绑大小约为 452KB，与 2015 年初相比增长了 53.6%。在中产阶级移动设备上，这占 12-20 秒的时间-To-Interactive 。

   

   不过，我们也可以超出捆绑包大小的预算。 例如，我们可以根据浏览器主线程的活动设置性能预算，即开始渲染之前的绘制时间，或跟踪前端 CPU 占用率。 Calibre、SpeedCurve 和 Bundlesize 等工具可以帮助您控制预算，并且可以集成到您的构建过程中。

   最后，性能预算可能不应该是一个固定值。 根据网络连接，性能预算应该适应，但较慢连接的有效负载更加“昂贵”，无论它们如何使用。

   注意：在广泛传播的 HTTP/2、即将到来的 5G 和 HTTP/3、快速发展的手机和蓬勃发展的 SPA 时代，设置如此严格的预算可能听起来很奇怪。 然而，当我们处理网络和硬件的不可预测性时，它们听起来确实是合理的，包括从拥挤的网络到缓慢发展的基础设施，再到数据上限、代理浏览器、保存数据模式和偷偷摸摸的漫游费用。

目录

1. 准备：计划和指标
2. 设定切合实际的目标
3. 定义环境
4. 资产优化
5. 构建优化
6. 交付优化
7. 网络、HTTP/2、HTTP/3
8. 测试和监控
9. 快速获胜
10. 一切都在一页上
11. 下载清单（PDF、Apple Pages、MS Word）
12. 订阅我们的电子邮件通讯不要错过下一个指南。