定位交互响应缓慢瓶颈的关键是监测主线程占用时长，尤其是超50ms的long task；利用PerformanceObserver监听longtask、event、paint等条目，结合performance.mark()打点与DevTools分析调度延迟及瓶颈类型。
识别导致交互响应缓慢的瓶颈代码，关键不是测函数执行多久，而是看主线程被占用了多长时间——尤其是那些超过 50ms 的“长任务”（long task）。HTML5 提供的 Performance API 不是计时器，而是浏览器运行时的真实调度记录仪。
监听 longtask 定位阻塞代码块
Chrome 和 Edge 将单次执行超 50ms 的任务标记为 longtask，它直接导致点击无响应、滚动掉帧。PerformanceObserver 可实时捕获这些任务，并给出精确起始时间与持续时长：
- 创建 observer 并监听 entryTypes: ['longtask']
- 每个 entry 包含 startTime 和 duration，可精确定位卡顿发生时刻
- 配合 performance.mark() 打点用户操作（如点击前打
click-start），就能判断“某次点击后是否立刻触发了长任务”
用 event 类型分析真实输入延迟
FID（首次输入延迟）已由 event 类型条目替代。监听 pointerdown 或 click 事件，查看 processingStart - startTime 的差值：
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 若该差值 >100ms，说明用户操作发出后，主线程仍在处理前序任务，尚未开始响应
- 结合 DevTools 的 Event Log 面板，可进一步定位到具体调用栈中的函数
- 注意：duration 字段只反映回调执行耗时，不能代表 FID；必须手动计算排队时间
联动 paint/navigation/resource 判断瓶颈类型
知道“卡”还不够，要分清卡在哪儿：
立即学习“前端免费学习笔记（深入）”；
- 若 largest-contentful-paint 延迟高，且 Main 线程上 Layout/Recalculate Style 占比大 → 重排重绘瓶颈
- 若 navigation 条目中 domContentLoadedTime 与 loadEventEnd 时间差大 → 资源加载或脚本阻塞
- 若 resource 条目显示某 JS/CSS 加载耗时长，且后续 longtask 集中出现 → 脚本解析执行拖慢主线程
别只信 console.time，要测调度延迟
performance.now() 测的是代码运行耗时，不是主线程可用性。一个 3ms 的函数，可能因触发强制同步布局（如读取 offsetTop 后立即设置 style）让后续任务排队 200ms：
- 在操作前后用 performance.mark('start') 和 performance.mark('end')
- 再用 performance.getEntriesByName('start')[0].startTime 与 getEntriesByName('end')[0].startTime 相减，得到实际调度间隔
- 若该间隔远大于函数内部耗时，说明中间存在排队 —— 这才是真正需要优化的瓶颈
