术语表

什么是交互到下一次绘制（INP）？阈值和优化方法

交互到下一次绘制衡量页面对点击、轻触和按键做出可见响应的速度。阈值、一次慢交互的三个阶段，以及每个阶段的优化办法。

陈屿审核人林舟又称 INP 最后更新 2026 年 11 月 4 日术语表

在 TapCub 里哪里看

性能报表

打开对应报表免费开始

一句话回答

交互到下一次绘制（INP）是 Core Web Vitals 之一，衡量响应速度：从点击、轻触或按键到浏览器画出下一帧的时间，取接近整次访问里最慢的那次交互。不超过 200 毫秒算良好。

公式： 交互延迟 = 输入延迟 + 处理耗时 + 呈现延迟 · INP ≈ 整次访问里最慢的交互（每 50 次交互忽略 1 个异常值）

什么是交互到下一次绘制？

交互到下一次绘制（INP）衡量页面响应有多快。访问期间的每一次点击、轻触和按键，它都计时到屏幕出现可见变化为止。页面的 INP 接近这些交互里最慢的一次（交互多的页面，每 50 次忽略 1 个异常值）。它是三项 Core Web Vitals 之一，2024 年 3 月取代了首次输入延迟。

评级	INP
良好	不超过 200 毫秒
需改进	200–500 毫秒
较差	超过 500 毫秒

一次交互的三个阶段

阶段	发生了什么	优化
输入延迟	用户点击时主线程正忙着别的事	拆分长任务；推迟第三方脚本
处理耗时	运行你的事件处理函数	处理函数里少做事；不急的工作放到下一次绘制之后
呈现延迟	浏览器重新计算布局并绘制	更小的 DOM、一次少改几个元素、避免强制布局

一个示例筛选按钮

示例数据：商品列表页上点一下筛选，P75 要 510 毫秒：输入延迟 40 毫秒，处理 380 毫秒（处理函数筛选 2,000 个商品并重建整个列表），呈现 90 毫秒。

优化针对处理阶段：先更新按钮状态、显示加载提示，让出主线程让浏览器先画一帧，然后再筛选，并且只渲染前 40 个结果。新耗时：30 + 110 + 50 = 190 毫秒，达到良好。完整的工作照样要做，但用户马上就看到了响应。

常见错误

只在高配笔记本上测。 INP 问题多出现在中端手机上。
忽略第三方脚本。 标签管理器、客服插件和广告常常是输入延迟的来源。
看平均值。 INP 关注的是最慢的交互，要按页面看 P75。

在 TapCub 里看交互到下一次绘制

TapCub 用站点脚本从真实访问里采集 Web Vitals（第一个页面隐藏时上报一次；用 data-vitals="false" 关闭）。在网站统计 › 监测 › 性能里，卡片可在 P75、中位数、P95 和平均值之间切换，分组可按页面、设备、浏览器、国家和操作系统拆分，「最慢页面」按 P75 最大内容绘制排序。详见性能文档。

相关阅读：LCP、CLS、网站性能指标。

常见追问

大家看完定义后最常问的几个问题。

还有其他问题？

直接和 TapCub 团队聊聊——工作日通常几小时内回复。

在线咨询帮助中心

INP 多少算好？

按真实访问的 P75 计，不超过 200 毫秒算良好，超过 500 毫秒算较差，中间算需改进。

INP 和 FID 有什么区别？

首次输入延迟（FID）只量首次交互被处理前的等待时间。INP 覆盖每次交互，一直量到屏幕更新为止。2024 年 3 月起 INP 取代 FID 成为 Core Web Vitals。

滚动算 INP 吗？

不算。只算点击、轻触和键盘输入；滚动和悬停不算。

为什么有些页面没有 INP？

INP 至少需要一次交互。只阅读和滚动的访问没有 INP 值。

在你自己的网站上看这个数字

加一行脚本就能开始，网站和 App 都能接，几分钟内就能看到第一批报表。

免费开始打开对应报表