INP 是 Core Web Vitals 里最容易被误解的指标，因为它不像 LCP 那样有一个"看得见的元素"。下面是我们被客户问得最多的八个问题，答案尽量短。
定义和阈值
Q：INP 到底测什么？
用户每次交互（点击、按键、触摸）到浏览器画出下一帧的延迟，取整个会话里偏差最大的那次作为分数。它衡量页面响应快不快。
Q：多少算合格？
低于 200 毫秒算好，200 到 500 毫秒需要改进，超过 500 毫秒算差。和 LCP 一样，要求 75% 的用户访问达标。
Q：它和 FID 什么关系？
FID 是旧指标，2024 年 3 月被 INP 替代。FID 只看第一次输入，而且只算输入延迟不算渲染，所以经常一片绿。INP 看所有交互，包含处理耗时和下一帧渲染耗时，严格得多。
怎么测
Q：为什么 PageSpeed 测出来和客户说的不一样？
PageSpeed 的 INP 是实验室模拟，很多交互它触发不了，有时直接显示无数据。要看真实情况，用 GSC 的 Core Web Vitals 报告或 CrUX。
Q：移动端为什么普遍比桌面差？
CPU 性能差，加上主线程任务没有为低端机优化。同一段 JS 在开发机上 30 毫秒，在四年前的中端安卓上就是 200 毫秒。
Q：有没有必要自己搭 RUM？
访问量超过每天一千就建议搭。web-vitals 库加一个上报接口，半天能上线。实验室数据只能定位方向，验收必须靠自己的真实数据。
怎么改
Q：改哪里收益最大？
按我们的经验排序：去掉事件处理器里的同步重活、列表虚拟化、第三方脚本延后、减少首屏水合。这四项能覆盖大多数站。
Q：加服务器有用吗？
基本没用。INP 是浏览器主线程的问题，服务器再快，JS 还是要在用户设备上跑。带宽和机器解决 LCP 和 TTFB，解决不了交互。
Q：改完多久能看到指标变化？
真实用户数据一般要两到四周才稳定。INP 取的是偏差最大的那次交互，样本量不够的时候波动很大。我们有个客户改完第三天看数据反而变差了，第二周才回落到 180 毫秒。别用三天的数据下结论。
Q：能不能只改最慢的那个交互？
可以，而且往往是性价比最高的做法。INP 的分数由少数极差交互决定，修好 P95 那一个交互，整站分数就能上一个台阶。前提是你得先知道是哪一个，这就要有能归因到元素的 RUM。
补一句
INP 有个天然缺陷：它只统计交互延迟，不统计"用户想点但没有可点元素"的时间。按钮灰着、加载中不能操作，这些体验问题不会进 INP。所以别把 INP 当体验的全部，它只是一个及格线。
我们的做法是把 INP 和两个自建指标放一起看：首次可交互时间、关键操作完成时间。三个数一起看，才不容易被漂亮的单项分数骗过去。
元析智能
为软件公司做 SEO 和 GEO 优化