Fast load times系列翻译——使用 RAIL 模型来衡量性能

Fast load times系列翻译——使用 RAIL 模型来衡量性能

RAIL 是一个 以用户为中心 的性能模型，它提供了一个如何思考性能的体系。该模型将用户体验分解为关键操作（例如：点击、滚动、加载）并帮助你为它们定义性能指标。

RAIL代表web应用程序生命周期的四个不同方面：响应、动画、闲置、加载（response, animation, idle, load）。用户对每种操作都有不同的性能期望，因此性能指标是[根据内容和用户如何感知延迟的UX（user Experience:用户体验）来定义的](UX research on how users perceive delays.)。

以用户为中心

让用户体验成为你性能优化的焦点。下表描述了用户感知性能的关键指标：

用户对性能延迟的感知：

延迟时间	用户体验
0 到16 ms	用户非常注重顺滑的动作，他们讨厌动画不流畅。只要每秒渲染 60 帧，用户就会认为是平滑的动画。也就是 16 帧每秒，这包括了浏览器绘制新帧的时间，留给程序约 10ms 内生成一个帧。
0 到100 ms	在这个时间范围内响应用户的操作，用户会认为结果是即时返回的。再长一点，用户动作和反应之间的联系就断开了。
100 到1000 ms	在这个范围内，用户会认为这是自然的或连续的进程的一部分。对于 web 页面上的大多数用户，他们会认为加载页面和渲染视图是同一件任务。
1000 ms 或更多	超出 1000 ms（1 秒钟），用户就会失去对正在执行的任务的关注。
10000 ms 或更多	超出 10000 ms（10 秒钟），用户会感到沮丧，并可能会放弃任务。他们可能会回来，也可能不再回来了。

用户对性能延迟都抱着不同的观点，这些观点取决于当时的网络条件和硬件性能。比如说：在快速的 WIFI 和高配的电脑上加载 web 网站通常会在 1s 之内，用户已经习惯了这种情况。在移动端的慢速的 3G 网络中会耗费更多时间，所以手机用户通常更有耐心，在 5s 内加载手机页面是一个更现实的目标。

目标和方针

在 RAIL 中，“目标” 和 “方针” 有着明确的含义：

• 目标。与用户体验相关的关键性能指标。例如：点击后在 100 毫秒内渲染完成。因为用户的感知是相对稳定的，这些目标短时间内不会改变。
• 方针。帮助你完成目标的建议。这些可能特指当前的硬件和网络环境，并且它们随时可能修改。

响应：在 50 毫秒内处理完成

目标：在 100 毫秒内完成用户输入到启动的转换，让用户感觉交互是即时的。

方针：

• 确保可见的响应在 100 毫秒内，用户输入的处理在 50 毫秒内。这大多用于输入，例如单击按钮、切换表单或启动动画。这不适用于拖拽或滚动。
• 虽然这听起来可能违反直觉，但立即响应用户输入并不总是正确的做法。你可以多加 100 毫秒的时间来处理其他事情，但是要注意不要阻止用户操作，如果可以的话尽量在后台处理。
• 对于需要超过 50 毫秒才能完成的操作，要始终提供反馈信息。

50ms 还是 100ms？

目标是在 100ms 内响应输入，那么为什么我们的预算只有 50ms？这是因为除了输入操作外，通常还有其他工作需要处理，并且这部分工作占用了响应的可用时间。如果一个应用在空闲的时间以建议的 50ms 块执行工作，这意味着如果输入发生在其中一个工作块期间，输入最多还可以排队 50 毫秒。下图演示了这种情况，它显示了在空闲期间接收的输入是如何排队的，因而减少了可用的处理时间。

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

目标：

• 在 10ms 或更少的时间内生成动画中的每一帧，最大预算是每帧 16 ms（1000 ms / 60 frame/s ≈ 16 ms）,但是浏览器需要大约 6 ms 去渲染他们所以目标是每 10 ms生成一帧。
• 以视觉平滑流畅为目的。当帧率波动时，用户很容易就会发现。

方针

• 像动画这样的高消耗内容，关键是在你能做的地方什么也不做，在你不能做的地方做最小值。利用100毫秒的响应预先计算昂贵的工作，使你最大限度地达到60帧每秒。TODO:优化上面这段话。
• 有关各种动画优化策略，请参阅渲染性能。

要意识到什么是动画。动画不仅仅只是酷炫的 UI 效果，这些交互都算是动画：

• 视觉效果，如输入输出、补间动画、加载动画
• 滚动，例如：快速滚动时，在用户停止后，页面会有一段继续滚动（惯性滑动）。
• 拖拽。动画通常遵循用户的交互，如平移或缩放地图。

闲置时间：充分利用闲置时间

目标：

充分利用闲置时间来尽量达到响应时间在 50ms 内

方针：

• 使用空闲时间来完成耗时工作。例如，在第一次页面加载时，尽可能少的加载数据，然后使用空闲时间去加载。
• 即使是空闲时间也要在 50 ms 内或更少的时间范围内工作，如果超过了这个范围，你可能会干扰到应用程序响应用户输入。
• 如果用户在空闲时间时发生页面交互，要始终让交互拥有最高优先级并终端空闲时间的工作。

加载：在五秒内完成发送和交互

当页面加载是否缓慢时，用户的注意力会被分散，用户可能会认为操作执行失败了。加载速度越快的公司访问量越大，反弹率更低，用户持续访问的时间越长。

目标：

• 相对于用户的设备和网络能力，优化加载速度和性能。一般来说，在慢速 3G 的中档移动设备上，首屏加载在 5 秒内是一个较好的目标。
• 后续内容的加载最好是在 2 秒内。

注意，上面的这些目标可能会随着时间而发生改变。

