使用 RAIL 模型衡量性能

RAIL 是一种以用户为中心的性能模型,提供考虑性能的结构。该模型会将用户体验细分为关键操作(例如点按、滚动、加载),并帮助您为每项操作定义性能目标。

**要点 **:核心网页指标是 Google 新推出的一项计划,旨在针对提供优质网站用户体验至关重要的质量信号提供统一指南。这是通过 RAIL 定义性能目标的推荐方法,其阈值与此处详述的阈值不同。

RAIL 表示 Web 应用生命周期的四个不同方面:响应、动画、空闲和加载。由于用户对每种情境有不同的性能预期,因此,系统会根据情境以及关于用户如何看待延迟的用户体验调研来确定效果目标。

专注于满足用户需求

让用户成为性能工作的中心。下表介绍了用户如何看待性能延迟的关键指标:

用户对性能延迟的感知
|时间|感受|
|–|–|
| 0 至 16 毫秒 | 用户非常擅长跟踪运动,如果动画不流畅,他们就会不喜欢。只要每秒渲染 60 帧,这类动画就会感觉很流畅。也就是每帧 16 毫秒(包括浏览器将新帧绘制到屏幕上所需的时间),让应用生成一帧大约 10 毫秒。 |
| 0 至 100 毫秒 | 在此时间范围内响应用户操作,让用户感觉能够立竿见影。时间再长,操作与反应之间的连接就会中断。 |
| 100 至 1000 毫秒 | 在此窗口中,事情感觉像是任务自然和持续推进的一部分。对于网络上的大多数用户,加载页面或更改视图代表着一个任务。 |
| 1000 毫秒或以上 | 一旦超过 1,000 毫秒(1 秒),用户就会失去专注于他们正在执行的任务的注意力。 |
| 10000 毫秒或更长 | 一旦超过 10,000 毫秒(10 秒),用户就会感到沮丧,并可能放弃任务。他们以后不一定会回来。 |

**注意 **:用户感知到的性能延迟有所不同,具体取决于网络条件和硬件。例如,通过快速 Wi-Fi 连接在功能强大的台式机上加载网站通常会在 1 秒内完成,并且用户已经习惯了这种情况。在 3G 网络连接速度较慢的移动设备上加载网站需要更多时间,因此移动用户通常更有耐心,在移动设备上 5 秒内加载完毕是一个更切合实际的目标。

目标与准则

在 RAIL 中,术语“目标”和“指南”具有特定含义:

  • 目标。与用户体验相关的关键效果指标。例如,点按即可在 100 毫秒以内完成绘制。由于人类的感知相对稳定,因此这些目标不太可能很快改变。

  • 指南。可帮助您实现目标的建议。这些建议可能特定于当前的硬件和网络连接状况,因此可能会随着时间的推移而变化。

响应:在 50 毫秒内处理事件

目标:在 100 毫秒内完成由用户输入发起的转换,让用户感觉互动是瞬时完成的。

准则

  • 为确保在 100 毫秒内获得可见响应,请在 50 毫秒内处理用户输入事件。这适用于大多数输入,例如点击按钮、切换表单控件或启动动画。这不适用于轻触拖动或滚动。

  • 虽然听起来可能有违常理,但立即响应用户输入并不总是合适的。您可以使用以下 100 毫秒的窗口执行其他开销较大的工作,但要小心不要阻止用户。请尽可能在后台运行。

  • 对于需要 50 毫秒以上才能完成的操作,请始终提供反馈。

50 毫秒还是 100 毫秒?

我们的目标是在 100 毫秒以内响应输入,那么为什么我们的预算只有 50 毫秒呢?这是因为,除了输入处理之外,通常还会执行其他工作,并且这些工作会占用可用于获得可接受输入响应的部分时间。如果某个应用在空闲时间内以推荐的 50 毫秒分块执行工作,则意味着如果输入在其中一个工作块期间发生,则可能会排队长达 50 毫秒。考虑到这一点,可以放心地假设只有剩余的 50 毫秒可用于实际的输入处理。下图直观显示了这种影响,该图显示了空闲任务期间接收的输入如何排队,从而缩短了可用的处理时间:

