💡
web 性能是加载时间和运行时的 客观测量+主观用户体验
用户对时间的感觉 - <可用性工程 - 第5章>
- 0.016s: 如果每秒渲染 60 个新帧,他们就会认为动画很流畅
- 0.1s: 用户感觉到系统在瞬间做出反应的极限
- 不需要特殊的反馈
- 队列进行排序的响应时间
- 1s: 用户思维流保持不间断的极限,即使此时用户会注意到延迟
- 用户确实会失去直接对数据进行操作的感觉,但是一般也不需要特殊的反馈
- 仍然感觉可以控制整体体验,并且他们可以自由移动,而不是在计算机上等待
- 10s: 用户的注意力能集中在对话上的极限
- 如果在 1~10s 之间,一个百分比指示器可能会比较多余,会违反显示惯性原则,一种常见的解决方案是将“忙碌”光标与屏幕底部小字段中快速变化的数字相结合,以指示已完成的工作量
- 显示惯性原则:
- 如果在 1~10s 之间,一个百分比指示器可能会比较多余,会违反显示惯性原则,一种常见的解决方案是将“忙碌”光标与屏幕底部小字段中快速变化的数字相结合,以指示已完成的工作量
- 如果超过了 10s, 则务必向用户提供反馈,指示任务大概何时完成
用户对性能延迟的感觉可能会有所不同,取决于网络条件和硬件,例如,通过快速 Wi-Fi 连接,在功能强大的台式机上加载站点时,通常只需不到 1 秒时间,用户已经习以为常。通过速度较慢的 3G 网络连接,在移动设备上加载站点则需要更长的时间,因此,移动用户通常会更有耐心。在移动设备上,5 秒钟内完成加载是更现实的目标。
RAIL - 衡量性能的模型
RAIL 说明
- RAIL 是 Response, Animation, Idle, 和 Load 的首字母缩写, 是一种由Google Chrome团队与2015年提出的性能模型, 用于提升浏览器内的用户体验和性能
- RAIL 模型的理念是 “以用户为中心最终目标不是让您的网站在任何特定设备上都能运行很快,而是使用户满意”
- RAIL 把交互分为四个阶段: 页面加载、空闲、响应用户输入、滚动和动画,其对应的主要原则是
- 响应: 应该尽可能快速的响应用户, 应该在 100ms 或者 100ms 以内响应用户输入
- 动画: 在展示动画的时候,每一帧应该以 16ms 进行渲染,这样可以保持动画效果的一致性,并且避免卡顿
- 空闲: 当使用 Javascript 主线程的时候,应该把任务划分到执行时间小于 50ms 的片段中去,这样可以释放线程以进行用户交互
- 加载: 应该在小于 1s 的时间内加载完成你的网站,并可以进行用户交互
目标 vs 准则
- 目标: 与用户体验相关的关键性能指标。例如,点击即可在 100 毫秒内绘制。由于人类的感知相对一致,因此,这些目标不太可能很快发生改变。
- 准则: 帮助您实现目标的建议。这些准则可能特定于当前硬件和网络连接条件