Core Web Vitals 是谷歌用来衡量真实用户页面体验的一组指标，目前包括 LCP（最大内容绘制）、INP（与下一次绘制的交互）和 CLS（累积布局偏移）。读完本文，你会知道这三个指标分别在衡量什么、怎样判断问题出在哪里，以及针对每一项该做哪些具体优化。
三项指标与良好标准
| 指标 | 衡量的体验 | 良好 | 较差 |
|---|---|---|---|
| LCP 最大内容绘制 | 加载速度：视口内最大的图片或文本块多久显示出来 | ≤ 2.5 秒 | > 4 秒 |
| INP 与下一次绘制的交互 | 交互响应：点击、轻触、按键后页面多久给出视觉反馈 | ≤ 200 毫秒 | > 500 毫秒 |
| CLS 累积布局偏移 | 视觉稳定：页面元素是否在加载过程中意外跳动 | ≤ 0.1 | > 0.25 |
INP 在 2024 年取代了原来的 FID（首次输入延迟）。两者的区别在于，FID 只看第一次交互的输入延迟，而 INP 会观察整个访问过程中的交互，反映的是页面整体的响应能力，因此要求更全面。
谷歌评估时看的是真实用户数据的第 75 百分位，也就是说，要让大多数访问者的体验都达到良好，而不是只在你自己的电脑上测得快。
先学会正确测量
测量工具分为两类，用途不同：
- 实地数据（真实用户）：来自 Chrome 用户体验报告（CrUX），可以在 PageSpeed Insights 顶部和 Google Search Console 的 Core Web Vitals 报告中看到。这是谷歌实际参考的数据，但需要足够的访问量才会显示。
- 实验室数据（模拟测试）：PageSpeed Insights 下半部分的 Lighthouse 结果、Chrome 开发者工具的 Performance 面板。适合排查原因和验证修改效果，但不能代表真实用户。
正确的流程是：用 Search Console 找到哪一组网址有问题，再用 PageSpeed Insights 和开发者工具定位具体原因，修改后用实验室工具验证，最后等待实地数据在接下来几周逐步更新。Search Console 的报告用法可以参考 Google Search Console 使用指南。
LCP 优化：让主要内容尽快出现
LCP 元素通常是首屏大图、横幅或者大标题。可以把 LCP 时间拆成四段来排查：服务器响应时间、资源开始加载前的延迟、资源下载时间、元素渲染延迟。对应的优化动作：
- 缩短服务器响应：启用页面缓存，使用 CDN，检查数据库慢查询；动态站点尤其要关注 TTFB。
- 让 LCP 图片尽早被发现：首屏大图不要用懒加载，不要通过 CSS 背景或 JavaScript 插入；可以给它加上 fetchpriority=”high”，必要时用 preload 预加载。
- 减小资源体积：使用 WebP 或 AVIF 格式，按实际显示尺寸输出图片，配合 srcset 为手机提供更小的版本。
- 减少渲染阻塞：精简首屏所需的 CSS，非关键脚本加 defer，字体使用 font-display: swap 避免文本长时间不可见。
INP 优化：减轻主线程负担
INP 差，几乎都和主线程被 JavaScript 长时间占用有关。用户点击按钮时，如果浏览器正在执行一个很长的脚本任务，就只能等它结束才能响应。优化思路：
- 清点第三方脚本：统计、客服聊天、广告、热力图、社交分享等脚本逐一评估，去掉不必要的，保留的尽量延迟加载。
- 拆分长任务：把耗时的计算拆成小块，在任务之间让出主线程，让浏览器有机会先处理用户输入。
- 先给反馈，再做重活：点击后先立即更新界面（如显示加载状态），把非紧急的统计上报、数据处理放到后面执行。
- 控制 DOM 规模：页面节点过多会让每次样式计算和布局变慢，长列表可以分页或按需渲染。
- 审视主题和插件：WordPress 网站常见的问题是页面构建器和插件叠加加载了大量脚本，即使当前页面用不到。
Chrome 开发者工具的 Performance 面板可以录制一次交互，直接看到是哪个脚本占用了时间。
CLS 优化：让页面稳定不跳
CLS 问题最影响用户情绪：正要点按钮，内容突然下移，结果点到了别的地方。常见原因和对策：
| 常见原因 | 处理方法 |
|---|---|
| 图片、视频没有设置尺寸 | 为 img 和 video 写明 width、height，或用 CSS aspect-ratio 预留空间 |
| 广告位、嵌入内容动态插入 | 提前为广告位和 iframe 设定固定或最小高度 |
| 顶部通知条、Cookie 提示后加载 | 改为覆盖层显示，或在初始 HTML 中就预留位置 |
| 网页字体替换导致文字重排 | 预加载关键字体，选择与后备字体尺寸接近的方案 |
| 用改变 top、height 的方式做动画 | 改用 transform 实现动画，不触发布局变化 |
正确看待 Core Web Vitals 与排名的关系
Core Web Vitals 是谷歌页面体验信号的一部分，但内容的相关性和质量仍然是排名的决定性因素。一个指标全绿但内容平平的页面，不会因此超过内容明显更好的竞争对手。合理的定位是：在内容有竞争力的前提下，把体验做好，避免因为加载慢、交互卡顿导致用户流失。体验改善带来的跳出率降低、转化提升，本身就有直接价值。更多和速度相关的整体优化，可以参考 网站速度优化实操清单。
常见问题
PageSpeed Insights 分数很高，为什么 Search Console 仍提示需要改进？
分数来自实验室模拟测试，而 Search Console 依据的是过去一段时间真实用户的数据。真实用户可能使用较慢的手机和网络，也可能触发你测试时没有覆盖的交互。以实地数据为准，同时用实验室数据排查原因。
修改完成后多久能在报告中看到变化？
实地数据是按约 28 天的滚动周期汇总的，修改后需要几周才能完全反映出来。在 Search Console 中点击“验证修正”后，也需要等待数据积累。
网站访问量很小，没有实地数据怎么办？
访问量不足时 CrUX 不会提供数据，这时可以先以 Lighthouse 实验室结果作为参考，按本文的方法优化 LCP、CLS 等可以模拟的指标。INP 依赖真实交互，可以在开发者工具中手动测试主要按钮和菜单的响应。
Core Web Vitals 的问题往往牵涉主题代码、插件和服务器配置，排查起来比较费时间。SEO飞侠 在 WordPress提速与安全加固 方案中整理了常用的处理思路；如果想知道自己网站卡在哪一项，可以通过 Telegram @Seofeixia 发来网址，我们先做一次免费诊断。