RAIL 是一种以用户为中心的性能模型，它提供了一种思考性能的结构。该模型将用户体验细分为关键操作（例如点按、滚动、加载），并帮助您为每个操作定义效果目标。
RAIL 代表 Web 应用生命周期的四个不同方面：响应、动画、空闲和加载。用户对每种情境都有不同的性能预期，因此性能目标是根据情境和有关用户如何感知延迟的用户体验研究来定义的。
专注于满足用户需求
让用户成为性能工作的焦点。下表介绍了用户如何感知性能延迟的关键指标：
用户对性能延迟的感知| 0 至 16 毫秒 | 用户非常擅长跟踪运动，他们不喜欢不流畅的动画。只要每秒渲染 60 个新帧，用户就会觉得动画很流畅。即每帧 16 毫秒，其中包括浏览器将新帧绘制到屏幕上所需的时间，因此应用大约有 10 毫秒的时间来生成一帧。 |
| 0 至 100 毫秒 | 在此时间窗口内响应用户操作，用户会感觉结果是即时的。如果时间过长，操作与反应之间的联系就会断开。 |
| 100 至 1000 毫秒 | 在此窗口中，各项任务会自然而然地连续推进。对于大多数 Web 用户而言，加载网页或更改视图代表一项任务。 |
| 1000 毫秒或更长时间 | 超过 1,000 毫秒（1 秒）后，用户会失去对正在执行的任务的注意力。 |
| 10000 毫秒或更长时间 | 超过 10,000 毫秒（10 秒）后，用户会感到沮丧，并可能会放弃任务。他们可能会也可能不会再回来。 |
目标和准则
在 RAIL 的上下文中，术语“目标”和“准则”具有特定含义：
目标。与用户体验相关的关键效果指标。例如，点按后在 100 毫秒内绘制。由于人类的感知相对恒定，因此这些目标不太可能在短期内发生变化。
指南。可帮助您实现目标的建议。这些建议可能特定于当前的硬件和网络连接条件，因此可能会随时间而变化。
响应：在 50 毫秒内处理事件
目标：在 100 毫秒内完成由用户输入发起的过渡，让用户感觉互动是即时的。
指南：
为确保在 100 毫秒内做出可见响应，请在 50 毫秒内处理用户输入事件。这适用于大多数输入，例如点击按钮、切换表单控件或启动动画。这不适用于轻触拖动或滚动。
虽然这听起来可能不合常理，但立即响应用户输入并不总是正确的做法。您可以使用这 100 毫秒的时间窗口来执行其他耗费资源的工作，但请注意不要阻塞用户。尽可能在后台执行工作。
对于需要超过 50 毫秒才能完成的操作，请始终提供反馈。
50 毫秒还是 100 毫秒？
目标是在 100 毫秒内响应输入，那么为什么我们的预算只有 50 毫秒？这是因为除了输入处理之外，通常还会执行其他工作，而这些工作会占用一部分可用于可接受输入响应的时间。如果应用在空闲时间以建议的 50 毫秒区块执行工作，这意味着如果输入发生在其中一个工作区块期间，则最多可以排队 50 毫秒。考虑到这一点，可以安全地假设只有剩余的 50 毫秒可用于实际输入处理。下图直观地展示了这种影响，其中显示了在空闲任务期间收到的输入如何排队，从而减少了可用的处理时间：
动画：在 10 毫秒内生成一帧
目标：
在 10 毫秒或更短时间内生成动画中的每一帧。从技术上讲，每帧的最大预算为 16 毫秒（1000 毫秒/每秒 60 帧 ≈ 16 毫秒），但浏览器需要大约 6 毫秒来渲染每帧，因此每帧的预算为 10 毫秒。
力求实现视觉流畅性。用户会注意到帧速率的变化。
指南：
在动画等高压力点，关键在于尽可能不执行任何操作，在无法避免时执行绝对最少的操作。尽可能利用 100 毫秒的响应时间来预先计算开销较大的作业，从而最大限度地提高达到 60 fps 的几率。
如需了解各种动画优化策略，请参阅渲染性能。
- 视觉动画，例如进入和退出、补间动画以及加载指示器。
- 滚动。这包括快速滑动，即用户开始滚动，然后松开，页面继续滚动。
- 拖动。动画通常会跟随用户互动，例如平移地图或双指张合进行缩放。
空闲：最大限度延长空闲时间
目标：尽可能延长空闲时间，以提高网页在 50 毫秒内响应用户输入的几率。
指南：
利用空闲时间完成延迟的工作。例如，对于初始网页加载，请尽可能少地加载数据，然后使用空闲时间加载其余数据。
在空闲时间执行工作，耗时不超过 50 毫秒。如果超过此时间，您可能会干扰应用在 50 毫秒内响应用户输入的能力。
如果用户在空闲时间工作期间与页面互动，则用户互动应始终具有最高优先级，并中断空闲时间工作。
加载：在 5 秒内呈现内容并可供用户互动
当网页加载缓慢时，用户的注意力会分散，并且用户会认为任务已中断。加载速度快的网站具有更长的平均会话时长、更低的跳出率和更高的广告可见率。
目标：
根据用户的设备和网络功能，优化快速加载性能。目前，首次加载的一个良好目标是，在连接速度较慢的 3G 网络的中端移动设备上，5 秒或更短的时间内加载页面并可供用户互动。
对于后续加载，理想的目标是在 2 秒内加载网页。
指南：
在用户常用的移动设备和网络连接上测试加载性能。您可以使用 Chrome 用户体验报告了解用户的连接分布。如果您的网站没有这些数据，2019 年移动经济建议，一个不错的全球基准是中端 Android 手机（例如 Moto G4）和慢速 3G 网络（定义为 400 毫秒 RTT 和 400 kbps 传输速度）。WebPageTest 上提供了此组合。
请注意，虽然您的典型移动用户的设备可能声称其使用的是 2G、3G 或 4G 连接，但实际上，由于丢包和网络差异，有效连接速度通常要慢得多。
您不必在 5 秒内加载所有内容，即可产生完全加载的感知。考虑延迟加载图片、对 JavaScript 软件包进行代码拆分，以及 web.dev 上建议的其他优化措施。
用于衡量 RAIL 的工具
有几种工具可以帮助您自动执行 RAIL 测量。您使用哪种方法取决于您需要的信息类型以及您偏好的工作流类型。
Chrome DevTools
Chrome 开发者工具可对网页加载或运行期间发生的所有情况进行深入分析。请参阅分析运行时性能入门，熟悉性能面板界面。
以下 DevTools 功能尤为重要：
限制 CPU，以模拟性能较弱的设备。
限制网络以模拟较慢的连接。
查看主线程活动，以查看录制期间在主线程上发生的每个事件。
在表格中查看主线程活动，以便根据活动所占用的时间长短对活动进行排序。
分析每秒帧数 (FPS)，以衡量动画是否真正流畅运行。
使用性能监视器实时监控 CPU 使用率、JS 堆大小、DOM 节点、每秒布局数等。
使用网络部分直观呈现录制期间发生的网络请求。
在录制时捕获屏幕截图，以准确回放网页加载或动画触发等操作期间的页面外观。
查看互动，快速了解用户与网页互动后发生了什么。
每当可能存在问题的监听器触发时，通过突出显示页面来实时发现滚动性能问题。
实时查看绘制事件，以识别可能损害动画性能的高开销绘制事件。
灯塔
Lighthouse 可在 Chrome 开发者工具、PageSpeed Insights、Chrome 扩展程序、Node.js 模块和 WebPageTest 中使用。您只需提供一个网址，它就会模拟一个使用慢速 3G 连接的中端设备，对该网页运行一系列审核，然后为您提供加载性能报告以及改进建议。
以下审核尤为重要：
答案
Max Potential First Input Delay。根据主线程空闲时间，估算应用响应用户输入所需的时间。
Total Blocking Time。 衡量网页无法响应用户输入（例如鼠标点击、屏幕点按或键盘按键）的总时长。
Time To Interactive。 衡量用户何时可以持续与所有页面元素互动。
加载
未注册控制页面和 start_url 的 Service Worker。Service Worker 可以在用户设备上缓存常用资源，从而减少通过网络提取资源所花费的时间。
推迟加载屏幕外图片。推迟加载屏幕外图片，直到需要它们时再加载。
适当调整图片大小。请勿提供明显大于移动视口中呈现尺寸的图片。
避免 DOM 规模过大。仅传送呈现网页所需的 DOM 节点，以减少网络字节数。
WebPageTest
WebPageTest 是一款 Web 性能工具，它使用真实的浏览器访问网页并收集计时指标。在 webpagetest.org/easy 中输入网址，即可获取有关该网页在连接到慢速 3G 网络的真实 Moto G4 设备上的加载性能的详细报告。您还可以将其配置为包含 Lighthouse 审核。
摘要
RAIL 是一种视角，它将网站的用户体验视为由不同互动组成的历程。了解用户对您网站的看法，以便设定对用户体验影响最大的效果目标。
专注于满足用户需求。
在 100 毫秒内响应用户输入。
在动画或滚动时，在 10 毫秒内生成一帧。
最大限度地增加主线程空闲时间。
在 5000 毫秒内加载互动内容。