跳到正文
概念 · 基础设施

Core Web Vitals（LCP/INP/CLS）

速览要点

它是什么
Google 自己的真实用户 UX 度量集（LCP、INP、CLS），通过 Chrome UX Report 采集，被用作 Google 搜索的排名信号
对 GEO 的作用
间接，且有边界：哪些 AI 引擎沿用了搜索排名，就会顺带继承这个信号；不沿用的，几乎无效
各引擎的影响
AI Overviews 直接生效（沿用 Google 排名）；Bing Copilot 部分生效（不如 AIO 那样有书面框架）；ChatGPT Search、Perplexity、Claude 几乎可忽略（没有公开文档把 CWV 列为输入）
最常见的混淆
把 CWV（真实用户 UX）当成 AI 爬虫端的性能问题（TTFB、SSR、抓取超时）。是两件事，度量对象不同，处理方式也不同
在 GEO 里是什么角色
属于必须保留的基线信号，不是新增的发力点；保住基线和持续加码不是一回事

1. 什么是 Core Web Vitals

Core Web Vitals（CWV）是 Google 在 2020 年推出、2021 年纳入搜索排名的一套真实用户 UX 度量。当前三项指标是：LCP（Largest Contentful Paint）衡量加载、INP（Interaction to Next Paint）衡量响应、CLS（Cumulative Layout Shift）衡量视觉稳定性。Google 自己的定义是：「Core Web Vitals 是 Web Vitals 中适用于所有网页、所有网站都应该度量、并会出现在 Google 全部工具里的那一部分」（Web Vitals 概览）。

这套信号属于 Google，不属于整个 AI 生态。现场数据来自 Chrome UX Report (CrUX)，采集对象是开启同步的 Chrome 用户，没有任何 AI 引擎会独立给你的 LCP 或 INP 打分。因此，CWV 对 AI 答案可见性的作用，取决于该引擎是否复用了使用 CWV 的宿主搜索系统。

实务里有三个相近概念经常被混为一谈，先把它们分清楚再讲后面的事：

名称度量对象信号归属
Core Web Vitals真实 Chrome 用户的 UX：LCP、INP、CLSGoogle 的排名系统（页面体验的一个子集）
页面体验（Page Experience）一组更宽的 Google 信号：CWV，加上 HTTPS、移动友好、不打扰式插页Google 的排名系统（其中真正会拉动排名的部分就是 CWV）
AI 爬虫端的性能一次爬虫请求的 TTFB、渲染就绪程度、抓取超时窗口各家爬虫自己的基础设施，不是 Google，也不是 CWV

最常见的错误就出在最后一类：以为提升 CWV 就能帮爬虫在自身的抓取时间内更顺利地拿到页面。这是另一类问题，处理方式也不同，详见 SSR for AI Crawlers。

2. 当前的三项指标 — LCP、INP、CLS

指标度量什么Good 阈值（按 75 百分位）
LCP（Largest Contentful Paint）视口内最大可见元素的渲染完成时间，即加载≤ 2.5 秒
INP（Interaction to Next Paint）从点击／触摸／按键到下一帧呈现的端到端延迟，即响应≤ 200 毫秒
CLS（Cumulative Layout Shift）页面生命周期内非用户主动触发的视觉位移累计分，即视觉稳定性≤ 0.1

这里给的是 Google 当前 stable 阶段的 Good 阈值；Needs Improvement 与 Poor 两档的具体数值在 web.dev 的各指标页上有详细说明，偶尔会调整。对排名与 AI Overviews 资格来说，要看的只有一件事：你的 75 百分位现场值有没有进入 Good 区间。越过 Good 之后再继续优化，Google 没有公开过任何额外的排名加权（§4）。

历史脚注：INP 于 2024 年 3 月 12 日正式取代 FID 成为 Core Web Vital（web.dev 公告，2024 年 1 月 31 日；Google Search 原始博客，2023 年 5 月）。老的审计工具与文章里如果还在用 FID（First Input Delay）的阈值，把它当作历史项理解即可；INP 度量的是每一次交互完整的「输入到下一帧」延迟，而 FID 只测第一次交互的输入延迟，因此 INP 是更严格、更具代表性的度量。

3. 各 AI 引擎的影响 — 对照表