方针：

• 站在在用户的角度测试你在移动设备和 web 上的负载性能。你可以使用Chrome用户体验报告找出你的用户的分布。如果你的站点没有可用的数据，根据《2019年移动经济》，一部中等规模的Android手机，比如Moto G4，以及一个慢速的3G网络(定义为400ms RTT和400kbps传输速度)是一个很好的全球基准。这里有个可用的测试工具。
• 请记住，虽然你的移动用户的设备可能声称它是在2G、3G或4G连接上，但实际上，由于丢包和网络差异，有效的连接速度通常要慢得多。
• 删除阻塞渲染的内容
• 你不需要在5秒内加载所有东西。考虑使用 懒加载、javaScript 代码分割已经 web.dev 上的其他优化建议。

学会识别影响页面加载性能的可能因素：

• 网络速度和延迟
• 硬件（比如说慢速的 CPU）
• 缓存被清除
• L2 / L3缓存的差异 （L2/L3:CPU的两种缓存技术，L3 更高级）
• JavaScript 的解析

测量 RAIL 的工具

有一些工具可以帮助你计算 RAIL 模型。使用哪种工具取决于你需要什么类型的信息，以及你喜欢什么类型的工作流。

Chrome 开发工具

Chrome 开发工具对页面加载或运行时发生的所有事情进行了深度分析并提供报告。详情参见从分析运行时性能开始这篇文章来熟悉界面 UI。

一下这些特性比较有意义：

• 限制你的 CPU 来模拟一个低性能设备。
• 限制你的网络来模拟低速网络连接。
• 展示主线程的活动以便你记录和查看主线程上的每个事件。
• 在表格中查看主线程的所有活动以便于找出花费时间最多的活动。
• 分析 FPS(frames per second:每秒的帧数)来衡量你的动画是否真的顺滑。
• 通过性能监视器实时监控CPU使用量、JS堆大小、DOM节点、每秒布局等。
• 将网络请求进行记录并可视化。
• 捕获屏幕截图，以便于回放页面在加载或触发动画时的样式，等等。
• 使用查看交互工具，来快速识别 用户与页面交互后页面上发生了什么。
• 当 有潜在问题的侦听器 被触发时，通过高亮来[实时查看性能问题](Find scroll performance issues in real-time)。
• 实时展示绘制事件，以识别可能会损害动画性能的绘制事件。

Lighthouse

可以在Chrome DevTools，web.dev / measure，Chrome扩展程序，Node.js模块以及WebPageTest中使用Lighthouse。你给它一个 URL，他会模拟使用慢速 3G 的中档设备，在页面上运行一系列检查，然后给出关于负载性能的报告，以及关于如何改进的建议。

以下的内容比较有意义：

响应

• [最大潜在输入延迟](Max Potential First Input Delay)，根据主线程的空闲时间，估计你的应用响应用户输入的时间。
• 不使用被动侦听器来提高滚动性能。
• 完全堵塞时间，测量堵塞页面响应的用户输入(如鼠标点击、屏幕点击或键盘按键)的总时间。
• 交互时间，测量用户能和页面内所有元素交互的时间。

加载

• 网用户输入 url 后是否使用了 service worker 来控制页面，Service Worker 可以在用户设备上存储公共资源，从而减少通过网络获取资源的时间。
• 在移动设备上页面加载是否不够快。
• 去除堵塞渲染的资源。
• 图片懒加载。
• 适当大小的图片，不要使用比视口窗呈现的尺寸大很多的图像。
• 不要链式发起关键请求（在可以避免的情况下）。
• 不要为所有资源都使用 http2。
• 将图片编码（用于小图片，用以减少 http 请求）。
• 使用文本压缩。
• 避免大型的网络载荷。
• 避免过多的 DOM 数量，通过仅传输呈现的页面所需的 DOM节点来减少请求大小。

WebPageTest

WebPageTest 是一个 web 性能工具，它使用真正的浏览器访问 web 页面并收集各项时间参数。在webpagetest.org/easy输入一个 URL ，以获取真实Moto G4设备上使用慢速 3G 网络的页面加载性能的详细报告。 您还可以在这个里面配置Lighthouse的相关配置。

总结

如果用户体验是一段旅程，那么 RAIL 模型就是旅程中的一个镜头。了解用户如何看待你的网站，以便制定对用户体验影响最大的性能目标。

• 以用户为中心。
• 在 100 毫秒内响应用户输入。
• 当动画播放时要在 10 毫秒内产生一帧。
• 最大化利用空闲时间。
• 在 5000 毫秒内加载好交互内容。

译者的话

这一章对 RAIL 模型和性能方针和目标进行了大概的介绍和举例，先让你知道有那么个东西，在后文中会详细介绍每一步骤如何操作。

RAIL 模型的概念贯穿整个系列，理解 RAIL 模型非常重要。通过对这几个用户体验的解析和归纳，得出了 RAIL 模型，通过 RAIL 模型再反过来优化加载过程和用户体验。再一个比较重要的就是确认了性能延迟指标：1s 以内。

理解 RAIL 模型中目标和方针的概念。目标有着明确的目的和限制，并且是长期稳定的。方针是有实效性的，用来辅助完成目标，是短期的可变的。我们可以对自己的项目进行研究思考，参照例子，针对项目写出四个操作的目标和方针。

最后给出了如何利用 RAIL 模型和 RAIL 模型的工具，并给出了如何使用的教程。有一些在平时开发中已经使用到了，有一些比较生僻但很有意义。可惜的是里面的教程也是英文的，有空再翻译一下吧。

欢迎关注我的个人微信公众号：前端 stack，每周分享一篇外文技术翻译哦

---

原文地址：https://web.dev/rail/