INP 偏高时如何定位长任务与交互延迟

INP 偏高时，不要先从代码库里随机寻找“看起来很重”的函数。更有效的顺序是：先用真实用户数据锁定慢交互的页面、目标元素和交互类型，再把延迟拆成 inputDelay、processingDuration、presentationDelay 三段，最后用 Long Animation Frames（LoAF）的脚本归因确认阻塞来自加载任务、事件处理器还是样式布局。这样才能把一个总分变成可修复的代码位置。

长任务只说明主线程被占用超过一定时间，并不自动等于 INP 根因。只有它与真实慢交互的时间窗口、阶段和脚本归因对上，才值得优先处理。

INP 官方说明：https://web.dev/articles/inp

现场定位指南：https://web.dev/articles/find-slow-interactions-in-the-field

背景：我曾经把所有红色长任务都当成根因

一次列表筛选页面的 INP 变差后，我最初只在实验室录制性能轨迹，看到一串超过 50 毫秒的长任务，就开始拆包和延迟加载。包体确实变小了，但现场 INP 几乎没有变化。后来把真实用户的慢交互按目标元素归类，才发现最差样本来自“保存筛选条件”按钮，而且主要耗时落在下一帧呈现，不是页面启动阶段的脚本解析。

这次经历让我不再把 INP 当作“JavaScript 执行时间的另一个名字”。官方定义里，交互延迟从用户开始点击、轻触或按键，一直覆盖到浏览器能够呈现下一帧。它既可能在事件处理器开始前被别的任务拖住，也可能在处理器结束后被样式计算和布局拖住。

旧排查方式的问题：总分、TBT 和任意长任务都不够具体

CrUX 或 PageSpeed Insights 能告诉你页面或整个来源的 INP 是否存在问题，但不能告诉你是哪一次交互造成的。实验室里的 Total Blocking Time 可以作为线索，却不是 INP 的替代指标；没有真实点击、轻触或键盘操作的加载测试，甚至不会产生有代表性的 INP。

长任务的定义也比 INP 简单得多。主线程一次只能处理一个任务，超过 50 毫秒的任务被视为长任务，超出 50 毫秒的部分称为阻塞时间。它可能延迟用户输入，也可能发生在用户没有交互的时候。只按“最长任务”排序，会把很多与差 INP 无关的后台工作排到前面。

新语义：先判断慢在哪一段

web.dev 将一次交互拆成三个可操作的阶段。把这三个值和交互目标放在一起看，定位方向会清晰很多：

INP 观察页面生命周期中的点击、轻触和键盘交互。官方当前建议在移动端和桌面端分别看第 75 百分位：不高于 200 毫秒为良好，超过 200 且不高于 500 毫秒需要改进，超过 500 毫秒较差。这些阈值用于判断体验，不应该直接替代对交互阶段的诊断。

代码对比：从只上报分数改为上报归因字段

标准版 web-vitals 可以上报 INP 值和评级，归因版本还会提供目标元素、交互类型、三段延迟以及与交互关联的 LoAF 条目。下面的采集只保留排查所需字段，并通过 Beacon 在页面后台化或离开时可靠发送。

import {onINP} from 'web-vitals/attribution';

onINP(({value, rating, attribution}) => {
  const {
    interactionTarget,
    interactionType,
    inputDelay,
    processingDuration,
    presentationDelay,
    longAnimationFrameEntries,
  } = attribution;

  const relatedFrame = longAnimationFrameEntries?.at(-1);
  const longestScript = relatedFrame?.scripts
    ?.toSorted((a, b) => b.duration - a.duration)[0];

  const payload = {
    metric: 'INP',
    value,
    rating,
    route: location.pathname, // 不上传查询串，减少敏感信息与高基数标签
    target: interactionTarget,
    type: interactionType,
    phases: {
      inputDelay,
      processingDuration,
      presentationDelay,
    },
    script: longestScript ? {
      invokerType: longestScript.invokerType,
      sourceURL: longestScript.sourceURL,
      sourceFunctionName: longestScript.sourceFunctionName,
    } : null,
  };

  const body = new Blob([JSON.stringify(payload)], {
    type: 'application/json', // Beacon 使用明确内容类型提交采样数据
  });
  navigator.sendBeacon('/rum/inp', body);
});

