前端可观测性：RUM 与 Core Web Vitals 监控

服务器指标再健康，也无法回答"用户在浏览器里到底经历了什么"。**真实用户监控（RUM）从浏览器侧采集真实用户的页面加载、交互、网络请求与错误，把"体验"变成可量化、可告警的数据。按 Datadog 的定义，一个用户会话（Session）**包含页面视图、用户操作、网络资源、错误与崩溃等事件，最长 4 小时、闲置 15 分钟自动结束。

为什么必须监控 Core Web Vitals

按 web.dev 官方定义，Core Web Vitals 是 Google 认为对所有网页都至关重要的三个真实用户指标，并给出明确阈值：

指标	衡量维度	良好阈值
LCP	加载性能	≤ 2.5 秒
INP	交互响应	≤ 200 毫秒
CLS	视觉稳定性	≤ 0.1

官方建议以第 75 百分位为评估口径，并区分移动端与桌面端。实验室工具（如 Lighthouse）用于上线前发现回归，但只有**现场测量（field data）**能反映真实设备、网络与用户行为的全貌——这正是 RUM 不可替代的原因。

参考：https://web.dev/articles/vitals

用 RUM 采集与关联

实践上分三步走：

埋点采集：接入 RUM SDK 或使用 web-vitals 库，把 LCP/INP/CLS 连同页面、设备、地域等上下文一起上报。
会话分析：按设备、浏览器、地域、页面切片查看性能分布，找出"慢用户"的共性。Datadog RUM 支持自定义搜索保存为视图，并直接在这些视图上建监控。
错误与崩溃追踪：错误追踪自动对错误、超时与崩溃分组告警，大幅缩短 MTTR；会话回放（Session Replay）则能像看录像一样复盘用户实际操作。

接入示例：web-vitals 与最小 RUM 上报

如果不想一上来就接商业 SDK，可以先自己用 web-vitals 库收数据。下面是最小可用的接入：

npm install web-vitals

import { onLCP, onINP, onCLS } from 'web-vitals';

function report(metric) {
  navigator.sendBeacon('/api/rum', JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,   // 'good' | 'needs-improvement' | 'poor'
    path: location.pathname,
    ua: navigator.userAgent,
  }));
}

onLCP(report);
onINP(report);
onCLS(report);

sendBeacon 适合在页面卸载或切后台时可靠地把数据送出去，避免用 fetch 在关闭标签页的瞬间丢失请求。metric.rating 是库按阈值算好的评级，后端直接按 poor 计数即可。接好后，把 SDK 拆到独立 chunk 异步加载，尽量别拖慢 LCP。

从前端指标到告警

RUM 的价值在于把体验指标变成告警源：例如"LCP P75 超过 2.5 秒""JS 错误率超过阈值"都可以配置监控。注意两点：一是用百分位与占比而不是平均值（平均值会掩盖尾部的糟糕体验）；二是把 RUM 告警与后端链路关联——页面慢往往要从 API 延迟、CDN 命中率去找根因。

告警阈值示例

下面是常见的前端性能告警项，可作为起点（具体阈值按业务微调）：

告警	建议阈值	说明
LCP P75	> 2.5s	首屏加载变慢，检查资源与图片
INP P75	> 200ms	交互卡顿，检查长任务与主线程
CLS P75	> 0.1	布局跳动，检查图片尺寸与字体加载
JS 错误率	> 1% 会话	结合错误追踪定位版本回归
崩溃率	> 0.1% 会话	优先处理，往往与特定设备/浏览器相关

告警要避免"一告就麻"。建议把告警细化到页面维度（比如只对核心落地页生效），并设置持续 N 分钟才触发，减少抖动造成的误报。

采集的取舍：采样、隐私与开销

RUM 采集是"越全越好"吗？并非如此。首先要做采样：对流量很大的站点，全量采集每条会话的成本与性能开销都不小，常见做法是按比例采样（如 10%-20%），但错误与崩溃事件通常全量保留，避免漏掉关键信号。其次要考虑隐私与合规：真实用户数据包含页面路径、设备信息甚至输入内容，部署前要确认是否触及 GDPR 等合规要求，配置脱敏规则，避免把敏感字段上报。最后是性能预算：RUM SDK 本身会占用少量带宽与主线程时间，要通过压缩、异步加载与按需初始化把它对 LCP、INP 的影响压到最低，否则监控本身就成了性能劣化源。

常见问题

RUM 和 Lighthouse 能互相替代吗？ 不能。Lighthouse 是合成测试，反映"一台固定设备上的表现"，适合上线前回归；RUM 反映真实用户分布，一个抓"会不会坏"，一个抓"实际有多慢"。
采样率设多少合适？ 没有统一答案。低流量站点可以全量；高流量站点从 10% 起步，观察采样数据与后端日志的对应关系再调整。错误与崩溃建议始终 100%。
用户隐私怎么处理？ 关闭或脱敏输入内容采集，避免收集可识别个人的字段；确认合规要求后配置数据保留期限。宁可少采，也不要违规。
指标只采到移动端怎么办？ 移动端与桌面端分开看，在 RUM 面板按设备维度过滤；优化目标也按占比最大的设备优先安排。

16IDC 观察

对独立站来说，RUM 是性价比极高的"用户体检报告"：它既能回答 SEO 语境下的体验问题（见 SEO 性能追踪），也能推动具体的性能优化（见 Core Web Vitals 优化）。如果已有 Sentry，可先在其上补 RUM 能力（Sentry 错误监控）；合成监控负责"主动演练"、RUM 负责"真实复盘"，两者互补见合成监控实战。更多内容请查看监控报警分类。

原文来源：https://docs.datadoghq.com/real_user_monitoring/

前端可观测性：RUM 与 Core Web Vitals 监控