Core Web Vitals 有个地方挺反直觉：它不看你服务器响应多快，也不看你机房离用户多远，它只看用户在页面上真实感受到的三件事，页面多久出来，点一下多久有反应，内容会不会乱跳。LCP 管加载，INP 管交互，CLS 管视觉稳定，良好线分别是 2.5 秒内、200 毫秒内和小于 0.1。这三个数背后还有个更要紧的口径，判定用的是真实用户数据，按 75 百分位算，所以实验室跑分再漂亮，也不等于真实用户那边就过了。
对做出海英文站的人，这三项更像一张体检单，它告诉你用户在哪个环节被卡住、卡住的人有多少，而不是给你一个能贴在墙上的分数。猎者出海做站这些年，技术 SEO 这一层的活基本都绕不开这张单子。想把整个 Google SEO 的框架先理清楚，可以看 Google SEO学习地图。Search Console 和 PageSpeed Insights 在国内能不能正常打开，以官方为准，这里不猜。
- 三项指标：LCP 看加载，INP 看交互，CLS 看视觉稳定。
- 合格线：LCP 2.5 秒内，INP 200 毫秒内，CLS 小于 0.1。
- 怎么查：Search Console 的 Core Web Vitals 报告看整站，PageSpeed Insights 测单个网址。
- 数据口径：真实用户数据，按 75 百分位判定。
这篇只围绕这三项：它们各测什么，线划在哪，报告和 PSI 怎么用，哪些地方最容易看错。
本文目录
Core Web Vitals 到底是什么，为什么 Google 要推它
官方给的定义是「Core Web Vitals is a set of metrics that measure real-world user experience for loading performance, interactivity, and visual stability of the page.」翻成人话，它量的不是服务器响应多快，也不是机房离用户多远，而是用户在页面上真实感受到的三件事：页面多久出来，点一下多久有反应，内容会不会乱跳。
官方的态度也很明确，强烈建议站长把这三项做到良好，理由是这对搜索表现和整体用户体验都有好处。这句话里没有承诺任何排名结果，它说的是建议做到，不是说做到了就一定会怎样。
三项指标对应页面体验的三个面：加载、交互、视觉稳定
LCP 看加载，具体是视口里最大的那张图、那块文字或者那段视频渲染出来的时间。INP 看交互，用户点一下、轻触一下、按一下键盘，页面多久给出反应。CLS 看视觉稳定，用户正读着，内容突然往下跳一截，这种意外偏移发生的频率就是它量的东西。
三项分开测，是因为这三个毛病的成因不一样。图片太大拖慢 LCP，脚本执行太久卡住 INP，广告位和字体替换造成 CLS，修法各不相同。揉成一个总分看，问题就查不下去了。
它是 Web Vitals 的子集，不是全部指标
Web Vitals 是一整套衡量页面体验的指标，Core Web Vitals 是其中一个子集，入选标准是适用于所有网页、所有站长都该测、并且会出现在 Google 的各种工具里。Web Vitals 里还有给特定场景用的指标，Core Web Vitals 是那条通用底线。
INP 就是个现成的例子。它是 FID 的继任指标，FID 只测第一次交互的输入延迟，后面的测不到。INP 在 2024 年成为稳定的 Core Web Vital 指标，把 FID 换了下来。
官方口径：页面体验是核心排名系统想奖励的内容之一，但没给权重数字
官方把 Core Web Vitals 和其他页面体验因素放在一起说，说它跟核心排名系统想奖励的东西是一致的。这句话能读出的只有一件事：它是排名系统会看的一类信号。读不出权重，也读不出做好了能涨多少位。
页面体验具体包含哪几块，写在 Page Experience是什么 那篇里，这里不重复。
LCP、INP、CLS 分别测什么，各自合格线是多少
这一节把三项拆开，一项一项说清楚测什么、线在哪、哪些行为算、哪些不算。
LCP：视口内最大图片、文本块或视频的渲染时间
LCP 记的是视口里最大的图片、文本块或视频渲染出来的时间，起点是用户第一次打开这个页面。良好线是页面开始加载后的 2.5 秒内。
它挑最大的那个元素，不挑最先出现的那个。这个设计对做站的人有个直接影响：首屏那张大图、那个大标题，权重最高，把它们弄快，比优化一堆小图标有用。
INP：点击、轻触、键盘交互的整体响应延迟
INP 测的是页面响应用户交互的整体响应性，观察的是整个访问过程中所有点击、轻触、键盘交互的延迟。良好线是小于 200 毫秒。
它有几个容易漏掉的细节。悬停、缩放、滚动这三类交互它不看。算的时候每 50 次交互会忽略一次延迟最高的，避免个别极端值把整页判死。最终取的是观察到的最长交互，去掉离群值之后。所以一个页面 INP 差，通常是某几个交互真的卡住了，不是所有交互都慢。
CLS：意外布局偏移的频率
CLS 衡量视觉稳定，量化的是用户碰到意外布局偏移的频率。良好线是小于 0.1。官方的算法是，布局偏移分数等于 impact fraction 乘 distance fraction，两个系数一乘得出这个分数。
它还有个窗口的概念。短时间内的连续偏移会被归成一个 session window，相邻两次间隔小于 1 秒、整个窗口最长 5 秒，取其中最差的那一段。用户输入之后 500 毫秒内发生的偏移，会带上 hadRecentInput 标记，可以不计入计算，因为那是用户自己操作引起的。
修 CLS 有个官方给的做法：要挪元素，别改 top、right、bottom、left，用 transform: translate()。
三项当前都是 stable 阶段，稳定指标每年变更不超过一次
LCP、CLS、INP 三项现在都处在 stable 阶段。stable 的指标每年变更不超过一次，还在 pending 阶段的指标至少要保持六个月，给整个生态留出适应时间。
这条对做站的人算个定心丸。这套指标不会下个月换一套，按它优化出来的东西能吃一段时间，不用天天盯着规则改版。
怎么查自己的 Core Web Vitals：Search Console 看整站，PageSpeed Insights 测单页
两个工具分工不同。Search Console 的 Core Web Vitals 报告看的是整站，按 URL 组归类。PageSpeed Insights 测的是单个网址，同时给实验室数据和真实用户数据，实验室数据是受控环境下跑出来的，适合调试。
数据从哪来也说清楚。报告里的数字来自 CrUX，也就是真实用户匿名上报的 field data。PSI 的 field 数据同样来自 CrUX，覆盖过去 28 天。
- 打开 Search Console 的 Core Web Vitals 报告。它按状态（Poor、Need improvement、Good）、指标类型（CLS、INP、LCP）、URL 组三个维度展示。看到 No data available，说明属性是新建的，或者 CrUX 里这个设备类型的数据还不够给出有意义的信息。
- 按设备拆开看。点图表旁边的 Open report 下钻到移动端或桌面端，把 Poor 和 Need improvement 各有多少 URL 记下来。这个数量决定后面先动哪一块。
- 在问题详情页挑一个示例 URL，跑 PageSpeed Insights。先看分布条上方报的 75 百分位，那是对应真实用户的数；再看下面的 Lighthouse 诊断，那里会指出是哪个元素拖慢了 LCP、哪一块在跳。示例表最多 200 行，不用一行行点。
- 认为某个问题修好了，回到那个问题的详情页点 Start Tracking，让报告跟着验证。不点这一步，你只能靠猜它有没有好。
- 想把数据攥在自己手里，用 web-vitals JavaScript 库，调 onCLS、onINP、onLCP 上报。官方强烈建议站点自建真实用户监测，因为 CrUX 不提供逐次访问的明细。
几个回查时要记住的限制。报告只收录已经索引的 URL，而且它只是样本，不是全部网址的清单。要查某一个具体 URL 的状态，这份报告不合适，它设计出来是看整站表现、排查影响多页的问题，单个 URL 得用外部测试工具。
PSI 和报告对不上也很正常。报告按 URL 组统计，PSI 一般按单个 URL，一个 URL 完全可能是它所在组里的异类。另外 PSI 在页面数据不足的时候会退到 origin 级粒度，把整站的数据拿给你看。
更新节奏也不一样。PSI 的 field 数据每天更新，CrUX 在 BigQuery 上的数据集每月更新，而且只到 origin 级别。CrUX 收录一个 URL 有门槛，URL 要能公开抓取、能被索引，还要有足够多的独立样本。
改动之后怎么确认真的落地，顺序和检查项写在 技术SEO自查 里。
三项指标的数字和分档：一张表看清合格线
| 指标 | 良好 | 需改进 | 差 | 说明 |
|---|---|---|---|---|
| LCP | ≤2.5s | 2.5 到 4s | >4s | 视口内最大元素的渲染时间 |
| INP | ≤200ms | 200 到 500ms | >500ms | 点击、轻触、键盘交互的延迟 |
| CLS | ≤0.1 | 0.1 到 0.25 | >0.25 | 意外布局偏移的频率 |
这三档不是分数，是优先级。落在需改进的 URL 要修，但排在差的 URL 后面。
判定口径得单独说清。统计按 75 百分位算，移动端和桌面端各算各的。三项的 75 百分位都是 Good，这个聚合才算通过评估。INP 数据不足的时候，LCP 和 CLS 两项的 75 百分位都是 Good 也算通过。LCP 或 CLS 只要有一项数据不足，页面或 origin 这一层就没法评估。
选 75 百分位不是随手定的。目的是让页面在大多数用户那里都能有好的体验，也包括设备和网络条件最差的那批用户。
官方还给了两条体量上的建议。一个页面连同它的所有资源，控制在 500KB 以内；移动端一个页面的资源数量，控制在 50 个以内。这两条不是硬指标，但页面体量压不下来，前面三项很难稳定在良好。
要长期盯这几个数，工具怎么选，见 SEO常用工具怎么选。
Core Web Vitals 和 SEO 排名到底什么关系，别把它当成排名开关
官方那句话的边界很清楚：Core Web Vitals 和其他页面体验因素一起，跟核心排名系统想奖励的东西是一致的。没有权重，没有提升幅度的数字。把它当成一个开关，做好了排名就打开，这是自己加戏。
更实际的看法是，它是一道筛子，不是加分项。用户在你的页面上点不动、内容乱跳，他退回去换一个结果，这个行为本身就会影响你的表现。指标只是把这件事量化出来给你看。
实验室跑分高也不代表真实体验好。官方的说法是 90 分以上算好，但实验室数据好，不等于真实用户的体验也会好。两套数据测的东西不一样，实验室是单台设备、固定网络条件下模拟加载，真实用户那边什么网络、什么手机、后台开着什么，你都控制不了。
还有个更让人不服气的地方：页面一个字没改，分数每次跑都可能不同。原因是本机网络、设备性能、资源竞争这些波动。所以别盯着某一次跑分做决策，看趋势。
真实用户的数据说有问题，那就是有问题；实验室说很好，只能当参考。判断顺序是先看 field，再看 lab，反过来容易自己骗自己。
排名还看别的，页面体验只是其中一类信号，整体怎么排的，见 Google排名因素。
几个容易踩的误区：报告和 PSI 为什么对不上、页面为什么没有 INP 值
下面这几条，都是看报告时会直接卡住的地方，一条一条对。
图表上的总数比表格里的总数小
正常，不是数据错了。图表里每个 URL 只按影响它最慢的那个问题计一次，表格是按每个问题各计一次，一个 URL 有两个问题就会被数两遍。
CLS 差、INP 好，整组状态还是 Poor
对的，URL 组的状态取这一组里表现最差的那个指标。一个组 CLS 差、INP 好，状态就是 poor。看到 Poor 之后要往下看是哪个指标拖的，别一上来就三项全改。
页面明明有流量，报告里却没有 INP 值
INP 要有交互才有数。用户只是打开页面看，从没点击、轻触或按键；或者他只滚动、悬停、缩放，这三类交互不算；再或者这个访问者是爬虫。这三种情况都出不来 INP。
报告里根本找不到某个 URL 组
URL 组缺 LCP 和 CLS 的最低数据量时，会被报告省略。组里数据不够，Search Console 会建一个更高层级的 origin 组来展示，所以你看到的是站级别的数，不是那个组自己的数。
整体数据比我自己测的慢
报告里的数据是把所有地区的请求合在一起算的。来自网络较慢地区流量占比较大的站，整体表现会被拉下去。这不是你的服务器差，是用户所在的位置和线路差。
排查顺序上，官方建议先修所有标为 Poor 的问题，然后按影响 URL 数量最多的排，或者按影响的是不是最重要的那批 URL 排。Need improvement 的可以改，但优先级低于 Poor。
最后一条要记住：CrUX 能告诉你有没有问题，不能告诉你原因。原因得靠 PSI 的实验室诊断，靠你自己去看这个页面到底加载了什么。
AI 能帮你做哪几步 Core Web Vitals 排查，哪几步必须自己来
AI 在这件事上能干的活，是把散的数据整理成能看的清单，判断还是人做。下面三步可以直接用。
先说最省事的。把 Search Console 报告导出的表格贴给 AI，让它按 Poor 优先、URL 数量从多到少分组排序，出一张待修清单。省的是手工排序的时间。
还有个能接上的动作。把 PSI 的 Lighthouse 诊断项贴给 AI，让它按 LCP、INP、CLS 三类归档，每类下面是具体的诊断项。分清楚了，哪一项归谁做也就清楚了。
对了，写稿或者开会要核对数字的时候，让 AI 把三项阈值和分档整理成对照表，数字你给它，它只负责排版，别让它自己换算。
还有一步可选：让 AI 照 web-vitals 库的官方示例，起草一段把指标发到分析端点的代码，人再改。这种草稿必须自己过一遍，别直接上线。
下面三条提示词是本文给的示例，不是官方模板，按需要改词就能用。
「下面是我从 Search Console Core Web Vitals 报告导出的表格，列有状态、指标类型、URL 数量。请按 Poor 优先、再按 URL 数量从多到少排序，输出一张待修清单，不要补充表格里没有的数字。」
「这是 PageSpeed Insights 对一个网址的 Lighthouse 诊断结果。请只根据我给的内容，把问题分成 LCP、INP、CLS 三类，每类列出对应诊断项，不要推测排名影响。」
「请把 LCP、INP、CLS 三项的良好阈值，以及 PSI 的 Good、Needs Improvement、Poor 三档区间，整理成一张三行对照表，数字照抄我列给你的，不要换算单位。」
必须自己动手的有三件。
- 在 Search Console 打开 Core Web Vitals 报告，选移动或桌面，点 Open report 下钻，记下 Poor 和 Need improvement 各有多少 URL。
- 在问题详情页的示例表里点一个 URL，跑 PageSpeed Insights，看 75 百分位和实验室诊断，决定这个组先修还是后修。
- 认为修好之后，回问题详情页点 Start Tracking，盯着验证结果。
猎者出海的AI Agent 运营模块每周拉一次数据，给你一张改稿单，但打开报告、判断先修哪个 URL 组，还是你自己来。
常见问题
三项指标里哪个最重要
没有单项优先这回事。三项的 75 百分位都是 Good 才算通过评估；只有 INP 数据不足时，LCP 和 CLS 两项都是 Good 也算通过。真要说先后，看报告里哪个指标拖的 URL 最多，就先修哪个。
为什么我的页面没有 INP 值
INP 要有真实的点击、轻触或按键才产生数据。用户只看不点、只滚动悬停，或者来的是爬虫，都出不来这个数。这类页面在评估时看另外两项。
PageSpeed Insights 和 Search Console 报告为什么对不上
两边统计的单位不一样。报告按 URL 组算，PSI 一般按单个 URL 算，一个 URL 可能是它所在组里的异类。另外 PSI 会去掉网址里的参数，报告是区分参数的。
实验室跑分 90 分以上就代表 Core Web Vitals 通过了吗
不代表。90 分以上只是实验室分数算好，官方明确说实验室数据好不等于真实用户的实际体验也好。判断通过与否，看真实用户那边的 75 百分位。
为什么报告里看不到我的网址
两种可能。报告只收录已经索引的 URL，没被索引的进不来；URL 组缺 LCP 和 CLS 的最低数据量时也会被省略。新建属性之后，CrUX 那边要几天才可能显示已有的数据。
Core Web Vitals 多久变一次
稳定指标每年变更不超过一次。还在 pending 的指标至少保持六个月，给生态留出适应时间。按现在这套优化，不用担心下个月标准就换了。
整个 Google SEO 从头做的顺序，看 谷歌SEO指南。
这三项说到底就是三个数字，值钱的是它们指向的东西：页面多久出来，点得动点不动，读的时候会不会跳。数字达标是结果，把页面弄轻、把脚本管住、给会跳的位子留好空间，才是要做的事。每周看一眼报告，挑影响的 URL 最多的那一项先修，修完点 Start Tracking 等结果。猎者出海的AI Agent 上线后每周给的那张改稿单，接的也是这个节奏，省掉的是拉数据的时间，判断还得你自己下。
发表评论