如何做好全球化的前端性能度量？

一、前言

ICBU 作为海外数字商业板块的常青树，扎根于全球化的土壤里，如何做好全球用户体验、提升页面性能已经成为了一个老生常谈的话题。 面对日益复杂的网络环境，如何做好全球化的前端性能度量，同时更进一步，基于度量做到让前端开发者更容易发现性能问题、问题都能有解法、解决后能看到效果，本文将根据多年前端性能优化的经验，从如下三个角度进行分享。

二、性能指标采集

1. CWV 是什么？

核心 Web 指标是适用于所有网页的 Web 指标子集，每位网站所有者都应该测量这些指标，并且这些指标还将显示在所有 Google 工具中。每项核心 Web 指标代表用户体验的一个不同方面，能够进行实际测量，并且反映出以用户为中心的关键结果的真实体验。

CWV，全称（Core Web Vitals，核心 Web 指标），包含 LCP、CLS、FID 三个指标，分别对应加载性能、交互性和视觉稳定性。

2. 为什么使用 FCP + CWV 作为核心指标？

选择使用 FCP + CWV 作为核心指标有以下几点考虑：

1. 我们需要一个统一的、标准的、符合行业规范的【指标】来对全球化场景下的前端性能进行度量；
2. 我们需要一个合理的区间来对当下的性能状态进行更加直观的展示（优秀、良好、较差）；
3. 【指标】本身需要能够客观的反应页面的状态，尽量减少主观性，且能指导页面优化方向；

3. 为什么【自定义首屏】不再被作为核心指标？

出于历史原因，ICBU 很长一段时间都使用【自定义首屏】（exposed_time）来作为衡量页面性能的关键指标，但随着时间推移，我们发现了【自定义首屏】的一些弊端，包括但不限于：

• 容易作弊： 【自定义首屏】需要在代码中手动上报，上报的时机完全取决于业务开发同学，数据可信度不高

• 缺乏共识： 每个团队对于首屏的定义都不相同，无法用统一的阈值来衡量所有场景的性能，各团队之间无法拉通、对齐，且与业内公认指标无法进行关联，比如 SEO 场景，自定义首屏优化后无法反馈 SEO 是否优化。

• 优化困难： 【自定义首屏】只能衡量“首屏时间”，当该指标较差需要优化时，开发者往往无从下手，因为导致首屏时间变长的因素过多，需要花费大量精力进行问题排查、性能优化。

• 指标过于单一： 在聊用户体验的时候，关注的不应该仅仅是页面加载的时间，而是页面加载到用户与页面交互的整个生命周期，除了加载性能以外，还应该关注用户交互延迟、页面布局偏移、核心元素加载时机等多维度的指标。

4. 为什么要在 CWV 的基础上增加 FCP 指标？

通常来讲，【LCP】已经反应大部分场景页面加载性能的情况，但是对于某些首跳场景、页面生命周期较短的场景而言，可能无法等到【页面最大元素】加载完毕就已经跳出了，针对这类场景我们在 CWV 的基础上再加上了 FCP，来作为衡量页面加载性能的辅助指标。 并且，我们认为，对于用户而言，【页面上首次渲染内容】的时机也是非常关键的，他可以很好的反应页面主文档在经过网络请求之后，真正渲染到页面上的时间差，利于我们在做性能优化的时候更精细的进行问题排查。

5. 当前的性能指标和业界指标有什么区别？

在选择阈值的时候主要考虑了两点因素：

• 形成共识： 即我们认为体验好的页面，在业内应该是公认的体验较好，各个团队间也都应该觉得好；

• 达成难度： 如果想要得到一个极致体验的页面，各项指标应该是定的越高越好，但实际却不是这样。过高的阈值会让性能优化的 ROI 降低，让开发者觉得高山仰止；

基于这两点，目前的前端核心性能指标完全 follow 了 Google 提供的指标阈值，并在其基础上针对国际化场景现状进行了微调，例如 FCP 指标，参考了【自定义首屏】的衡量标准，对各阶段的阈值进行了部分调整， 使其在不影响用户体验的情况下更易于达成。 在展示数据的 75 百分位值的同时，性能平台也增加了 90 分位值、中位数、平均值等多个维度数据的展示，我们鼓励开发者从不同视角对性能进行评估，更多的探索极致性能、极致体验。

6. CWV 指标阈值设定的背景是什么？

如果把 FCP 的优秀区间设为 0-0.1s，从指标上来看的确很优秀，但是又有几个网站能做到这么极致？所以这样来定阈值不具备任何参考价值。在 Google 评估如何设置阈值时，会根据 Chrome 用户体验报告 (CrUX) 中的数据来验证这些阈值是否可以实现， 为了确保该阈值可实现，要求至少有 10% 的用户满足该阈值的条件，并且会根据实际数据的变化不断进行调整。 基于各类文献可以得出，各个指标阈值的设置主要基于以下两点：

• 体验质量
• 可实现性

6.1 LCP 的取值依据

体验质量：

