Chrome DevTools 如何分析 JavaScript 执行耗时

Chrome DevTools Performance面板可精准分析JS执行耗时：录制操作后查看Main线程Scripting黄色区块（≥50ms为长任务），结合FPS曲线、帧详情及Memory面板的堆快照与GC分析，多维度定位瓶颈。

直接用 Chrome DevTools 的 Performance 面板就能精准看出 JavaScript 执行耗时，不需要额外插件或代码。

打开 Performance 面板并录制操作

按 F12 或 Ctrl+Shift+I（Win）/Cmd+Option+I（Mac） 打开开发者工具，切换到 Performance 标签页。点击顶部的红色圆点按钮开始录制，然后在页面上执行你想分析的操作（比如点击按钮、滚动、加载数据），再点停止按钮。DevTools 会生成一份完整的性能快照。

重点看 Main 线程上的 Scripting 时间

录制完成后，时间轴下方默认显示 Main 线程活动。黄色区块代表 JavaScript 执行（Scripting），宽度越宽说明耗时越长：

• 找连续超过 50ms 的黄色块——这就是“长任务”，会阻塞页面响应
• 把鼠标悬停在某一块上，能看到具体函数名和耗时（例如 handleSearch()：42.6ms）
• 点击该区块，在下方 Bottom-Up 或 Call Tree 视图里，能看清是哪个函数调用链占了最多时间

结合 FPS 和帧详情定位卡顿根源

顶部有 FPS 曲线图，绿色表示流畅（≈60 FPS），出现红色三角说明掉帧。点击某帧，展开它的详细处理过程：

立即学习“Java免费学习笔记（深入）”；

• 如果一帧里 Scripting 时间远超 16ms（60fps 预算），就说明 JS 拖慢了渲染
• 注意是否同时触发了大量 Layout（紫色）或 Paint（绿色）——可能是 JS 修改了样式却没批量处理，导致反复回流重绘
• 对比“Scripting”和“Rendering”占比，判断瓶颈是纯计算问题，还是 DOM 操作引发的连锁反应

用 Memory 面板辅助排查隐性耗时

有些 JS 耗时高不是因为逻辑慢，而是内存压力大，触发频繁垃圾回收（GC）。在 Memory 面板中：

• 选 Heap snapshot，操作前后各拍一次快照，对比是否有对象没被释放（尤其是闭包、事件监听器、定时器）
• 关注 Detached DOM trees —— 这类残留节点会让 GC 更吃力，间接拉长 JS 执行间隔
• 若发现 GC 频繁且耗时高，优化方向就不是改算法，而是清理引用、解绑监听器

不复杂但容易忽略：别只盯着单个函数耗时，要结合主线程负载、帧节奏和内存状态一起看。一次录制，多个维度交叉验证，才能真正找准 JS 耗时的真实原因。