如何修复 Core Web Vitals 得分不佳的问题？
核心网页指标
先弄清楚是哪项指标未达标、出问题的是哪类设备、涉及哪一组页面；Search Console 的 Core Web Vitals 报告基于真实的 Chrome 访问数据，三项指标都能看到。然后针对该指标背后的原因逐一修复：对于 LCP，关键在于主图或主要文本多快加载出来；对于 INP，关键在于拖慢响应的长时间 JavaScript 任务；对于 CLS，关键在于出现时没有预留空间的内容。实测数据涵盖最近 28 天，因此需要用一个月的时间来判断修复是否有效。
第 1 步：找出未达标的指标
- 在 Search Console 中打开 Core Web Vitals 报告，选择移动设备或桌面设备；两者是分开评级的。
- 打开列出的某个问题（例如移动设备上的 LCP 问题），查看受影响的 URL 组和示例 URL。同一组页面共用一个状态，由其中最差的指标决定。
- 将某个示例 URL 放到 PageSpeed Insights 中运行，即可同时看到该页面的实测数据，以及便于调试的实验室测试结果。
Lighthouse 等实验室工具无法测量 INP，因为测试过程中没有人与页面交互，所以它们改为报告 Total Blocking Time。对于 INP，真实用户数据才是可靠的依据。
如何修复 LCP 过慢的问题
web.dev 的 LCP 优化指南把 LCP 拆分为四个部分：服务器响应时间、主资源开始加载前的延迟、资源的下载时间，以及渲染前的延迟。先从耗时最长的部分入手：
- 让 LCP 图片能在初始 HTML 中被发现，而不是通过 JavaScript 或 CSS 动态注入，并为其添加
fetchpriority="high"。 - 绝不要对 LCP 图片使用懒加载。
- 减小图片体积： 使用合适的尺寸、现代图片格式和压缩，并使用离访问者较近的 CDN。
- 移除阻塞渲染的资源： 精简样式表，不在
<head>中放置同步脚本，主要内容采用服务端渲染。 - 加快服务器响应： 减少重定向，并让页面可以在边缘节点缓存。
如何修复 INP 不佳的问题
INP 优化指南把每次交互拆分为输入延迟、处理时间和呈现延迟：
- 输入延迟： 减少页面加载期间运行的 JavaScript，使用户点按时主线程处于空闲状态。
- 处理时间： 将耗时较长的事件处理函数拆分为更小的任务并让出主线程，先完成可见的界面更新，再延后处理其余工作。
- 呈现延迟： 保持 DOM 精简，避免在修改样式后立即读取样式而强制触发布局，并在较长的页面上使用
content-visibility。
如何修复过高的 CLS
CLS 优化指南列出了常见的成因及对应的修复方法：
- 未设置尺寸的图片和视频： 添加
width和height属性，或使用 CSSaspect-ratio。 - 广告、嵌入内容和 iframe: 在它们加载之前，先在布局中为其预留空间。
- 在现有内容上方插入的内容： 使用尺寸合适的占位元素，或将新内容插入到访问者正在阅读的内容下方。
- 网页字体： 预加载重要字体，避免文字在较晚时才重新排版。
- 动画： 对
transform做动画，而不是对top、left等属性。
能够使用浏览器往返缓存(back/forward cache)的页面，在访问者返回时同样可以避免布局偏移。
第 3 步：确认修复效果
部署之后，在 Core Web Vitals 报告中打开对应问题并开始验证。Google 会对该组页面监测 28 天；验证不会触发重新抓取，也不会加快任何进程，它只是跟踪问题是否已经消失。由于实测数据按 28 天滚动统计，报告会逐步改善，请不要期望立刻见效。关于各项指标的含义，请参阅LCP、INP 和 CLS 是什么意思？。
AutoPSEO 如何提供帮助
AutoPSEO 的 Core Web Vitals 报告会以图表形式展示您的网站或单个 URL 约六个月的每周 Chrome UX Report 数据，可按手机、桌面或平板查看。这样您可以直观地看到修复在哪一周生效，或者某次发布在哪一周造成了退步，而无需等待下一个 28 天窗口结束。