决定 INP 高低的，从来不是页面"平均有多快"，而是最慢的那一次交互卡在了哪一段。这是 INP 与前一代指标最本质的差别：它不取平均，也不只看第一次操作，而是把整段访问里最差的那次交互拿出来当代表值。web.dev 的 INP 指标说明把这件事写在最前面，理解了这一点，后面的排查顺序才不会跑偏。 要继续分辨第三方资源还是主题脚本拖慢交互，可以按WordPress 内联脚本的交互排查拆开看。
INP 记的是最慢的那一次
页面上的点击、点按、按键会被归成"交互"，每次交互取其中耗时最长的那个事件作为这次交互的延迟。整页的 INP 是这些交互里最慢的一个（交互特别多的页面会按每 50 次交互忽略一次最高值，再取第 75 百分位）。只有鼠标点击、触屏点按、键盘按键三类被计入；滚动、悬停、缩放一律不算。所以一个"看起来很卡"的页面，如果卡的是滚动体感，INP 可能完全不反映。
还有一个必须记住的边界：如果访客只滚动、只悬停、或者是被搜索引擎爬虫访问，页面可能根本没有 INP 值。数据缺失不等于表现好，也不等于表现差。
一次交互拆成三个时间块
web.dev 的 INP 指标说明在"一次交互里包含什么"那一节把延迟拆成三段，三段相加就是这次交互的总延迟：
- 输入延迟：从用户动手到事件回调开始跑之间的时间。主线程正忙着别的事时，这段最长。
- 处理时长：事件回调本身跑完所需的时间。回调里写了多少重活，就在这段体现。
- 呈现延迟：回调跑完到浏览器把下一帧画出来之间的时间。样式计算、布局、绘制都算在这里。
注意 INP 量的不是"请求发出去多久、数据回来多久"，而是下一帧被画出来的那一刻。一个请求要跑 800 毫秒，但只要在 60 毫秒内先给了一次视觉反馈，INP 就不会把 800 毫秒算进去。这解释了为什么"加个加载提示"有时比"优化接口"更有效。
三段各自的成因与线索
| 时间块 | 典型成因 | 判断线索 |
|---|---|---|
| 输入延迟 | 主线程被长任务占住：脚本下载、解析、编译，或多个操作挤在一起 | 录一次交互过程，看点击后到界面有反应之间有没有大段空白 |
| 处理时长 | 事件回调里做了大量计算、同步 DOM 操作 | 把回调里的逻辑拆开看，耗时集中在哪一段 |
| 呈现延迟 | DOM 过大、样式计算复杂，或者先改样式又立刻读样式导致浏览器被迫同步做布局 | 录一次性能追踪，看布局与样式计算是否和脚本交替出现 |
三段都可能同时变差，但同一页通常只有一段是主因。判断主因时优先看输入延迟：它最长，说明主线程在等；它最短而呈现延迟最长，说明问题在渲染而不在脚本。
怎么按段排查
- 先列出这个模板上真实会发生的交互：菜单展开、搜索框输入、加入购物车、表单校验，只留访客真会做的。
- 在页面还在加载时就点一遍——主线程最忙的时段，问题最容易复现。
- 逐个交互测三段，找出最长的一段作为这轮的唯一目标。
- 针对输入延迟：拆分长任务、把非关键工作让出主线程、删掉页面上用不到却一直在跑的代码。
- 针对处理时长：把回调里与界面无关的逻辑挪出交互路径。
- 针对呈现延迟：压小 DOM、减少样式规则、消除先写后读的强制同步布局。
- 改完把同一批交互重测一遍，看三段里最长的是不是换成了别的那段。
哪些插件会在前台持续占用主线程，站内旧文哪些插件会拖慢速度里按类型列过；工具类插件的选择边界见SEO 与性能优化的 10 款工具用途与选型注意事项。
什么时候先别追 INP
三类页面可以先放一放。一是几乎没有交互的页面，比如纯图文归档和静态落地页，采集不到有效输入，硬优化没有对象。二是访客主要在移动端用数据网络打开，而你的测试环境是插着网线的桌面机，实验室里怎么点都点不出真实输入延迟——这种情况应该先看真实数据而不是继续在本地调。三是交互本身就是重活，比如在线编辑器、复杂表单校验工具，延迟有相当一部分是业务逻辑本身带来的，改前端只能压缩不能消除。
另外要清楚 web.dev 的 Web Vitals 说明的口径：INP 在 200 毫秒或更低算好，按第 75 百分位、移动与桌面分开衡量；Lighthouse 这类实验室工具测不出 INP，只能用 TBT 作代理。TBT 变好通常会带动 INP，但它是代理，不是替代品，官方也没有公布它与排名位置的换算关系。
怎么确认改善是真的
验证要按同样的交互清单做前后对照，而不是凭手感。改之前先把每个交互的三段数值记下来，改之后在同样条件下重测：如果最长的一段明显变短、且没有把负担转移到另一段上，才算这一步有效。真实数据那侧要看 URL 分组里这一组的状态变化，并确认移动和桌面两端方向一致。如果本地三段都很好而真实数据没动，多半是访客的设备与网络条件比实验室苛刻得多，这时候该换思路而不是继续加码。
