前端性能监控应该采集哪些数据？

简化版

前端性能监控要采集真实用户的 LCP、INP、CLS 等体验结果，并用 Navigation/Resource Timing、长任务、接口和错误补充原因；每条数据必须带页面模板、release、设备、网络和采样上下文。分析以 P75 等分位数和分群为主，建立发布对比、告警、定位、修复与验证闭环。

详细版

实验室数据环境可控，适合复现和看 trace；RUM 覆盖真实设备、网络、缓存状态和交互，适合评价分布。二者互补，不能拿 Lighthouse 单次分数替代现场 Core Web Vitals。

当前 Core Web Vitals 良好阈值是 P75 LCP ≤2.5s、INP ≤200ms、CLS ≤0.1。还应采集 TTFB/FCP、LCP 元素与四段归因、交互归因、资源耗时/失败、API、Long Task、JS 错误和业务关键阶段。

监控 SDK 必须控制采样、批量、发送时机、字段基数和隐私，不能收集输入内容或完整敏感 URL。版本号与 source map 关联后，指标劣化才能定位到发布。

完整版教学

一、监控要同时回答结果、原因和上下文

只知道 LCP=4 秒，无法判断是 HTML、图片还是主线程慢；只知道 hero.jpg 下载 1 秒，也不知道用户主内容是否受影响。成熟数据模型要把体验指标和诊断属性关联。

层次	数据例子	回答的问题
结果	LCP、INP、CLS	用户体验多差
原因	TTFB、资源、长任务	时间花在哪里
上下文	页面、release、设备	谁在什么条件下出问题

记忆钩子：没有上下文的指标不能定位，没有结果指标的耗时不能证明影响用户。

二、核心指标与当前评价口径

LCP 衡量加载主内容，INP 衡量页面生命周期内交互响应，CLS 衡量非预期布局偏移。当前良好阈值分别是 2.5 秒、200 毫秒和 0.1，并按页面或站点真实访问的第 75 百分位评价。

Good: LCP ≤ 2500ms, INP ≤ 200ms, CLS ≤ 0.1
Poor: LCP > 4000ms, INP > 500ms, CLS > 0.25

FCP、TTFB 仍有诊断价值，但不属于当前三个 Core Web Vitals。指标集合会演进，SDK 与看板要记录定义和库版本，避免历史曲线因计算方式变化而误判。

三、为什么分位数比平均值更适合体验

平均值会把快慢用户混在一起，也可能被极端值拉动。P75 表示排序后 75% 的观测不超过该值，能关注较慢用户同时保持统计稳定。

假设 100 次访问中前 74 次 LCP 都是 1.5 秒，第 75 次为 3.1 秒，后 25 次为 5 秒；平均约 2.4 秒，看似良好，但 P75 已是 3.1 秒，未达到 LCP 良好阈值。评价口径必须在 SQL、看板和告警中一致。

样本少时分位数抖动大。新页面只有 20 次访问，P75 的统计置信度不足，应设置最小样本、滚动窗口并避免因一次访问自动回滚。

四、浏览器 API 能提供哪些诊断数据

Navigation Timing 提供文档导航阶段，Resource Timing 提供资源发起、响应和传输等信息，PerformanceObserver 可订阅多类 performance entry。跨源资源若未通过相应 Timing-Allow-Origin 暴露，很多详细阶段会被限制。

const observer = new PerformanceObserver(list => {
  for (const entry of list.getEntries()) queueMetric(entry)
})
observer.observe({ type: 'resource', buffered: true })

Web Vitals 的边界和交互归因较复杂，生产中常优先使用维护中的官方库而非自行拼凑。自研仍需处理 bfcache、页面隐藏、SPA 路由和重复上报等生命周期问题。

五、采样、上报与 SDK 自身成本

全量上传每个资源会造成高数据量和 SDK 开销。核心结果可高采样，详细 trace 低采样；发生错误或指标异常时可提升诊断采样，但要防止偏差。

假设日活 100 万、每次会话 80 条资源记录、每条压缩后 300 字节，全量原始上报约 1,000,000×80×300≈24GB/日，还未计协议开销。按会话 5% 采样可降到约 1.2GB/日，但统计时必须带采样率权重。

上报应批量、限制队列，页面隐藏时可用适合卸载阶段的发送方式，但仍不能保证 100% 到达。监控 SDK 失败不能阻塞业务，第三方脚本也要纳入自身性能预算。

六、分群、告警和发布闭环

全站 P75 正常可能掩盖某个结算页或低端 Android 的严重问题。至少按页面模板、设备等级、网络、地区、浏览器和 release 分群，同时控制高基数字段，避免每个完整 URL 都成为独立维度。

发现：release R42 移动端 LCP +35%
  ↓
定位：商品页 image load delay 增加 700ms
  ↓
修复：恢复 HTML 中的 Hero URL 与优先级
  ↓
验证：同分群 P75 回到基线

告警要比较稳定基线、绝对阈值、相对变化和最小样本。只以“超过 2.5 秒”报警会对长期已差页面持续轰炸，也可能漏掉从 1.0 秒退化到 2.4 秒的大幅回归。

隐私上不采集输入文本、token 和完整查询参数，对 URL、用户标识和堆栈做脱敏与留存控制。性能监控不是绕过数据合规的理由。

七、常见误区与追问

误区：Lighthouse 分数就是线上用户体验。 它是特定实验环境的综合结果，RUM 才覆盖真实分布。
误区：平均 LCP 小于 2.5 秒就达到 Core Web Vitals 良好。 官方评价使用 P75，不是平均值。
误区：采集越多越容易定位。 高基数、噪声和 SDK 成本会损害系统与业务，需要分层采样。
追问：为什么 Resource Timing 看不到跨域详细耗时？ 跨源资源需通过 Timing-Allow-Origin 等机制授权暴露。
追问：SPA 如何区分路由性能？ 定义软导航边界、业务 mark 和路由上下文，并避免重复累计页面级指标。
追问：性能告警如何减少误报？ 结合基线、阈值、样本量、持续窗口和版本变化，而非单点触发。
追问：监控 SDK 怎样避免成为性能问题？ 异步、批量、采样、限队列、失败隔离，并测量自身字节和主线程成本。

八、加强记忆

用“结果、原因、上下文、分位数、闭环”设计 RUM：核心 Web Vitals描述用户结果，导航/资源/长任务提供原因，页面与 release 等上下文支持分群；P75 与最小样本保证评价口径，采样和隐私控制成本；最终每次异常都能从发布发现、定位到同分群验证修复，而不是停在看板上。

简化版

详细版