RAIL 是一种以用户为中心的性能模型，可为性能思考提供结构。该模型将用户体验分解为关键操作（例如点按、滚动、加载），并帮助您为每项操作定义性能目标。
RAIL 代表 Web 应用生命周期的四个不同方面：响应、动画、空闲和加载。用户对每种情境下的性能有不同的期望，因此性能目标是根据情境和用户对延迟的感知情况的用户体验研究来定义的。
专注于满足用户需求
将用户作为性能优化工作的重点。下表介绍了用户感知到的性能延迟的关键指标：
用户对性能延迟的感知| 0 至 16 毫秒 | 用户非常擅长追踪运动，因此不喜欢不流畅的动画。只要每秒渲染 60 个新帧，他们就会认为动画流畅。也就是说，每帧 16 毫秒，包括浏览器将新帧绘制到屏幕上所用的时间，这使得应用大约有 10 毫秒的时间来生成帧。 |
| 0 至 100 毫秒 | 在此时间范围内响应用户操作，用户会感觉结果是即时的。如果时间再长，行动与反应之间的联系就会断开。 |
| 100 至 1000 毫秒 | 在此窗口中，所有内容都像是任务的自然延续。对于网络上的大多数用户来说，加载网页或更改视图都表示一项任务。 |
| 1000 毫秒或更长 | 超过 1000 毫秒（1 秒）后，用户就会无法专注于正在执行的任务。 |
| 10000 毫秒或更长 | 如果超过 10,000 毫秒（10 秒），用户会感到沮丧，并可能会放弃任务。他们可能稍后会回来，也可能不会回来。 |
目标和准则
在 RAIL 的背景下，目标和准则这两个术语具有特定含义：
目标。与用户体验相关的关键效果指标。例如，点按即可在 100 毫秒内完成绘制。由于人类的感知能力相对稳定，因此这些目标在短期内不太可能发生变化。
准则。可帮助您实现目标的建议。这些建议可能与当前的硬件和网络连接条件有关，因此可能会随时间推移而发生变化。
响应：在 50 毫秒内处理事件
目标：在 100 毫秒内完成由用户输入触发的过渡，让用户感觉互动是即时完成的。
准则：
为确保在 100 毫秒内获得可见的响应，请在 50 毫秒内处理用户输入事件。这适用于大多数输入，例如点击按钮、切换表单控件或启动动画。此设置不适用于触摸拖动或滚动。
虽然这可能听起来有悖常理，但并非总是应该立即响应用户输入。您可以使用这 100 毫秒的时间窗口来执行其他耗时的工作，但请注意不要阻塞用户。尽可能在后台执行工作。
对于耗时超过 50 毫秒的操作，请务必提供反馈。
50 毫秒还是 100 毫秒？
目标是在 100 毫秒内响应输入，那么为什么我们的预算只有 50 毫秒？这是因为除了输入处理之外，通常还会执行其他工作，而这些工作会占用可用于实现可接受的输入响应的时间。如果应用在空闲期间以建议的 50 毫秒块执行工作，这意味着如果输入发生在其中一个工作块期间，则最多可以排队 50 毫秒。考虑到这一点，可以放心地假设只有剩余的 50 ms 可用于实际的输入处理。下图直观地展示了这种效应，其中显示了在空闲任务期间收到的输入是如何排队的，从而减少了可用的处理时间：
动画：在 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 以模拟性能较低的设备。
限制网络速度，以模拟较慢的连接。
查看主线程活动：查看录制期间主线程上发生的所有事件。
在表格中查看主线程 activity，以便根据哪些 activity 占用的时间最多来对 activity 进行排序。
分析每秒帧数 (FPS)，以衡量动画是否真正流畅运行。
借助性能监控器，您可以实时监控 CPU 使用率、JS 堆大小、DOM 节点数、每秒布局数等。
使用网络部分直观呈现您在录制时发生的网络请求。
在录制时截取屏幕截图，以便准确重现网页在加载时或动画触发时的外观。
查看互动，快速了解用户与网页互动后发生了什么。
通过在可能存在问题的监听器触发时突出显示网页，实时发现滚动性能问题。
实时查看绘制事件，以识别可能会损害动画性能的代价高昂的绘制事件。
灯塔
Lighthouse 可在 Chrome 开发者工具中、PageSpeed Insights 中、作为 Chrome 扩展程序、作为 Node.js 模块以及在 WebPageTest 中使用。您只需提供一个网址，它就会模拟使用慢速 3G 连接的中端设备，对网页进行一系列审核，然后为您提供有关加载性能的报告，以及有关如何改进的建议。
以下审核尤为相关：
答案
首次输入延迟最长预估值。根据主线程空闲时间，估算应用需要多长时间才能响应用户输入。
Total Blocking Time。 衡量网页无法响应用户输入（例如鼠标点击、屏幕点按或键盘按键）的总时长。
可交互时间。 衡量用户何时可以持续与所有网页元素互动。
加载
无法注册用于控制网页和 start_url 的 Service Worker。Service Worker 可以在用户设备上缓存常用资源，从而减少通过网络获取资源所花费的时间。
推迟加载屏幕外图片。延迟加载屏幕外图片，等到需要这些图片时再加载。
适当调整图片大小。请勿提供比在移动设备视口中呈现的尺寸大得多的图片。
避免 DOM 规模过大。仅传送渲染网页所需的 DOM 节点，从而减少网络字节数。
WebPageTest
WebPageTest 是一款网页性能工具，可使用真实浏览器访问网页并收集时间指标。在 webpagetest.org/easy 中输入网址，即可获得详细报告，了解网页在连接到慢速 3G 网络的 Moto G4 实际设备上的加载性能。您还可以将其配置为包含 Lighthouse 审核。
摘要
RAIL 是一种视角，可将网站的用户体验视为由不同互动组成的历程。了解用户对您网站的感知，以便设定对用户体验影响最大的效果目标。
专注于满足用户需求。
在 100 毫秒内响应用户输入。
在动画或滚动时，在 10 毫秒内生成一个帧。
最大限度地延长主线程空闲时间。
在 5000 毫秒内加载互动内容。