演讲 PPT: 谷歌体验度量指标集 Web Vitals

演讲场所: 网易-集团前端沙龙

演讲简介: 本次分享主要围绕谷歌最新提出的谷歌体验度量指标集-Web Vitals, 包含:

• 该指标集提出的背景、含义、计算原理，并对围绕该指标集的谷歌系产品做简要介绍。
• 最后会介绍当前云音乐前端监控平台对该指标集的跟进情况和用户最佳实践等。

演讲时间: 2020-10-21

信息

以下为演讲逐字稿

演讲逐字稿

主题介绍

大家好，我是来自云音乐的 kkdev163，在云音乐主要从事前端监控平台建设相关的工作。本次分享为大家带来的主题是《谷歌体验度量指标集 Web Vitals》。

本次主要分为四个部分：...

背景

云音乐在 19 年的时候上线了前端监控平台，我们通过部署平台自动接入 SDK， 采集用户端的一些性能数据，并在平台上做可视化展示。

同时我们也基于 Lighthouse 搭建了一套实验室环境的性能度量体系。

结合二者，我们做了一个体验基线，在全体同事的努力下，云音乐整体的评分和通过率有了一些提升。

但在运作的过程中，我们也收到了一些反馈：

1. 实验室环境指标项很多，开发者有一定的认知成本
2. 实验室环境指标 与 真实用户侧指标 不一致，在做优化时，难以对齐。
3. 真实用户侧指标 domReady、load 等 虽然可以评估页面加载的快慢，但与用户肉眼所见的页面渲染，并不能直接关联。

谷歌在今年提出了 Web Vitals，云音乐及时做了跟进和落地，他在一定程度上解决了我们的痛点，那么我们来看下， Web Vitals 是什么，他为什么能解决我们的问题？

概要

Web Vitals 是谷歌提出的一组用来衡量 用户体验 的 度量指标集。

它包含了左侧,与用户体验直接关联的核心指标，以及右侧的一些辅助指标。

绿色核心指标是我们今天要重点展开介绍的。

核心指标集主要用来度量用户体验中的三个方面：

• 1. 加载时性能
• 2. 可交互性
• 3. 视觉稳定性

分别用 LCP、FID、CLS 三个指标来衡量，并且谷歌也基于 Chrome 的用户数据，将每个指标划分为三档：

• 较好
• 有待提高
• 较差

核心指标集将页面的健康程度最终只落到于这三项指标上，聚焦于这三项指标展开优化，就能在很大程度上解决体验问题。

接来下，我们来详细的介绍这三个指标项：

LCP

LCP 指标的含义

LCP 最大内容渲染时间，是指当前视窗(viewport)中的最大内容元素的渲染时间。

在用户体验中，他被用来衡量页面的加载时性能。通常来说，视窗中最大的内容区块，是网页设计者最希望为用户传递的内容，而这部分关键内容的加载快慢，直接影响了用户的体验。

衡量的标准

谷歌给出的建议是 LCP 需要控制在 2.5 秒 内，如果超出了 4 秒，对于用户来说，体检就会较差。

为了我们后续更好地展开优化，我们来了解下 LCP 的判定规则。首先我们来看下哪些元素的渲染可能会被判定为 LCP。

哪些元素会包含在内

• <img> 图片元素
• <svg> 中的 <image> 元素
• <video> 元素中的 poster image
• background-image: url() 使用背景图的元素
• 包含文字节点的块级(block-level)元素

如何判定元素大小

对 LCP 来说，一个元素的大小，仅仅只包含，当前视窗内可见的部分。如果一个元素，有部分内容超出了当前视窗或者是有不可见的 overflow, 只会计算可见部分的大小。

对于图片元素的判定，是结合图片自身的大小与屏幕上渲染的大小，取二者中较小的值。

对于包含文字的块级节点，只计算包裹所有文字节点的最小矩形面积。

Demo 演示

