CWV是性能症状而非原因。通过OpenTelemetry将其整合到以用户为中心的可观测性中，可提供上下文，理解性能问题“为何”发生，连接用户体验与业务成果，并弥合前后端鸿沟。
译自：A User-Focused Approach To Core Web Vitals via OpenTelemetry
作者：Virna Sekuj
Core Web Vitals (CWV) 是我们用于监控前端性能的，基于用户体验的最标准化遥测数据之一。它们在获取网站基本性能方面（如加载时间和交互性）的快照方面非常有用。但用户期望和行业工具都已超越静态指标，孤立的 CWV 不足以满足性能需求。
通常，这些指标被视为 SEO 分数。尽管 CWV 对于网站排名和可发现性至关重要，但我们还可以做更多事情来利用这些数据进行故障排除和优化，以满足终端用户对更快、更稳定、响应更灵敏的网站日益增长的需求。
将 CWV 引入真正的可观测性领域，即典型的后端监控实践正在向前端发展，是实现这一目标的好方法。
Core Web Vitals 是症状，而非原因
谷歌定义的三项 CWV——最大内容绘制 (LCP)、累积布局偏移 (CLS) 和下一次绘制交互 (INP)——描述了用户如何体验应用程序或网站。它们捕捉了用户体验 (UX) 的基础要素：加载速度、稳定性和交互性。
然而，它们常常孤立存在，与用户试图完成的更广泛的流程和目标脱节。例如，工程团队可能会将 LCP 缩短半秒，却发现结账转化率并未提高。这些指标在描述“发生了什么”方面很出色，但它们没有触及“为什么”。
可观测性存在的目的正是揭示这一点。它追踪从缓慢的 API 到延迟渲染的路径，将技术行为与人类体验联系起来。通过将 CWV 集成到以用户为中心的可观测性系统中，团队可以用解释这些体验的上下文来丰富每个追踪。
以用户为中心的可观测性是怎样的
当我们谈论以用户为中心的可观测性时，我们指的是什么？本质上，它是传统可观测性实践的演进，旨在确保我们对数据的仪器化、监控和分析都围绕真实用户影响展开。
传统可观测性关注系统和端点，而以用户为中心的可观测性将这一视角扩展到人，捕捉他们在实际使用产品时的体验。
例如，端点可能运行正常，但用户仍可能因前端渲染问题、JavaScript 瓶颈或本地网络状况而遇到困难。
以用户为中心的方法弥补了这一差距。
将 Core Web Vitals 与 OpenTelemetry 引入可观测性
将 CWV 变为可观测数据点，而不是孤立的指标，是获取更丰富、更具可操作性信息，从而真正帮助我们优化最终用户体验的关键。一种方法是采用 OpenTelemetry 等标准。
OpenTelemetry (OTel) 已经成为在微服务之间收集分布式追踪和指标的行业标准。同样的模型现在可以应用于前端性能，通过将传统上孤立的指标（如 CWV）视为更大的追踪中的 span 或span 事件，从而提供更多上下文。
例如，在 Embrace 的模型中，CWV 以带时间戳的 span 事件形式出现在代表完整用户会话的更大顶级 span 中。在 Honeycomb 的模型中，是他们的仪器化为浏览器追踪中的每个 CWV 创建一个 span，该追踪代表页面加载或用户交互，并将值作为 span 属性附加。
这些相似的方法保留了因果关系和上下文：
- 每个 CWV 都嵌套在一个更大的 span 或追踪中，而不是孤立存在。
- CWV 可以携带属性，例如负责的 DOM 元素、设备和网络条件或导致延迟的资源。
- 然后，这些事件可以与相邻的技术 span（例如 API 调用、图像获取或 JavaScript 执行）一起分析，以精确查明导致性能下降的原因。
- CWV 事件可以通过不同的解决方案与后端性能下降相关联，例如追踪上下文传播（如果在同一个工具中使用）或跨 OpenTelemetry 兼容工具的 span 转发集成。这弥合了前端和后端性能之间的差距。
这种方法不是将 CWV 视为独立的指标，而是将其视为用户实际体验中的可观测时刻。
这种方法的优点
采用这种以用户为中心、基于 OpenTelemetry 的 CWV 方法具有一些明显的优势：
- 您从聚合数据转向个体数据，并获得更精确的故障排除方法。
传统的 RUM 工具和 Chrome 用户体验报告 (CrUX) 在 75 百分位下运行，将多样化的用户体验扁平化为一个单一数字。但长尾用户，即那些使用较慢设备、较弱网络或具有复杂应用程序状态的用户，往往是揭示最关键性能问题的人。通过将每个 Core Web Vital 建模为用户会话时间线内的离散事件，您不再分析平均值，而是开始调查真实体验。每个 LCP、INP 和 CLS 事件都可以追溯到特定的用户旅程，包括设备上下文、网络状态以及其周围发生的技术操作。
- 您将用户体验 (UX) 与业务成果相关联，并可以优先处理最重要的性能问题。
一旦 CWV 事件存在于分布式追踪中，它们就可以与更高级别的产品或收入指标相关联。您可以停止猜测缓慢的 LCP “可能”会损害转化率，而是开始量化它。例如，您可能会发现 LCP 事件大于 3 秒的会话转化率低 15%，或者 CLS 的飙升与结账完成率的下降相关。因为这些 CWV 事件存在于更大的追踪中，这些追踪可以通过追踪传播或网络 span 转发等产品连接到后端，所以您可以在整个技术栈中衡量技术性能与用户参与度之间的关系。
- 您弥合了前端和后端之间的鸿沟，避免了无休止的试错修复周期。
将 CWV 视为 span 事件使前端和后端团队最终能在同一个时间线中看到相同的故事展开。当用户遇到缓慢的 LCP 时，它不再是埋藏在聚合报告中的谜团；它是一个直接位于导致它的 API 调用或第三方脚本 span 旁边的事件。这种共享可见性消除了困扰性能优化的试错循环。工程师不再猜测哪种修复“可能”有效，而是可以在上下文中追踪根本原因，从浏览器的渲染线程到数据库查询。
还有哪些工作要做
CWV、OpenTelemetry 和以用户为中心的可观测性之间的桥梁正在建设中，但尚未标准化。
一些供应商正在采用 span 方法来建模 CWV，这扩展了它们作为真正的用户体验标记而非单一指标的实用性。为使其成为普遍做法，OpenTelemetry 生态系统仍需在关键领域趋于成熟：
- 标准化： 针对
browser.web_vital事件的官方 OTel 语义约定仍在开发中；需要更广泛的采用和稳定化以实现互操作性。 - 原生支持： OTel JavaScript SDK 尚未默认发出 CWV 事件或将其映射到会话追踪中。
- 追踪上下文传播： 持续将前端 CWV 事件链接到后端追踪仍然需要仔细的标头传播和采样对齐。
- 跨供应商融合： 供应商必须就通用模式达成一致，以便 CWV 事件、会话追踪和后端 span 可以在不同工具之间进行协调分析。
脚手架已经存在，但成熟度尚未达到。然而，随着 OpenTelemetry 语义标准的成熟，工程师将获得更灵活的方法将 Core Web Vitals 集成到以用户为中心的可观测性系统中。
