Core Web Vitals 详解：LCP、INP 和 CLS 及其优化方法

Core Web Vitals（核心网页指标）是 Google 用来衡量页面真实体验的三项指标：加载有多快、响应有多快，以及加载过程中有多稳定。它们是 Google 在排名中考虑的页面体验信号的一部分；更重要的是，它们反映了访客对你网站的真实感受。

三项 Core Web Vitals

当至少 75% 的真实访问（第 75 百分位）在三项指标上都达到“良好”阈值时，页面就通过了评估。

2024 年 3 月，INP 取代 First Input Delay（FID）成为 Core Web Vitals 之一。INP 更严格：它考虑的是整个访问过程中所有交互的响应性，而不只是第一次交互。

现场数据与实验室数据

现场数据来自真实的 Chrome 用户，以 28 天滚动窗口收集在 **Chrome 用户体验报告（CrUX）**中。Google 在页面体验方面使用的就是这些数据。你可以在 Search Console 的“核心网页指标”报告和 PageSpeed Insights 中看到它们。

实验室数据来自模拟测试（例如 Lighthouse），在固定的设备和网络上进行。它非常适合排查问题和测试修改，但不是 Google 用于排名的数据，而且无法直接测量 INP（最接近的实验室替代指标是 Total Blocking Time）。

流量较低的页面可能没有足够的现场数据；在这种情况下，Google 可能会使用相似页面或整个网站（“来源”）的数据。

Largest Contentful Paint（LCP）

LCP 标记视口中最大的图片或文字块完成渲染的时间，通常是首屏大图、大标题或特色视频的封面图。

LCP 可以分解为四个部分，它们指向不同的修复方向：

1. Time to First Byte：服务器响应需要多长时间
2. 资源加载延迟：浏览器开始下载 LCP 资源之前的时间
3. 资源加载时间：下载需要多长时间
4. 元素渲染延迟：从下载完成到渲染之间的时间

如何改善 LCP

• 加快服务器速度：页面缓存、CDN、更快的主机以及更少的数据库查询
• 让 LCP 图片尽早被发现：在 HTML 中使用普通的 <img>（而不是 CSS 背景或由 JavaScript 插入的图片），并添加 fetchpriority="high"
• 绝不要延迟加载 LCP 图片
• 优化图片：合适的尺寸、WebP 或 AVIF、良好的压缩
• 减少阻塞渲染的资源：内联关键 CSS，延迟加载非关键 JavaScript
• 对所需的第三方来源（例如图片 CDN）使用 preconnect

Interaction to Next Paint（INP）

INP 衡量用户交互（点击、点按或按键）与屏幕上下一次视觉更新之间的延迟。它报告的是访问过程中最慢的交互之一。

INP 较差通常是因为主线程上运行的 JavaScript 太多，导致浏览器无法快速响应。

如何改善 INP

• 减少并拆分 JavaScript：删除未使用的库，进行代码拆分，只在需要时加载功能
• 拆分长任务：超过 50 毫秒的任务会阻塞主线程；在各段工作之间把控制权交还给浏览器
• 审查第三方脚本：跟踪代码管理器、在线客服插件、A/B 测试工具和广告脚本是常见的“元凶”
• 保持 DOM 精简：非常大的页面会让每次更新都变慢
• 在交互时立即给出视觉反馈，然后再执行繁重的工作

Cumulative Layout Shift（CLS）

CLS 衡量意外的布局移动，也就是你正要点按时按钮却突然跳开的那种令人沮丧的体验。它根据有多少内容移动以及移动了多远来计算分数。

如何改善 CLS

• 为图片和视频设置宽度和高度，或使用 CSS aspect-ratio，以预留空间
• 用固定尺寸的容器为广告、嵌入内容和 iframe 预留空间
• 避免在现有内容上方插入内容，例如在加载后把页面往下推的横幅
• 谨慎使用 font-display: swap，并预加载关键的网页字体，或使用备用字体的度量值，避免文字重新排版
• 用 transform 做动画，而不是使用 top 或 height 等会触发布局的属性

一套实用的工作流程

1. 查看 Search Console 的“核心网页指标”报告，了解哪些 URL 组未通过，以及是哪项指标未通过
2. 从每个未通过的组中选择一个有代表性的 URL
3. 运行实验室测试，诊断是什么慢
4. 在模板层面修复：大多数问题会影响使用同一布局的所有页面
5. 验证：部署后在 Search Console 中开始验证；现场数据最多需要 28 天才能反映出改进