介绍完了 LCP 的计算原理后，我们来看一个 Demo 演示，在页面加载过程中，在 2000ms 时页面加载了骨架屏，由于不包含我们上面提到的元素，所以没有 LCP 产生；在 2400 毫秒时，加载出了文字节点，此时浏览器会抛出一个 Performance 信息对象，包含当前的 LCP 元素 和 渲染时间。随着加载的继续，在 3000 ms 和 4500 ms 分别会抛出新的 信息对象。

随着页面的加载，浏览器会持续抛出 LCP 对象，直到用户开始交互(点击、滚动、按键等)为止。该页面最终的 LCP 值是 4500ms。

由于超出了 4 秒，所以是属于较差的 LCP

哪些因素会影响 LCP

• 请求 html 时的服务器响应时间
• 阻塞渲染的 CSS、JavaScript
• 资源加载时间
• 客户端渲染 (Client-side rending)

LCP 虽然只是衡量了最大内容元素的渲染时间，但是该元素的渲染却与整个页面的请求加载链路有关，所以优化 LCP 需要综合地从以上 4 个影响方面出发。

FID

FID 用户首次输入的延迟。

我们经常会看到一些页面，在加载初期，对于用户的交互，有些响应延迟。这主要是由于页面在加载初期，虽然渲染出了部分元素，但主线程仍然处于繁忙状态，无法及时地响应事件处理器，从而让用户感知到明显的延迟。

根据谷歌的建议，这个延时如果能控制在 100 毫秒 内，会有比较好的可交互体验，如果超出了 300 毫秒，用户的可交互体验就会较差。

FID 计算演示

我们通过一个例子来更好的理解 FID。

页面加载初期，屏幕上渲染出了按钮，并且正在努力地计算骨架区块内容，浏览器的主线程处于繁忙状态。

如果在这个时候用户点击了按钮，浏览器是没有办法马上响应的。

它需要等到骨架区块计算渲染完成，处于空闲状态后，才会去响应点击事件的处理器，并产生一些 UI 变更。

在整个过程中 FID 计算的是，从用户点击到主线程首次空闲，有能力去处理事件响应器的时间。

而事件处理器本身的执行耗时，和由此可能产生的 UI 变更并不会记录在 FID 内。

从这个例子，我们也可以看出，FID 的值与用户在什么时候进行交互有很大关系，如果用户是等到浏览器完全空闲后在交互，那 FID 就会很小。。所以在数据呈现上，我们会使用分布图，来查看用户 FID 的分布。

有哪些事件会被记录为 FID ？

FID 主要发生于用户输入的独立事件 如 点击、键盘输入等

滚动、缩放等连续事件，不会记录在内。

如果没有绑定事件处理器？

FID 记录的是 收到用户输入事件 到 下一次浏览器处于空闲状态的 时间差。所以即使没有绑定事件处理器，FID 也能够被准确测量出来。

这样设计的目的，也是因为有些交互元素并不直接依赖于事件处理器，但是需要主线程处于空闲状态才能正常地响应，如：

• Checkboxes, radio buttons，and Text fields(<input>, <textarea>)
• 选择器的下拉菜单(<select>)
• 链接 <a>

影响 FID 的主要因素

导致 FID 的主要原因是 页面加载过程中 解析和执行了太重的 JavaScript, 导致主线程繁忙。

优化的思路有：

1. 减小 JS 文件体积（Code-splitting、延迟加载）
2. 减少主线程执行开销 (拆分 Long Tasks、异步执行、web worker)

CLS

我们最后来介绍 CLS ，累计布局偏移。 我们经常会发现一些页面，存在视觉抖动的情况，主要的原因是发生了布局的偏移。

该指标，可以用来衡量用户体验中的视觉稳定性。

谷歌给出的评估标准是 < 0.1，与之前指标不一样，他是一个分数，我们需要来看下，它是如何计算的？这样才能更好地帮助我们理解，布局偏移在我们页面上产生的影响面。

首先他的计算公式是 影响面积分数 * 距离分数

