Google:使用 RAIL 模型衡量性能

概要

本文搬运自:《Measure performance with the RAIL model》,由于文章最后一次更新于2020-06-10。所以文章中的一些标准可能跟现在实际情况有所出入,比如在移动设备上 5 秒内加载是一个更现实的目标

由于一些地方是机翻读起来很奇怪,所以本人进行了适当的修改,如有错误还请各位指正。

正文

RAIL 是一种以用户为中心的性能模型,该模型可用于衡量性能。该模型会将用户体验细分为关键操作(例如点按、滚动、加载),并帮助您设定各个关键操作的性能目标。

RAIL 代表 Web 应用生命周期的四个不同方面:响应(Response)、动画(Animation)、空闲(Idel)和加载(Load) 。用户对每种情境的性能预期不尽相同,因此,我们根据具体情境以及关于用户如何感知延迟的用户体验调研来确定性能目标。

以用户为中心

让用户成为您性能工作的焦点。下表介绍了用户感知性能延迟的关键指标:

延时 用户对性能延迟的感知
0 至 16 ms 用户不会喜欢不流畅的动画。只有每秒渲染 60 帧才能感知到流畅的动画,也就是每帧 16ms (1000ms/60帧),这 16ms 包括了浏览器将新帧绘制到屏幕上所用的时间,所以需要让应用生成1帧的时间控制在大约 10ms
0 至 100 ms 在此时段内响应用户操作,会让用户感觉能够立即看到结果,时间再长一点的话,用户的操作和应用的反馈之间的连接就会中断
100 至 1000 ms 在此时段内,事情感觉是任务自然且持续进展的一部分,对于网络上的大部分用户,加载页面或者更改视图往往代表着一个任务。
1000 ms或更长 超过 1 秒后,用户就无法专注于(应用/页面)所执行的任务
10000 ms或更长 用户可能会放弃任务,甚至再也不会回来了

影响用户感知性能延迟的因素有很多,具体取决于网络条件和硬件。例如,通过快速 Wi-Fi 连接在功能强大的台式机上加载网站通常在1秒内完成,并且用户已习惯这一点。在3G连接速度较慢的移动设备上加载网站需要更多时间,因此移动用户通常更具耐心,而在移动设备上5秒即可完成加载是一个更切合实际的目标。

目标(Goals)和指南(Guidelines)

在 RAIL 的上下文中,目标和指南具有特定含义。

  • Goals:与用户体验相关的关键绩效指标。例如点击即可在 100ms 内进行绘画。由于人类的感知相对恒定,这些目标短期内不太会变化。
  • Guidelines:帮助您实现目标的建议。这些可能特定于当前的硬件和网络连接条件。因此可能会随着时间变化。

响应(Response):在 50ms 内处理事件

Goals:

  • 在 100ms 内完成由用户输入到应用启动的过程,让用户感觉交互是即时的。

Guidelines:

  • 为确保100ms内可见响应,请在50ms内处理用户输入事件。如单击按钮、切换表单控件或启动动画。但是这不适用于触摸拖动或者滚动。
  • 立即响应用户输入并不总是正确的选择。可以使用这100ms的窗口期来执行其他昂贵的工作,但是要小心不要阻止用户。如果可以,请在后台工作。
  • 对于需要超过 50ms 才能完成的操作,请始终提供反馈。

50ms 还是 100ms

我们的目标是在 100ms 内响应输入,为什么我们的预算只有 50ms ?这是因为除了输入处理之外,通常还需要完成其他工作,并且该工作占用了可用于可接受的输入响应的部分时间。

如果应用程序在空闲时间以建议的 50ms 块执行工作,则意味着如果输入发生在这些工作快之一期间,则输入可以排队长达 50ms 。考虑到这一点,可以安全的假设只有剩余的 50ms 可用于实际输入处理。下图直观的展示了这种效果,该图显示了如何对空闲任务期间接收到的输入进行排队,从而减少可用处理时间:

动画(Animation):10ms 内生成一帧

Goals:

  • 在 10ms 或更短时间内生成动画中的每一帧。从技术上讲,每一帧的最大预算是 16ms,但是浏览器需要大约 6ms 来渲染每一帧。因此生成每帧的时间是 10ms。
  • 追求视觉流畅。用户会注意到帧率的变化。

Guidelines:

  • 像动画这样的高压点(high pressure points)中,关键在于能做的地方什么都别做,不能做的地方绝对少做。请利用100ms响应来预先计算昂贵的工作,以便最大限度提高达到 60FPS 的可能。
  • 有关各种动画优化策略,请参阅渲染性能。

动画不仅仅是花哨的UI效果,这些交互中的每一个都视为动画:

  • 视觉动画:进入和退出、中间帧以及加载动画。
  • 滚动:包括快速滚动,即用户开始滚动,然后松开,页面继续滚动。
  • 拖动:平移地图或缩放。

空闲(Idel):充分利用空闲时间

Goals:

  • 充分利用空闲时间,以增加页面在 50ms 内响应用户输入的几率。

