【背景】 做了 5 年前端，最近半年被绩效指标绑死在「核心页面端到端 P99 ≤ 300ms」上。但每次复盘对不上号：后端 APM（SkyWalking + 自研埋点）显示核心查询接口 P99 是 85ms，前端 RUM（自研 SDK 基于 PerformanceObserver + fetch 拦截）上报的同一接口 P99 是 210–260ms。差出来的 120–170ms 去哪了？
我拆了 200 个 traceId 逐段对：
- 后端处理段（APM 内部）：P99 ≈ 85ms ✓
- 网关 + 网络段（RUM 的 ttfb - 后端处理）：P99 ≈ 60–90ms（跨地域用户更明显，一线城市 30ms 能压到，三四线城市能到 150ms）
- 前端 JS 执行 + 渲染段（RUM 的 responseEnd - ttfb）：P99 ≈ 40–70ms（大 JSON 解析 + React 重渲染占大头）
三段加起来 RUM P99 210–260ms，后端 APM P99 85ms，差了 2.5 倍。
后端同学的原话：「我们 P99 是 85ms，没超 SLO，别找我。」 我的困境：用户感知的是 260ms，我背的 KPI 也是 260ms，但 175ms 里有 100ms+ 是网络和渲染，我动不了。
【常见分歧 / 做法】 我调研了几个团队，大致四种立场：
-
信后端 APM：「网络抖动、用户设备慢、弱网环境不是服务端的问题，SLO 应该只锚定后端处理时间。」——典型后端团队立场，好处是可控、可复现，坏处是用户感知被忽略。
-
信前端 RUM：「用户体感就是端到端，不管哪段慢都是体验问题。」——前端 / 产品立场，但归因困难，一旦超 SLO 扯皮。
-
拆段定 SLO：后端段 P99 ≤ 100ms（APM 度量），网络段 P99 ≤ 80ms（RUM 的 ttfb - 后端时间，需要 traceId 贯穿），前端渲染段 P99 ≤ 100ms（RUM 的 responseEnd - ttfb）。每段独立 owner，超了谁修谁。——最合理但工程成本最高，traceId 贯穿 + 分位数计算 + 弱网过滤都得上。
-
只看 RUM 的 p75 不看 p99：「p99 里全是弱网 / 低端机 / 后台切前台的噪声，p75 才代表真实体验。」——务实但容易被质疑「为什么不看最差用户」。
【我的倾向与理由】 我倾向 方案 3（拆段定 SLO）+ 方案 4 的噪声过滤，具体做法：
- traceId 贯穿：后端响应头带
X-Trace-Id，前端 fetch 拦截器拿到后写入 RUM 上报 payload。这样每个 RUM 样本能关联到后端 APM 的 span，精确拆段。我们目前的做法是后端网关统一注入，前端 SDK 在fetchwrapper 里从response.headers.get('x-trace-id')取值。 - 噪声过滤：RUM 上报时附带
navigator.connection.effectiveType（2g/3g/4g/5g）、deviceMemory、navigator.devicePixelRatio、页面是否处于visibilityState: hidden切回（后台切前台的 fetch 重放会打出极端值）。计算 SLO 分位数时过滤掉effectiveType in ['2g','3g']和hidden 切回的样本。 - 分位数口径：SLO 用 p95 不用 p99——p99 在 10 万样本里只有 1000 个，弱网长尾全堆在这 1000 个里，波动太大没法做回归。p95 兼顾尾部和稳定性。
- 每段独立告警：后端段超 100ms 告警后端，网络段超 80ms 告警 SRE（检查 CDN / 网关），渲染段超 100ms 告警前端。别搞一个「端到端 P99」大锅告警。
【想听大家在什么场景下怎么选】
- 你们团队前端 RUM 和后端 APM 的 P99 差异一般多大？有没有人做过 traceId 贯穿前后端的实践？坑在哪？
- B 端（内网 / 办公网，网络段基本可忽略）和 C 端（公网，弱网长尾严重）场景下，SLO 锚定策略是不是应该完全不同？
- 前端渲染段 P99 超过 100ms，你们是先优化 JSON 体积（压缩 / 裁剪字段）还是先优化 React 渲染（memo / 虚拟列表 / 代码分割）？有没有量化过两者的 ROI？
- p95 vs p99 这个选择，你们的 on-call 流程里怎么说服对方？p99 虽然噪声大但「最坏情况」叙事更有说服力，怎么平衡？