原文地址：web.dev/rail/

原文作者：

发布时间：2020年6月10日

RAIL是一个以用户为中心的性能模型，它提供了一个思考性能的结构。该模型将用户的体验分解为关键动作（例如，点击、滚动、加载），并帮助您为每个动作定义性能目标。

RAIL代表Web应用生命周期的四个不同方面：响应、动画、闲置和加载。用户对这些情境中的每一个情境都有不同的性能预期，因此，性能目标的定义要基于情境和用户体验研究，即用户如何感知延迟。

RAIL性能模型的4个部分

关注用户

让用户成为你绩效工作的焦点。下表描述了用户如何看待性能延迟的关键指标。

用户对业绩延迟的看法

/	/
0到16毫秒	用户特别擅长跟踪运动，他们不喜欢动画不流畅。他们认为，只要每秒钟呈现60个新帧，动画就很流畅。每一帧需要16毫秒，其中包括浏览器将新帧绘制到屏幕上所需的时间，因此，一个应用程序产生一帧画面的时间大约为10毫秒。
0到100毫秒	在这个时间窗口内响应用户的操作，用户会觉得结果是即时的。再长一点，动作和反应之间的联系就会被打破。
100到1000毫秒	在这个窗口内，事情会让人觉得是自然而连续的任务进展的一部分。对于网络上的大多数用户来说，加载页面或改变视图代表着一项任务。
1000毫秒或更多	超过1000毫秒（1秒），用户就会失去对正在执行的任务的关注。
10000毫秒或更多	超过10000毫秒（10秒），用户会感到沮丧，很可能放弃任务。他们可能会，也可能不会再回来。

根据网络条件和硬件的不同，用户对性能延迟的感知也不同。例如，在功能强大的台式机上通过快速的Wi-Fi连接加载网站通常会在1秒内完成，用户已经习惯了这一点。而在移动设备上用慢速3G连接加载网站则需要更多的时间，所以移动用户通常更有耐心，在移动设备上5秒内加载是一个更现实的目标。

目标和准则

在RAIL的背景下，目标和准则这两个术语有特定的含义。

目标。与用户体验相关的关键性能指标。例如，在100毫秒内点选到画。由于人类的感知是相对恒定的，所以这些目标不太可能在短时间内改变。
准则。帮助你实现目标的建议。这些可能是针对当前硬件和网络连接条件的，因此可能会随着时间的推移而改变。

响应：在50ms以下处理事件

目标：在100毫秒内完成用户输入发起的过渡，让用户感觉到交互是即时的。

准则：

为了确保在100毫秒内获得可见的响应，在50毫秒内处理用户输入事件。这适用于大多数输入，如点击按钮、切换表单控件或启动动画。这不适用于触摸拖动或滚动。
虽然这听起来可能有悖直觉，但立即响应用户输入并不总是正确的呼吁。你可以利用这100毫秒的窗口来做其他昂贵的工作，但要注意不要阻挡用户。如果可能的话，在后台进行工作。
对于需要超过50毫秒才能完成的操作，一定要提供反馈。

50毫秒还是100毫秒？

我们的目标是在100毫秒内响应输入，为什么我们的预算只有50毫秒？这是因为除了输入处理之外，一般还有其他工作正在进行，而这些工作占据了可接受的输入响应的部分时间。如果一个应用程序在空闲时间内以推荐的50毫秒分块执行工作，这意味着如果输入发生在其中一个工作块期间，可以排队长达50毫秒。考虑到这一点，可以肯定的是，只有剩余的50毫秒可用于实际的输入处理。下图直观地显示了这种效果，它显示了在空闲任务期间收到的输入如何被排队，从而减少了可用的处理时间。

闲置任务如何影响输入响应预算。

动画：在10毫秒内制作一帧动画

目标：在10毫秒或更短的时间内制作出动画中的每一帧。

在10毫秒或更短的时间内制作动画的每一帧。从技术上讲，每一帧的最大预算是16毫秒（1000毫秒/60帧/秒≈16毫秒），但浏览器需要大约6毫秒的时间来渲染每一帧，因此，每一帧的准则是10毫秒。
追求视觉上的流畅性。当帧率变化时，用户会注意到。

准则：

在动画这样的高压点，关键是能不做的地方就不做，不能做的地方就做绝对的最小。只要有可能，就利用100毫秒的响应来预先计算昂贵的工作，这样你就能最大限度地提高达到60帧的机会。
关于各种动画优化策略，请参见渲染性能。

认识所有类型的动画。动画不仅仅是花哨的UI效果。每一种交互都被认为是动画。

视觉动画，如出入口、微调和加载指示器。

滚动。这包括甩动，即用户开始滚动，然后放手，页面继续滚动。

拖动。动画经常跟随用户交互，比如平移地图或捏住放大。

闲置：最大化闲置时间

目标：最大化闲置时间，增加页面在50毫秒内响应用户输入的几率。

准则：

