转载

RAIL简介：一个以用户为中心的性能模型

web性能优化，这是大家耳熟能详的东西了。

一说到性能优化，大家可能立马就会想到和加载相关的时间了，比如首字节时间、白屏时间、首屏时间、用户可交互时间、DOMContentLoaded时间、onLoad时间等等，但是不同的人也许会有不同的衡量标准，比如有些人比较重视白屏时间，有的比较关注首屏时间等，这并非完全一致的。当然我们可能还会考虑其他方面的性能优化问题，比如DOM渲染、60FPS动画、benchmarks等，但是我们应该什么时候去做优化呢？一直做？所有都做？这可能有点不切实际。

我们大部分人都没有足够的时间投入到优化工作中，我们需要一个权威的标准来告诉我们哪些重要的事情是必须优化的和哪些次要的。

对此，Chrome团队提出了一个以用户为中心的性能模型： RAIL 。

在我们深入了解 RAIL 之前，我们先回想一下，我们为什么要做性能优化？其实无非就是一个字，“慢”！

一个DOM操作很慢？一个网页加载很慢？在 <head> 中加载一个 <script> 很慢？JavaScript动画很慢？一个20ms的操作很慢？那么0.5s或者10s呢？...

显然不同的操作是需要不同数量级时间的，脱离了这个操作的上下文谈快慢是没有任何意义的。当你在加载一个几十kb的文件时，0.5s也许用户觉得没有问题，但是如果是一个tap操作要等0.5s才响应，那估计用户早就掀桌子走人了。

所以“什么是慢？”，其实就是用户觉得这个操作怎么样，毕竟我们的站点是为用户而建的。

这就是RAIL所谓的“Focus On The User”。

Focus On The User

时至今日，web已经不是以前那种简单的静态页面了，我们的站点越来越多样化，对交互体验要求越来越高了，我们会想方设法地提高站点的用户体验，以期望留住更多用户。

什么样的体验才是好的呢？一个重要的准则就是要让用户忙碌起来，我们不能让用户等待！

其实很早之前，人们就一直在探索web站点的体验性，这个调研就提出了响应时间的3个重要限制，分别是0.1s、1s、10s；然而现在已经是2016了，我们当然不会再以这3个临界值为标准了，Chrome团队提出了一个参考标准：

延时	用户行为
0-16ms	对于一个60fps刷新频率的屏幕，这个时间范围代表了屏幕渲染一个单独帧的时间（1000/60~=16ms)。人们非常擅长跟踪运动，他们不喜欢那些不符合预期的运动，也不喜欢可变帧率和周期性停止。
0-100ms	在这个时间范围内向用户做出响应，他们会感觉到这样的结果是即时的。超过100ms，行动和反应之间的连接就会被破坏。
100-300ms	用户会感受到一个轻微的可察觉的延迟。
300-1000ms	在这个时间范围内，事情看起来是断断续续的。对web上得大多数用户，加载页面和改变视图都代表了一个任务。
1000+ms	超出1s，用户会渐渐地对他们正在执行的任务失去耐心。
10000+ms	用户会绝望的，然后放弃任务，并且不会再爱了。