这张表的判定逻辑只有一条：某个 AI 引擎是否复用了一个已经使用 CWV 的宿主搜索系统。按这条判定，引擎刚好分成三类。

引擎CWV 对 AI 可见性的作用为什么
Google AI Overviews直接生效（沿用 Google 排名）AIO 取自 Google 经典网页索引与排名系统；CWV 是 Google 明文写入文档的排名信号（页面体验），并且 Google 明确把「为 AI 功能做优化」定性为「仍然是 SEO」（AI 优化指南）
Bing Copilot部分生效（沿用 Bing 排名；没有像 AIO 那样的成文框架）Bing 把页面加载时间列为排名因素之一（Bing Webmaster Guidelines），但没有专门把 Core Web Vitals 列出来；Copilot 「从排名到采信」这条链的公开说明也不像 Google 那么完整
ChatGPT Search · Perplexity · Claude几乎可忽略／未有公开文档这些引擎各自有独立的检索与引用机制，没有公开文档把 CWV 列为输入。它们真正在意的「性能」是另一回事：爬虫侧的 TTFB、SSR 就绪、抓取超时，见 §5

这张表的关键读法是：CWV 在哪些 AI 引擎里影响可见性，取决于该引擎是否复用了一个本来就把 CWV 当作排名信号的搜索系统。它不是通用的 AI 引擎信号，作用也并不对等。所谓「为 AI 优化 CWV」，本质上只是一笔仅对 Google 见效的投入。

4. 为什么作用是间接的 — 把机制讲清楚

在 Google 这一侧，完整的因果链是：

CWV → Google 搜索的一项排名信号 → 页面在某个查询下被索引并排序 → 进入 AI Overviews 的摘取候选池 → AIO 从候选里选出若干条来采信并附上引用 → 你的页面（出现或不出现）作为出处链接出现在答案下方。

CWV 只是 Google 多项排名信号中的一项，与内容质量、E-E-A-T、链接信号、主题相关性等并列。Google 自己也把话说得很死：「页面体验里除 Core Web Vitals 之外的其他方面，不会直接帮助你的网站获得更高排名」（页面体验）。换句话说，CWV 的确会拉动排名，但同属「页面体验」的其他属性并不会在 CWV 之外再叠加权重。信号是真的，分量有边界。

还有一点要补充：即便在 Google 这一侧，CWV 也不是 AIO 选段那一步直接消化的输入。AIO 从候选池里挑哪几条，依然由经典排名所用的那套质量系统决定，再叠加几项 AI 特有的可用性因素（内容是否便于被检索、是否便于被原文取用）。真正决定你能否被选中（前提是已进入候选池）的，是 可引用性（chunk 形态、可整段引述的论断）、E-E-A-T、实体识别 与 Knowledge Graph 存在性。GEO 也从未把 CWV 算作这几个发力点之一。

到了其他引擎，这条因果链整段就不存在了。Perplexity、ChatGPT Search、Claude 各自维护独立的检索索引，引用谁也由自己决定；从来没有任何一家把「Bing 的页面加载时间会顺势成为 Perplexity 的引用因素」这类对应关系写进公开文档。

5. Core Web Vitals 与 AI 爬虫端的性能不是一回事

这是最常被混淆的一处。CWV 度量的是 Chrome 上的真实用户，数据来自 CrUX 现场采集；AI 爬虫不在这份数据集里，因为 CrUX 的入选条件要求是登录并开启同步历史的 Chrome 用户（CrUX 方法学）。

层级度量什么GEO 失败形态修复入口
Core Web Vitals（本页）现场里的真实 Chrome 用户：LCP、INP、CLSGoogle 排名下滑 → AIO 候选池资格被削弱（间接）Web 性能工具链：web.dev、PageSpeed Insights
AI 爬虫端的性能一只爬虫的 TTFB、首字节 HTML 完整度、抓取超时爬虫在预算时间内拿不到可解析的内容 → 任何引擎都不会引用SSR for AI Crawlers；爬虫抓取行为见 AI 爬虫

