RAIL 是一种以用户为中心的性能模型，它为思考性能提供了结构。该模型将用户的体验分解为关键操作（例如，点击、滚动、加载），并帮助您为每个操作定义性能目标。
RAIL 代表 Web 应用程序生命周期的四个不同方面：响应 (Response)、动画 (Animation)、空闲 (Idle) 和加载 (Load)。用户对这些上下文中每一个都有不同的性能期望，因此性能目标的定义基于上下文和关于用户如何感知延迟的 UX 研究。
关注用户
使用户成为您性能工作的焦点。下表描述了用户如何感知性能延迟的关键指标
用户对性能延迟的感知| 0 到 16 毫秒 | 用户非常擅长跟踪运动，并且他们不喜欢动画不流畅的情况。只要每秒渲染 60 个新帧，他们就会认为动画是流畅的。即每帧 16 毫秒，包括浏览器将新帧绘制到屏幕上所需的时间，这为应用程序留出了大约 10 毫秒来生成帧。 |
| 0 到 100 毫秒 | 在此时间窗口内响应用户操作，用户会感觉结果是即时的。任何更长的时间，操作和反应之间的联系就会断开。 |
| 100 到 1000 毫秒 | 在此窗口内，事物感觉是任务的自然且连续的进展的一部分。对于 Web 上的大多数用户来说，加载页面或更改视图代表一项任务。 |
| 1000 毫秒或更长 | 超过 1000 毫秒（1 秒），用户会失去对他们正在执行的任务的关注。 |
| 10000 毫秒或更长 | 超过 10000 毫秒（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 秒内交付内容并变为可交互
当页面加载缓慢时，用户的注意力会游移，并且用户会认为任务已中断。加载速度快的网站具有更长的平均会话时间、更低的跳出率和更高的广告可见度。
目标:
针对用户的设备和网络功能优化快速加载性能。目前，首次加载的良好目标是在5 秒或更短的时间内在具有慢速 3G 连接的中端移动设备上加载页面并变为可交互。
对于后续加载，一个好的目标是在 2 秒内加载页面。
指南:
在用户的常用移动设备和网络连接上测试加载性能。您可以使用Chrome 用户体验报告来了解用户的连接分布。如果您的网站没有数据，《2019 年移动经济》建议，良好的全球基准是中端 Android 手机（例如 Moto G4）和慢速 3G 网络（定义为 400 毫秒 RTT 和 400 kbps 传输速度）。此组合在 WebPageTest 上可用。
请记住，尽管您的典型移动用户的设备可能声称它处于 2G、3G 或 4G 连接上，但实际上，由于数据包丢失和网络差异，有效连接速度通常会慢得多。
您不必在 5 秒内加载所有内容即可产生完整加载的感知。考虑延迟加载图像、代码拆分 JavaScript 包以及 web.dev 上建议的其他优化。
用于衡量 RAIL 的工具
有一些工具可以帮助您自动化 RAIL 测量。您使用的工具取决于您需要的信息类型以及您喜欢的Workflow类型。
Chrome DevTools
Chrome DevTools 提供了对页面加载或运行时发生的一切的深入分析。请参阅开始分析运行时性能以熟悉性能面板 UI。
以下 DevTools 功能尤其相关
限制您的 CPU 以模拟性能较低的设备。
限制网络以模拟较慢的连接。
查看主线程活动以查看您在录制时主线程上发生的每个事件。
在表格中查看主线程活动以根据占用时间最多的活动对活动进行排序。
分析每秒帧数 (FPS) 以衡量您的动画是否真正流畅运行。
可视化网络请求，这些请求在您使用网络部分进行录制时发生。
在录制时捕获屏幕截图，以回放页面加载时或动画触发时页面的确切外观，等等。
查看交互以快速识别用户与页面交互后页面上发生的情况。
实时查找滚动性能问题，方法是在每当可能存在问题的侦听器触发时突出显示页面。
实时查看绘制事件，以识别可能损害动画性能的代价高昂的绘制事件。
Lighthouse
Lighthouse 在 Chrome DevTools 中、PageSpeed Insights 中、作为 Chrome 扩展程序、作为 Node.js 模块以及在 WebPageTest 中可用。您为其提供 URL，它模拟具有慢速 3G 连接的中端设备，在页面上运行一系列审核，然后为您提供有关加载性能的报告以及有关如何改进的建议。
以下审核尤其相关
响应
最大潜在首次输入延迟。根据主线程空闲时间估算您的应用响应用户输入所需的时间。
总阻塞时间。衡量页面被阻止响应用户输入（例如鼠标点击、屏幕点击或键盘按键）的总时间。
可交互时间。衡量用户何时可以始终如一地与所有页面元素进行交互。
加载
未注册控制页面和 start_url 的 Service Worker。Service Worker 可以缓存用户设备上的常用资源，从而减少通过网络获取资源所花费的时间。
延迟加载屏幕外图像。延迟加载屏幕外图像，直到需要它们为止。
正确调整图像大小。不要提供比移动视口中渲染的大小大得多的图像。
避免过大的 DOM 大小。仅运送渲染页面所需的 DOM 节点，以减少网络字节数。
WebPageTest
WebPageTest 是一种 Web 性能工具，它使用真实浏览器访问网页并收集计时指标。在 webpagetest.org/easy 中输入 URL，以获取有关页面在具有慢速 3G 连接的真实 Moto G4 设备上的加载性能的详细报告。您还可以将其配置为包含 Lighthouse 审核。
总结
RAIL 是一种透镜，用于将网站的用户体验视为由不同交互组成的旅程。了解用户如何感知您的网站，以便设定对用户体验影响最大的性能目标。
关注用户。
在 100 毫秒内响应用户输入。
在动画或滚动时，在 10 毫秒内生成一帧。
最大限度地利用主线程空闲时间。
在 5000 毫秒内加载交互式内容。