INP

INP（Interaction to Next Paint，下次绘制交互）是衡量页面可交互性的指标，记录用户点击、点按或按键之后，页面到下一次绘制之间的延迟^[1]。它在 2024 年 3 月取代首次输入延迟（FID），成为核心网页指标的一项，量的是整次访问里所有交互的响应情况^[2]。INP 偏高时，用户点按钮没有立刻反应，会以为页面卡住；它只存在于真实用户的浏览器里，不影响抓取，却进入页面体验的排序参考^[4]。

计量的交互

INP 只统计点击、点按和键盘输入。滚动与悬停不计入，因为这两类延迟由浏览器的合成线程处理，不反映主线程的忙碌程度^[4]。

每一次交互被拆成三段：输入延迟、处理用时、呈现延迟^[4]。输入延迟是主线程腾出手来之前等待的时间，处理用时是事件回调的执行时间，呈现延迟是回调结束到画面刷新的间隔。

整页的 INP 取哪一次交互，与交互次数有关。交互较少时取最慢的那一次，交互很多时改用接近第 98 百分位的取值，把偶发的一次排除掉^[4]。

及格线与评级

Google 把 INP 分成三档，取值同样按第 75 百分位计算^[2]：

评级	第 75 百分位取值
良好	200 毫秒以内
需要改进	超过 200 毫秒，不超过 500 毫秒
差	超过 500 毫秒

超出及格线的影响

没通过的页面会显示在 Search Console 里，站长能按网址分组查看^[2]。用户侧的损失是操作没有反馈：填表、加购、切标签这类动作延迟明显时，用户会重复点击或者直接离开。INP 属于页面体验相关的排序参考，不单独决定名次^[2]。

常见成因

• 输入延迟高：主线程被长任务占住，事件排在后面才被处理；
• 处理用时高：事件回调里做了大量计算，或者发起了同步请求；
• 呈现延迟高：DOM 规模过大，或者样式改动触发了整个页面的重新布局。

第三方脚本是常见的来源。统计、广告、客服这类代码在页面上运行，会与自家代码争抢主线程^[4]。

改善办法

1. 把长任务拆成小段，每段结束交还主线程，让浏览器先处理用户的输入；
2. 把纯计算搬进 Web Worker；
3. 把非关键脚本改成 defer，或者等页面空闲后再加载；
4. 缩小 DOM，避免在循环里读取布局信息；
5. 屏幕外的内容用 content-visibility 暂缓渲染。

// 长任务切成两段，中间交还主线程，用户输入才能插进来
async function handleClick() {
  renderFirstPart();
  await scheduler.yield();
  renderSecondPart();
}

改动带来的代价

拆分任务会让代码变复杂，状态跨段维护容易出错。Web Worker 与主线程通信有序列化成本，适合计算量大的场景，不适合频繁的小任务。把脚本推迟到空闲时执行，会改变统计上报的时点，报表里的事件时间可能整体后移。

与抓取和收录的关系

INP 在用户交互时产生，爬虫不会点击按钮，所以它不进入抓取与收录的判断。百度把搜索分成抓取、建立索引、展现三步^[3]，这三步都发生在服务器与应用侧。INP 影响的是用户操作的响应，以及页面体验这一路的排序参考。

附录

参见

• LCP
• CLS
• 第三方脚本
• 首屏加载

参考资料

官方（境外）

1. 《PerformanceEventTiming》，MDN Web Docs。
2. 《Interaction to Next Paint (INP)》，web.dev，2025-09-02 更新。

官方（国内）

3. 《百度搜索的工作原理》，百度搜索资源平台，2023-12-21 更新。

第三方

4. 《Interaction to Next Paint (INP)》，corewebvitals.io，2026-03-03 更新。

外部链接

无。