基于“一秒钟原则”，我们通常认为，用户对一项任务失去注意力的等待时间为 1s，Google 研究发现，1s 这个值是用来描述一个区间的近似值，这个区间从几百毫秒到几秒不等。

1 秒阈值的两个常见引用来源是卡德等人和米勒。卡德通过引用纽厄尔的认知统一理论，定义了 1 秒的"立即响应"阈值。纽厄尔将立即响应解释为"必须在大约一秒钟内对某些刺激作出的响应（即大约从 0.3 秒到 3 秒）。"纽厄尔在此之前就"认知的实时约束"展开过讨论，其中指出"与环境交互引发的认知计算是以秒计的"，范围从大约 0.5 秒到 2-3 秒。1 秒阈值的另一个常见引用来源是米勒，他指出"如果响应延迟超过两秒（可能超出时长为一秒左右），那么人类可以通过且将会通过机器通信执行的任务将发生严重的特征改变。"

基于以上研究，LCP （最大内容绘制）的“良好”阈值应该在 0.3s-3s 之间，由于 FCP （首次内容绘制）的“良好”阈值为 1.8s（2021 年更新的数据），所以最终 LCP 的“良好”候选阈值应该在 1.8s-3s 之间。

可实现性：

确定好阈值之后我们再来看能够满足候选“良好”阈值所占的百分比，从 CrUX 的数据我们可以看到：

只有不到 10% 的域满足 1s 的阈值，但 1.5 秒到 3 秒之间的其他所有阈值也都满足我们的要求，即至少有 10% 的域满足"良好"阈值，因此这些阈值仍然是有效的候选值。 此外，为了确保所选取的阈值对于优化良好的网站始终都可实现，我们分析了全网表现最出色的网站的 LCP 性能，从而确定哪些阈值对于这些网站是始终都可实现的。具体来说，我们的目标是确定一个对于表现最出色的网站来说，始终可以在第 75 个百分位数实现的阈值。我们发现，1.5 秒和 2 秒的阈值并不是始终都可以实现的，而 2.5 秒的阈值是始终可以实现的。

6.2 CLS 的取值逻辑 体验质量：

累积布局偏移 (CLS) 是一项新指标，用于测量页面可见内容的偏移量。鉴于 CLS 是一项全新指标，我们不知道能够直接为该指标的阈值提供参考的研究。因此，为了确定一个符合用户期望的阈值，我们对具有不同布局偏移量的真实世界页面进行了评估，进而确定在对享受页面内容造成严重干扰之前，用户可接受的最大偏移量。在我们的内部测试中，我们发现 0.15 及以上的偏移水平始终被认为具有干扰性，而 0.1 及以下的偏移水平虽然可以被注意到，但不具有过度干扰性。因此，虽然零布局偏移是理想情况，但我们得出的结论是，0.1 及以下的值是 CLS 的候选"良好" 阈值。

可实现性：

虽然 CrUX 数据表明 0.05 可能是一个合理的 CLS "良好"阈值，但我们认识到，目前在某些用例中还难以避免干扰性的布局偏移。例如，对于如社交媒体嵌入这样的第三方嵌入内容，嵌入内容的高度有时在完成加载之前是未知的，这就可能导致布局偏移大于 0.05。因此，我们的结论是，虽然许多域都满足 0.05 的阈值，但将 CLS 阈值定为略微宽松一点的 0.1 能够在体验质量和可实现性之间取得更好的平衡。我们希望网络生态系统在未来能够确定一个针对由第三方嵌入引起的布局偏移的解决方案，这将使我们能够在核心 Web 指标的未来迭代中采用 0.05 或 0 这两个更为严格的 CLS "良好"阈值。

6.3 FID 的取值逻辑

体验质量：

雅各布·尼尔森 (Jakob Nielsen) 撰写的响应时间：3 个重要界限常常被引用，文章中将 0.1 秒定义为用户感觉到系统立即做出反应的界限。
在实现时间性的完美虚拟按钮一文中，卡雷索亚 (Kaaresoja) 等人研究了在不同的延迟下，触摸触屏上的虚拟按钮和随后显示按钮被触摸的视觉反馈之间的同时性感知。当按下按钮和视觉反馈之间的延迟为 85 毫秒或更短时，参与者在 75% 的情况下报告视觉反馈是在按下按钮的同时出现的。此外，对于 100 毫秒或更短的延迟，参与者报告的按下按钮的感知质量始终很高，而感知质量在 100 毫秒到 150 毫秒的延迟下有所下降，并且在 300 毫秒的延迟下达到非常低的水平。

鉴于上述研究，Google 得出结论，100ms 左右的延迟值范围是 Web 指标合适的首次输入延迟阈值。 此外，鉴于用户在 300 毫秒或更长的延迟下报告了低质量级别，则 300 毫秒为合理的"欠佳"阈值。

可实现性：

据 Google 观察，全网最出色的网站始终能够在第 75 个百分位数上（并且通常在第 95 个百分位数上）满足此阈值，所以 100ms 是合理的 FID “良好” 阈值。

