Web 性能指标 INP 详解与优化实战

INP（Interaction to Next Paint）已取代 FID，成为衡量交互响应性的核心 Web 指标。它更真实地反映用户「点击后页面多久有响应」的体验。

为什么 FID 不够

FID 只测第一次交互的输入延迟，忽略后续交互，也忽略输入后的处理耗时。INP 则统计用户整个页面生命周期内所有交互，取接近最差的那一次（约第 75 百分位）作为分数。

INP 关注从用户输入到下一次绘制的完整延迟，由三部分组成：输入延迟、处理时间、呈现延迟。

常见瓶颈

INP 偏高的原因通常有：

1. 主线程长任务：大型计算、渲染阻塞了事件处理；
2. 昂贵的处理函数：事件回调里做了重活；
3. 强制同步布局：读布局又改布局，触发回流。

优化策略

拆分长任务

用 scheduler.yield() 或 setTimeout 把长任务切成小块，让主线程有机会响应交互。

async function process(items) {
  for (const item of items) {
    handle(item);
    if (shouldYield()) await scheduler.yield();
  }
}

降低事件回调开销

• 用 useDeferredValue/useTransition 把非紧急更新降级；
• 对高频事件（输入、滚动）做节流或防抖；
• 避免在回调里做同步的 DOM 读写交错。

减少呈现延迟

让交互触发的 UI 变化走合成路径，只用 transform/opacity，避免布局抖动。

测量与监控

用 PerformanceObserver 监听 event 与 longtask，或用 Web Vitals 库自动采集，把 INP 纳入监控看板。

结语

INP 把「交互响应」这件事从「有没有响应」提升到「响应得快不快」。优化 INP 的核心，始终是让主线程保持空闲、可及时响应。