测量宏任务间隔即事件循环延迟,用settimeout(0)结合performance.now()获取调度延迟,≥4ms属正常;持续>10ms提示主线程压力;配合mark/measure、周期采样与long tasks api可精准评估ui响应健康度。

要测量宏任务之间的间隔,本质是测事件循环中“上一个宏任务结束”到“下一个宏任务开始执行”之间的时间差——这个空隙反映主线程是否被长时间占用,也叫事件循环延迟(Event Loop Latency)。
用 setTimeout 捕捉调度延迟
这是最常用、最贴近真实场景的方式。核心思路:把一个微延迟任务(setTimeout(fn, 0))提交进队列,它实际执行时刻与提交时刻的差值,就是这段时间内事件循环被阻塞的时长。
- 调用
performance.now()记录提交时间 - 在
setTimeout回调里再次调用performance.now() - 两者相减即为该次调度的实际延迟(单位:毫秒)
示例:
function measureLatency() {
const start = performance.now();
setTimeout(() => {
const end = performance.now();
console.log(`本次事件循环延迟:${(end - start).toFixed(2)} ms`);
}, 0);
}注意:浏览器对 setTimeout(0) 有最小延迟限制(通常 ≥4ms),所以测得值 ≥4ms 是正常的;若持续远高于 10ms,说明主线程存在长任务或频繁渲染压力。
结合 mark/measure 追踪关键宏任务边界
如果想测特定两个宏任务(比如一次点击和后续的渲染完成)之间的间隔,需手动打点:
- 在第一个宏任务入口处(如
click事件回调开头)调用performance.mark('task-start') - 在第二个宏任务可确认的终点(如
requestAnimationFrame回调、或 DOM 更新后setTimeout)调用performance.mark('task-end') - 再用
performance.measure('gap', 'task-start', 'task-end')
这样得到的 duration 就是这两个宏任务触发点之间的真实时间跨度,包含中间所有微任务、渲染、以及可能的空闲期。
周期性采样,识别趋势而非单点
单次测量意义有限。建议以固定频率(如每秒 1–2 次)调用延迟测量,并聚合统计:
- 记录 p50、p95、最大值,观察延迟分布
- 当连续多次 >16ms(即掉帧阈值),可预警 UI 响应卡顿风险
- 配合
Long Tasks API(performance.getEntriesByType('longtask'))交叉验证
这种“心跳式”采样能更可靠地反映事件循环健康度,而不是被某次偶然抖动误导。
避免常见干扰
测量结果容易失真,需注意:
- 不要在同步长任务(如大数组遍历、复杂计算)内部测延迟——此时事件循环已被锁死,测出来的是任务本身耗时,不是空隙
- 避免在同一个 JS tick 内重复使用相同 mark 名,否则会被覆盖
- DevTools 的 Performance 面板开启「User Timing」轨道,可直观看到 mark 和 measure 标记,辅助调试
不复杂但容易忽略。











