INP替代FID快一年了，你的网站还卡在200ms以上？

Google在2024年3月正式用INP（Interaction to Next Paint）替代了FID作为Core Web Vitals的交互指标。到现在2026年中，我抽查了30个中文网站，超过一半INP还在200ms以上。如果没关注过这个指标的变化，现在该补课了。

INP和FID有什么不一样

FID只测第一次交互的输入延迟，可以说是个开机第一脚。INP测的是整个页面生命周期中所有交互的延迟，取第98百分位——说白了就是看最卡的那几次操作。

这个变化很关键：你的页面可能FID很低（第一下点击很快），但用户点第五下、第十下的时候卡了，INP就会暴露出来。我的一个落地页FID 12ms（绿），INP却高达 340ms（红），因为页面里有个第三方聊天插件在后台吃主线程。

Google的标准：INP ≤ 200ms 及格，≤ 100ms 优秀，> 500ms 差。超过300ms基本就该动手优化了。

第一件事：找出谁在吃主线程

Chrome DevTools的Performance面板录一段操作，看Main线程的火焰图。我遇到最典型的三类问题：

一是Google Analytics和百度统计同时加载，两个脚本争主线程。解决方案是延迟加载（用requestIdleCallback包裹），或者只保留最需要的那一个。实际效果：INP从420ms降到180ms。

二是事件处理函数里做了重计算。比如一个搜索框的input事件里嵌了正则匹配+DOM更新，每次按键都触发。改成防抖300ms + Web Worker处理正则，INP从520ms降到了95ms。

三是没有用CSS containment。一个长列表页面，改了列表第一项的数据，浏览器却重排了整页。给列表容器加 contain: layout style 一行CSS，INP从290ms降到了130ms。

第二件事：拆长任务

浏览器主线程一次处理超过50ms的任务就会阻塞用户交互。用Performance面板看长任务（红色三角标记），然后拆：

原来一个初始化函数一次干了5件事（加载配置、请求数据、渲染图表、绑定事件、启动轮询），耗时180ms。拆成5个子任务，每个用setTimeout(fn, 0) 或在合适的时候用scheduler.postTask分开执行。改完后每个子任务不超过30ms，INP直接降了60%。

第三件事：注意第三方脚本

各类统计代码、客服插件、广告SDK是最容易被忽略的INP杀手。我的经验：第三方脚本用 async 加载，非关键的用 type="module" 推迟，实在绕不开的放Web Worker。最重要的一步——定期排查，看看有没有悄悄更新的SDK变重了。

检测工具

PageSpeed Insights现在直接显示INP数据（基于CrUX真实用户数据）。本地开发用Web Vitals扩展或者Lighthouse的Timespan模式录交互过程。上线后CrUX Dashboard免费，还能按设备拆开看。

标签： Core Web Vitals INP 网站优化 网页性能 SEO