衡量什么：以用户为中心的绩效的关键指标 (Measuring What Matters User Centric Performance)

以用户为中心的性能衡量

以用户为中心的性能衡量并不基于系统是否产生流量或技术负载；它着眼于人们是否快速、轻松、可靠且令人满意地实现目标。最强大的测量系统可以同时读取行为数据、用户感知、业务成果和技术性能。

1. 用户行为指标

这些显示了用户实际执行的操作：

• 任务完成率： 成功完成定义任务的用户百分比。
• 任务持续时间： 达到目标所需的时间。
• 错误率： 失败操作、验证错误或系统错误的频率。
• 错误恢复率： 发生错误后恢复并完成任务的用户百分比。
• 功能采用率： 合格用户在给定时间内使用该功能的比率。
• 漏斗放弃： 用户在多步骤流程中放弃的地方。
• 实现价值的时间： 注册或输入与第一个有意义的结果之间的时间。

行为指标在与特定用户目标相关时效果最佳，例如“完成结账”而不仅仅是“增加点击量”。 GitLab 的 UX 框架将任务完成情况、任务时间、错误、首次点击准确性和功能采用率视为关键行为指标。 handbook.gitlab

2. 用户感知指标

分析显示发生了什么；态度指标有助于解释原因：

• 客户满意度 (CSAT)： 他们对体验的满意度。
• 感知的易用性： 产品使用起来的容易程度。
• 客户努力得分 (CES)： 他们认为自己付出的努力。- **感知效率：**产品是否节省时间。
• 净推荐值 (NPS)： 推荐产品的可能性。
• **感知有用性：**是否解决了有意义的问题。

一个产品可能具有很高的任务完成率，但仍然让人感到沮丧或不必要的困难。因此，行为和态度措施应一起评估。 handbook.gitlab

3. 留存率和价值指标

这些表明产品是否提供持续的价值：

• 激活率： 新用户完成第一个有意义的操作的百分比。
• 留存率： 一段时间后返回并保持活跃的用户百分比。
• 流失率： 停止使用该产品的用户百分比。
• DAU/WAU/MAU： 每日、每周和每月活跃用户。
• 粘附性： 一般近似为 DAU÷MAU 比率。
• 群组保留： 按注册日期或共同特征单独跟踪群组。
• 推荐率： 用户推荐或邀请其他人的频率。

功能结构：定义代表交付给用户的价值的北极星指标，然后选择团队可以影响的两到三个输入指标。例如，协作产品将“每周成功的协作”列为其北极星；可以使用激活、功能采用和保留作为推动者。 youtube

4. 技术性能指标

在数字产品中，技术速度应该从用户的角度来衡量：

用户体验	有用的指标
首次曝光	首个内容绘制 (FCP)、最大内容绘制 (LCP)
决心	累积布局偏移 (CLS)
服务器响应	第一个字节的时间 (TTFB)
流畅度	帧一致性和动画响应
可靠性	崩溃、请求失败、中断和错误率

Web 性能应通过受控实验室测试和真实用户监控 (RUM) 来衡量；因为设备、网络、个性化和交互从根本上改变了体验。 网络

5. 一组实用的测量

大多数团队可以从五个指标开始：

1. 价值指标： 主要结果是用户前来的原因。
2. 行为指标： 任务完成率或任务持续时间。
3. 感知指标： CSAT、CES 或感知的易用性。
4. 保留指标： 群组保留或重用。
5. 可靠性或性能指标： 错误率、INP、LCP 或正常运行时间。

好的指标应该是清晰的、规范化的、随着时间的推移具有可比性、划分为有意义的用户组并且可操作。不要仅仅依赖总页面浏览量、下载量、注册用户或会话持续时间；这些可以在不产生有意义的价值的情况下增长。 youtube

示例

对于在线退款服务：

• 北极星： 成功退回每位在职员工的索赔。
• 行为： 请求完成率和中值提交时间。
• 感知： 发货后易用性评分。
• 保留： 在 90 天内提交第二次请求的员工百分比。
• 技术： 插头加载期间的错误率和 INP。
• 诊断： 凭证验证步骤中的放弃率。这种组合不仅决定了有多少人进入流程；还决定了有多少人进入流程。他们是否能够完成它，体验感觉如何，他们是否返回，以及技术问题是否阻碍了成功。

