前端性能监控到底该以哪个耗时为口径：LCP、TTI、还是「用户点完能看见结果」？

背景

热榜上 #1374 那个提问把后端「trace 三段加起来 80ms、网关却看到 2.4s」的缝隙讲得很透。我从前端这边看，类似的「口径对不上」每天都在发生，只是没人系统讨论：

• 后端说「这个接口 P99 200ms 达标」；
• 前端 RUM 报表说「这个页面 LCP 2.8s，黄色」；
• 用户投诉说「我点了提交转了 5 秒才有反应」。

三方都对，三方都对不上。我 15 年前端生涯里，最痛的不是某个指标不准，而是团队根本不知道「性能达标」到底指哪个数字。

常见分歧 / 几种做法

1. LCP / INP / CLS 派：Web Vitals 是 W3C 标准、能进 Core Web Vitals 报表、能跟 SEO 挂钩，作为前端性能唯一 KPI；
2. TTI / FCP 派：老一代 SPA 团队习惯，「用户能点」比「能看到」更贴近真实体验；
3. 业务口径派：按「关键用户旅程」拆，比如「登录页 → 输入密码 → 看到首页数据」端到端耗时，不看单页指标；
4. 接口耗时派：直接拿 XHR 的 duration 当性能指标，简单粗暴但和业务方最容易对齐；
5. 混合派：LCP 看首屏、INP 看交互、业务旅程看端到端，三条线并行。

我的倾向与理由

我倾向混合派，但必须有一个「老板能看懂」的头条指标——通常是「关键用户旅程 P90 端到端耗时」。理由：

• LCP 只覆盖「首屏可感知」，覆盖不到「用户点按钮后等多久才看到结果」，而后者才是用户投诉的 80%；
• 接口耗时是后端的事，前端拿它当 KPI 等于把锅甩出去；
• 业务旅程端到端耗时（从用户手势开始，到 DOM 更新完成且可交互）天然包含「网络 + 渲染 + JS 阻塞 + 后端」，是真正的用户体感。

但前提是：埋点必须能从 pointerdown 一路采到「DOM Mutation 稳定」或 requestIdleCallback，中间任何一段断了，这个数字就废了。这也是我目前最没把握的点——React 18 并发渲染 + Suspense 场景下，「DOM 稳定」的判据到底怎么定，我踩过坑：MutationObserver 在 hydration 抖动期会假阳性。

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

1. 你的团队现在「性能达标」到底看哪个数字？是 LCP、TTI、还是自研的业务旅程耗时？
2. 后端接口 P99 达标但用户投诉体验差，你们怎么定位「消失的时间」在前端哪一段？（我目前的做法：PerformanceObserver('event') 采 input → fetch 前后打点 → requestAnimationFrame 序列比对，但 hydration 场景漏得厉害）
3. React 18 并发渲染 + Suspense 下，「DOM 可交互」的判据你们怎么定？我试过 MutationObserver + requestIdleCallback 组合，假阳性率约 8%，有没有更稳的做法？
4. 如果只能选一个指标进季度 OKR，你选哪个？为什么？

先抛砖，期待被拍。