RAIL，以用户为核心的性能模型

程序员文章站 2022-04-27 20:24:24

...

难道对性能提建议还能有不好的吗？其实我们都在回避这个问题的答案：每条优化建议的后面都跟着警告和免责声明，有时候这些建议还是相互矛盾的。像“ DOM 太慢了”或者“尽可能地使用 CSS 动画”这样的大标题之下，掩盖着的实际场景要复杂的多。

现在最常见的性能话题大概就是“加载时间”吧，就拿它来举例。有人用 Speed Index 作为衡量的标准；有人以页面首次绘制时间为准；仍有人使用 body.onload 或 DOMContentLoaded 又或者别的事件为准。衡量的标准并不统一。还有其他衡量性能的方法，比如用 JavaScript 基准（JavaScript benchmark）；比如60 FPS。但是这些标准适用在什么场合？任何时间点都适用吗？听起来有点不现实啊。

我们当中几乎没有人可以把时间完全投入在优化上，所以我们需要一个标准来告诉我们现在要去优化什么东西（或者什么东西暂时不需要优化了）。该说的都说了，现在我们需要一个明确的指引告诉开发者，在用户的眼里“性能”意味着什么，毕竟用户才是我们最终服务的对象。

Chrome 团队已经考虑过这个问题，并提出了 RAIL 模型。用户在这个性能模型中扮演了很重要的角色。

如果你迫不及待想要把 RAIL 的精髓分享给你的团队，那可以说说这些：

RAIL 将用户体验根据关键动作（比如，轻触、拖拽、滚动、加载）分割到了不同的模块中。
RAIL 给这些动作制定了性能目标（比如，轻触后的绘制要在100毫秒之内完成）。
RAIL 提供了一个思考性能问题的方法论，所以当设计师和开发者想要处理对用户影响最大的问题的时候有法可依。
在讲如何运用 RAIL 以及如何使用它辅助你的项目前，让我们先看看这个模型是怎么来的。就从大家都很讨厌的词“慢”，开始吧。

“慢”

改变 DOM 结构会拖慢性能？如果在 <head> 标签中添加 <script>，让脚本一开始就被加载呢？JavaScript 动画比 CSS 动画要慢。一个操作要用 20 毫秒会不会太慢了？0.5 秒呢？10 秒呢？

不同的操作需要的完成时间长短不一，这是肯定的。脱离内容谈加载速度都是耍流氓。举个例子，在浏览器空闲的时间里，代码在 touch 句柄和游戏循环（game loop）中的主线路径的性能要求应该是不同的。换言之，用户的性能期望会根据产品的内容不同而不同。我们为用户体验所做的一切能不能被终端用户感知到，才是最重要的。事实上， Google’s ten things we know to be true这篇文章中第一条就是“聚焦于用户，则一切将水到渠成”。

不要再问“‘慢’意为着什么？”了，而应该问“在使用产品时，用户的感受是怎样的”。

以用户为核心，考虑性能

在人机交互领域（HCI）有一个长期的研究项目就是针对这个问题的，你可以从 Jakob Nielsen 的研究成果中得到一些结论。基于研究成果，和现在最受欢迎的动画效果，我们得到以下阀值：

100 毫秒：用户采取操作后，要在 100 毫秒内收到响应，才不会有延迟感。
1 秒：在当前时窗中，物体要显得自然又有整体性。超过了 1 秒，用户就对当前任务的会失去耐心。对于 web 中的大部分用户而言，加载页面或者改变视图就需要在 1 秒内完成。
16 毫秒：屏幕一秒钟渲染 60 次，所以每一帧渲染到屏幕上至多 16 毫秒（1000毫秒/60 ~= 16）。人们本能地会跟随运动，当动画帧出现中断或者卡顿，我们常常会觉得不爽。
有了这些阀值，我们就有了参考的标准，下一步就是将这些值映射到开发中。现在让我们来考虑以下应用场景：

