Core Web Vitals 变化盘点：INP 取代 FID，先修哪个指标？

2024 年 3 月起 INP 正式取代 FID 成为 Core Web Vitals 的交互响应指标，衡量整个访问过程中的所有点击、触摸和按键，而不只是第一次。文章梳理了指标阈值、Search Console 报告的查看与验证流程，以及 LCP、INP、CLS 三类问题的常见原因和排查顺序。

INP 取代 FID 意味着什么

• FID 只统计访客的第一次交互，页面后续卡顿完全测不到；INP 记录整个访问中每次点击、触摸和按键，取排除离群值后最慢的一次
• Chrome 数据显示约 90% 的页面停留时间发生在加载完成之后，INP 覆盖的正是用户真正能感知的部分
• INP 达标线是 200ms 以内，200–500ms 为需改进，超过 500ms 判为差

Content Warehouse 泄露文档的关联

• 2024 年 3 月流出的 Google 内部 API 文档确认，公开的 Core Web Vitals 指标只是背后更大规模点击排名系统的代理
• 文档提到 NavBoost 系统会用约 13 个月的滚动点击数据重新排序结果
• 页面慢或不稳定会产生更多 bad clicks——用户点进来又立刻返回搜索结果，优化 Core Web Vitals 等于减少这种回流

在 Search Console 里查报告的正确姿势

• 入口在左侧 Experience 下的 Core Web Vitals，分 Mobile 和 Desktop 两份报告
• 报告按模板把 URL 分组，而不是逐条列出，点进差评组能看到具体是 LCP、INP 还是 CLS 不达标、受影响 URL 数量和样本
• 修复后点 Validate fix，Google 会重新抓取样本并用真实用户数据更新状态，通常需要两到四周

三个指标的阈值和典型病因

• LCP：最大可见元素渲染时间，2.5 秒内达标；常见原因是 Hero 图加载晚或服务器 TTFB 过高
• INP：交互到下一次绘制的延迟，200ms 内达标；常见原因是长 JavaScript 任务阻塞主线程、广告和聊天组件等第三方脚本过重
• CLS：布局偏移，0.1 以内达标；常见原因是图片和广告没预留尺寸、Web 字体回退设置不当导致文字回流
• 三项指标都按真实访问的第 75 百分位判定，即至少四分之三的访问要达标

什么时候 Search Console 不够用

• 低流量页面拿不到足够的真实访问数据，报告会显示无数据，需要用 Lighthouse 等实验室工具
• Search Console 只告诉你哪个模板哪个指标出问题，定位到具体脚本要用 Chrome DevTools
• 如果每次发版都重新引入布局偏移，应该把性能监控加进构建流程，而不是每月看一次报告
• Shopify 站点的 INP 问题往往出在第三方 App，装新工具前先评估追踪代码的重量

团队常犯的错误

• 把 Core Web Vitals 当成一个总分去刷 PageSpeed Insights 满分，实际上它是三个独立问题
• Google 只看是否越过 Good 阈值，过了之后继续优化对排名的边际收益很小
• 动手改代码前先用测速工具确认到底是加载、交互还是布局的问题，避免盲目猜测