RAIL 模型
RAIL 模型是一种以用户为中心的性能模型，提供一套评估用户交互性能的方法。
推荐将它用于评估优化游戏、社交等交互性能要求高的应用。
RAIL 代表 Web 应用生命周期的四个不同方面：
- Response 响应
- Animation 动画
- Idle 空闲
- Load 加载
用户对这些情况分别有不同的性能期望。
用户对性能延迟的看法
| 耗时 | 用户感受 |
|---|---|
| 0 ~ 16ms | 在这个耗时内，动画流畅。这要求每秒60帧，每帧只有 16 毫秒时间，包括浏览器渲染时间，应用约有 10 毫秒时间来生成一帧。 |
| 0 ~ 100ms | 响应用户交互的时间，更长的时间会让人感觉响应慢 |
| 100 ~ 1000ms | 在这个时间内，用户觉得交互是连续的，例如更新视图、切换页面 |
| 1000ms ~ | 超过1s，用户会分散注意力 |
| 10000ms ~ | 超过10s，用户会失去耐心，考虑放弃 |
用户对性能延迟的感受，取决于网络和硬件条件。
例如，使用台式机加有线宽带的用户，比使用新iPhone加5G网络的用户更没有耐心，而使用旧手机和3G网络的用户会耐心等待页面响应。在移动设备上，5s内完成加载是更现实的目标。
目标和准则
目标
与用户体验相关的关键性能指标。
例如，点击即可在 100ms 内绘制。由于人类的感知基本相同，这些目标长期都不太可能发生改变。
准则
帮助您实现目标的建议。
这些准则可能特定于当前硬件和网络连接条件，因此可能会随着时间而改变。
Response
目标：在 100 毫秒内完成由用户输入发起的变化，让用户感觉交互是即时的。
准则：
- 为了确保在 100 毫秒内产生可见响应，需要在 50 毫秒内处理完用户输入事件。适用于除了触摸、滚动外的大多数事件。触摸、滚动的要求标准更高，应该在 16 毫秒内响应，以保障交互体验流畅。
- 响应并不是越快越好，例如连续交互的情况下，应根据实际需要做节流、防抖。
- 对于需要 50 毫秒以上才能完成的操作，及时提供操作反馈。
Animation
目标：在 10ms 内生成动画的每一帧。浏览器需要大约 6 毫秒来渲染一帧。
准则：利用播放动画前的 100ms 响应时间来预先完成计算，尽量不要在播放动画时执行其他操作。
以下交互属于动画：
- 视觉动画：进入、退出、loading动画
- 滚动
- 拖放
- 触摸交互，如平移、缩放
Idle
目标：最大限度增加空闲时间以提高页面在 50 毫秒内响应用户输入的几率。
准则：
- 利用空闲时间继续延迟加载
- 将任务分片到 50ms 内，以便及时响应用户交互产生的任务
- 用户交互任务是最高优先级的，应中断空闲时间任务
Load
目标：
- 对于移动设备，首次加载的理想目标是 5s 内
- 对于后续加载，加载页面的理想目标是 2s 内
影响页面加载性能的因素：
- 网速
- 硬件（CPU）
- 缓存失效
- 解析 JavaScript