RAIL 其实是 Response、Animation、Idle 以及 Load 四个单词的缩写，是 Google 团队在 2015年提出的性能模型，用于提升浏览器内的用户体验和性能。
RAIL模型的理念是“以用户为中心，最终目标不是让您的网站在任何设备上都能运行的很快，而且使用户满意”
四个单词的阐述：
-
相应（Response） ：应该尽可能快速的响应用户，应该在100ms以内响应用户输入。
-
动画（Animation） ：在展示动画的时候，每一帧应该以 16ms 进行渲染，这样可以保持动画效果的一致性，并且避免卡顿
-
空闲（Idle） ：当使用 Javascript 主线程的时候，应该把任务划分到执行时间小于 50ms 的片段中，这样可以释放线程以进行用户交互
-
加载（Load） ：应该在小于 1s 的时间内加载完成你的网站，并可以进行交互。
根据网络条件和硬件的不同，用户对于性能延迟的理解也会有所不同，eg：通过WIFI连接的功能强大的台式机加载站点通常可以在1s内完成，用户对此已经习惯，但是在3G、4G这样连接速度较慢的移动设备上加载网站需要花费更多的时间，因此移动用户通过更有耐心，在移动设备上加载 5S 是一个更现实的目标
这四个单词代表着与网站和应用的生命周期相关的方面，这些方面以不同的方式影响着整个网站的性能
我们将以用户来作为之后性能优化的核心，下面先了解下用户对于延迟的反应
| 延迟 | 用户反映 |
|---|---|
| 0 ~ 16ms | 人眼可以感知每秒 60 帧的动画，即每帧 16 ms，除了浏览器将一帧画面绘制到屏幕上的时间，网站应用大约需要 10ms 来生成一帧 |
| 0 ~ 100ms | 在该时间范围内响应用户操作，才会是流畅的体验 |
| 100 ~ 1000ms | 能够感觉到明显的延迟 |
| >1s | 用户的注意力将离开对执行任务的关注 |
| >10s | 用户感到失望，可能会放弃任务 |
响应
指标：应该尽可能快速的响应用户，应该在 100ms 以内响应用户输入。
网站性能对于响应方面的要求是，在用户感知延迟之前接收到操作的反馈。比如用户进行了文本输入、按钮单击、表单切换及启动动画等操作后，必须在 100ms 内收到反馈，如果超过 100ms 的时间窗口，用户就会感知延迟。
看似很基本的用户操作背后，可能会隐藏着复杂的业务逻辑处理及网络请求与数据计算。对此我们应当谨慎，将较大开销的工作放在后台异步执行，而即便后台处理要数百毫秒才能完成的操作，也应当给用户提供及时的阶段性反馈。
比如在单击按钮向后台发起某项业务处理请求时，首先反馈给用户开始处理的提示，然后在处理完成的回调后反馈完成的提示。
动画
指标：在展示动画的时候，每一帧应该以 10ms 进行渲染，这样可以保持动画效果的一致性，并且避免卡顿。
前端所涉及的动画不仅有炫酷的UI特效，还包括滚动和触摸拖动等交互效果，而这一方面的性能要求就是流畅。众所周知，人眼具有视觉暂留特性，就是当光对视网膜所产生的视觉在光停止作用后，仍能保留一段时间。
研究表明这是由于视神经存在反应速度造成的，其值是 1/24s，即当我们所见的物体移除后，该物体在我们眼中并不会立即消失，而会延续存在 1/24s 的时间。对动画来说，无论动画帧率有多高，最后我们仅能分辨其中的 30 帧，但越高的帧率会带来更好的流畅体验，因此动画要尽力达到 60fps 的帧率。
目前大多数设备的屏幕刷新率为 60 次/秒，那么浏览器渲染动画或页面的每一帧的速率也需要跟设备屏幕的刷新率保持一致。所以根据 60fps 帧率的计算，每一帧画面的生成都需要经过若干步骤，一帧图像的生成预算为 16ms（1000ms / 60 ≈ 16.66ms），除去浏览器绘制新帧的时间，留给执行代码的时间仅 10ms 左右。如果无法符合此预算，帧率将下降，并且内容会在屏幕上抖动。 此现象通常称为卡顿，会对用户体验产生负面影响。关于这个维度的具体优化策略，会在后面优化渲染过程的相关章节中详细介绍。
今天先给大家整理这么多，欢迎大家砸坑，也欢迎大家关注小编博客