利用空闲时间来完成延迟的工作。例如，对于最初的页面加载，尽可能少地加载数据，然后利用空闲时间加载其余部分。
在空闲时间内执行工作，时间不超过50毫秒。任何更长的时间，你就有可能干扰应用程序在50毫秒内响应用户输入的能力。
如果用户在闲置时间工作期间与页面进行交互，那么用户交互应始终处于最高优先级，并中断闲置时间工作。

加载：在5秒内传递内容并实现交互

当页面加载缓慢时，用户的注意力会游离，用户会认为任务被破坏。加载速度快的网站，平均会话时间长，跳出率低，广告浏览量高。

目标：

根据用户的设备和网络能力，优化快速加载性能。目前，对于首次加载来说，一个好的目标是在3G慢速连接的中端移动设备上，在5秒或更短的时间内加载页面并进行交互。
对于后续加载，一个好的目标是在2秒内加载页面。

请注意，这些目标可能会随着时间的推移而改变。

指南：

在用户常用的移动设备和网络连接上测试您的加载性能。您可以使用Chrome用户体验报告来了解您的用户的连接分布情况。如果您的网站没有数据，The Mobile Economy 2019建议，一个良好的全球基线是一个中档Android手机，如Moto G4，以及一个缓慢的3G网络（定义为400毫秒RTT和400 kbps传输速度）。这个组合可以在WebPageTest上使用。
请记住，虽然你的典型移动用户的设备可能会声称它是在2G，3G或4G连接上，但实际上，由于数据包丢失和网络差异，有效的连接速度往往要慢得多。
消除渲染阻塞资源。
你不必在5秒内加载所有的东西来产生完全加载的感觉。考虑懒加载图片、拆分JavaScript捆绑代码，以及web.dev上建议的其他优化。

认识影响页面加载性能的因素：

网络速度和延迟

硬件(例如，较慢的CPU)

缓存驱逐

L2/L3缓存的差异

解析JavaScript

测量RAIL的工具

有一些工具可以帮助您实现RAIL测量的自动化。您使用哪一个取决于您需要什么类型的信息，以及您喜欢什么类型的工作流程。

Chrome DevTools

Chrome DevTools 提供对页面加载或运行时发生的所有事情的深入分析。请参阅 "开始分析运行时性能 "以熟悉性能面板用户界面。

以下 DevTools 功能特别相关：

节流你的CPU，以模拟一个较低功率的设备。
节流网络以模拟较慢的连接。
查看主线程活动，以查看您在录制时主线程上发生的每个事件。
在表格中查看主线程活动，以根据占用时间最多的活动进行排序。
分析每秒帧数(FPS)，以衡量你的动画是否真正平稳运行。
使用性能监控器实时监控CPU使用率、JS堆大小、DOM节点、每秒布局等。
使用网络部分可视化录制时发生的网络请求。
在录制时捕获屏幕截图，以回放页面加载时的确切外观，或动画播放时的确切外观，等等。
查看交互，以快速确定用户与页面交互后在页面上发生了什么。
每当潜在的问题监听器发射时，通过高亮显示页面，实时发现滚动性能问题。
实时查看绘制事件，以识别可能会损害动画性能的代价高昂的绘制事件。

灯塔

Lighthouse可以在Chrome DevTools、web.dev/measure、Chrome扩展、Node.js模块以及WebPageTest中使用。你给它一个URL，它就会模拟一个3G慢速连接的中端设备，在页面上运行一系列审计，然后给你一份关于加载性能的报告，以及如何改进的建议。

以下的审计特别相关：

响应

最大潜在的首次输入延迟。基于主线程空闲时间，估算应用程序响应用户输入所需的时间。
不使用被动监听器来提高滚动性能。
总阻塞时间。衡量页面响应用户输入（如鼠标点击、屏幕点击或键盘按下）的总阻塞时间。
互动时间。衡量用户何时能够持续地与所有页面元素进行交互。

加载时间

不注册一个控制页面和start_url的服务工作者。服务工作者可以在用户的设备上缓存常用资源，减少通过网络获取资源的时间。
移动网络上的页面加载速度不够快。
消除渲染阻塞资源。
推迟屏幕外图像。推迟屏幕外图像的加载，直到需要时才加载。
适当地调整图像大小。不要提供明显大于移动视口中渲染尺寸的图像。
避免链接关键请求。
不将HTTP/2用于所有的资源。
有效地对图像进行编码。
启用文本压缩。
避免巨大的网络有效负载。
避免过大的DOM大小。通过只运送渲染页面所需的DOM节点来减少网络字节。

WebPageTest

WebPageTest是一款使用真实浏览器访问网页并收集计时指标的网络性能工具。在webpagetest.org/easy输入网址，就可以在3G慢速连接的真实Moto G4设备上获得详细的网页加载性能报告。你也可以将其配置为包括Lighthouse审计。

总结

RAIL是将网站的用户体验看作是由不同的互动组成的旅程的一个视角。了解用户如何看待您的网站，以便设定对用户体验影响最大的性能目标。

关注用户。
在100毫秒内响应用户的输入。
在动画或滚动时，在10毫秒内制作一帧画面。
最大限度地延长主线程的空闲时间。
在5000毫秒内加载交互式内容。

[Web翻译]用RAIL模型测量性能