Core Web Vitals 详解：用通俗语言理解 LCP、INP 和 CLS

Core Web Vitals 不是你网站的性格测试

Core Web Vitals 常常被当成一张神秘的成绩单。页面拿到一个红色数字，有人在 Slack 里发截图，然后团队开始争论 JavaScript 框架。

这并不特别有用。

更好的理解方式其实更简单：它们是三项测量，用来判断一个页面在真实设备上，对真实用户来说是否好用。它们无法涵盖性能、可访问性或质量的所有方面。但它们确实能捕捉到三类常见的挫败感：

• 主要内容出现得太慢。
• 用户想做点什么时，页面反应迟缓。
• 用户正在阅读或点击时，布局到处跳动。

这就是三项 Core Web Vitals：LCP、INP 和 CLS。

Google 将它们作为页面体验信号的一部分，但 SEO 并不是最值得关注的理由。更好的理由是：缓慢、跳动、无响应的页面会浪费用户时间。它们通常也更难转化、更难支持，并且更容易随着时间变差。

三项指标，各用一句话说明

在进入细节之前，先给出通俗版本：

• LCP，即 Largest Contentful Paint，衡量主要可见内容加载出来需要多久。
• INP，即 Interaction to Next Paint，衡量页面在整个访问过程中对用户交互的响应有多快。
• CLS，即 Cumulative Layout Shift，衡量页面发生了多少意外的布局移动。

常见阈值如下：

| 指标 | 良好 | 需要改进 | 较差 | |---|---:|---:|---:| | LCP | 2.5s 或更快 | 2.5s–4.0s | 超过 4.0s | | INP | 200ms 或更快 | 200ms–500ms | 超过 500ms | | CLS | 0.1 或更低 | 0.1–0.25 | 超过 0.25 |

这些数字通常按真实用户访问的 第 75 百分位 进行评估。这一点很重要。你的目标不是让某一次实验室测试完美无缺，而是让大多数用户获得良好体验，包括使用较慢手机和不稳定网络的人。

如果你正盯着一份自动化报告，不确定从哪里开始，最好先把诊断和恐慌分开。我们有另一份指南，介绍如何在不恐慌的情况下阅读 Lighthouse 报告，其中更详细地覆盖了这个工作流程。

LCP：页面什么时候让人感觉已经加载好了？

Largest Contentful Paint 衡量视口中最大的可见内容元素的渲染时间。实际中，它通常是：

• 一个 hero image，
• 一个大标题，
• 一张精选文章图片，
• 一张产品图片，
• 一大块文本。

LCP 关心的不是每个脚本、跟踪像素和首屏以下图片什么时候加载完成。它问的是：用户来到这里想看的主要内容，什么时候变得可见？

这使得 LCP 比传统的“页面加载时间”更接近人的感受。一个页面从技术上看可能很晚才完全加载完成，但如果主要内容很快出现，它仍然会显得很快。反过来也一样：页面可能已经触发 load 事件，但 hero 区域仍然是空白、模糊的，或者被渲染延迟挡住。

LCP 较差的常见原因

大多数糟糕的 LCP 问题都来自几个可预见的位置：

1. 服务器响应慢

如果 HTML 文档到达得晚，其他一切都会晚开始。

1. 阻塞渲染的 CSS 或 JavaScript

浏览器已经拿到内容，但还不能绘制出来。

1. 未优化的 hero images

最大元素太大、格式不合适、没有被优先加载，或者被错误地延迟加载。

1. Web fonts 延迟文本渲染

大标题可能就是 LCP 元素，而字体加载可能延迟它，或在视觉上改变它。

1. 客户端渲染延迟

如果页面需要先加载一个很大的 JavaScript bundle 才能显示有意义的内容，LCP 就会受影响。

如何改进 LCP

从实际的 LCP 元素开始。在知道浏览器测量的是什么之前，不要随机优化资源。

实用修复包括：

• 快速提供 HTML：在适当位置使用缓存，减少后端工作，避免缓慢的重定向。
• 优化 LCP 图片：使用合适的尺寸、压缩方式和格式。
• 不要延迟加载首屏的 hero image。
• 当主图片确实是优先级最高的资源时，谨慎使用 fetchpriority="high"。
• 只有在能显著减少渲染延迟时，才内联关键 CSS。
• 减少首次有意义渲染之前所需的 JavaScript。
• 使用 font-display: swap 或其他有意设计的字体策略。

图片和字体是常见元凶。对于图片，取舍并不只是“文件小就好”。格式选择、编码成本和浏览器支持都很重要，因此我们保留了一棵实用决策树，用于判断 什么时候 AVIF 优于 WebP，什么时候不是。对于大量使用文字的页面，web fonts 仍然是最容易获得的性能收益之一，因为许多网站发送的字体文件比实际使用的更多。

INP：页面被触碰时是否会响应？

Interaction to Next Paint 衡量响应能力。更具体地说，它关注用户交互与浏览器处理该交互后的下一次视觉更新之间的延迟。

交互包括：

• 点击按钮，
• 点击菜单，
• 选择复选框，
• 在表单字段中输入，
• 打开手风琴组件。

INP 在 2024 年取代 First Input Delay 成为 Core Web Vital。这是一个好的变化。First Input Delay 只看第一次交互。INP 覆盖范围更广：它会考虑整个页面访问期间的交互，并将一次高延迟交互报告为页面的响应性得分。

通俗地说：INP 能发现那些看起来已加载、但用起来卡住的页面。

你很可能用过这样的页面。它看起来已经准备好了。你点击菜单。半秒钟内什么都没发生。你又点了一次。然后两件事同时发生。这就是 INP 问题。

