【背景】
做了 8 年前端，最常被 SRE 和产品同学挑战的一句话是：「你们 API P99 才 80ms，为什么用户还在骂页面卡？」
我们团队负责一套 To C 的 H5 + 小程序混合前端，核心页面（商品详情 / 下单确认）的 SLO 目前是：
- 后端 API P99 < 150ms（由后端团队背）
- 前端错误率 < 0.1%（由前端团队背）
- 页面可用性 > 99.9%（由前端团队背）
但用户感知到的「快不快」，其实是：网络 RTT + 服务端处理 + 前端 JS 解析/执行/渲染 + 二次请求瀑布 + 设备性能。我们内部埋了 Web Vitals（LCP / CLS / INP）和 Performance API 的 Navigation Timing 拆解，发现一个扎心的数据：
API P99 = 80ms 达标的那批请求里，INP P75 依然有 340ms+，低端 Android（4GB RAM、骁龙 6 系以下）占比 38%，这部分用户 INP P90 能到 1.2s。
也就是说：后端 SLO 全绿，用户照样骂。
这个 gap，目前在我们团队里没有人明确背。
【常见分歧 / 几种做法】
我调研了身边几个团队（电商、SaaS、内容平台），发现大致四种路线：
路线 A：前端 SLO = Web Vitals（LCP / CLS / INP），按 RUM 采样，不分设备
- 好处：指标用户可感知，Google 也认（Core Web Vitals 影响 SEO）
- 问题：LCP 对首屏有意义，但「下单确认页」用户更关心 INP；不分设备的话，高端机拉低均值，低端机的痛苦被稀释；RUM 采样率通常 1%–10%，样本量够不够做 P99 存疑
- 落地成本：低（Sentry / ARMS / 自建 RUM 都支持），但定阈值时产品会挑战「为什么 INP P75 是 200ms 而不是 100ms」
路线 B：前端 SLO = TTI（Time to Interactive）或「页面完全可交互」
- 好处：直接对应「用户能不能点」
- 问题：TTI 已经被 Chrome DevTools 和 Web.dev 标记为 deprecated（2023 年），因为定义模糊、测量不稳定；替代方案是 INP，但 INP 是「交互到下一帧渲染」，跟「能不能点」不完全等价
- 落地成本：中（需要自己定义「可交互」的判定条件，比如主流程按钮可点击 + 无 Long Task 阻塞）
路线 C：前端不背延迟 SLO，只背错误率 + 可用性，延迟全归后端
- 好处：职责边界清晰，前端不用跟后端扯皮「你的 API 慢导致我的页面卡」
- 问题：用户不认这个边界。用户看到的是「这个 App 真卡」，不是「你的 API 慢了」或「你的 JS 执行慢了」。当 API P99 达标但页面体验差时，这个 gap 变成三不管地带
- 落地成本：最低，但产品满意度会持续被拖
路线 D：按设备/网络分群定 SLO（高中低端机分别定 INP / LCP 阈值）
- 好处：最贴近真实用户体验，不会用高端机均值掩盖低端机问题
- 问题：分群维度多（OS / 芯片 / RAM / 网络类型 / 地理位置），RUM 样本被切得太碎后统计意义下降；维护成本高，每次改阈值都要重新拉数据论证
- 落地成本：高（需要 RUM 平台支持多维度切分 + 自动告警，很多商业 RUM 产品对「设备分群告警」支持很弱）
【我的倾向与理由】
我倾向路线 A 的改良版，核心思路：
- 主指标用 INP（P75），不用 LCP——因为我们的核心场景是「交互型页面」（下单、搜索、筛选），不是「内容型页面」（文章阅读）。INP 直接度量「用户点了之后多久有响应」，跟用户骂「卡」的体感最对齐。
- 分两个桶：通用桶 + 低端机桶。低端机桶不追求 P99（样本太碎），用 P75 做 SLO，阈值比通用桶宽 50%。这样既覆盖了低端机体验，又不至于因为样本量不够导致告警噪音。
- 前端 SLO 里加一条「API 瀑布深度」指标：一次页面加载触发的前端→后端请求数（串行链深度）。这个指标前端能直接控制（合并请求、预取、缓存），比单纯看 API P99 更有前端视角。
- 落地成本控制在 2 人周以内：RUM 用现有 ARMS 的 Web Vitals 采集（已有），加一个「低端机分群」的过滤条件（User-Agent 解析 + deviceMemory API），告警规则配 2 条（INP P75 通用 / INP P75 低端机），不需要新平台、不需要新埋点。
关键权衡：我不追求「完美度量」，而是追求「比现在多覆盖一个维度、且 2 周内能上线」。一个能用、能告警、能归因的 70 分 SLO，好过一个设计完美但半年后还没落地的 100 分 SLO。
【想听大家】
- 你们团队前端 SLO 是怎么定的？有没有「后端 API 全绿但用户骂前端」的实际案例？最后 gap 怎么收的？
- 路线 D（设备分群）你们试过吗？RUM 分群后样本量够不够做 P75 告警？有没有被告警噪音逼回不分群的？
- 前端 SLO 如果独立于后端 API SLO，在故障定责时怎么切？「API P99 达标但 INP 超标」，oncall 该拉谁？
- 有没有团队把「前端 JS 执行时间」（Performance API 的 script evaluation）纳入 SLO 的？这个指标噪声大吗？
- 一个更尖锐的问题：前端 SLO 到底该由前端团队定，还是该由产品/SRE 定？ 前端自己定的 SLO，产品会不会觉得「你自己定的标准你自己达标了，有什么用」？