目标
实验室分数优化的是模拟器，字段数据描述的才是用户。先从 RUM 的 p75 按设备与路由分段审计，用实验室当显微镜归因，修复后回到字段里验证指标真正生活的地方。分段是关键：平均 2.8 秒的 LCP 可能掩盖着移动端 3.9 秒的人群。
步骤要点
- 从字段数据出发：拉取真实用户按设备等级与路由分段的 p75 Core Web Vitals，定位哪个人群经历哪种失败。
- 逐个归因失败指标：对最差的“人群-指标”组合抓 trace 归因——LCP 归晚发现资源、CLS 归布局偏移、INP 归长任务。
- 按人群影响排序修复：候选修复按“受影响用户比例 × 指标改善”打分，先修动得最多用户毫秒的。
- 每个修复带实验室验证：逐个落地，每个都在 trace 里确认特定原因已消除再进入下一个。
- 字段验证并重定基线：部署后数天内盯受影响人群的 p75，确认改善在真实条件下存活。
排错提示
总分看着还行用户却抱怨慢，是平均值掩盖了移动端人群，务必分段看；五个优化捆一个部署让指标动了也说不清谁的功劳，一修一 trace 一字段核对；实验室改善显著字段纹丝不动，多半是归因错了对象或用户路径与测试路径不同。
适用边界
RUM 采样有最低流量门槛，低流量页面只能依赖实验室加抽样人工验证；字段指标的确认有几天的时间窗，灰度发布要配合分段观测。
代码示例
field (RUM p75, 28d):
LCP CLS INP
mobile 3.9s 0.18 410ms <- failing
desktop 2.2s 0.04 180ms
attribution (mobile /product/*, 62% of traffic):
LCP 3.9s: hero image late-discovered (no preload)
CLS 0.18: reviews widget pushes layout 210px
INP 410ms: filter tap handler 300ms (main thread)
rank (users x improvement):
1 preload + fetchpriority hero est. 1.1s LCP
2 reserve reviews slot (aspect) est. 0.14 CLS
3 move filter to worker est. 220ms INP
after (field p75, +7d): LCP 2.4s, CLS 0.04, INP 190ms