本节中重复出现的概念```text

📦 Laboratuvar vs saha Kontrollü, tekrarlanabilir teşhis ile gerçek kullanıcı ortamındaki doğrulama.

📦 Core Web Vitals (CWV) LCP, INP ve CLS—yükleme, yanıt ve görsel kararlılık; gerçek kullanıcıların 75. yüzdeliğinde.

📦 FID → INP (Mart 2024) FID yalnızca ilk girdi gecikmesini ölçüyordu; INP ziyaret boyunca etkileşim yanıtını ölçer.

📦 RUM Gerçek kullanıcı izleme: cihaz, ağ, rota ve özellik boyutlarında production ölçümü.

📦 CrUX Chrome kullanıcı deneyimi raporu—uygun siteler için kamuya açık saha verisi.

📦 Performans bütçesi LCP/INP/CLS, JS ağırlığı, üçüncü taraf maliyeti ve iş akışı başarı limitleri.

📦 Attribution (ilişkilendirme) web-vitals attribution build: LCP öğesi, INP hedefi, LoAF ve alt faz süreleri.

## 实验室测试和现场测量

**以用户为中心的性能实验室测试**在受控、可重复的条件下测量产品； **现场测量**观察用户真实环境中的性能。实验室结果通常更适合找出问题的原因；现场结果可以更好地了解产品在日常使用中是否有效。 [web.mit](https://web.mit.edu/6.813/www/sp16/classes/11-experiment-design/)

### 实验室测试

实验室测试将用户、任务、设备和条件纳入定义的协议中。

典型尺寸：

- 任务完成率。
- 任期。
- 错误频率和恢复。
- 导航或点击路径。
- 首次点击准确性。
- 感知的可用性和工作量。
- 任务后满意度。
- 设计版本之间的比较。

**优点：**高控制性和重复性；比较竞争设计很容易；隔离特定的接口问题；适用于原型设计和受控 A/B 型实验。

**限制：**参与者的行为可能会有所不同，因为他们知道自己正在被观察；人为的任务可能无法反映真正的优先事项；安静的测试室无法重现所有工作场所、网络或技术条件。如果真实环境更具挑战性，实验室可能会高估可用性。

比较实验室和现场可用性测试的研究并未找到普遍的赢家：当条件有利时，结果可能相似；当条件有利时，结果可能相似；当条件有利时，结果可能相似。差异出现在困难的条件、较差的可用性或竞争的任务中。 [pubmed.ncbi.nlm.nih](https://pubmed.ncbi.nlm.nih.gov/30487113/)

### 现场测量现场测量是在用户通常工作、旅行、购物或操作产品的地方进行的。它可能包括直接观察、情境访谈、日记研究、远程遥测或现场可用性测试。

有用的现场指标：现实世界的任务成功；持续时间，包括中断；环境和网络条件；设备/平台差异；错误频率和严重性；解决方法；重用和保留；滞后、崩溃和失败的请求；用户对工作流程合规性的评论。

**优点：**真实的行为和背景；分心会暴露基础设施或环境工具造成的问题；它显示了产品是否融入了真实的日常生活。它在移动、工作场所、工业、医疗保健和基于位置的产品中尤其有价值。

**限制：**对变量的控制较少；难以直接比较参与者；数据可能比较嘈杂；隐私和同意要求更加严格。

现场现实性强，实验室精密性和控制性强。 [web.mit](https://web.mit.edu/6.813/www/sp16/classes/11-experiment-design/)

### 测量什么？

|问题 |实验室测量|场地尺寸|
|---|---|---|
|用户能完成任务吗？ |定义场景中的完成率 |实际工作完成率|
|他们的工作效率如何？ |任务持续时间、点击次数、击键次数 |持续时间，包括中断、转换和解决方法 |
|出了什么问题？ |观察到的错误和失败的交互 |生产错误、支持请求、放弃的任务 |
|感觉如何？ |满意度、工作量、感知可用性 |长期满意度、信任、挫折、感知价值 |
|可靠吗？ |受控响应时间和设备测试|真实延迟、连接变化、崩溃和故障 ||它能产生价值吗？ |即时任务结果 |重用、保留、采用和业务/用户成果 |

### 推荐方法

将两者用作循环；不要只选择一个：

1. **从实验室开始**——发现明显的可用性问题，比较替代方案。
2. **现场测量**——在真实条件下测试行为。
3. **返回实验室**——调查重大现场问题的原因。
4. **在生产中验证** - 通过分析、反馈和性能监控。
5. **对结果进行切片**——设备、体验、辅助功能需求、位置、连接和任务类型。

示例：移动费用应用程序在实验室中可能会获得 95% 的运费。在光线较差或移动网络较差的情况下拍摄芯片时，该领域可能会出现丢帧现象。实验室指示接口问题；该领域揭示了使其重要的环境和技术条件。

基本原则：**描述实验室技能；现场验证实际性能**。可靠的以用户为中心的评估通常需要两者。

## 核心网络生命力：关键指标

**核心网络生命力 (CWV)** 是 Google 以用户为中心的指标，用于评估页面体验的三个部分：加载、响应能力和视觉稳定性。当前设置是**LCP、INP 和CLS**。 [网络](https://web.dev/articles/vitals)

|公制|采取什么措施|好目标|
|---|---|---:|
| **最大内容涂料 (LCP)** |主要可见内容（英雄图像、标题或大文本块）出现的速度有多快？ ≤ 2.5 秒 |
| **与下一个油漆的相互作用（INP）** |在整个访问过程中对点击、敲击和键盘交互的视觉响应有多快？ ≤ 200 毫秒 |
| **累积布局偏移 (CLS)** |加载或使用页面时有多少可见内容意外发生变化 | ≤ 0.1 |

### 每个指标都说明了什么？- **LCP — 加载：** “用户能否快速看到重要内容？”
- **INP — 响应：** “用户交互时界面是否立即响应？”
- **CLS — 稳定性：** “他们可以阅读并点击页面而不会意外滚动吗？”

INP 将于 2024 年取代**首次输入延迟 (FID)**——正式过渡**2024 年 3 月 12 日**。 FID 仅测量初始相互作用； INP 评估整个访问过程中的互动反应。自 2024 年 9 月起，浏览器工具中的 FID 支持已停止。 [dynatrace](https://www.dynatrace.com/knowledge-base/core-web-vitals/) · [developer.chrome](https://developer.chrome.com/docs/crux/release-notes)

### CWV 是如何评估的？

真实用户数据**75。以百分比**表示，分别针对移动设备和桌面设备进行测量。要使页面获得总体“良好”CWV 评级，所有三个指标都必须满足“良好”阈值。 [网络](https://web.dev/articles/vitals)

Lighthouse 和 Chrome DevTools 对于问题诊断很有用；真实的用户现场数据显示跨设备、网络和位置的实际性能。 PageSpeed Insights、CrUX 和 Search Console 有助于跟踪这些结果。 [网络](https://web.dev/articles/vitals)

### 典型的补救措施

- **LCP：**优化视觉效果，减少渲染阻塞资源，提高服务器响应，优先考虑首屏内容。
- **INP：** 分割长 JavaScript 任务，限制主线程工作，加速事件处理程序。
- **CLS：** 为图像和广告分配空间，不要在现有内容之上添加内容，修复字体和大小。

CWV是有价值的技术指标；但应与以用户为中心的结果相结合，例如任务完成、放弃、满意度和转换。快速页面不一定是有用或成功的页面。## 最大内容涂料 (LCP)

**LCP 测量用户打开页面后主要可见内容出现的速度。** 它记录视口中最大图像、视频帧或文本块渲染完成的时刻；是感知加载速度的有力指标。 [网络](https://web.dev/articles/lcp)

### 什么才算是 LCP？

LCP元素通常：英雄或横幅图像；突出的标题或文本块；产品形象；视频海报或第一个可见视频帧；这是一个加载了 CSS 的大图像。

LCP 与 **First Contentful Paint (FCP)** 不同：FCP 测量任何内容出现的第一时刻； LCP 估计主要内容变得可见的时刻。 [网络](https://web.dev/articles/lcp)

### LCP 阈值

| LCP 结果 |经验|
|---|---|
| **2.5 秒或更短** |好 |
| **超过 2.5 – 4 秒** |应该改进|
| **超过4秒** |弱|

**75% 的页面加载。考虑百分比**，至少与移动设备和桌面设备分开，以便结果代表大多数用户，而不仅仅是平均值。 [网络](https://web.dev/articles/lcp)

### LCP 缓慢的原因是什么？

LCP 通常由 **四个延迟** 组成：

1. **服务器响应延迟：** 浏览器等待第一个 HTML 响应 (TTFB)。
2. **加载延迟：** 浏览器较晚发现LCP资源或较晚开始请求它。
3. **资源加载时间：** 图片、视频、字体或其他内容需要很长时间才能下载。
4. **渲染延迟：** 源已准备就绪，但 JavaScript、CSS 或其他工作延迟了渲染到屏幕的时间。 [developer.chrome](https://developer.chrome.com/docs/performance/insights/lcp-breakdown)根据 HTTP Archive Web Almanac 2024，大约 73% 的移动页面上，LCP 元素是图像；基于图像的 LCP 往往比基于文本的 LCP 慢大约两倍。关闭首屏 LCP 映像中的延迟加载并在必要时使用 `fetchpriority="high"` 给予网络优先级，可以保留关键预算。

### 如何提高LCP？

- 改善服务器响应；使用有效的缓存或 CDN。
- 优化 LCP 图像并正确调整其大小。
- 使用现代格式和适当的压缩。
- 当发现延迟时，仅预加载关键的 LCP 资源。
- 不要延迟加载首屏 LCP 图像。
- 删除渲染阻塞 CSS 和不必要的 JavaScript。
- 减少长主线程任务。
- 加载网络字体时使重要文本快速显示。
- 避免过多的重定向和关键请求链。

使用 Lighthouse 等实验室工具来诊断原因；使用真实用户现场数据验证改进。在受控测试中看起来不错的页面对于速度较慢的设备或网络上的用户来说可能仍然会产生较差的 LCP。

## FID、INP 和 CLS

这些指标涵盖体验的两个不同部分：**响应性**（页面响应输入的速度）和**视觉稳定性**（内容是否停留在用户期望的位置）。

### 首次输入延迟 (FID)

**FID 测量用户首次交互和浏览器开始处理交互之间的延迟。** 它仅捕获初始输入延迟，例如，按钮点击和事件处理程序启动之间的延迟。FID 最初用于检测被 JavaScript 阻止的页面；但它没有测量完整的交互或后续交互。 FID 现已不再作为 **Core Web Vital 退役，并由 INP** 取代。 [developer.chrome](https://developer.chrome.com/docs/crux/release-notes)

FID的架构缺点是它允许开发人员通过异步事件人为地提高分数；当长时间的任务在后台运行时，用户会感觉页面枯燥。 INP 消除了这个盲点。

### 与下一次绘制的交互 (INP)

**INP 衡量整个访问过程中对用户交互的视觉响应的速度。** 输入延迟包括事件处理程序处理、渲染作业以及下一次屏幕更新之前的时间。 [网络](https://web.dev/articles/inp)

示例：点击导航菜单；在搜索字段中输入；不要触摸“添加到购物车”；打开对话框或弹出菜单；选择过滤器或选项卡。

| INP 分数 |响应能力|
|---|---|
| **≤ 200 毫秒** |好 |
| **> 200 – 500 毫秒** |应该改进|
| **> 500 毫秒** |弱|

好的 INP 是实际页面访问量的 **75%。百分比**——通常移动设备和桌面设备是分开评估的。 [网络](https://web.dev/articles/optimize-inp)

INP 分为三个子阶段：**输入延迟**（如果主线程繁忙）、**渲染时间**（繁重的事件处理程序）、**呈现延迟**（样式/布局/绘制和大型 DOM）。优化取决于哪个阶段占主导地位。

#### 提高 INP

- 拆分长 JavaScript 任务（`scheduler.yield()` 或调度程序 API）。
- 减少不必要的 JavaScript 和第三方脚本。
- 保持事件处理程序小而高效。
- 将非必要的工作推迟到互动之后。
- 避免过多的 DOM 更新。- 使用高效的渲染和动画技术。
- 减少页面加载期间主线程阻塞。

**长动画帧 (LoAF)** API 公开超过 50 毫秒的可视化更新来诊断 INP：按调用程序、脚本类型和 `sourceURL` / 字符位置标记罪魁祸首代码。

### 累积布局偏移 (CLS)

**CLS 衡量可见内容的意外移动。** 高 CLS 意味着按钮、文本或图像出现后发生移动；用户可能会失去位置或单击错误的控件。 [网络](https://web.dev/articles/cls)

常见原因：图像/视频尺寸过大；放置在现有内容之上的广告或横幅；延迟加载字体改变文本大小；动态通知；在布局变得可见后更改布局的 JavaScript。

| CLS 分数 |视觉稳定性 |
|---|---|
| **≤ 0.1** |好 |
| **> 0.1 – 0.25** |应该改进|
| **> 0.25** |弱|

CLS 是一个无单位的分数，而不是时间度量。它考虑了受影响的视口比率和偏移距离。 [docs.newrelic](https://docs.newrelic.com/docs/new-relic-solutions/observability-maturity/digital-experience/l2-cwv-cls/)

#### 改进 CLS

- 为图像和视频开放 `width` 和 `height`。
- 为广告、嵌入和动态内容分配空间。
- 不要在已经可见的内容之上插入内容。
- 预加载或固定重要字体。
- 更喜欢 `transform` 和 `opacity` 而不是动画中的布局功能。
- 使用与最终内容尺寸相同的占位符。
- 如果您使用 `content-visibility: auto`，请使用 `contain-intrinsic-size` 预留空间以避免滚动。

### 实际区别- **FID：** 浏览器是否快速处理第一次交互？ （历史）
- **INP：** 页面在整个访问过程中是否快速响应交互？
- **CLS：** 当用户阅读和交互时，页面视觉上是否稳定？

在当前的 Core Web Vitals 报告中重点关注 **INP 和 CLS**； FID 在解释旧报告或历史数据时最有意义。

## 超越核心网络生命力

LCP、INP、CLS为强制；但它并不能解释所有性能问题。支持指标诊断原因；产品和业务指标显示技术改进是否真正对用户有效。

### 解释支持指标和报告

|公制|有什么帮助解释|
|---|---|
| **首次内容绘制 (FCP)** |用户第一次看到任何页面内容 |
| **第一个字节的时间 (TTFB)** |服务器、网络和后端响应延迟 |
| **总阻塞时间 (TBT)** |实验室测试中主线程阻塞|
| **速度指数** |可见内容逐渐出现的速度有多快？
| **焊接重量** | JavaScript、CSS、图像、字体和第三方负载大小 |
| **长期任务/LoAF** | JavaScript 和长关键帧阻塞主线程 |
| **错误率和失败率** |请求、脚本或关键工作流程是否失败 |
| **转型、放弃和任务成功** |性能是否影响用户结果 |

FCP 和 TTFB 在诊断 LCP 时特别有用：TTFB 可以揭示服务器延迟，FCP 可以揭示渲染阻塞或过早渲染问题。 TBT 本质上是**实验室诊断**；字段不会取代 INP。 [网络](https://web.dev/articles/user-centric-performance-metrics)

解读报告时：1、从现场数据入手；查找受影响的页面、设备、地理位置、浏览器和用户段。
2. 看第 75 个百分位数，而不是平均值。
3. 将“用户体验”与“原因”分开。
4. 使用实验室工具重现并隔离原因。
5. 不仅仅是得分最低的页面；优先考虑影响重要旅程的问题。
6. 假设、有针对性地改变、再次测量。
7. 验证更改是否提高了性能和用户结果，例如完成或转换。

不要将灯塔得分视为目标。目标不是“100”，而是“100”。它们为真实用户带来更快、响应更灵敏、更稳定的体验。

### 不断发展的客户端架构（简要）

在 SPA 中，软导航不会重置 LCP，并且 CLS 可能会继续累积。实验性 **软导航 API** 可检测用户操作 + URL 更改 + 可见绘制条件下的软导航，为测量 RUM 中的间隙 LCP 打开了大门。使用 **Speculation Rules API** 进行预渲染/预取可以使 LCP 更接近于零（跟踪部分中的 Ray-Ban 示例）。 **sGTM（服务器端标签管理器）**减少了主线程和 DNS/TLS 成本，以从浏览器获取第三方标签权重 - 直接反映在 INP 和 LCP 中。

## 实验室工具

### Lighthouse：绩效审计

Lighthouse 提供性能、可访问性、SEO、最佳实践和 PWA 功能的自动审核。绩效报告包括指标、诊断检查、机会和建议的改进链接。 [developer.chrome](https://developer.chrome.com/docs/devtools/lighthouse)

使用灯塔用于：

- 拉取请求或构建控件。
- 可重复的基线比较。
- 检测渲染阻塞源。- 查找过大的图像和未使用的 JavaScript。
- 研究 LCP、CLS、FCP、TBT 和相关实验室指标。
- 测试网站流量低或无流量的页面。

在一致的条件下运行 - 相同的 URL、设备模拟、网络配置文件、身份验证状态和重复。考虑单次运行的噪音；查看中位数或趋势。在 Lighthouse CI 中，`numberOfRuns`（例如 3-5）和基于度量的断言根据分数噪声创建更可靠的门。

### Chrome DevTools 性能面板：深度诊断和人工智能辅助

性能面板记录浏览器跟踪，包括网络活动、CPU 工作、JavaScript 执行、渲染、布局、绘制和用户交互。 Lighthouse 是当您发现症状但需要找到确切的阻塞活动时使用的工具。 [developer.chrome](https://developer.chrome.com/docs/devtools/performance/overview)

实际工作流程：

- 节省页面加载或缓慢的交互。
- 在 **Insights** 视图中查找 LCP 阶段、渲染阻塞请求、布局转换违规者和长任务。
- 找到负责主时间线和火焰图的脚本、样式重新计算、布局或绘制。
- 将跟踪与网络面板和受影响的 DOM 元素相关联。
-修正后重新保存。

Chrome DevTools 还为保存的性能配置文件提供 AI 帮助。能够解释选定的见解或跟踪活动并提出可能的改进建议；将其用作分析辅助工具，根据您的跟踪和代码验证每个建议。 [developer.chrome](https://developer.chrome.com/docs/devtools/ai-assistance/performance) LoAF 寄存器将 INP 瓶颈缩小到功能和资源位置。

### WebPageTest：真实测试和高级分析WebPageTest 对于跨位置、浏览器、设备、连接配置文件和重复运行的实际高级测试非常有用。 **幻灯片** 用户随时间推移看到的内容； **瀑布**显示请求依赖性、调度、优先级和资源延迟。 [performance.shopify](https://performance.shopify.com/blogs/blog/how-to-test-with-webpagetest)

研究时使用它：

- 某些国家或地区的性能缓慢。
- 移动设备和缓慢的网络行为。
- 与第一次出现重复出现。
- CDN、DNS、TLS、服务器和连接调度。
- 视觉发现和请求优先级。
- 第三方脚本和瀑布瓶颈。
- 视觉进步，而不仅仅是最终分数。
- 第三方SPOF模拟（标签服务器宕机时关键路径是否被阻塞）。

## 现场工具

### 使用 `web-vitals.js` 在现场捕获 CWV

`web-vitals` 库在浏览器中测量 Core Web Vitals，并将结果发送到您的分析或可观察系统。一个最小的应用程序：```html
<script type="module">
  import {onCLS, onINP, onLCP}
    from 'https://unpkg.com/web-vitals@4?module';

  function sendToAnalytics(metric) {
    navigator.sendBeacon('/rum', JSON.stringify({
      name: metric.name,
      value: metric.value,
      id: metric.id,
      path: location.pathname
    }));
  }

  onCLS(sendToAnalytics);
  onINP(sendToAnalytics);
  onLCP(sendToAnalytics);