https://youtu.be/4t_Ox_nwHn0
在上面的视频中，用户做了这些事情：

等待页面加载完成，
观看酷炫的动画，
滚动页面，
轻触图标，
观看导航栏展开的动画，
等待页面加载完成，
观看动画，
滚动页面。

给用户的刚刚采取的动作用色块做记号，然后得到下面这张图：

每个色块代表一个动作，你可以观察到一共有4个色块也就是4个动作。emmm，RAIL 也是4个字母呢，美妙的巧合。

让我们再来看一个视频，感受一下交互过程吧：

https://youtu.be/jpJIBQy-a2A

我们可以把交互的过程分成4个独立的模块。在 Google，我们将这些模块称为 RAIL，每个模块都是它们的性能目标，这些目标也是基于我们刚刚介绍过的阀值。

RAIL 性能模型

RAIL 是 response （响应）、 animation（动画）、idle（浏览器空置状态）和 load（加载）。

从这四个模块角度来思考你的产品。如果在每个模块上，你都可以达到性能优化的目标值（也就是上文提及的阀值），那么最终用户感受到的将会是极致的体验。

现在让我们一个个来看。

Response
如果用户点击了一个按钮，你需要保证在用户察觉出延迟之前就得到反馈。无论是表单控制还是执行动画，只要有输入，这个原则都适用。如果没有在合理的时窗内完成响应，也就是*采取动作和得到响应之间出现了断层，用户将会察觉到这个延迟。

响应的速度根本上来说取决于输入的延迟，输入的延迟存在于：指甲触到屏幕玻璃和实际像素到达屏幕之间。你有没有过这样的经历：轻触到某种东西，结果它没有给出任何反应，接着你就会质疑自己那个东西是否真的接收到你的轻触。这种自我怀疑的场景就是我们想要避免的！

响应的主要交互是：

tapping（轻触） – 当用户轻触或者点击一个按钮或者图标时（比如，轻触菜单图标打开一个抽屉导航）。

要得到响应式的回应，我们需要：

在首次收到输入时，在100毫秒内得到回应。
理想情况下，收到的回应就是最终结果。但如果最终结果还需要花更长的时间得到，那也要给用户一个“加载中”的标识，或是颜色的变更，告诉用户“本产品已经接收到了指令，还在处理中”，不至于让用户自我怀疑

2. Animation

动画现在是应用的一大支柱，从滚动到视图变化，都有动画的身影。我们要明确在这段时间里能做些什么，因为用户可能常常是直接操作，帧率的改变很容易被察觉到。但是用户想要的只是流畅的响应而已。

动画包含了以下概念：

视觉动画
这个包括了动画的开始和退出，状态改变时的动画，还有加载标识。

滚动
当用户开始滚动页面，页面出现猛动的情况。

拖拽
当我们需要对用户的拖拽交互在100毫秒以内做出响应时，比如平移地图或者缩放屏幕时，我们需要依赖动画。

要合理地动画，每一帧动画要在16毫秒内完成，才能达到60FPS（1000ms/60 ~= 16.6 ms）。

3. IDLE

要制作响应迅速动画精良的应用通常需要比较长的工时。Optimistic UI模式利用这个技术达到了很好的效果。并非所有工作都要在 response 阶段或者 load 阶段完成：评论引导、组件初始化、数据检索和排序和分析数据的送都不是需要立刻传达给用户的，所以可以在浏览器空闲的时候再处理这些任务。

要想合理地应用浏览器空闲时间，最好把时间以 50 毫秒为单位分组。为什么要这么做呢？在上文里也提到的，用户做出动作后，应用应该在 100 毫秒内给出响应，不应该出现一个模板渲染 2 秒之久。

4. LOAD

页面加载时间是最常见的性能话题。对用户来说最先看到的内容应该是最有意义、最先被加载出来的。接着页面要持续响应用户，绝对不允许出现在滚动页面、轻触或者看动画的时候卡顿。特别是当多个页面使用同一个线程的时候，要实现这样的目标真的很困难。