INP 较差的常见原因

INP 通常是主线程问题。浏览器想要响应，但 JavaScript、渲染工作或布局计算挡在了路上。

典型原因包括：

• 大型 JavaScript bundles，
• 昂贵的事件处理程序，
• 客户端渲染应用中的 hydration 工作，
• 第三方脚本争抢主线程，
• 页面加载后的长任务，
• 小交互触发复杂的 DOM 更新，
• layout thrashing，即代码反复读取和写入布局值。

营销标签、analytics、聊天小组件和同意横幅都可能造成影响。这并不意味着“删除所有东西”。它意味着页面上的每个脚本都有成本，而交互延迟往往就是这种成本显现出来的地方。

如何改进 INP

改进 INP 并不依赖某个神奇属性，而更多是减少主线程争用。

有用的方法包括：

• 将长 JavaScript 任务拆成更小的块。
• 将非必要工作推迟到页面可用之后。
• 删除未使用的 JavaScript，而不只是压缩它。
• 保持事件处理程序小而可预测。
• 避免为了很小的状态变化重新渲染界面的大部分区域。
• 在可能时使用 CSS 处理简单的视觉状态。
• 审计第三方脚本，并只在需要的地方加载它们。

也要关注交互设计。一个能立即给出视觉反馈的按钮，即使后续工作需要更久，也会让人感觉更灵敏。这不能替代性能优化，但它是良好界面工程的一部分。我们的 accessible web buttons 清单与此有重叠：清晰状态、正确语义和可预测行为对用户和浏览器都有帮助。

CLS：页面是否停留在用户预期的位置？

Cumulative Layout Shift 衡量可见元素的意外移动。如果用户开始阅读一段文字，而上方的广告、图片或横幅加载出来，把文本向下推，这就会计入 CLS。

CLS 不是用秒来衡量的。它是一个基于内容移动量和移动距离的分数。越低越好。

关键词是 意外。由用户操作引起的布局变化通常不会以同样方式计算。如果有人点击“显示更多”后内容展开，这是预期行为。如果一个 newsletter banner 在三秒后出现在顶部，并把所有内容往下推，那就不是预期行为。

CLS 较差的常见原因

CLS 问题往往很普通：

• 图片缺少 width 和 height 属性，
• 广告或 embeds 没有预留空间，
• cookie banners 被插入到内容上方，
• web fonts 以不同指标换入，
• 延迟加载的促销条，
• 动态注入到页面顶部附近的内容。

修复通常是在内容到达之前预留空间。浏览器应尽早知道页面的形状。

如何改进 CLS

从可见的位移开始。观看录制，或使用浏览器工具识别哪些元素发生了移动。

然后应用那些朴素的修复：

• 为图片添加显式的 width 和 height 属性。
• 对响应式媒体容器使用 CSS aspect-ratio。
• 为广告、embeds 和 iframes 预留固定或最小空间。
• 避免在加载后将横幅注入到现有内容上方。
• 选择与最终字体指标相近的字体 fallback。
• 避免改变 top、left、width 或 height 等布局属性的动画；优先使用 transforms。

CLS 是少数几个纪律胜过巧思的性能指标之一。如果页面有稳定的盒子，它通常就会得分不错。

Field data 和 lab data 都有用，但它们回答的是不同问题

一个常见困惑是，不同工具会显示不同数字。这很正常。

Field data 来自真实用户。它反映实际设备、网络、位置和浏览器条件。Google 的 Chrome User Experience Report 就是 field data 的例子。

Lab data 来自受控测试环境。Lighthouse 是熟悉的例子。它可重复，适合调试，但它并不等同于用户的真实体验。

用 field data 判断用户是否真的遇到了问题。用 lab data 复现并调试这个问题。

还要记住，Core Web Vitals 通常按单个 URL 或 URL 组评估，而不是作为品牌的某个抽象整体属性来评估。你的首页、博客文章、定价页和结账页可能有完全不同的瓶颈。

合理的工作顺序

如果三项指标都很差，诱惑是从所有地方同时开始。请克制。

一个实用顺序是：

1. 先修复明显的 CLS

缺失的图片尺寸和不稳定的横幅通常是快速收益。

1. 改进重要模板的 LCP

聚焦重要页面：产品页、落地页、文章、注册流程。

1. 用真实交互调查 INP

点击用户真正会点击的东西。菜单、筛选器、表单和结账控件通常比初始加载轨迹更能暴露问题。

1. 审计第三方脚本

保留那些能证明其成本合理的脚本。删除或延迟那些不能的脚本。

1. 设定性能预算

没有预算，性能改进会衰退。新脚本、图片和设计组件会悄悄抵消之前的工作。

重点是：不要为了徽章而优化。要为了用户旅程而优化。低流量页面上的一点分数提升，可能不如一个略不完美但快得多的结账交互重要。

<!-- tool-cta:start -->

💡 试试这个： 由于 LCP 通常是图片问题，先用 Image Compressor 压缩你的首屏主视觉资源，作为一个简单的初步优化。

<!-- tool-cta:end -->

Core Web Vitals 不能告诉你什么

Core Web Vitals 有用，但并不完整。

它们不会告诉你内容是否优秀。不会告诉你导航是否合理。不会保证可访问性。不会衡量隐私、安全、信任、可读性，也不会判断页面是否回答了用户的问题。

它们也不能取代判断。一个页面可以通过 Core Web Vitals，却仍然令人不愉快。一个复杂应用可能未达到某个阈值，但仍然是在其约束下负责任地工程实现的。

把 LCP、INP 和 CLS 当作烟雾报警器。它们响起时，就去调查。它们安静时，也要继续维护这栋建筑。