rail 模型 ​

rail 模型是一种以用户为中心的性能模型, 它提供了一种考虑性能的结构

该模型将用户体验分解到按键操作(点击, 滚动, 加载), 对每个操作都能定义性能目标

rail 代表 Web 应用生命周期的四个不同方面:响应,动画,空闲和加载

用户对这些上下文分别有不用的性能期望, 因此,性能模板是根据上下文以及用户如何感知延迟的用户体验研究来定义的

以用户为中心 ​

0-16 ms ​

用户非常关注轨迹运动, 他们喜欢流畅的动画, 每秒 60 帧的动画是流畅的

每一帧只有 16ms 的时间, 包括了浏览器将新帧绘制到屏幕所需时间, 因此应用约有 10ms 的时间来生成一个帧

0-100 ms ​

在此时间窗口内响应用户操作会让用户觉得结果是即时呈现的

如果时间更长, 操作与用户反应之间的联系就会中断

100-1000 ms ​

在此时间窗口内, 用户会觉得任务进展基本上是自然连续的

对大多数用户来说, 加载页面或更改视图是一项任务

1s 以上 ​

超过 1s, 用户注意力就会从正在执行的任务上转移

10s 以上 ​

用户会感到失望, 可能会离开

目标和准则 ​

• 目标

与用户体验相关的关键性能指标

例如: 点击即可在 100ms 内绘制

• 准则

有助于实现目标的建议

不同硬件与网络连接条件下不同

响应: 在 50ms 内处理事件 ​

目标 ​

在 100ms 内完成由用户输入发起的转换, 让用户感觉交互是即时的

准则 ​

• 为了确保在 100ms 内产生可见响应, 需要在 50ms 内处理用户输入事件. 适用于大多数输入, 例如:点击按钮,切换表单控件,启动动画. 不适用于触摸拖动或滚动

动画: 在 10ms 内生成一帧 ​

目标 ​

• 在 10ms 或者更短的时间内生成动画的每一帧. 从技术角度考虑,每一帧的最大预算是 16ms, 但是浏览器需要大约 6ms 的时间来渲染一帧

准则 ​

• 有关各种动画优化策略,参阅 /rendering-performance

空闲: 最大限度增加空闲时间 ​

目标 ​

最大限度增加空闲时间以提高页面在 50ms 内响应用户输入的几率

准则 ​

• 利用空闲时间完成延缓的工作

例如, 对于初始页面加载,应加载尽可能少的数据,然后利用空闲时间加载其余数据

• 在 50ms 或更短的空闲时间内执行工作

如果时间更长, 可能会干扰应用在 50ms 内响应用户输入的能力

• 如果用户在空闲时间工作期间与页面交互,应该中断空闲时间工作, 用户交互始终保持最高优先级

加载: 在 5s 内交付内容并实现可交互 ​

当页面加载缓慢时,用户注意力会分散, 他们会认为任务已中断

加载速度快的网站具有更长的平均会话时间, 更低的跳出率和更高的广告可见性

目标 ​

• 根据用户的设备和网络能力优化相关的快速加载性能

对于首次加载, 在使用速度较慢的中端移动设备上, 理想的目标是在 5s 内实现可交互

• 对于后续加载, 理想目标是 2s 内加载页面

准则 ​

• 在最常见的用户移动设备和网络连接上测试负载性能

• 消除阻塞渲染资源

• 为了产生完整加载的感觉, 您不必再 5s 内加载所有内容

可以考虑延迟加载图像, 代码拆分 js 包

RAIL 的测量 ​

Chrome DevTools ​

可以对加载或运行页面时发生的一切活动进行深入分析

分析运行时性能

Lighthouse ​

Chrome DevTools 中以 Chrome 扩展和 Node.js 模块的形式提供了 Lighthouse,WebPageTest 中也提供了此工具

总结 ​

• 以用户为中心

• 在 100ms 内响应用户输入

• 播放动画或执行滚动时,在 10ms 内生成一帧

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

• 在 5000ms 内加载交互式内容