AI 端的性能问题，真正可操作的判断只有一条：爬虫能不能在它给自己留的时间内把你的 HTML 抓回去并解析掉？ 这个问题的答案和你的 CWV 没有关系。一个站点可以三项 CWV 全绿，却交付了一份 Perplexity 抓取器读不动的 CSR 壳；另一个站点可以 INP 在人类用户那一端不达标，却在首字节就吐出一份对爬虫完全可解析的 SSR HTML。这两层处理的是性质不同的问题，相应的处理方式也不能互相替代。

由此可以得到一条相当实用的判断准则：GEO 审计里冒出一个性能问题时，先判断它落在哪一层，再决定怎么动手。CWV 的问题归 Web 性能工程处理；爬虫抓取的问题归渲染与基础设施处理。两者可以同时出现、单独出现，也可以都不出现。

6. 三类反模式

下面这三种做法，乍听之下都成立，实际却各有各的失败原因。前两种刚好相反，一种是对同一事实的过度投入，另一种则是全盘否定；第三种是把 KPI 放错了层。

反模式听起来对的理由实际为什么错
「为 AI 提升引用率而把 CWV 再优化一档」（比如把 LCP 从 2.0 秒压到 1.0 秒「给 AI 看」）CWV 是 Google 的信号；Google 又驱动 AIO；所以 CWV 越好 AIO 就越多跨过 Good 阈值之后，更高的 CWV 分数并不会带来额外的排名加权（页面体验）；而 AIO 的「选段」一步另有筛选标准，例如 可引用性 与 E-E-A-T，这些维度根本不把 CWV 当作输入。已经达标后再做边际优化，AI 端的回报几乎为零
「AI 引擎不看 UX，所以 CWV 无关紧要」的确，ChatGPT Search、Perplexity、Claude 都没有把 CWV 当作输入漏算了 AI 曝光里来自 Google AI Overviews 与 Bing Copilot 的那部分；在那里 CWV 仍然决定你能不能进入候选池。况且 CWV 与人类用户的转化、留存等结果之间的相关性从未消失，这本来就是当初投入它的真正理由
「把 CWV 当作 GEO 的 KPI」CWV 可量化、便于审计，又对应一个 Google 信号这是放错了层。GEO 的 KPI 看的是 AI 侧的结果，比如引用率、声量份额、平均位置，详见 GEO 指标。CWV 是一项 Web 性能 KPI，它先作用于 Google 的一项排名输入，再间接参与某个引擎候选池的形成；把它直接当作 GEO 的结果指标，等于把中间好几层因果压成一层

一句话归纳：CWV 不是 GEO 的信号，它是 Google 的排名信号；它对 AI 的相关性，取决于哪些引擎复用了 Google 的排名。

7. 这件事对 GEO 意味着什么 + 该怎么做

你的需求从这里开始
测量我当前的 CWVGoogle PageSpeed Insights · Search Console 的 Core Web Vitals 报告 · CrUX（现场数据）
修 LCP / INP / CLS通用的 Web 性能工具链：web.dev/vitals 与各指标对应的页面
修 AI 爬虫 真正看到的东西SSR for AI Crawlers：另一类问题，另一种修法
把性能检查纳入 GEO 审计GEO 审计：CWV 占一项检查位；爬虫抓取就绪占另一项
了解 AIO 是怎么继承 CWV 的Google AI Overviews 中复用 Google 质量系统那一节
知道真正能拉动 AI 引用的信号是哪几样可引用性 · E-E-A-T · 实体识别 · Knowledge Graph 存在性
追踪 AI 侧结果（而不是 CWV）作为 KPIGEO 指标
SEO 与 GEO 共用基线的框架SEO vs GEO：CWV 是「绝不丢弃」那一行，不是新增的 GEO 发力点

在 GEO 里，CWV 属于必须保留的基线，而不是新增的发力点。它在 Google 排名管用的地方依旧管用，要达到的标准就是 Google 公布的 Good 阈值，不必再追加更激进的过度优化。「保留」和「发力点」并不是一回事：一个只需要维持在基线达标的信号，不应该成为 GEO 边际投入的去处。

参考资料

官方文档（截至 2026-05）：

其他引擎与数据来源：

业界与独立测量：

常见问题

