必须在<head>内联脚本中注册带buffered:true的PerformanceObserver监听input、keydown、compositionend、blur、selectionchange事件，过滤entry.name==='input'&&entry.duration>0，并配合performance.mark打点、longtask对齐及同步视觉补偿。
监听 event 类型并过滤编辑器相关操作
HTML 编辑器的关键交互（如 input、keydown、compositionend、blur）会生成 event 类型的 PerformanceEventTiming 条目，但必须显式启用监听且带 buffered: true，否则注册前的输入就彻底丢失。
常见错误是只监听 click 或漏掉中文输入法场景 —— compositionend 才是用户真正完成一次中文输入的信号，而 input 在拼音过程中会高频触发，干扰判断。
- 必须在
<head>内联脚本中注册，不能等DOMContentLoaded；否则首段编辑操作永远捕获不到 - 过滤条件要具体：
entry.name === 'input' && entry.duration > 0，排除合成阶段的无效条目 - 对富文本编辑器（如
contenteditable），额外监听selectionchange，它反映光标移动或选区变化，也是关键响应点
用 performance.mark 标记编辑器状态变更点
PerformanceObserver 提供的是“事件发生时的耗时”，但编辑器内部状态流转（如从空内容 → 插入图片 → 渲染完成）需要你主动打点才能对齐。单纯依赖 event.duration 无法区分是 JS 处理慢，还是后续 DOM 更新/布局/绘制拖了后腿。
比如用户粘贴一段 Markdown 后，paste 事件的 duration 可能只有 12ms，但实际页面卡顿发生在解析 + 渲染后的第 3 帧 —— 这时候不打点就完全看不到瓶颈在哪。
立即学习“前端免费学习笔记（深入）”；
- 在
beforeinput回调开头打performance.mark('editor-beforeinput-start') - 在编辑器内部完成 DOM 更新、样式应用后（例如
requestAnimationFrame回调里），立即打performance.mark('editor-render-ready') - 避免在打点前后读取
offsetHeight或getBoundingClientRect()，否则会意外触发同步 layout，污染测量结果
关联 longtask 定位阻塞源头
编辑器卡顿往往不是单次操作慢，而是被某个长任务“拦腰截断”。event.duration 高，大概率意味着该事件处理期间主线程正被另一个 >50ms 的任务霸占 —— 比如语法高亮扫描、实时预览渲染、或未拆分的大型插件初始化。
仅看 event 条目只能知道“卡了”，结合 longtask 才能定位“谁干的”。但注意：longtask 不提供函数名，需靠时间戳对齐。
- 在用户聚焦编辑器时打
performance.mark('editor-focused')，再监听longtask条目是否在之后 100ms 内出现 - Chrome DevTools 的 Performance 面板录制 + 筛选
Long Tasks轨道，直接看到对应 JS 文件和调用栈（比纯代码监控更准） - 若发现长任务总出现在
highlight.js或prism.js执行阶段，说明高亮逻辑未做分块或懒加载
上报与视觉补偿必须同步执行
不能等 PerformanceObserver 回调收到 event 条目后再决定是否加 loading 动画 —— 它的回调是微任务，可能比用户感知延迟晚 30~60ms，此时按钮已灰掉、骨架屏已闪现，体验反而更差。
真实可用的补偿逻辑，必须在事件处理函数内部就判断并执行，performance.measure() 只用于事后归因和上报，不用于实时决策。
- 在
input或keydown回调里，用performance.now()记录开始时间，逻辑结束后立刻计算耗时，超阈值（如 100ms）就同步禁用输入框、显示throttling状态 - 上报用
navigator.sendBeacon()，字段至少包含：type: 'editor-input-delay'、duration、target: event.target.tagName、isComposition: !!event.isComposing - 移动端尤其要注意：
textInput事件在 iOS Safari 中不可靠，优先依赖input+compositionend组合判断
