前端 P99 到底该看哪个指标：LCP、FCP、可交互还是「用户感知时长」？

背景

社区里后端侧的讨论很热（连接池、超时重试、慢 SQL），但前端这边我们常年的痛点其实是：性能指标到底看哪个、看多少分位。我做了 15 年前端，带过的团队里，最常见的做法是「看平均值或 75 分位」，理由是 Web Vitals 官方口径就是 p75。但线上出过太多次「p75 很健康、p99 已经烂成粥」的事故——慢机型、弱网、低端 Android、CDN 边缘节点抖动，全部被 p75 的口径平均掉了。于是团队开始争论：到底该盯 LCP、FCP、TTI，还是干脆自己造一个「用户感知时长」？

常见的几种做法（我观察到的分歧）

1. Web Vitals 原教旨派：LCP / INP / CLS 三件套，p75 达标就收工。优点是口径统一、Chrome UX Report 有大盘数据可对照、Sentry/ARMS 都内置；缺点是对「长尾用户」不敏感，且 INP 在 2024 年替换 FID 之后团队还没完全适应。
2. 自造「感知时长」派：从用户点击到首屏可交互的端到端秒表，自己打点、自己算 p99。优点是真贴用户体感；缺点是口径不统一（不同页面、不同业务线、不同 SDK 版本各算各的），维护成本高，跨团队没法横向对比。
3. 分层派：基础设施层看 TTFB + 资源加载，应用层看 LCP/FCP，业务层看「关键路径 API 的 P99」，三层各管一段。优点是责任清晰；缺点是链路长，一旦抖动很难快速归因到哪一层。
4. SLO 派：不追具体指标，只定义「页面可用性 SLO」+「核心交互成功率 SLO」，指标降级为诊断工具。理念干净，但落地时 SLO 怎么和发版节奏、on-call 责任绑在一起，很多团队没想清楚。

我的倾向与理由

我偏向 3（分层）+ 4（SLO 兜底） 的混合做法，理由有两条：

• 落地成本：自造「感知时长」听起来美好，但口径维护、SDK 升级、跨端一致性，长期看是个无底洞。Web Vitals 三件套的采集成本几乎为零（PerformanceObserver + 上报通道），把省下来的精力投到「p99 归因链路」上，收益更高。
• 收益权衡：p75 达标 ≠ 用户满意。我的经验是，对 C 端高频页面，在 Web Vitals 之上加一条 p99 的「关键 API 耗时 + 首屏可交互」复合指标就够了——不要全量页面都加，只挑 GMV 相关或投诉率高的 Top 5–10 个页面，成本可控，信号密度最高。

想听大家在什么场景下怎么选

1. 你们团队现在前端性能到底盯哪个指标？p75 还是 p99？
2. Web Vitals 三件套在你们项目里够用吗？什么场景下不够？
3. 自造「感知时长」指标的成本，你们实际投入了多少人天？值不值？
4. 小团队（< 10 人）和大团队（> 50 人）在指标选择上的取舍有什么不同？

欢迎贴你们的具体做法和踩过的坑，越具体越好。