Performance面板可精确测量script真实耗时：需刷新页面或触发交互使脚本执行，勾选Screenshots和Memory辅助分析；火焰图黄色块对应Scripting任务，含Parse HTML、Evaluate Script等阶段，悬停查看详情，双击进入Call Tree定位瓶颈；需结合Layout/Paint块、CPU节流及Bottom-Up视图交叉验证真因。
直接用 Performance 面板录制并下钻到具体 <script> 执行块，就能看到它在主线程上的真实耗时——不是估算，是精确到毫秒的运行时间。
录制时确保捕获完整脚本生命周期
脚本执行耗时只有在真实执行过程中才能被准确采样。所以录制不能只点“开始”再点“停止”，要让脚本真正跑起来：
- 刷新页面（F5 或 Ctrl+R）触发 HTML 解析和内联脚本执行；
- 或手动触发某个交互（比如点击按钮），使动态插入/延迟执行的
<script>被加载并运行； - 务必勾选 Screenshots 和 Memory，它们不影响脚本计时，但能帮你确认是否因内存抖动或渲染卡顿干扰了执行节奏。
从火焰图定位 script 对应的任务块
录制完成后，火焰图（Flame Chart）中黄色区域代表 Scripting 阶段。每个水平条形就是一个任务（Task），包括：
-
Parse HTML：解析到
<script>标签时的初始处理； -
Evaluate Script：实际执行 JS 代码（含内联脚本、
eval、setTimeout回调等）； -
Function Call：某函数被调用的具体帧，可展开看到文件名、行号和耗时（如
index.js:42— 18.7 ms）。
鼠标悬停在任一黄色条上，底部 Summary 会显示类型、起始时间、持续时间；双击可跳转到底部 Call Tree 视图，按耗时倒序排列所有函数，一眼锁定最重的脚本片段。
区分不同 script 的执行上下文
同一个页面可能有多个 <script>，它们的执行时机和归属不同：
-
内联脚本（
<script>...</script>）：通常出现在 Main 线程的Parse HTML → Evaluate Script链路里，时间紧挨着对应 HTML 行； -
外部脚本（
<script src="a.js"></script>）：在 Loading 阶段下载后，进入 Scripting 阶段执行，火焰图中会标出文件名（如a.js）； -
动态插入脚本（
document.createElement('script')）：出现在用户交互之后，常位于某次点击或滚动事件的回调栈底部，需结合 Event Log 追踪源头。
交叉验证避免误判
单看一个黄色块的耗时还不够，要排除干扰因素：
- 检查该任务前后是否有长 Layout / Paint 块——若 script 后立刻跟大块紫色，可能是它触发了强制同步布局（如读取
offsetTop后改样式），实际瓶颈不在 JS 本身； - 对比 CPU 节流（如 4x slowdown）下的耗时变化：如果原始耗时 20 ms，节流后变成 80 ms，说明它是 CPU 密集型，优化方向是拆分或移入 Web Worker；
- 打开 Bottom-Up 标签页，筛选 “ScriptEvaluation”，查看哪些脚本占用了总 Scripting 时间的 70% 以上——这才是真瓶颈。