Core Web Vitals 对排名的影响有多大？

Google 明确表示，页面体验只是众多信号之一，相关性和有用的内容更重要。一个内容薄弱的快速页面，不会超过一个优秀的页面。但当页面的相关性相近时，更好的体验会有帮助；而且更快的页面一贯有更高的转化率，这一点无论排名如何都很重要。

针对不同平台的建议

WordPress

• 使用缓存插件或主机级缓存来缩短服务器响应时间
• 选择轻量级主题；重型页面构建器往往会添加大量 CSS 和 JavaScript
• 审查插件：每个插件都可能给每个页面添加脚本，损害 INP
• 使用能提供 WebP 或 AVIF 并添加宽度和高度属性的图片优化插件
• 延迟加载或删除不需要在每个页面上运行的第三方脚本

Shopify

• 检查已安装的应用，许多应用即使不使用也会在每个页面注入脚本
• 使用主题内置的响应式图片功能
• 限制首页上的区块和轮播图数量
• 上传前压缩图片并调整尺寸

自行开发和重度使用 JavaScript 的网站

• 使用服务端渲染或静态生成，让内容无需等待 JavaScript 就能显示
• 按路由拆分代码，按需加载组件
• 用 web-vitals JavaScript 库测量真实用户的 INP 并发送到统计工具，从而看到哪些交互较慢

自己测量真实用户数据

Search Console 和 PageSpeed Insights 显示的是汇总的 Chrome 数据，但只针对流量足够的页面，而且有延迟。要查看每个页面、每位访客的 Core Web Vitals，请添加真实用户监控（RUM）。开源的 web-vitals 库会从访客的浏览器上报 LCP、INP 和 CLS；你可以把这些数值发送到 Google Analytics 4 或其他统计工具。RUM 还会记录哪个元素是 LCP、哪次交互最慢，这正是解决问题所需要的信息。

关于 Total Blocking Time 和 Speed Index

除了 Core Web Vitals，Lighthouse 还会报告其他指标。**Total Blocking Time（TBT）**衡量加载期间主线程被阻塞的时长，与 INP 相关。**First Contentful Paint（FCP）**标记首次出现任何内容的时间。Speed Index 衡量可见区域被填充的速度。它们是有用的诊断指标，但本身并不是 Core Web Vitals。

常见误区

• “PageSpeed 必须得 100 分才能获得排名。” 不是。对页面体验而言，重要的是现场数据通过 Core Web Vitals 阈值，而相关性要重要得多。
• “Core Web Vitals 只对 Google 重要。” 更快、更稳定的页面能提升每一位访客的转化率和满意度，无论他们从哪里来到你的网站。
• “多装几个缓存插件会有帮助。” 叠加多个缓存或优化插件经常会引起冲突。使用一个配置得当的方案即可。

要点总结

• Core Web Vitals 衡量加载（LCP）、响应性（INP）和视觉稳定性（CLS）。
• 良好阈值是在真实访问的第 75 百分位上，LCP ≤ 2.5 秒、INP ≤ 200 毫秒、CLS ≤ 0.1。
• 重要的是真实 Chrome 用户的现场数据；实验室测试用于诊断问题。
• LCP 通常可以通过更快的服务器和更好地优化首屏大图来改善。
• 减少并拆分 JavaScript（尤其是第三方脚本）可以改善 INP。
• 为图片、广告和嵌入内容预留空间可以改善 CLS。

常见问题

为什么我的实验室分数和现场分数不同？

实验室测试模拟的是一种设备和网络。现场数据反映的是你真实访客的设备、网络和行为，包括实验室测试不会执行的交互。

改进多久后会在 Search Console 中显示？

现场数据涵盖过去 28 天，所以修复最多需要四周才能完全反映出来。

Core Web Vitals 在桌面端也重要吗？

重要。Google 会分别评估移动端和桌面端。由于设备和网络更慢，移动端通常更难通过。

多少分算是好的 PageSpeed 分数？

90 分或以上算好。但这个分数只是实验室测试的汇总；对页面体验来说，重要的是现场数据通过 Core Web Vitals。