</script>
```官方库还提供了 **attribution** 构建：LCP 元素或资源为 INP 添加调试上下文，例如 `inputDelay` / `processingDuration` / `presentationDelay`、`interactionTarget` 和 LoAF 记录。它给出的是犯罪坐标而不是分数。 [developers.google](https://developers.google.com/codelabs/chrome-web-vitals-js)

在生产中添加隐私安全维度：页面模板和路线；设备类别和连接类型；浏览器和操作系统；国家或地区；版本;登录/匿名；实验或功能标志。

除非您的隐私设计明确允许，否则请勿提交 URL、用户 ID、表单内容或其他个人数据。

### CrUX 和外部数据

**Chrome 用户体验报告 (CrUX)** 代表符合条件的真实 Chrome 用户在热门网站上的体验。通过PageSpeed Insights、Search Console、CrUX API和BigQuery提供LCP、INP、CLS等维度的现场数据。 [developer.chrome](https://developer.chrome.com/docs/crux)

CrUX 的价值在于： 针对公共网络进行基准测试；检查性能问题是否影响真实用户；验证版本是否会改变现场性能；移动端与桌面端的比较；历史趋势。

CrUX 有覆盖范围和可用性限制；它可能不代表每个用户或每个页面。 28日均线未能显示出昨日派发的影响。与第一方 RUM 一起使用以获得精确的受众和产品特定维度。

### 超越 Web Vitals RUM

真实用户监控还应该捕获：

- 路线变更或 SPA 导航计时（可以通过软导航增强）。
- API 延迟和失败的请求。- JavaScript 错误和承诺拒绝。
- 长任务和长关键帧 (LoAF)。
- 按功能划分的交互延迟。
- 搜索、支付、登录或上传完成。
- 愤怒点击，重试并放弃。
- 崩溃、离线状态和连接更改。
- 可测量的可访问性故障。

有用的问题不仅仅是“INP 不好吗？”不是； “哪些交互速度慢，对于哪些用户，在哪个版本上 - 这是否阻碍了任务的完成？”

添加第三方营销/分析脚本进行测量时，可能会自相矛盾地破坏 INP/LCP。 **sGTM** 将浏览器中的数十个脚本折叠成一个第一方流；它将 JS 执行、DNS 和 SSL 的成本转移到云端，这样计量本身就不会损害性能。

## 预算、警报和持续监控

绩效预算将质量目标转化为可执行的限制。针对用户指标和原因定义预算：

- LCP：75% ≤ 2.5 秒。
- INP：75% ≤ 200 毫秒。
- CLS：75% ≤ 0.1。
- JavaScript 传输：按路线商定最大传输量。
- 页面总权重：按设备类别划分的最大值。
- 第三方请求：批准的清单和最高费用。
- 错误率：最大可接受百分比。
- 关键工作流程成功：最低完成率。

使用三个警报级别：

- **警告：** 接近公制限制。
- **回归：**指标因超过商定的百分比而恶化。
- **严重：** Core Web Vital 或关键工作流程已超出故障阈值。

Lighthouse CI 断言示例 — 更喜欢基于度量的门而不是分数：```json
{
  "ci": {
    "collect": {
      "url": ["http://localhost:3000/", "http://localhost:3000/blog"],
      "numberOfRuns": 3,
      "settings": { "preset": "desktop" }
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", {"minScore": 0.9}],
        "first-contentful-paint": ["warn", {"maxNumericValue": 2000}],
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}]
      }
    }
  }
}
```### 持续监控示例

一个实际的系统可能是这样工作的：

1. Lighthouse 在每个版本中都运行在一组具有代表性的页面上。
2. WebPageTest 每晚从多个位置和连接配置文件运行。
3. `web-vitals.js`（如果可能的话归属）发送生产中的匿名 LCP、INP 和 CLS。
4. 仪表板按版本、路线、设备和地理位置对结果进行切片。
5. 当移动 INP 连续两个周期恶化 15% 时，将触发警报。
6. 团队监控受影响的 DevTools + LoAF 交互。
7. 缩短较长的 JavaScript 任务后，将对跟踪数据和现场数据进行验证。
8. 只有在绩效提高且任务完成度/转化率不下降的情况下才会保留变更。

这会创建一个反馈循环：**Lighthouse 检测、DevTools 诊断、WebPageTest 压力测试、RUM 验证、预算防止回归**。

### 实践中的持续监控（简短案例说明）

- **Taboola：** 出版商网站上的 TBT/INP 高；使用 LoAF、第三方缩小尺寸和渲染引擎重新设计进行瓶颈标记。
- **Fotocasa：** FID 期间为绿色； 2024 年 3 月 INP 后，Search Console 中显示“需要改进/薄弱”。 RUM 解决了图库、地图和过滤器交互中隐藏的客户端缓慢问题。
- **Ray-Ban：** 使用推测规则预渲染产品页面； LCP 下降约 43%（低于 1 秒），PDP 转化率移动约 101%/桌面约 156% 增加。
- **T-Mobile：** 当 LCP 超过 2 秒时，每延迟 100 毫秒，转化率就会降低，跳出率就会增加；他们将速度转变为 KPI，并将访问订单转化率提高了约 60%。

该测量不是为了将板子涂成绿色；是让使命在真实的旅程中成为可能。

## 最常混淆的配对```text
❌ FID hâlâ güncel bir Core Web Vital’dır
✓ FID Mart 2024’te emekli oldu; odak INP’dedir (ziyaret boyunca yanıt)