想要尽快将页面加载出来，我们需要把最需要传达的内容在 1 秒内渲染出来。超过 1 秒钟，用户的注意力就会被分散，当前执行的任务将有中断感。要达到在 1 秒内渲染完毕的目标，我们要优先考虑关键渲染路径，将所有不需要在加载时处理的任务延迟到浏览器空闲时再处理（或根据需求拦加载）。

性能目标

性能本质上来说是逃避工作的艺术，但是当它变得不可逃避的时候，保证你做的工作是高效的、花在处理问题上的时间是值得的。

既然现在我们有了 RAIL 模型，让我们来总结一个性能目标吧。

如何实践

这里有几条好用的提升性能的方法：

将用户的使用场景设定成 MacBook Pro 或者类似配置的机器是不合理的，大多数用户使用的设备都比开发测试时用的设备性能落后个 10 倍！

Nexus 4 配置中端，是很不错测试设备。
在 3G 环境下测试。
仔细分析你的数据，看看你的用户用的都是什么设备。然后你就能在测试阶段感受到 90% 的用户的体验效果啦。

电源和内存

如果达到了上述的性能目标，但把用户的设备搞的内存一点儿不剩还只剩下 10% 的电量，那用户也会很不高兴的。

现在我们还不能确定如何处理共享资源，不过可以确定在之后我们会想出解决方案，到时候就改名为 BLAIMR 或者 PRIMAL 了（B 代表电池，M 代表内存）。

商业前景

通常我们都是为了兴趣而工作，因为我们超爱做一些很酷的东西。我们当然不能凭空想工作，我们需要把商业计划交给经理、持股人还有客户，性能会影响到用户体验的问题，自然也指的关注。

幸运的是，很多大公司都愿意同我们共享数据，来完善这个模型，以下是一些案例：

Google: 2% slower = 2% less searching per user
Yahoo: 400 milliseconds faster = 9% more traffic
AOL: Faster pages = more page views
Amazon: 100 milliseconds faster = 1% more revenue
Shopzilla: 5 seconds faster = 25% more page views, 7 to 12% more revenue
Aberdeen Group: 1 second slower = 11% fewer page views, 7% less conversion
Google uses website speed in search ranking.

总结

RAIL 模型通过将用户的交互行为划分为不同区块，来检验一个产品的用户体验。当你了解了每个交互模块，你将会知道用户期望得到的是什么，换言之，你的目标是什么。

摸索目标的过程很辛苦，但是以诚心对待用户，用户也会如此对待你的（产品）。

资源

如果你想要了解更多关于 RAIL 的资料，可以看看下面的链接：

演示

“Performance RAIL’s: The Art and Science of optimizing for Silicon and Wetware” (slides), Ilya Grigorik, Google, May 2015
“How Users Perceive the Speed of The Web” (slides), Paul Irish, FluentConf, April 2015
“Performance on RAILs” (视频), Paul Lewis, Nordic.js, September 2015

各种文档

“Optimizing Performance,” Web Fundamentals, Google Developers
“Browser Rendering Optimization” (course), Udacity
“Profile” (performance), Google Web Tools, Google Developers
“The RAIL Performance Model,” Web Fundamentals, Google Developers

性能调查

Performance Audit of theverge.com” (July 2015) (complementary slides)
Performance Audit of imore.com” (July 2015)
Performance Audit of m.reddit.com” (July 2015)
Performance Audit of m.espn.com” (April 2015)
Performance Audit of squarespace.com” (April 2015)
Performance Audit of cafepress.com” (April 2015)
Performance Audit of CNET, Wikipedia and Time.com” (February 2015)(complementary slides)
Performance Audit of Wikipedia Rich Editor” (February 2015)

原文链接：Introducing RAIL: A User-Centric Model For Performance

译文来自：知乎作者：kmokidd