结论先给：Core Web Vitals 是否达标，只由 CrUX 现场数据的 P75 分位决定；Lighthouse 实验室跑出 98 分并不参与排名判定。真正需要盯的三个指标是 LCP、INP、CLS，判定窗口是滚动的 28 天。
98 分与“不合格”为什么能同时成立
工程团队报喜、搜索端掉量，这类冲突大多不是谁在撒谎，而是两边看的根本不是同一份数据。PageSpeed Insights 的同一个页面里，其实并列着两套结果：上半部分是实验室数据，下半部分是现场数据。
| 对比维度 | 实验室数据（Lab） | 现场数据（Field / CrUX） |
|---|---|---|
| 采集方式 | 模拟加载，固定设备与网络档位 | 真实 Chrome 用户匿名上报 |
| 样本量 | 单次或数次 | 过去 28 天的全部合格访问 |
| 统计口径 | 单次得分 | 第 75 百分位（P75） |
| 是否参与排名 | 否 | 是 |
| 常见工具 | Lighthouse、WebPageTest | CrUX、Search Console 核心网页指标报告 |
差距主要来自四处。设备与网络：真实买家用的是中端安卓机加 4G，不是办公室的台式机加千兆宽带。缓存状态：实验室几乎总是冷缓存，真实访问里相当比例带着缓存与登录态。第三方脚本：客服插件、热力图、像素代码在真实环境里全部加载，实验室常被拦截或降级。交互路径：INP 衡量的是用户点下去之后页面多快给出反馈，而一次冷启动加载根本不会触发它。
三组最容易算错的口径差
其一，分位口径：看 P75，不是平均值
把 28 天内的访问按体验从好到差排成一队，排在第 75% 位置的那一次，才是决定成败的样本。平均值会被少数极快的访问拉高，掩盖掉尾部问题。这意味着一个页面只要最慢的那 25% 访问没被救回来，其余 75% 做得再漂亮，也不计入达标。优先级排序因此要反过来：先动拖尾的那批页面，而不是平均分最高的那批。
其二，设备口径：移动端与桌面端分开判定
同一份 CrUX 数据里，移动与桌面是两条独立判定线，谷歌以移动端为主要依据。外贸 B2B 站点常见的落差是：内部自测 LCP 1.8 秒，而东南亚、中东的采购商在真实网络环境下打开同一页面，LCP 4.6 秒。两笔数据都真实，但只有后者进入排名计算。
其三，时间口径：28 天滚动窗口，改完成绩不会立刻变
改版上线当天去查核心网页指标报告，看到的仍是过去 28 天的混合结果。要等一个完整窗口滚过去，数据才会稳定反映新版本。上线两周就判定“改了没用”，结论大概率是错的；反过来，把一次偶然的流量高峰当成优化见效，也一样危险。
达标线分三档，中间那一档最值得先抢
| 指标 | 良好 | 需改进 | 差 |
|---|---|---|---|
| LCP（最大内容绘制） | ≤ 2.5 秒 | 2.5–4.0 秒 | > 4.0 秒 |
| INP（下次绘制交互） | ≤ 200 毫秒 | 200–500 毫秒 | > 500 毫秒 |
| CLS（累积布局偏移） | ≤ 0.1 | 0.1–0.25 | > 0.25 |
“需改进”这一档的存在，说明优化不必一步到位。把 LCP 从 4.2 秒压到 2.6 秒，虽然尚未进入“良好”，但已经跳出“差”区间，排名层面往往就能看到变化，而工作量只有冲进“良好”的三分之一左右。先把所有页面从“差”推进到“需改进”，通常比死磕少数几个页面冲满分更划算。
把技术层的谷歌SEO优化与内容、外链放进同一套验收口径，是避免“各自达标、整体不涨”的关键动作。
一张 28 天对齐表
| 周次 | 动作 | 验收口径 |
|---|---|---|
| 第 1 周 | 口径对齐与基线采集：按页面组（首页、分类页、产品页、博客）分别导出 CrUX 与 GSC 数据，同时保存一份 Lighthouse 基线 | 每一组都有 P75 数值与页面清单，两套数据差异记录在案 |
| 第 2 周 | 定位拖尾样本：把 P75 最差的 25% 页面单独成组，逐页比对 Lab 与 Field 的差值 | 差值超过 1 秒的页面逐条归因到具体资源 |
| 第 3 周 | 动最慢的那批：优先处理首屏图片、字体加载策略、第三方脚本延迟、交互回调 | 单页 LCP 下降幅度可量化，CLS 归因到具体元素 |
| 第 4 周 | 复测与回滚判定：等待窗口滚动，比对第 1 周基线 | 连续 7 天 P75 改善才判定有效，否则回滚 |
钧笠营销在服务 100 多家出海企业的过程中观察到一个规律：技术整改真正卡住的往往不是改不动，而是改完之后没人等满一个窗口就下了结论。把验收节点写进排期，比多改几行代码更能决定结果。
顺带一提：这批数据也在影响广告那一边
同一批产品页既承接自然流量，也承接付费点击。落地页体验是 Google Ads 质量得分的组成部分，体验差会同时抬高点击成本。所以技术整改的收益不能只算自然流量那一栏——把两边的转化数据一起看，才知道这次改动值不值。这一点在做 SEO 与 SEM 的预算分配时尤其关键：页面体验是少数几个能让两条渠道同时受益的杠杆。
常见问题
LCP 达标了，INP 还差很多，先动哪个？
看哪一侧更靠近自己的业务动作。如果页面主要靠表单拿询盘，INP 直接影响填写体验，优先处理；如果页面以阅读为主、跳出率居高不下，LCP 的影响更大。两者都落在“差”区间时，一般先动 LCP，因为它通常对应更少的改动量。
只看 Search Console 的核心网页指标报告够吗？
用来看趋势和页面分组够用，但报告对低流量页面会做归并处理，单页问题容易被摊薄。单页诊断建议配合 PageSpeed Insights 的现场数据部分，以及 CrUX 的按页查询接口。
多语言站点需要分开看吗？
需要。不同语言版本往往部署在不同的地域节点，面向的网络环境差异明显。按语言版本分别建基线，才能避免某一个语种的慢速表现被整体平均值掩盖。
写在结尾
Core Web Vitals 的难点从来不是优化技巧，而是把分数口径统一到同一张表上。先把 CrUX 的 P75 当唯一标准，再按页面组拆开看，并用 28 天窗口验收，这三步做完，技术团队的努力和搜索端的反馈才对得上。
需要有人帮你把这张表落地？钧笠营销常驻上海临港新片区，成立 2 年，已服务 100+ 家出海客户，提供从技术审计到内容、外链的一体化谷歌SEO优化服务。咨询电话 18001580822。