使用PerformanceObserver捕获交互到下次渲染INP定位UI延迟

通过 PerformanceObserver 直接获取“交互到下次渲染 (INP)”指标是完全可行的，但并非一个“一键获取”的简单操作。你需要组合监听特定的事件类型，进行后续的数据聚合与计算，并常常需要关联“长任务”来定位导致卡顿的根本原因。

必须启用 Event Timing API 并监听 event 类型

INP 指标的核心数据来源于 Event Timing API。浏览器通过 type: ‘event’ 的 PerformanceEventTiming 条目暴露每次交互的耗时细节。关键在于，你需要在页面生命周期的早期（例如，在 标签内的同步脚本中）就注册好 PerformanceObserver，并开启 buffered: true 选项。此举可确保捕获到观察器注册之前已发生的用户交互，比如页面加载初期的点击或键盘输入。

• 建议调用 performance.setResourceTimingBufferSize(200) 来适当提升性能条目的缓冲容量。
• 在初始化观察器前，先通过 ‘PerformanceEventTiming’ in window 检查 API 支持情况。
• 获取到的 entry.duration 值，代表了该次交互从事件触发到浏览器下一帧渲染完成的总耗时，其中涵盖输入延迟、处理延迟和呈现延迟。

深入理解 duration 值的实际含义

entry.duration 是一个综合性指标，虽不分解交互各阶段，但能直观反映页面响应健康程度：

• < 1ms：通常表示交互未阻塞主线程或未触发重绘，可暂时忽略。
• ≥ 50ms：极有可能存在长任务、强制同步布局或大量样式计算，这类情况需要重点关注。
• 需要明确的是，单次高 duration 值并不等同于 INP。INP 定义为页面生命周期内所有有效交互耗时的第98百分位值。因此，你必须累积足够数量的交互数据（通常数十次）之后，才能进行有意义的统计。

手动聚合近似 INP 值并上报

实际上，官方 web-vitals JavaScript 库内部正是采用此逻辑。你也可以自行实现一个轻量级聚合逻辑：

• 声明一个数组，例如 const inpCandidates = []，每次观察器收到 entry.duration > 0 的条目时，将其推入数组。
• 为这个数组设置长度限制（比如最多存储100个值），以防止内存无限增长。
• 在页面卸载前（beforeunload 事件），或设定定时器（例如每30秒），对数组进行排序，然后取 Math.floor(数组长度 * 0.98) 索引位置的值，作为当前页面 INP 估算值进行上报。

结合 longtask 定位 UI 卡顿根源

当发现某次交互的 duration 值异常偏高时，下一步应同步检查同一时间段内是否有“长任务”发生，以定位卡顿根源：

• 使用另一个 PerformanceObserver 监听 type: ‘longtask’（阈值通常设为 ≥100ms）。
• 比对时间戳：如果某个长任务的 startTime 与高耗时交互事件的持续时间高度重叠，那么基本可以断定，主线程被该长任务阻塞，导致交互响应缓慢。
• 常见诱因包括：未进行节流处理的 resize/scroll 事件监听器、嵌套的布局抖动，以及同步的 DOM 查询与修改循环。