性能报告里有很多数字，容易让人陷入“再提高两分”的游戏。后来我更愿意把 Core Web Vitals 当成三条排查线索：主要内容来得够不够快，用户操作后页面有没有及时回应，阅读过程中布局会不会突然跳动。方向明确后，优化不必从复杂方案开始。
LCP、INP、CLS 分别在问什么
LCP 大致代表首屏主要内容出现的时间。内容页里常见的 LCP 元素是标题或头图。如果头图是问题，就检查文件大小、响应格式、优先级和 CDN；如果标题是问题，可能是阻塞样式、字体或服务端响应慢。
INP 关注交互响应。点击菜单后迟迟不动，通常不是网络，而是主线程被一段长 JavaScript 占住。先用性能面板找到长任务，再考虑拆分计算、减少渲染或延后不重要的脚本。CLS 则对应意外位移，图片没有尺寸、顶部晚插入横幅、字体切换改变字宽，都是常见原因。
普通页面先做这些便宜的事
- 给图片写明确的宽高或
aspect-ratio，先把位置留好。 - 首屏大图不要懒加载，其他图片再使用
loading="lazy"。 - 删掉并未使用的大型脚本，比微调压缩参数更直接。
- 字体只保留需要的字重，正文优先使用可靠的系统回退。
- 静态资源设置长期缓存，HTML 保持可更新的短缓存。
这些改动看起来普通，却经常覆盖大部分问题。只有确认瓶颈以后，才值得上预加载、分片策略或更复杂的服务端缓存。
不要忘记低端设备：开发电脑上 80 毫秒的脚本，在普通手机上可能变成几百毫秒。CPU 降速测试往往比换一个评分工具更有启发。
一次检测和真实用户并不是同一回事
本地工具适合定位和复现，但它只代表一次特定网络、设备与页面状态。真实数据会包含缓存命中、不同地区网络、旧手机和各种内容长度。两者不一致时，先确认样本页面和时间范围，不要急着宣布某一边“错了”。
我会先用实验室工具找到明显问题并验证修改，再观察一段时间的真实分布。目标也不是所有访问都达到完美数字，而是让大多数用户的体验越过可接受线，同时不牺牲内容和可维护性。
指标应该帮助我们提出更好的问题，而不是替用户决定什么体验最重要。
当优化完成后，最好把原因写进代码注释或项目文档，比如“这张图不能懒加载，因为它通常是 LCP 元素”。否则几个月后的“清理代码”很可能把重要细节又改回去。