AI 引擎会用 Core Web Vitals 决定引用谁吗？
只是间接生效，而且只限于那些直接沿用了搜索排名结果的引擎。Google AI Overviews 走的就是经典 Google 搜索的索引与质量系统（见 [AI 优化指南](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide)），CWV 在 Google 排名里的权重也就顺势带了进来。Bing Copilot 借助 Bing 排名部分继承，因为 Bing 把页面加载时间列为排名因素之一。ChatGPT Search、Perplexity、Claude 各自有独立的检索与引用机制，没有公开文档把 CWV 列为输入；对这些引擎来说，关键是爬虫能否在自身留给抓取的时间内取回可解析的 HTML，这比你的 LCP 分数重要得多。
如果我把 LCP 从 2.0 秒优化到 1.0 秒，引用率会上升吗？
几乎不会有直接收益。一旦你的 LCP 进入 Good 区间（≤ 2.5 秒），再往下优化对 Google 排名的边际收益很有限，对 AI Overviews 的选段也没有任何已知的额外作用。Google 自己的说法是：「页面体验里除 Core Web Vitals 之外的其他方面，不会直接帮助你的网站获得更高排名」（[页面体验](https://developers.google.com/search/docs/appearance/page-experience)）。真正能带动 AI 引用的发力点在可引用性（chunk 形态、可整段引述的论断）、真实 E-E-A-T、实体清晰度，不在已经达标的性能指标上做微调。
那是不是可以不再关心页面速度？
不是。「AI 引擎不看 UX，所以 CWV 不重要」这种说法，和过度优化属于同一个误区，只是方向相反。CWV 仍然是 Google 的排名信号，所以从 Google AI Overviews 拿到的那部分 AI 曝光，它依旧有作用。即便不谈 AI，CWV 与转化、留存等真实用户结果的相关性从未变过，这本来就是当初投入它的理由。要避开的另一种错误，是反过来把 CWV 当成 AI 引擎会额外加权的信号；并不会。
AI 爬虫的抓取超时和 INP、LCP 是同一件事吗？
不是，把两者混为一谈是从业者最常犯的错。CWV 度量的是真实 Chrome 用户的体验，数据来自 Chrome UX Report（见 [CrUX 方法学](https://developer.chrome.com/docs/crux/methodology)）；爬虫不在这份数据集里，因为入选条件要求是登录并开启同步历史的 Chrome 用户。AI 爬虫各自有自己的抓取预算（通常只有几秒），关心的是 TTFB，以及你的 HTML 是不是在首次响应就 SSR 完整、可被解析。优化 CWV 不会自动修好爬虫侧的问题；SSR 就绪和 TTFB 是另一类问题，详见 [SSR for AI Crawlers](/zh/ssr-for-ai-crawlers)。
INP 已经取代 FID 了吗？
是，2024 年 3 月 12 日正式取代。Google 在 2024 年 1 月发出公告（[web.dev 公告](https://web.dev/blog/inp-cwv-march-12)），此前 INP 经历了约十个月的预览期（[Search Central，2023 年 5 月](https://developers.google.com/search/blog/2023/05/introducing-inp)）；从那以后 INP 就是第三项 Core Web Vital。如果你在老审计工具或老文章里仍看到 FID 阈值，按历史项理解即可。当前的指标是 INP（Interaction to Next Paint，Good ≤ 200 ms）。

延伸阅读

参考来源

一手来源

  1. Web Vitals (overview, definition, current metrics) · Google (web.dev)
  2. Interaction to Next Paint (INP) · Google (web.dev)
  3. Understanding page experience in Google Search results · Google Search Central
  4. AI features and your website · Google Search Central
  5. Optimizing for generative AI features in Google Search · Google Search Central · 2026-05-15
  6. Advancing Interaction to Next Paint (INP becomes a Core Web Vital, March 12, 2024) · Google (web.dev) · 2024-01-31
  7. Introducing INP to Core Web Vitals · Google Search Central · 2023-05-10
  8. Bing Webmaster Guidelines · Microsoft Bing
  9. Chrome UX Report (CrUX) — methodology · Google (Chrome for Developers)

二手来源

  1. Web Almanac 2024 — Performance chapter · HTTP Archive
  2. Rakuten 24 case study — Core Web Vitals and business KPIs · Google (web.dev)
  3. Google Core Web Vitals to add Interaction to Next Paint on March 12 · Search Engine Land
最近更新： 2026-05-23 作者： Ray Yang 主题： 基础设施