Web 性能指标

对于 Web 开发人员来说，如何衡量一个 Web 页面的性能一直是一个难题。

最初，我们使用 Time to First Byte、DomContentLoaded 和 Load 这些衡量文档加载进度的指标，但它们不能直接反应用户视觉体验。

为了能衡量用户视觉体验，Web 标准中定义了一些性能指标，这些性能指标被各大浏览器标准化实现，例如 First Paint 和 First Contentful Paint。还有一些由 Web 孵化器社区组（WICG）提出的性能指标，如 Largest Contentful Paint 、Time to Interactive、First Input Delay、First CPU Idle。另外还有 Google 提出的 First Meaningful Paint、Speed Index，百度提出的 First Screen Paint。

这些指标之间并不是毫无关联，而是在以用户为中心的目标中不断演进出来的，有的已经不再建议使用、有的被各种测试工具实现、有的则可以作为通用标准有各大浏览器提供的可用于在生产环境测量的 API。

RAIL 性能模型

RAIL 是 Response, Animation, Idle, 和 Load的首字母缩写, 是一种由 Google Chrome 团队于 2015 年提出的性能模型, 用于提升浏览器内的用户体验和性能。

RAIL 模型的理念是”以用户为中心，最终目标不是让您的网站在任何特定设备上都能运行很快，而是使用户满意”。

这个名字的由来是四个英文单词的首字母：

响应（Response）：应该尽可能快速的响应用户, 应该在 100ms 以内响应用户输入。
动画（Animation）：在展示动画的时候，每一帧应该以 16ms 进行渲染，这样可以保持动画效果的一致性，并且避免卡顿。
空闲（Idle）：当使用 Javascript 主线程的时候，应该把任务划分到执行时间小于 50ms 的片段中去，这样可以释放线程以进行用户交互。
加载（Load）：应该在小于 1s 的时间内加载完成你的网站，并可以进行用户交互。

用户对性能延迟的看法

在这里插入图片描述

用户对性能延迟的感知有所不同，具体取决于网络条件和硬件。例如，通过快速 Wi-Fi 连接，在功能强大的台式机上加载站点时，通常只需不到 1 秒时间，用户已经习以为常。通过速度较慢的 3G 网络连接，在移动设备上加载站点则需要更长的时间，因此，移动用户通常会更有耐心。在移动设备上，5 秒钟内完成加载是更现实的目标。

响应: 在 50 毫秒内处理事件

目标

在 100 毫秒内完成由用户输入发起的转换，让用户感觉交互是即时的。

准则

为了确保在 100 毫秒内产生可见响应，需要在 50 毫秒内处理用户输入事件。这适用于大多数输入，例如点击按钮、切换表单控件或启动动画。但是，这不适用于触摸拖动或滚动。
尽管听起来可能有些自相矛盾，但是，即时响应用户输入并非总是正确的做法。您可以利用这 100 毫秒的时间窗口来执行其他需要消耗大量资源的工作，但是，注意不能妨碍用户。如果可能，应在后台工作。
对于需要 50 毫秒以上才能完成的操作，请随时提供反馈。

50 毫秒还是 100 毫秒？

目标是在 100 毫秒内响应输入，那么，为什么我们的预算只有 50 毫秒？这是因为除输入处理外，通常还有需要执行其他工作，而且这些工作会占用可接受输入响应的部分可用时间。如果应用程序在空闲时间以推荐的 50 毫秒区块执行工作，这就意味着，如果输入在这些工作区块之一中发生，它最多可能会排队 50 毫秒。考虑到这一点，假设只有剩余的 50 毫秒可用于实际输入处理才是安全地做法。下图展示了这种影响，图中显示了在空闲任务期间收到的输入如何排队，从而减少可用的处理时间：
在这里插入图片描述

动画：在 10 毫秒内生成一帧

识别所有类型的动画。动画不是花哨的 UI 效果。下面这些交互都是动画： - 视觉动画，例如进入和退出，补间和加载指示器。 - 滚动。这包括滑动，即用户开始滚动，然后松开，而页面会继续滚动。 - 拖放。动画通常遵循用户交互，例如平移地图或捏合缩放

目标：

在 10 毫秒或更短的时间内生成动画的每一帧。从技术上来讲，每帧的最大预算为 16 毫秒（1000 毫秒/每秒 60 帧≈16 毫秒），但是，浏览器需要大约 6 毫秒来渲染一帧，因此，准则为每帧 10 毫秒。
目标为流畅的视觉效果。用户会注意到帧速率的变化。

准则：

在动画之类对计算速度要求极高的场景下，关键在于即使可行，您也不能执行任何其他操作，让不能执行的操作保持绝对最少。只要可能，您就要利用这 100 毫秒的响应时间预先计算最消耗资源的工作，从而最大限度地提高达到 60 fps 的几率。
有关各种动画优化策略，请参阅渲染性能。

空闲：最大限度增加空闲时间

目标：

最大限度增加空闲时间以提高页面在 50 毫秒内响应用户输入的几率。

准则：

利用空闲时间完成延缓的工作。例如，对于初始页面加载，应加载尽可能少的数据，然后利用空闲时间加载其余数据。

在 50 毫秒或更短的空闲时间内执行工作。如果时间更长，您可能会干扰应用在 50 毫秒内响应用户输入的能力。

如果用户在空闲时间工作期间与页面交互，则应中断空闲时间工作，用户交互始终具有最高优先级。

加载：在 5 秒内交付内容并实现可交互

目标：

根据用户的设备和网络能力优化相关的快速加载性能。目前，对于首次加载，在使用速度较慢 3G 连接的中端移动设备上，理想的目标是在 5 秒或更短的时间内实现可交互。
对于后续加载，理想的目标是在 2 秒内加载页面。

准则：

在最常见的用户移动设备和网络连接上测试负载性能。您可以使用 Chrome 用户体验报告来了解用户的连接分布。如果数据不适用于您的站点，移动经济 2019 建议的理想全球标准是中端 Android 手机，例如 Moto G4 和速度较慢的 3G 网络（定义的 RTT 为 400 毫秒，传输速度为 400 kbps）。WebPageTest 上提供了这一组合。

请记住，尽管您的典型移动用户的设备可能声称它使用的是 2G、3G 或 4G 连接，但实际上，由于数据包丢失和网络差异，有效连接速度通常要慢得多。

消除阻塞渲染资源。

为了产生完整加载的感觉，您不必在 5 秒钟时间内加载所有内容。不妨考虑延迟加载图像、代码拆分 JavaScript 包以及 web.dev 上建议的其他优化。