修复每个核心网页指标
三个指标，三个不同的任务。能改进每个指标的具体修复方案，不涉及理论。
← Guides All guides in this topic
LCP：让主要内容快速加载
最大内容绘制通常是一张英雄图像、一个大标题或海报帧。找到那个元素。其他一切都是次要的，直到它足够快。
影响 LCP 的杠杆：压缩和调整资源大小、使用现代格式、设置尺寸、在发现较晚时预加载确切的 URL、将其放在 CDN 上，以及降低 TTFB 以便字节可以开始传输。避免对 LCP 图像进行延迟加载。避免延迟实际 LCP 节点的轮播。
服务器角度：如果 HTML 本身很慢，任何图像技巧都救不了你。先修复缓存和源站。
关键要点：命名 LCP 元素，然后让该文件及其发现路径的速度枯燥乏味地快。
INP：保持主线程空闲
交互到下一次绘制关心的是页面在点击后的响应速度有多快。主线程上的大量 JavaScript 通常是罪魁祸首：大型水合、昂贵的处理程序、永远运行的第三方脚本。
杠杆：删除或延迟第三方、拆分处理程序、避免在营销页面上使用大型同步组件、倾向于使用小岛屿的服务器渲染 HTML，以及在真实的中端 Android 设备上测试，而不仅仅是桌面节流预设。
关键要点：INP 改进是因为你从主线程中删除了工作，而不是因为你微观优化了 CSS 过渡。
CLS：阻止页面跳动
累积布局偏移是视觉不稳定。没有尺寸的图像、延迟交换和调整文本大小的字体、在布局中打开一个洞的广告和嵌入，以及在内容上方注入的横幅。
杠杆：在媒体上使用宽度和高度或 CSS aspect-ratio、为广告预留槽位、不会导致布局爆炸的字体显示策略，以及不在现有内容上方进行延迟加载 UI。优先转换现有空间而不是在顶部插入新块。
关键要点：如果某个元素稍后出现，要提前为它预留空间。
导致不断失败的错误
| Metric | Common miss | Better move |
|---|---|---|
| LCP | Lazy-loading the hero | Eager + preload the real LCP URL |
| LCP | Optimising a non-LCP image | Identify the LCP node first |
| INP | Blaming CSS animations | Cut JS and third parties |
| INP | Testing only on desktop | Use a mid-tier phone |
| CLS | Ignoring font metrics | Subset fonts, reserve space |
| CLS | Cookie banners without space | Reserve or overlay carefully |
关键要点：大多数重复失败是流程错误，而不是缺少微优化。
如何通过全部三项
在失效网站上的操作顺序：先解决 LCP，再解决 INP，最后解决 CLS。每个步骤之间重新测量字段数据。使用 CWV 检查清单作为发布门槛，当你仍然无法判断是服务器还是前端问题时，使用慢速网站指南。
在移动端达到第 75 百分位数通过三项就足够了。一旦字段数据健康，不要为了实验室中的满分 100 而阻止发布。
关键要点：先解决 LCP。一旦主内容路径是诚实的，INP 和 CLS 就更容易了。
一周的救援计划
第 1 天：拉取字段数据，在排名前三的模板上标记 LCP 元素，列出所有第三方脚本及其所有者。第 2 到 3 天：仅发布 LCP 媒体和发现修复。第 4 天：删除或延迟表现最差的第三方，在手机上重新检查 INP。第 5 天：为你在字段体验中能看到的 CLS 违规者预留空间。第 6 到 7 天：重新测量，记录剩余问题，决定遗留工作是否会阻止发布。
这一周胜过一个月的混合重构，因为每一天都只关注一个指标和一个反馈循环。如果 LCP 在第 3 天后仍然是红色，不要启动设计系统清理。坚持在 LCP 元素上直到它改善。
关键要点：每天关注一个指标并重新测量，胜过混乱的性能待办事项列表。