很多性能优化停在“压缩图片、开缓存”，上线后几周又回到原点。
原因通常不是技术不够，而是没有把性能变成持续治理的工程流程。
先把指标和页面分层
我会先做两层拆分：
- 业务层：核心入口页、交易页、内容页
- 指标层：
LCP、INP、CLS
不同页面关注点不同：
- 内容页更关注 LCP
- 交互页更关注 INP
- 所有页面都要控制 CLS
三类问题的典型修复手段
LCP 常见问题：
- 首屏图片过大
- 关键字体阻塞
- 首屏数据请求链路过长
修复重点是“关键资源前置 + 非关键延迟加载”。
INP 常见问题：
- 主线程长任务过多
- 大组件首次交互阻塞
- 低优先级逻辑抢占交互
修复重点是“切分任务 + 降低首屏 JS + 控制同步计算”。
CLS 常见问题：
- 图片和广告位未预留尺寸
- 字体切换导致重排
- 动态模块插入触发布局抖动
修复重点是“明确尺寸约束 + 稳定布局骨架”。
把性能纳入发布流程
我建议每次发布至少做三件事：
- 关键页面跑一轮 Lighthouse 或 RUM 对比
- 记录本次变更对核心指标影响
- 指标回退时触发发布阻断或告警
性能一旦有了“门禁机制”，就不会只靠人记住。
小结
Core Web Vitals 最有价值的地方，不在于分数本身，而在于它提供了一套跨团队可对齐的性能语言。
把它变成日常工程流程，性能才会长期稳定。