三、性能数据分析

1. 多通道数据流转

在数据流转通道的设计上，为了兼容多端的性能数据采集和旧的采集逻辑，我们采用了多通道 + 对照组的方式。 多通道（Web + App）：

• Web：黄金令箭多点位对性能数据进行采集
• App：UT 通道，保障数据传输效率和完整性

对照组（SLS）：

• 同时将数据采样发送至 SLS，用于数据对比，数据准确性矫正；

2. 多维度聚合分析

为了满足开发者的性能分析诉求，我们需要对采集上报的性能数据进行多维度的聚合处理，区别于以往的取平均值进行分析，我们对取值范围进行了扩充，包括（75 百分位、中位数、90 百分位），用于分析长尾性能数据、规避离群值对整体性能的影响。 同时基于场景、URL、spm_id、国家、端型等多个维度，对性能数据进行聚合，让开发者能通过不同视角进行性能分析，保障性能分析的准确性。

3. 为什么默认取 75 百分位值？

参考一些业内各类文献，选择 75 百分位值的原因基于如下两个标准：

1. 选取的百分位值应当 确保对页面或网站的大多数访问都达到了目标性能水平
2. 选取的百分位值应当 不受异常值的过度影响

这两点如何解释呢？

首先是第一点，通俗一点讲就是应该选择一个高百分位值，也就是大部分页面都能实现的值，但是随着百分位值的升高，结果值受异常数据影响的可能性就越大。 其次是第二点，如果我们为了满足第一个标准，可以选择一个较高的百分位（例如：95 百分位数）作为阈值， 但是随着百分位数的增加，其结果值越容易受到异常数据的影响。 比如我们使用 95 百分位数对页面进行评估，页面总共采集了 100 条数据，如果其中有 5 条数据是异常值，那么第 95 百分位数就会收到异常值的影响。 综上所述，为了兼顾两个目标，分析得出 75 百分位值更接近合理的平衡点，在采用 75 百分位值时，大多数网站都能达到性能水平或者更高，且 100 条数据中，只有当异常数据达到 25 条时，才会对结果值造成影响，几率相较于 95 百分位值更低，结果值的可信度更高。

四、性能报表展示

基于分析的数据需要找到合适的报表进行性能数据的展示，同时为了提供全球化的视野，性能平台进行了一系列的定制开发。

1. 核心性能指标卡片

• 筛选框：可以根据日期、地区、端型进行数据筛选
• 总采样 PV，指当前采集到性能数据的条数
• 核心指标模块：

• 指标分级：数据异常（紫色）、较差（红色）、良好（橙色）、优秀（绿色）
• 指标趋势：展示当前指标较昨日的变化情况，绿色为下降，红色为上升。（这里的核心指标下降都是向好趋势）

2. 性能优化方案

• 指标状态：会根据当前情况展现指标分级后的中文描述（数据异常、较差、良好、优秀）
• 解决方案：会根据现有沉淀的性能解决方案给出建议

3. 页面主文档 - 网络加载链路分析图

主要分为【网络加载阶段】和【页面渲染阶段】，各阶段计算逻辑参考：

4. 实时数据趋势图

• 基于 SLS 通道，实现全球性能数据的实时观测

5. 全球流量分布图

• 全球流量分布：按 pv 排序，可以根据对应的国家进行数据下钻

6. 用户性能分布图（Google CrUX 数据）

• 指标分级占比：该直方图展示的是 URL 在各级别区间的占比，拿图中 FCP 指标举例，可以理解为该页面 FCP 指标优秀占比为 52.70%，良好占比为 30.12%，剩下的则为较差的级别。
• 75 百分位值：图中箭头所指的 p75 数据为 Google 分析的用户数据排行第 75 百分位的值，指向的区域颜色代表了网站当前的性能情况（绿色：优秀、橙色：良好、红色：较差）。

五、小结

以上就是目前 ICBU 在全球化前端性能领域的探索进度，未来还会不断的有新的能力和方案沉淀。 最后，我们一定要清楚的认识到 性能指标好 ≠ 用户体验好 ，但是性能指标依然是辅助我们进行分析和优化的指南针，会引导我们更好的持续优化用户体验。

参考链接：

• 定义核心 Web 指标阈值：https://web.dev/defining-core-web-vitals-thresholds/
• 认知统一理论：https://dl.acm.org/doi/book/10.5555/86564
• 响应时间：3 个重要界限：https://www.nngroup.com/articles/response-times-3-important-limits/
• 因果关系感知：https://psycnet.apa.org/record/1964-05029-000
• 实现时间性的完美虚拟按钮：https://dl.acm.org/doi/10.1145/2611387
• Web Vitals Changelog：https://chromium.googlesource.com/chromium/src/+/master/docs/speed/metrics_changelog/README.md
• CWV 等体验指标纳入 Google 搜索排名：https://developers.google.com/search/blog/2020/11/timing-for-page-experience
• CWV FAQ：https://support.google.com/webmasters/thread/86521401