Event Timing API是监控输入响应延迟的核心方案，它量化用户操作到界面反馈的完整耗时，包含JS执行、样式计算、布局、绘制与合成，duration>100ms即可能造成可感知卡顿。
在复杂交互中监控输入响应延迟，核心是把“用户按下键/点击/滚动”到“界面可视反馈出现”之间的耗时量化出来，而不是只看 JS 执行时间。浏览器的 Event Timing API 是目前最直接、最贴近真实体验的方案，它原生捕获用户输入事件从触发到渲染完成的完整链路。
用 Event Timing API 捕获关键延迟指标
该 API 会自动记录 click、keydown、scroll、input 等事件的处理耗时，并包含是否导致长任务、是否阻塞渲染等上下文：
- 启用方式只需一行代码：
new PerformanceObserver(cb).observe({ type: 'event', buffered: true }) - 重点关注
processingStart（事件开始处理）与processingEnd（JS 处理结束）之差，即纯 JS 响应耗时 - 更关键的是
duration字段——它涵盖 JS 执行 + 样式计算 + 布局 + 绘制 + 合成，代表用户真正感知的“卡顿”长度 - 若
duration > 100ms，大概率已超出用户可接受的响应阈值（RUM 中常设为 50ms 或 100ms 预警线）
结合 Long Tasks 监控主线程阻塞源头
输入延迟高，往往不是因为单个函数慢，而是主线程被其他长任务持续占满。仅看事件本身会漏掉“隔壁代码正在吃资源”的真相：
- 用
PerformanceObserver监听longtask类型，获取阻塞时长、起始时间、关联的 iframe 或脚本 URL - 将 Long Task 的时间窗口与同一时刻的输入事件（如
keydown）做时间对齐，就能定位“是谁拖慢了输入” - 特别注意第三方 SDK（统计、广告、客服插件）常引入隐蔽长任务，它们可能在用户聚焦输入框时悄悄执行
模拟真实操作路径，注入可控埋点
自动化工具或 RUM 系统难以覆盖所有分支逻辑，对关键路径（如表单提交前的校验链、富文本编辑器中的快捷键组合）需主动打点：
立即学习“Java免费学习笔记（深入）”；
- 在事件监听器入口用
performance.mark('input_start')，在视图更新完成（如requestAnimationFrame回调里）打performance.mark('input_rendered') - 用
performance.measure计算二者间隔，上报时带上操作类型（ctrl+z、enter_submit）、字段名、当前焦点元素 - 避免在高频事件（如
input）中每轮都打点，可采样或仅对异常延迟（如 >200ms）上报
排查常见干扰项，排除误判
响应延迟高不等于 JS 写得差，需先排除环境与配置干扰：
- 确认未开启 Chrome 的“Slow 3G”或 CPU 节流（DevTools → ⚙️ → Preferences → Network / Performance）
- 检查是否启用了大量 DevTools 面板（如 React/Vue 插件），它们本身会显著增加事件处理开销
- 验证页面是否运行在 iframe 中且跨域，部分性能 API 在受限上下文中不可用或数据不全
- 留意防抖/节流设置是否过严——比如搜索框输入防抖设为 500ms，用户连续输入时会感觉“按了没反应”
