页面慢到底谁背锅：LCP/INP 的后端 TTFB 与前端渲染，责任边界你团队怎么划？

【背景】 5 年前端，去年大促前复盘一次商品详情页事故：用户投诉「打开卡」，前端用 RUM 拉数据，LCP P75 = 2.8s，INP P75 = 410ms；后端拉自家 API 监控，P99 = 820ms，「我们没问题」。两边各看了各的指标，对质 2 小时没结论，最后谁也没改进什么，大促前才靠「加缓存 + 砍字段」硬扛过去。

拆开那次 LCP 的瀑布：TTFB 950ms（占 34%）、2.1MB JSON 传输 280ms、主线程解析 + 首帧 1550ms。问题很明显：后端「API 没慢」，前端「JS 没卡」，但用户感知是「页面慢」——因为没人对「用户感知指标」负责，每人只对自己切片的指标负责。

【常见分歧 / 几种做法】

1. 按指标硬切：后端只对 TTFB / API P95 负责，前端对 JS bundle、长任务负责，传输归网络。问题：切片的分母不同（API 调用次数 vs 页面 PV），两边都达标用户照样卡；
2. 性能预算写进 CI：TTFB ≤ 300ms、bundle gzip ≤ 250KB、长任务 ≤ 200ms，超了卡发布。问题：谁拍这些数字？拍错了要么全绿也慢，要么天天红没人看；
3. 灰色地带不归属：API 返回 2MB 数据、前端解析 300ms——是后端 over-fetch 还是前端渲染差？多数团队的答案是「都不是，下次再说」。

【我的倾向与理由】

1. 先定一个「用户感知唯一指标」：我们最终选 INP P75 ≤ 200ms 作为页面级 SLO，LCP P75 ≤ 2.0s 做辅助。它必须是跨端共背的，谁都不能用「我的 API 没慢」豁免；
2. 再按瀑布切片分预算：TTFB（后端 100% 负责）≤ 300ms、传输（共同负责，后端主导砍字段）≤ 100KB、首帧渲染（前端 100% 负责）≤ 500ms。每片独立打点、独立告警，超预算的 PR 直接卡在 CI；
3. 灰色地带用「数据契约」解决：API 文档里写死字段白名单和体积上限（我们定 ≤ 80KB gzip），超限走 review——把「返回多少数据」从运行时问题变成契约问题，前端解析慢就是前端的问题，没得推。

这套跑了一季度，LCP P75 从 2.8s 降到 1.4s，关键是「对质」从 2 小时变成看一张瀑布图 10 分钟。

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

1. 你们团队的页面性能是「一个人端到端 own」还是「前后端分片 own」？分片时切片指标怎么定的？
2. 性能预算你们是硬门槛（卡发布）还是软目标（只告警）？硬门槛下被谁挑战过、怎么扛住的？
3. 「API 返回数据太大」这种灰色地带，你们靠什么机制归属：数据契约、code review 规范，还是干脆没人管？
4. RUM 数据里「网络差用户」要不要从 P75 分母里剔除？剔了指标好看了，但真卡的用户还在。