动画:在 10 毫秒内生成一帧

目标

  • 在 10 毫秒或更短的时间内生成动画中的每一帧。从技术上讲,每一帧的最大预算为 16 毫秒(1000 毫秒 / 60 帧/秒约 16 毫秒),但浏览器需要大约 6 毫秒才能渲染每一帧,因此准则是每帧 10 毫秒。

  • 力求实现视觉流畅。当帧速率发生变化时,用户会注意到。

准则

  • 在诸如动画之类的高压力点中,关键是力所能及的方面都做不到,而绝对最小为不能。请尽可能利用 100 毫秒响应来预先计算开销非常大的工作,以便最大限度提高达到 60 fps 的几率。

  • 如需了解各种动画优化策略,请参阅渲染性能

注意 :识别所有类型的动画。动画不仅仅是精美的界面效果。这些互动中的每一种都被视为动画:

  • 视觉动画,例如进入和退出、补间动画和加载指示器。
  • 滚动。这包括快速滑动,即用户开始滚动,然后松开,页面会继续滚动。
  • 正在拖动。动画通常出现在用户互动之后,例如平移地图或双指张合进行缩放。

空闲:最大限度地延长空闲时间

目标:最大限度地延长空闲时间,以提高网页在 50 毫秒内响应用户输入的几率。

准则

  • 利用空闲时间完成推迟的工作。例如,对于初始网页加载,请尽可能少加载数据,然后使用空闲时间加载其余数据。

  • 在空闲时间不超过 50 毫秒时执行工作。如果时间更长,则可能会干扰应用在 50 毫秒内响应用户输入的能力。

  • 如果用户在空闲时间工作期间与页面交互,则用户互动应始终具有最高优先级,并中断空闲时间工作。

加载:提交内容并在 5 秒内实现互动

如果网页加载速度缓慢,用户的注意力就会分散,用户就会认为任务无法正常工作。网站加载速度快,平均会话数更长、跳出率更低、广告可见度更高

目标

  • 根据用户的设备和网络功能进行优化,以实现快速加载性能。目前,在 3G 网速较慢的中端移动设备上加载网页并可在 5 秒或更短的时间内加载网页是一个不错的目标。

  • 对于后续加载,最好在 2 秒内加载页面。

**注意 **:这些目标可能会随时间而变化。

准则

**注意 **:

确定影响网页加载性能的因素:

  • 网速和延迟
  • 硬件(例如运行速度较慢的 CPU)
  • 缓存逐出
  • L2/L3 缓存的差异
  • 解析 JavaScript

用于测量 RAIL 的工具

有几种工具可以帮助您自动进行 RAIL 测量。具体使用哪种方法取决于您需要什么类型的信息以及偏好的工作流类型。

Chrome DevTools

Chrome 开发者工具可以对页面加载或运行时发生的一切进行深入分析。请参阅分析运行时性能入门,熟悉性能面板界面。

开发者工具的以下功能尤为相关:

灯塔

Lighthouse 可在 Chrome 开发者工具、PageSpeed Insights、Chrome 扩展程序、Node.js 模块和 WebPageTest 中使用。您为其提供一个网址,它会模拟 3G 连接速度较慢的中端设备,在网页上运行一系列审核,然后为您提供负载性能报告以及有关如何改进的建议。

以下审计工作尤为相关:

答案

加载

WebPageTest

WebPageTest 是一种网页性能工具,它使用真实的浏览器访问网页并收集时间指标。在 webpagetest.org/easy 上输入一个网址,以获取页面在 3G 网速较慢的实际 Moto G4 设备上的加载性能的详细报告。您还可以对其进行配置,使其包含 Lighthouse 审核。

摘要

RAIL 是一个镜头,用于将网站的用户体验视为由不同互动组成的历程。了解用户如何看待您的网站,以便制定能够最大限度地影响用户体验的效果目标。

  • 专注于满足用户需求。

  • 100 毫秒以内响应用户输入。

  • 在设置动画效果或滚动时,在 10 毫秒以内生成帧。

  • 最大限度地延长主线程空闲时间。

  • 在 5000 毫秒内加载互动式内容。