Guidelines:

  • 利用空闲时间完成推迟的工作。如对于初始页面加载,加载尽可能少的数据以便尽快展现页面,然后利用空闲时间加载其余数据。
  • 在 50ms 或更短的空闲时间内执行工作。如果再长,您就有可能会干扰应用程序在 50ms 内响应用户输入的能力。
  • 如果用户与页面交互时刚好有在空闲时间内运行的程序,则用户交互应该始终拥有最高优先级。

加载(Load):交付内容并在5s内实现互动

当页面加载缓慢时,用户注意力会转移,用户甚至会感觉任务中断。加载速度快的网站会有更长的平均会话时间、更低的跳出率和更高的广告可见度。

Goals:

  • 目前,首次加载的一个理想目标是在3G网络连接较慢的中端移动设备上以5秒以内的时间加载页面并开启互动。
  • 对于后续加载,较好的目标是在2秒内加载页面。

这些目标可能会随时间发生变化。

Guidelines:

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

  • 网速和延迟
  • 硬件(CPU)
  • 缓存
  • L2/L3 缓存的差异
  • 解析JavaScript

RAIL测量工具

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

Chrome DevTools

Chrome 开发者工具可以深入分析页面加载或运行时发生的一切。如需熟悉性能面板界面,请参阅分析运行时性能入门。 下面这些开发者工具功能尤为相关:

  • 限制CPU以模拟性能较低的设备;
  • 限制网络流量以模拟较慢的网络(高速3G、低速3G、离线等);
  • 查看主线程活动,以了解录制时主线程上发生的每个事件;
  • 在表格中查看主线程activity,以便根据activity占用时间最长的activity对其进行排序;
  • 分析每秒帧数(FPS)以衡量动画是否真正顺畅运行;
  • 您可以使用Performance Monitor实时监控CPU使用率、JS堆大小、DOM节点、每秒布局数等等;
  • 使用网络部分直观呈现录制过程中发生的网络请求;
  • 在录取时截取屏幕截图,以准确播放网页加载时或动画被触发等情况下网页的显示效果;
  • 查看交互报告,可快速识别在用户和网页交互以后网页上发生的事件;
  • 通过在每次触发潜在问题的监听器时突出显示网页,实时发现滚动性能问题;
  • 实时查看绘制事件,以确定可能损害动画性能的高开销绘制事件;

Lighthouse

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

以下audits尤其相关:

  • Response:

    • Max Potential First Input Delay:根据主线程空闲时间估算应用响应用户输入所需的时间;
    • 不使用被动监听器来提升滚动性能;
    • Total Blocking Time:衡量网页被禁止响应用户输入(如鼠标点击、屏幕点按或键盘点按)的总时长;
    • 可交互时间:衡量用户何时能以一致的方式与所有页面元素互动;
  • Load:

    • 未注册用于控制网页和 start_url 的 Service Worker。Service Worker可以在用户设备上缓存通用资源,从而减少通过网络提取资源所花费的时间;
    • 网页加载在移动网络上不够快;
    • 避免使用阻塞渲染的资源;
    • 延迟加载屏幕外的图片:图片懒加载;
    • 适当调整图片大小:请勿提供明显大于在移动设备视窗中呈现的图片;
    • 避免链接关键请求;
    • 未针对所有资源使用HTTP2;
    • 对图片进行高效编码;
    • 启用文本压缩;
    • 避免网络负载过大;
    • 避免DOM规模过大,通过仅提供呈现网页所需的DOM节点来减少网络字节数;

WebPageTest

WebPageTest是一款Web性能工具,它使用真实浏览器来访问网页和收集计时指标。在webpagetest.org/easy 上输入一个网址,获取页面在3G连接速度较慢的实际 Moto G4设备上的网页加载性能的详情报告。您还可以将其配置为包含 Lighthouse 审核。

总结

RAIL是一个将网站的用户体验展现为由不同互动组成的旅程的镜子。了解用户对您网站的看法,以便设定正确的目标来达到最佳的用户体验:

  • 专注于满足用户需求
  • 在 100ms 以内响应用户输入;
  • 在添加动画效果或滚动时,在 10ms 以内生成帧;
  • 充分利用主线程空闲时间;
  • 在 5000ms 以内加载互动式内容;
相关推荐
SunTecTec5 分钟前
Flink Docker Application Mode 命令解析 - 修改命令以启用 Web UI
大数据·前端·docker·flink
涵信16 分钟前
第十一节:性能优化高频题-响应式数据深度监听问题
javascript·vue.js·性能优化
拉不动的猪1 小时前
前端常见数组分析
前端·javascript·面试
小吕学编程1 小时前
ES练习册
java·前端·elasticsearch
Asthenia04121 小时前
Netty编解码器详解与实战
前端
袁煦丞2 小时前
每天省2小时!这个网盘神器让我告别云存储混乱(附内网穿透神操作)
前端·程序员·远程工作
一个专注写代码的程序媛3 小时前
vue组件间通信
前端·javascript·vue.js
一笑code3 小时前
美团社招一面
前端·javascript·vue.js
懒懒是个程序员3 小时前
layui时间范围
前端·javascript·layui
NoneCoder3 小时前
HTML响应式网页设计与跨平台适配
前端·html