如何利用 Performance API 识别 JS 脚本解析 (Compile) 与执行耗时的配比

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《如何利用 Performance API 识别 JS 脚本解析 (Compile) 与执行耗时的配比》，聊聊，我们一起来看看吧！

Performance API 不直接暴露脚本解析/编译耗时，但可通过 resource timing、performance.now() 埋点、longtask 监控及 DevTools 工具间接分析各阶段性能瓶颈。

Performance API 本身不直接暴露脚本“解析（Compile）”阶段的耗时，因为浏览器引擎（如 V8）将编译与执行深度耦合，且现代 JIT 编译器会动态优化、懒编译、去优化，导致传统意义上的“纯解析时间”难以独立剥离。但你可以通过 performance.getEntriesByType('navigation') 和 performance.getEntriesByType('resource') 结合关键时间戳，间接推断 JS 脚本在加载链路中各阶段的耗时分布，并识别是否存在编译/执行瓶颈。

关注 script 资源的完整生命周期阶段

对每个 initiatorType === 'script' 的资源条目，其 PerformanceResourceTiming 对象包含多个时间字段，可组合分析：

• fetchStart → responseEnd：网络 + 服务器响应耗时（不含解析）
• responseEnd → executionStart（非标准字段，需间接估算）：这部分实际涵盖脚本下载完成后的解析（Parse）、编译（Compile）、预热（Warm-up）及首次执行前准备；浏览器未暴露 parseStart 或 compileEnd，但可通过以下方式逼近：
• duration：从 fetchStart 到 loadEventStart（或 domContentLoadedEventStart）的总耗时，含网络、解析、编译、执行、渲染等全链路

用 performance.now() 配合 script 标签时机定位执行耗时

真正能被你精确测量的是“执行耗时”，而非解析/编译本身。推荐在脚本内主动埋点：

• 在