通过 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 查询与修改循环。
