结论：Core Web Vitals 达标与否只看 CrUX 现场数据里 INP 的 p75 值，Lighthouse 实验室跑分不进谷歌的排名评估。这句话决定了后面所有动作的方向——优化对象应该是真实用户设备上最慢的那四分之一访问，而不是开发机上的那一次漂亮成绩。
绿勾与红叉为什么会同时出现
同一个页面、同一天，Lighthouse 性能 98 分、全项绿勾，Search Console 的 Core Web Vitals 报告却写着”需要改进”。这不是工具出错，而是两套数据的采集方式不同：Lighthouse 在受控环境做一次性模拟加载，网络与 CPU 都是固定的；CrUX（Chrome User Experience Report）记录的是真实 Chrome 用户在过去 28 天里、用各自的手机与网络访问时留下的字段数据。前者叫实验室数据，后者叫现场数据，谷歌用于评估的是后者。
更关键的是统计口径。三项指标都取第 75 百分位（p75）：把 28 天内所有访问按体验从好到差排序，取第 75% 那一次的成绩作为页面代表值。跑分反映的是”开发者设备上最快的一次”，p75 反映的是”真实用户里最慢的一批”。两者差 0.3 秒是常态，差 1 秒以上并不罕见。
INP 接棒 FID 之后，考核对象变了
INP（Interaction to Next Paint）正式取代 FID 成为响应性指标后，不少原本及格的站点一夜变红。原因在于测量终点不同：FID 只量”用户首次交互到浏览器开始处理”的输入延迟；INP 量的是”交互发生到下一帧真正画出来”的完整链路。
一次交互的 INP 可拆为三段：输入延迟、处理时长、呈现延迟。多数团队把力气全压在第二段——拆包、压缩、Tree Shaking，却漏掉第三段：回调早已执行完，浏览器还要做样式重算、布局、绘制并把结果提交到屏幕，这段同样计入 INP。交互触发大面积重排重绘时，呈现延迟常常吃掉一半以上预算。
阈值是固定的：INP ≤ 200ms 为良好，200–500ms 为需要改进，超过 500ms 为差；LCP ≤ 2.5s，CLS ≤ 0.1。
4 类在真实设备上才暴露的扣分代码
一、超过 50ms 的长任务
单次执行超过 50ms 的 JS 任务被称为长任务（Long Task），它会让后续交互排队等待。同一段脚本在开发中端机上跑 200ms，在低端安卓机上可能被放大到 600ms。
二、被忽略的第三方脚本
在线客服、热力图、A/B 测试、广告像素，每个都自带监听器与网络请求。常见情况是首屏交互被 6 到 9 个第三方域名的脚本包围，任何一个打嗝都会直接反映到 INP。
三、一次性 hydration
前端框架把首屏全部组件一起激活，用户点第一个按钮时主线程恰好最忙。
四、回调里干重活
在 click 回调中同步读写 DOM、触发全量重渲染、同步调用本地存储，都会把响应时间堆到 400ms 以上。
3 组来自 CrUX 的对照数字
钧笠营销在两年间服务 100+ 家出海客户时，记录过几组典型现场数据，均取自 CrUX 的 28 天滚动窗口、移动端口径：
- 某外贸产品页：Lighthouse 性能 96 分、实验室 INP 62ms；CrUX 移动端 p75 为 412ms。把 4 个第三方脚本改为首次交互后再加载，28 天后 p75 降到 238ms。
- 某询盘表单页：去掉提交回调里的同步序列化（原耗时 180–260ms），并把按钮 loading 改为 CSS 动画而非 JS 逐帧更新，p75 从 517ms 降到 291ms，同周期表单提交率上升 18%。
- 某列表页：把一次性 hydration 改为按可视区域分片激活，每次加载的长任务数从 14 个降到 3 个，CLS 同步从 0.19 降到 0.06。
三组数据的共性是：改动都不在加载阶段，而在交互阶段。这也是 LCP 的优化经验无法直接平移到 INP 上的原因。
一张 28 天校准表
CrUX 是 28 天滚动窗口，改完当天看不到结果，需要按周推进：
第 1–7 天只做测量。接入 web-vitals 的 attribution 版本，按设备档位与页面类型分别统计 INP p75，并记录最慢交互的目标元素。这一周不要动代码。
第 8–14 天动第三方脚本。把非必要的客服、热力图、A/B 脚本改为交互后加载或空闲时加载；转化追踪保留，但触发时机后移。
第 15–21 天动回调本身。把重活拆成”先响应、后计算”两步：立即给出视觉反馈（禁用按钮、loading），把数据整理、埋点上报、DOM 重写放进下一帧或 Web Worker；避免回调里同步读取布局属性，那会触发强制同步布局。
第 22–28 天只看 p75。若仍卡在 200–500ms 区间，重新采样再判断，因为此时窗口里混着改动前后的数据。
LCP、INP、CLS 的优先级怎么排
三项要分开看，别混在一张表里追。经验顺序是：LCP 先过 2.5s 这道线，它决定用户愿不愿意停留；INP 排第二，它决定用户能不能完成操作；CLS 放在第三位核对，它决定用户会不会点错。我们在做谷歌SEO优化时也沿用这个次序：三项都不达标时优先修 INP，因为它直接卡在询盘、加购、提交这类转化动作上，是三项里离营收最近的一项。
什么时候该交给外部团队
如果连续两个 28 天窗口 p75 仍高于 500ms，问题多半不在几行代码，而在整站架构：模板过度组件化、数据请求瀑布嵌套、CDN 回源路径过长。这类排查需要同时懂前端性能与谷歌抓取逻辑的人一起做。位于上海临港新片区的钧笠营销，两年里已为 100+ 家出海企业做过现场数据诊断，服务覆盖谷歌SEO优化与技术性能治理，咨询电话 18001580822。判断标准只有一条：能让 CrUX 的 p75 在 28 天内真正移动的改动才值得做，其余都是自我安慰。