• 影响面积分数指的是，布局移动前后求并集的面积占整个视窗的比例，在这个的例子中，是 1/2
• 距离分数指的是，这次偏移的最大距离 占 整个视窗长边的比例，在这个例子中，是 1/4

所以在这个例子中，布局位移评分为 0.5 * 0.25 = 0.125。

参考这个例子，了解了计算方式后，相信大家对 0.1 的布局偏移能产生多大的影响面，应该是有了直观的感受。

CLS 影响因素

1. 图片 size 属性
2. 不要在已渲染的元素上方插入新元素
3. 使用 trasmform 动画

谷歌系工具简介

在了解完了核心指标的定义、计算原理 常见的影响因素后，我们来看下，在日常的开发过程种，如何去使用这三个指标，帮助我们优化用户体验。

展开介绍本地端工具...

这几个工具是我们在开发阶段，可以本地使用的，那有没有办法采集用户端的数据呢？谷歌提供了用户体验报告 API，和可视化的产品。。

展开介绍用户端分析工具...

以上的用户端数据，依赖于 Chrome 的数据采集，并且维度也比较单一，我们只能查到像 music.163.com 主域名的数据，对于更细分的页面，往往是查不到数据的。

所以为了支持更精细化的数据采集，谷歌也为我们提供了 web-vitals npm 包，通过这个包，我们可以方便地采集用户端的数据。

云音乐实践

在云音乐，我们将 npm 包整合到了现有的 sdk 中，采集并呈现了核心指标的视图。

对于核心指标，我们是根据谷歌的建议，将 75% 的用户 是否通过好的标准，设为达标线。以 LCP 为例，好的标准是 2.5 秒，该页面在 2.5 秒内的用户占比只有 74%，所以 LCP 指标未达标。

通过这个看板，我们能直观地了解到，我们的页面在用户端的真实体验占比如何。

由于这几个指标是依赖于 Chrome 浏览器的 API, 相信也有不少同学，会担心指标的的兼容性如何？

我们通过一段时间的数据采集，发现随着用户设备的更新，我们采集的覆盖率也在逐步的上升，云音乐的某个应用已经达到了 39% 的用户覆盖率。

同时在实验室侧，我们也将 Lighthouse 升级到了 6.0 版本，在 6.0 下会提供 核心指标值，并提供针对核心指标的优化建议。

通过这次平台的升级更新，解决了我们一开始提到的痛点。。

• 我们的开发者只需要重点关注 核心指标集
• 用户侧 与 实验室侧 有了相同的指标进行验证性能
• 用户侧的性能，可以使用与用户体验直接相关的指标体现，我们是站在用户视角，评估最终肉眼所见的渲染快慢，与中间使用到的前端技术方案无关。

通过这次升级，我们也发现了一些新的问题，比如在使用 核心指标 的评估体系下，我们整体的平均分，有了大幅的下降。。这说明，我们的页面可以在新的评估标准下，有进一步优化的空间。

比如我们的某个页面，此前长期霸榜，但在新的评估体系下，在真实用户侧 和 实验室侧都暴露出了新的体验问题。如存在 LCP 值过大，存在 CLS 等。

在平台更新了 WebVitals 后，我们现在推荐的使用方式是这样的：念 PPT

这里打个小广告，WAPM 平台是支持 网易集团内部应用接入的，如果有其他事业部的同学想使用 的话，也可以加下 POPO 交流群。

最后我作个简短的总结：

这次分享，我们介绍了 云音乐引入 WebVitals 的背景，并且介绍了 3 个 核心指标集的定义和计算原理等，并介绍了平时在开发过程中可以使用到的谷歌工具。

最后我们给出了当前云音乐落地情况 和 带来的一些问题。

我们相信随着 WebVitals 指标的进一步普及 还有 开发者的及时更进，我们可以给用户带来的更好的用户体验。 Make The Web More Awesome!

我的分享结束了，谢谢大家。