性能优化指标
预计阅读时间: 16 分钟引言
性能优化是老生常谈的话题了, 但是我们要做性能优化的前提是什么呢?
当然是量化性能的标准了啊, 无法量化, 那又何来的优化呢?
那现在的问题就是如何量化了, 靠体感嘛, 肯定不现实啊, 不同设备, 在不同环境, 不同时间都会有不同的性能表现, 而且体感的阈值也会比较大, 特别明显的才会感觉到
在这个话题上业界也经过多年的实践, 尝试过许多量化用户体验的方式, 例如
- 测量页面白屏时长
- 计算可交互耗时 (Time to interact)
- 计算总阻塞时间 (Total blocking time, TBT)
- 计算首次有效绘制 (First Meaningful paint, FMP)
这些指标往往逻辑复杂、难以测量, 甚至定义都有歧义, 所以逐渐消亡
经过大浪淘沙, 近年来近年来最实用的用户体验量化指标是基于开源库 web-vitals 获取页面渲染耗时, 交互延迟等指标
web-vitals 各指标简介
web-vitals 是谷歌的 Chrome 维护团队于 2020 年开源的工具库, 它基于统一的浏览器 Performance API 获取标准化的用户体验指标
它主要测量6项指标, 分别是
- 首次内容绘制 (First Contentful Paint, FCP)
- 最大内容绘制 (Largest Contentful Paint, LCP)
- 首次输入延迟 (First Input Delay , FID)
- 交互到绘制延迟（Interaction to Next Paint, INP）
- 累积布局偏移 (Cumulative Layout Shift, CLS)
- 第一字节时间 (Time to First Byte, TTFB)
1. 首次内容绘制 (First Contentful Paint, FCP)
FCP 测量从页面开始加载到页面中任意部分内容 (文本、图像、svg、canvas 等内容) 完成渲染的时长
其值为浮点数, 单位是毫秒. FCP 值越小表示该指标状况越好、页面的厨师内容渲染越快
页面中率先出现的文本图像等视觉可见内容, 直接决定了用户对页面加载速度的主观体验, 所以这一指标选择测量这些内容的渲染耗时, 从而量化用户的主管体验
注意, FCP 测量的是任意部分 DOM 完成渲染的耗时, 而非全部内容完成渲染耗时, 不等于 onLoad 事件
按照 Chrome 官方的推荐标准, FCP 指标分为 3 个等级
- 优: 小于 1.8 秒
- 待改进: 大于 1.8 秒且小于 3 秒
- 差: 大于 3 秒
2. 最大内容绘制 (Largest Contentful Paint, LCP)
LCP 测量从页面开始加载到可视区域内尺寸最大的文字或图像渲染完成的耗时
其值为浮点数, 单位是毫秒. LCP 值越小表示该指标状况越好、最大元素渲染越快
之所以测量最大的内容, 是因为尺寸最大的内容往往是最能吸引用户的注意力, 其渲染耗时, 直接影响了用户对页面整体渲染速度的体验
我们可以用 Chrome 浏览器自带的 DevTool 中的 Performance Insights 工具来判断页面中什么元素是最大内容
按照 Chrome 官方的推荐标准, LCP 指标分为 3 个等级
- 优: 小于 2.5 秒
- 待改进: 大于 2.5 秒且小于 4 秒
- 差: 大于 4 秒
3. 首次输入延迟 (First Input Delay , FID)
FID 测量用户首次交互 (点击、触摸) 后到浏览器开始响应之间的时间剪个
其值为浮点数, 单位是毫秒. FID 值越小表示该指标状况越好, 用户首次与页面交互式, 浏览器响应的延迟学校
这一指标只关注页面中首次交互的原因是, 首次交互时, 页面汪汪楚玉尚未完全加载的状态, 异步响应数据在等待响应、部分 JS 和 CSS 仍在执行和渲染的过程中, 浏览器的主线成灰短暂的处于忙碌状态, 往往不能及时响应用户交互
但是第一次交互的延迟长短往往决定了用户对网页流畅度的第一印象, 所以这一指标的测量目标, 也能量化用户的主观体验
按照 Chrome 官方的推荐标准, FID 指标分为 3 等级:
- 优: 小于 100 毫秒
- 待改进: 大于 100 毫秒且小于 300 毫秒
- 差: 大于 300 毫秒
FID 指标与下文将要提到的 INP 指标测量目标有所重叠, 且普适性不及 INP, 未来可能会被 INP 替代
扩展知识 (普适性)
普适性 (Universality) 是指某种特性、原则或规律在广泛的条件下都适用或存在的性质. 这个概念可以用于多个领域, 如数学、物理学、计算机科学以及社会学等
- 数学中的普适性: 不了解
- 物理学中的普适性: 不了解
- 计算机科学中的普适性: 图灵机模型展示了计算机的本质, 理论上他可以模拟任何其他计算模型的能力, 这种能力被称为计算机的普适性
- 社会学中的普适性: 虽然文化背景和社会环境对人们的行为有很大影响, 但有些基本的人类行为模式或者心理特征被认为是跨文化的, 例如亲情关系的重要性、对安全的需求等
需要注意, 普适性并不意味着完全无例外地适用于每一个案例: 而是指在一个广泛范围内具有高度的一致性和适用性, 在实际应用时, 还需要考虑具体情况下的特殊因素
4. 交互到绘制延迟（Interaction to Next Paint, INP）
INP 测量用户在页面浏览过程中的所有交互 (点击、键盘输入、触摸等) 与浏览器渲染响应的整体延迟情况
其值为浮点数, 单位是毫秒. INP 值越小表示该指标状况越好, 用户的各类交互响应延迟减小
与 FID 只关注首次交互不同, INP 会关注用户浏览网页全过程中的所有交互, 所以 web-vitals 库中获取 INP 值的 onINP(FCPReportCallback) 方法, 通常会在页面可视化状态变化或页面卸载时多次触发, 综合统计一段时间内的多次交互, 按特定算法, 计算该时间段内的 INP 指标值
INP 指标 3 个等级的评分分别为:
- 优: 小于 200 毫秒
- 待改进: 大于 200 毫秒且小于 500 毫秒
- 差: 大于 500 毫秒
INP 是新进加入
web-vitals的指标, 仍处于试验阶段, 其标准可能会有调整, 目前描述的是其 2023 年 5 月的状况
5. 累积布局偏移 (Cumulative Layout Shift, CLS)
CLS 测量页面中所有意外布局变化的累计分值
其值为浮点数, 无单位, 值的大小表示意外布局变化的多少和影响范围的大小
CLS 值的计算类似 INP, 会统计一段时间内的所有意外布局变化, 按特定算法, 计算出分值
所谓意外布局变化是指 DOM 元素在前后绘制的 2 帧之间, 非用户交互引起的 DOM 元素尺寸、位置变化
按照Chrome官方的推荐标准, CLS指标3个等级的评分分别为：
- 优：小于 0.1
- 待改进：大于 0.1 且小于 0.25
- 差：大于 0.25
6. 第一字节时间 (Time to First Byte, TTFB)
TTFB 测量前端页面 (Document) 的 HTTP 请求发送后, 到接收到第一个字节数据响应的耗时, 通常包括重定向、DNS 查询、服务器响应延迟等耗时
其值为浮点数, 单位是毫秒. 值越小表示该值状态越好, 页面 HTTP 响应的耗时越短, 也就是页面的加载更快
TTFB 指标值的大小直接决定着页面厨师内容渲染耗时的长短, 往往和 FCP、LCP 指标有明显的相关关系, 对用户体验又直接影响, 所以 web-viatals 也将其当作了量化用户体验的指标之一
除了可以通过 web-vitals 库的 onTTFB() API 获取, 也可以使用 Chrome 自带的 DevTool Network 网络面板计算得出: 文档响应的整体耗时 减去 内容下载耗时（Content Download
TTFB指标3个等级的评分分别为：
- 优：小于 800 毫秒
- 待改进：大于 800 毫秒且小于 1800 毫秒
- 差：大于 1800 毫秒
尽管以上指标可以通过与原生 Performance API 计算获得, 但仍然推荐使用 web-vitals 库, 因为它帮助我们处理了许多细节问题, 例如标签页处于后台时的计算、指标获取时机、浏览器兼容性等等, 能确保我们测量出标准、稳定的指标数值
6 类指标对比
| 名称 | 含义 | 注意事项 | 值单位 |
|---|---|---|---|
| 首次内容绘制(First Contentful Paint, FCP) | 测量从页面开始加载到页面中任意部分内容（文本、图像、<svg/>、<canvas/>等内容）完成渲染的时长 | 测量任意部分DOM渲染的耗时, 而非全部内容, 不等于页面所有内容完全加载完成的onLoad事件 | 毫秒 |
| 最大内容绘制 (Largest Contentful Paint, LCP) | 测量从页面开始加载到可视区域内尺寸最大的文字或图像渲染完成的耗时 | 对于UI渲染逻辑复杂的前端应用, 不同优化可能会有不同的最大元素, 统计获得的最大元素可能有多个 | 毫秒 |
| 首次输入延迟(First Input Delay , FID) | 测量用户首次交互（点击、触摸）后到浏览器开始响应用户交互之间的时间间隔 | 未来可能会被INP替代 | 毫秒 |
| 交互到绘制延迟(Interaction to Next Paint, INP) | 测量用户在页面浏览过程中的所有交互（点击、键盘输入、触摸等）与浏览器绘制对应响应的整体延迟情况 | 通常会在页面可视化状态变化或页面卸载时进行计算 | 毫秒 |
| 累积布局偏移(Cumulative Layout Shift, CLS) | 测量页面中, 一定时间段内所有意外布局变化的累计分值 | - 通常会在页面可视化状态变化或页面卸载时进行计算 - web-viatals提供的onCLS()方法会多次触发 - onCLS()获取到的sources字段可能会因为元素卸载而变成null, 统计时可以使用xpath进行特殊处理 | 分值 |
| 第一字节时间(Time to First Byte, TTFB) | 测量页面本身 (Document) 的HTTP请求发送后, 到接收到第一字节数据响应的耗时 | 往往和FCP、LCP指标有相关关系 | 毫秒 |
web-vitals 库使用示例
以上 6 项均可通过 web-vitals 库内置的 API 方便的获取, 将 web-vitals 库集成到用户访问的前端页面, 即可方便的获取用户的真实体验数据, 例如:
要注意的细节是, 这些指标中:
- onFCP, onTTFB 均在页面初始化是自动触发
- onFID 是在用户第一次与页面交互时触发
- onCLS, onINP 则因为要测量页面的全生命周期, 往往无固定触发时间点, 在实践中通常会在交互停止一段时间后, 或页面可是状态变化 (例如切换标签页) 后多次触发
- onLCP 的触发分 2 种情况
- 如果有用户交互, 例如点击、按下按键、会立刻触发 onLCP 回调
- 如果始终没有用户交互, 则会在页面标签页切换到后台时触发 onLCP 回调
web-vitals 这些指标是 Chrome 维护团队基于海量用户数据, 经过大量实践后设计出来的, 能科学的将主观的用户体验量化为客观的指标, 是我们进行体验优化的必备工具
大量的收集这些指标数据, 加上汇总分析便可以实现针对用户体验的“真实用户监控”, 从用户客户端收集到海量数据, 要比我们在内部的测试开发环境上测量出的少量数据更全面、更客观、更有说服力, 更有助于我们作出数据驱动的优化策略