访客来到您的网站，但页面迟迟打不开；点了按钮却没有反应；刚开始阅读，文字就往下跳。这三种小小的失望，在 Google 那里各有其名：Core Web Vitals。衡量和提升网站速度最清晰的途径，正是这三项指标。
本文将介绍 Core Web Vitals 是什么、LCP、INP 和 CLS 指标最新的“良好”阈值、如何用哪些工具正确测量这些数值，以及对每项指标效果最显著的优化方法。
即使您没有技术团队，读完本文后也能自行检查网站状况，并向您的服务商或开发人员提出正确的问题。
为什么网站速度既关乎客户，也关乎 SEO？
慢速网站首先会让您失去用户。在移动网络下盯着空白屏幕等了几秒钟的访客，会返回搜索结果点击下一个链接。对于您通过广告带来的流量，这直接意味着金钱损失。
在 Google 方面，Core Web Vitals 属于“页面体验”范畴，是排名系统考虑的信号之一。Google 搜索中心对此有明确说明；但同一文档也强调，内容的相关性仍然具有更大的决定作用。也就是说，速度快但内容薄弱的页面不会排到前列；而在质量相近的两个页面之间，体验则可能拉开差距。
速度本身不会让您排第一，但缓慢很容易让您落后。
Core Web Vitals 指标与 2026 年阈值
Core Web Vitals 由三项指标组成，分别衡量用户体验的不同方面：加载、交互和视觉稳定性。
| 指标 | 衡量什么？ | 良好 | 需要改进 | 较差 |
|---|---|---|---|---|
| LCP（Largest Contentful Paint，最大内容绘制） | 页面中最大的图片或文本块出现在屏幕上所需的时间 | ≤ 2.5 秒 | 2.5–4 秒 | > 4 秒 |
| INP（Interaction to Next Paint，交互到下一次绘制） | 页面对点击、触摸和按键做出视觉响应所需的时间 | ≤ 200 毫秒 | 200–500 毫秒 | > 500 毫秒 |
| CLS（Cumulative Layout Shift，累积布局偏移） | 页面加载和使用过程中元素的意外移动 | ≤ 0,1 | 0,1–0,25 | > 0.25 |
一个重要细节：Google 依据真实用户的第 75 百分位来评估这些数值。也就是说，至少 75% 的访问应处于“良好”阈值以内。页面要通过 Core Web Vitals 评估，三项指标都必须良好；只要有一项较差，就不会取平均值。
如何测量 Core Web Vitals：实地数据与实验室数据
测量中最常见的错误，是只看一个 PageSpeed 分数就下结论。数据分为两类，各自说明不同的问题：
- 实地数据（field data）：即从 Chrome 用户真实体验中收集的 Chrome UX Report（CrUX）数据。这正是 Google 在排名中参考的数据，反映的是最近 28 天的情况。
- 实验室数据（lab data）：即 Lighthouse 在单一模拟设备和网络条件下进行的测试。它非常适合诊断问题，但不能完全代表真实用户体验。它无法直接测量 INP，而是参考 Total Blocking Time（TBT，总阻塞时间）。
什么工具用于什么用途？
- PageSpeed Insights：针对单个网址同时显示实地数据和实验室数据。请以上方的“真实用户体验”部分为准。
- Search Console — Core Web Vitals 报告：将整个网站划分为相似的页面组，显示移动端和桌面端哪些 URL 表现较差。
- Chrome DevTools（Performance 面板）：供开发人员逐行查找交互缓慢和布局偏移原因的工具。
- web-vitals 库：Google 提供的小型 JavaScript 库，用于将真实用户测量数据发送到您自己的分析工具。
如何优化 LCP：更快地显示主要内容
在大多数企业网站上，LCP 元素是页面顶部的大图（hero）或主标题。LCP 时间由四部分组成：服务器首次响应（TTFB）、资源发现、资源下载和屏幕渲染。优化也按这一顺序进行。
- 加快服务器响应：web.dev 认为 TTFB 在 0.8 秒及以下为良好。页面缓存、优质托管和 CDN 能显著缩短这一时间。
- 让 LCP 图片尽早被发现：不要通过 CSS 背景或 JavaScript 加载图片，而是直接写在 HTML 中；并用 fetchpriority="high" 设置优先级。
- 不要对首屏图片使用懒加载：懒加载适用于首屏以下的图片；用在主图上会推迟 LCP。
- 压缩图片：使用 WebP 或 AVIF 格式、合适的尺寸和 srcset，避免在移动端下载不必要的大文件。
- 减少阻塞渲染的资源：前置关键 CSS，清理未使用的 CSS 和同步加载的脚本，字体使用 font-display: swap。
关于托管方面的决策对速度的影响， 域名与主机选择 一文中也专门讨论过类似的两难选择。
如何优化 INP：对点击即时响应
INP 问题通常源于浏览器主线程（main thread）被 JavaScript 占用。用户点击菜单时，浏览器恰好在运行某个分析脚本或庞大的轮播代码，响应因此延迟。
- 拆分长任务：将超过 50 毫秒的 JavaScript 任务拆分成小块；先向用户提供视觉反馈，再执行繁重的工作。
- 审查第三方脚本：在线聊天气泡、热力图工具、多个广告和分析标签是影响 INP 最常见的元凶。保留真正在用的，其余的延迟加载。
- 保持 DOM 精简：在包含成千上万个元素的页面上，每次交互后的重绘成本都会变高。
- 减轻插件和主题负担：现成主题在每个页面加载的无用代码，尤其会拖慢低配手机上的交互。
在这一点上，基础架构的选择起决定作用。靠插件堆起来的网站与按需编写的轻量网站之间的差异， WordPress 还是定制开发 一文。
如何优化 CLS：防止页面跳动
正在阅读的那一行突然往下跳，或者正要点击时按钮换了位置，这就是 CLS 所衡量的。好在解决方法通常很简单：
- 为图片和视频指定尺寸：通过 width 和 height 属性或 CSS aspect-ratio，让浏览器预先留出空间。
- 为广告、横幅和嵌入内容预留固定区域：后加载的 Cookie 提示或促销横条不应把内容往下挤，而应以覆盖层（overlay）形式在上方弹出。
- 让字体切换更平滑：预加载网页字体，并使备用字体的尺寸与其接近。
- 动画使用 transform：用 transform 和 opacity 做动画，而不是 top、left、height 等会影响布局的属性。
不同类型网站最常见的速度问题
每个网站变慢的原因各不相同。按网站类型总结我们在项目中遇到的情况：
| 网站类型 | 最常见的问题 | 首先检查的地方 |
|---|---|---|
| 使用现成主题的企业网站 | 主题臃肿、插件众多、轮播图片过大 | 未使用的插件、主图尺寸、页面缓存 |
| 电商网站 | 商品图片、筛选器、大量跟踪和营销标签 | 分类页的 LCP、第三方脚本、购物车交互的 INP |
| 单页应用（React、Vue 等） | JavaScript 包体积大、内容在浏览器中生成过晚 | 服务端渲染或预渲染、代码分割 |
| 新闻与博客网站 | 广告位延迟加载导致内容偏移 | 为广告位预留的固定区域、CLS |
此表只是一个起点；确切的诊断始终要靠测量。不过，了解问题最可能出在哪里，能在与开发人员沟通时节省时间。例如，如果某个电商网站的商品详情页很快，分类页却很慢，问题往往在于列表中的几十张图片同时以原始尺寸下载。
如果您的目标是像移动应用一样快速轻盈的体验，就需要在设计阶段讨论这一点。事后添加到页面上的每一个“小”功能，都会占用速度预算。
提升网站速度的分步计划
不要试图同时修复所有问题，而是从影响最大的开始：
- 第 1 步 —在 Search Console 中打开 Core Web Vitals 报告，列出移动端“较差”的页面组。
- 第 2 步 —从每组中选一个示例网址在 PageSpeed Insights 中测试，记下哪项指标未达标。
- 第 3 步 —先解决模板层面的问题：使用同一模板的数百个页面，一次修复即可全部改善。
- 第 4 步 —先实施图片、缓存和 CDN 等见效快的优化，再处理 JavaScript 和第三方脚本。
- 第 5 步 —在 Search Console 中点击“验证修复”，等待实地数据在 28 天内更新。
速度不是一次性项目，而是需要持续守护的预算。一个新插件、一张大图或一段额外的跟踪代码，都可能在几周内抵消已有的成果。因此，每次添加新功能前，都要问一问：“这会让页面慢多少？”如果您想从更宏观的角度了解速度在搜索曝光中的位置， 也可以看看我们的技术 SEO 检查清单。
- 移动端 LCP 是否低于 2.5 秒？
- INP 是否低于 200 毫秒，多余的第三方脚本是否已清理？
- CLS 是否低于 0.1，所有图片是否都设定了尺寸？
- 主图是否不使用懒加载并优先加载？
- 图片是否为 WebP/AVIF 格式且尺寸合适？
- 页面缓存、压缩和 CDN 是否已启用？
- 是否定期查看 Search Console 的 Core Web Vitals 报告？
常见问题
什么是 Core Web Vitals？
Core Web Vitals 是 Google 为衡量真实用户体验而设定的三项指标：衡量加载速度的 LCP、衡量交互响应的 INP 和衡量视觉稳定性的 CLS。这些指标用于 Google 的页面体验评估。
LCP 多少秒算良好？
根据 Google 的标准，LCP 在 2.5 秒及以下为良好，超过 4 秒为较差。评估依据真实用户访问的第 75 百分位。
INP 为什么取代了 FID？
FID 只测量页面上首次交互的延迟，大多数网站都能轻松通过。而 INP 会跟踪页面上的所有交互，并报告其中最慢的之一，因此能更好地反映用户的真实体验。这一变更于 2024 年 3 月生效。
PageSpeed 分数不到 100，我的 SEO 就会很差吗？
不会。Lighthouse 分数是一项实验室测试，并非直接的排名信号。重要的是真实用户数据中的 LCP、INP 和 CLS 处于良好阈值以内。一个 85 分但实地数据良好的页面，比一个 100 分的测试结果更有意义。
Core Web Vitals 的修复多久能体现出来？
由于实地数据基于最近 28 天的用户体验，修复效果完全体现在报告中大约需要四周。而在实验室测试中，您可以立即看到改善。
结语
Core Web Vitals 把网站给访客的感受浓缩为三个数字：主要内容在 2.5 秒内出现，每次点击在 200 毫秒内得到响应，页面偏移低于 0.1。实现这些目标，往往不需要昂贵的重建，而需要准确的诊断和有条不紊的小幅修复。
CYF Tech 开发的 网站和 Web 软件 从一开始就按速度预算进行设计；对于现有网站，我们也提供 Core Web Vitals 分析和优化服务。如果您想和我们一起找出网站变慢的原因， 联系我们.