Core Web Vitals 2026年最新标准：INP替代FID后，你的网站该优化什么

2024年3月Google正式用INP（Interaction to Next Paint）替换了FID（First Input Delay），到现在两年多了。但说实话，大部分站长的LCP和CLS已经优化得差不多了，INP反而是三个Core Web Vitals里最难搞的一个。

如果你还不清楚INP是什么：它衡量的是用户交互（点击、触摸、键盘输入）到浏览器实际渲染出视觉反馈之间的延迟。不是只测第一次交互，是测整个页面生命周期里所有交互中最慢的那几次，取第75百分位作为评分依据。

INP的门槛和现状

Google的标准是：

— 低于200毫秒：优秀

— 200-500毫秒：需要改进

— 超过500毫秒：差

2026年HTTP Archive的数据显示，全球移动端网站INP中位数大概在280毫秒——大部分站点都在"需要改进"这个区间。细分到国内，WordPress站点因为插件多、各种统计代码和广告脚本叠加，INP普遍在350-500毫秒。

INP差的最常见原因（按频率排序）

我排查了大概20个站点的INP数据，90%的问题出在这几件事上：

1. 长任务阻塞主线程

JavaScript里任何一个超过50毫秒的Task都会延迟浏览器的渲染响应。常见的罪魁祸首：第三方统计代码的定时器、广告脚本的DOM操作、过重的React/Vue组件渲染。

解法：用Chrome DevTools的Performance面板录制一次交互，看主线程上哪个Task把50ms线冲破了。大函数拆小，或者用scheduler.postTask()降优先级。

2. 事件回调里做重计算

点击一个按钮，触发了一个遍历3000条数据的数组操作。用户点完100毫秒后页面才有反应——INP直接炸。

解法：点击事件只触发状态更新或请求，实际计算放到requestAnimationFrame或Web Worker里异步做。

3. CSS触发了大量重排

特别是动态修改width、height、top、left这些几何属性。每次修改都触发Layout → Paint → Composite的完整管线。

解法：改用transform和opacity做动画和交互反馈，这两个属性只触发Composite阶段，不触发Layout。

4. 移动端的300毫秒双击延迟残留

虽然大部分现代浏览器已经消除了这个延迟，但如果你用了某些老旧的移动端适配库（比如一些2019年之前的FastClick实现），它们反而可能重新引入延迟。

实操：怎么给站点测INP

PageSpeed Insights和Lighthouse跑的是实验室数据，测的是FID不是INP（因为INP需要真实用户交互数据）。想看INP，两个地方：

1. Google Search Console → 核心网页指标报告 → 选"INP"。这里能看到全站真实的第75百分位数据。

2. Chrome User Experience Report（CrUX），在Data Studio里建一个报告面板。BigQuery里有公开的CrUX数据集，可以按URL级别看INP分布。

如果你没多少真实用户访问（新站或者日UV低于500），INP数据可能会因为样本不足而不可用。这时候用Web Vitals扩展在本地模拟各种交互场景，手动测。

一个快速见效的优化

把首屏所有非关键的第三方脚本延迟加载。测过一个站，把百度统计、CNZZ、客服聊天窗口、分享按钮这些脚本从同步加载改成load事件后再加载，INP从310ms降到了185ms。改动很小，效果明显。

核心就一句话：用户点了东西，浏览器应该立刻给他反馈。任何阻碍这个反馈的东西，都是INP要干掉的。

标签： Core Web Vitals INP 网站优化 SEO 网站性能 Google搜索