这里没有把整个 attribution 对象原样上传，是因为现场数据要控制体积、隐私和维度数量。建议对样本采样，限制 sourceURL 到站内脚本，并避免上传输入值、文本内容、用户标识和完整 URL。interactionTarget 是 CSS 选择器，也应在服务端做长度和基数限制。

用 LoAF 把延迟连接到具体脚本

从 web-vitals 4 开始，归因版本可提供三段延迟以及关联的 longAnimationFrameEntries。LoAF 条目中的 duration、blockingDuration、renderStart、styleAndLayoutStart 和 scripts，可以帮助判断一帧里是脚本、渲染还是布局占了主要时间。

其中 scripts 尤其有用。它可以给出调用来源 invoker、调用类型 invokerType、脚本地址、字符位置和函数名。官方示例列出的调用类型包括事件监听器、定时回调、Promise 兑现或拒绝，以及经典脚本和模块脚本。把这些字段与三段延迟组合后，可以形成比较稳定的判断：

• 高 inputDelay 加 classic-script 或 module-script，优先检查页面加载期的编译、求值和初始化任务；
• 高 inputDelay 加 user-callback，优先检查定时器或 requestAnimationFrame 周期工作；
• 高 processingDuration 加 event-listener，优先进入对应事件处理函数；
• 高 presentationDelay 且 styleAndLayoutStart 后占用明显，优先检查 DOM 规模、样式计算和布局。

兼容注意：现场和实验室要各做一半工作

LoAF 的浏览器支持并不完全一致，归因字段也会受到 API 可用性影响。因此采集端要允许 longAnimationFrameEntries 为空，不能因为没有脚本归因就丢弃整个 INP 样本。基础的目标元素、交互类型和三段延迟仍然可以帮助缩小范围。

真实用户数据用于回答“哪个页面、哪类设备、哪个目标元素最慢”，实验室工具用于回答“这段代码为什么慢”。复现时应模拟现场常见设备能力、页面加载状态和操作路径，而不是只在高性能电脑上等待页面完全空闲后点击一次。若慢交互集中发生在加载期，还要在主线程最忙时执行相同操作。

iframe 也是一个常见差异来源。顶层页面的用户体验会受到 iframe 内交互影响，但普通页面脚本无法直接读取跨源 iframe 内部的 Event Timing 细节，这可能造成 CrUX 与自建 RUM 的差异。遇到这类差异时，先确认组件边界，不要把缺失归因当作“没有问题”。

采用建议：证据指向哪一段，就优化哪一段

如果输入延迟高，先减少加载期和周期性主线程工作，拆分长任务，并延后非必要脚本。若处理时长高，缩短事件处理器同步路径，把大循环分块，把不影响首帧反馈的工作推迟到后续任务；主线程一次只能执行一个任务，拆开后才能给更高优先级的交互留出机会。

若呈现延迟高，继续删 JavaScript 往往不是第一选择。应检查大 DOM、复杂选择器、强制同步布局以及一次交互触发的大范围渲染。先让界面尽快呈现可见反馈，再异步完成网络请求和次要更新，因为 INP 衡量的是下一帧是否及时出现，而不是所有异步业务最终完成的时间。

最后把现场指标按页面类型、设备类别和交互目标聚合，并持续观察第 75 百分位。一次实验室优化通过不代表现场已经改善；只有同一类真实交互的三段延迟和整体 INP 一起下降，才算真正闭环。

相关问题

长任务一定会导致 INP 变差吗？ 不一定。只有它阻塞了真实交互或下一帧呈现，才会成为该交互的关键原因。

TBT 能代替 INP 吗？ 不能。TBT 可作为实验室线索，但 INP 覆盖真实页面生命周期中的交互延迟。

为什么 PageSpeed Insights 只能看到分数，找不到按钮？ CrUX 主要告诉你页面或来源是否有问题；要定位目标元素和阶段，需要 RUM 或 web-vitals attribution 数据。

应该先拆包还是先优化事件处理器？ 先看哪一段延迟最高。加载期输入延迟高时拆包更可能有效，处理时长高时应优先进入对应事件处理函数。