❌ Yeşil Lighthouse skoru saha CWV’nin iyi olduğu anlamına gelir
✓ Lab teşhis eder; CrUX/RUM gerçek kullanıcı deneyimini doğrular

❌ Ortalama LCP “yeterince iyi”yi temsil eder
✓ 75. yüzdeliği mobil ve masaüstü ayrı izleyin

❌ TBT, INP’nin yerine geçer
✓ TBT lab teşhisidir; saha yanıtı için INP kullanın

❌ web-vitals skoru tek başına kök nedeni gösterir
✓ Attribution + LoAF etkileşim hedefi ve suçlu betiği gösterir

❌ CrUX dünkü deploy’u yansıtır
✓ CrUX ~28 günlük ortalamadır; anlık regresyon için birinci taraf RUM şarttır

检查表：衡量需要衡量的内容

1. 从行为、感知、保留和技术/可靠性中各选择一个北极星 + 一个指标。
2. 定义关键旅程的实验室场景和现场维度（设备、网络、地理位置、路线）。
3. 分别修复移动/桌面 LCP、INP 和 CLS 的 p75“良好”阈值。 4、将LCP拆分为四个延迟（TTFB、发现、下载、渲染）；将INP分为三个阶段。
4. 在代表性 URL 上运行 Lighthouse CI + WebPageTest；读取中值/趋势。
5. 使用 web-vitals （首选属性）+ 隐私安全维度在生产环境中安装 RUM。 7、使用CrUX进行基准测试；依靠 RUM 进行回归和特征诊断。
6. 定义预算和三个警报级别（警报/回归/严重）；通过任务成功或转变来验证改进。

如果这八项你都答不出来，那你还在“看比分”；您还没有进行面向用户的测量。

本集要点

1. 以用户为中心的衡量结合了行为、感知、保留和技术性能，而不仅仅是流量或实验室分数。 2.实验室解释能力及原因；现场验证真实世界的性能；两者是一个循环。
2. 当前的核心Web Vitals是LCP、INP和CLS； FID 是历史性的。 p75 处的阈值：LCP ≤ 2.5s，INP ≤ 200ms，CLS ≤ 0.1。
3. LCP分为四个延迟，INP分为三个阶段； LoAF 和归因将根本原因归因于坐标而不是分数。
4. 软导航、推测规则和 sGTM 等架构工具有助于消除测量盲点和第三方加权。
5. 预算、警报和持续监控使改进永久化； Taboola、Fotocasa、Ray-Ban 和 T-Mobile 表明，衡量与业务成果息息相关。

目标不是让棋盘变绿。目标是了解并有意识地进行设计，用户是否能够快速、可靠且令人满意地完成重要任务。

下一步：我们将把 Core Web Vitals 从“好的指标”转变为产品需求、预算和发布门槛。