分析 javascript 动态导入的加载性能，核心在于利用浏览器开发者工具的 network 面板和 performance 面板，结合 import() 返回的 promise 生命周期进行监控。具体做法是开启 performance 录制并过滤 xhr/fetch 请求以观察网络耗时，同时在代码中通过 console.time 或 promise.then 记录从调用到模块解析、下载及执行完成的各阶段耗时，从而定位是网络传输慢还是脚本解析阻塞了主线程。
如何捕获动态导入的网络请求与耗时
要获取动态导入的具体网络数据，最直接的方法是使用 Chrome DevTools 的 Network 面板。当代码执行到 import('./module.js') 时，浏览器会发起一个新的 HTTP 请求。在 Network 面板中，你可以筛选出该请求，查看其 Size（传输大小）、Time（总耗时）以及 Waterfall（时间轴分布）。为了更精确地分析，可以结合 Performance 面板的 "Network" 轨道，观察该请求何时开始、何时结束，以及它是否导致了主线程的阻塞。此外，通过 PerformanceObserver API 监听 resource 类型的长任务，也能自动化采集这些指标。
const startTime = performance.now();
import('./heavy-module.js')
.then((module) => {
const endTime = performance.now();
console.log(`Dynamic import took: ${endTime - startTime}ms`);
// 使用模块
module.doSomething();
})
.catch((error) => {
console.error('Failed to load module:', error);
});
上述代码展示了如何在运行时手动计算动态导入的总耗时。通过 performance.now() 获取高精度时间戳，包裹住 import() 调用，可以得到从发起请求到模块完全解析并执行完毕的总时长。这个数值包含了网络延迟、服务器处理时间、浏览器下载时间以及 JS 引擎的编译和执行时间。如果该数值较大，可以通过对比 Network 面板中的请求耗时来区分瓶颈所在。
立即学习“Java免费学习笔记（深入）”；
如何评估模块加载对主线程的影响
动态导入虽然不会像同步脚本那样阻塞 HTML 解析，但模块的编译和执行仍然发生在主线程上，可能导致 UI 卡顿。评估这一影响的关键是观察 Long Tasks（长任务）。在 Performance 面板中，标记为红色的条形图代表超过 50ms 的长任务。如果动态导入的模块体积较大，其解析和执行过程可能会触发长任务，导致帧率下降。可以使用 PerformanceObserver 监听 longtask 类型，量化这种阻塞程度。
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.log(`Long task duration: ${entry.duration}ms`);
console.log(`Start time: ${entry.startTime}`);
}
});
observer.observe({ entryTypes: ['longtask'] });
这段代码设置了一个观察者，专门记录所有超过 50ms 的长任务。当动态导入触发后，如果观察到相关的长任务，说明模块的解析或执行对主线程造成了显著压力。你可以将长任务的持续时间与动态导入的总耗时进行对比，如果两者接近，说明瓶颈主要在 JS 引擎的编译和执行阶段；如果长任务远小于总耗时，则可能主要受限于网络或 I/O。
不同网络条件下动态导入的实际表现差异
在实际项目中，网络环境的变化会极大影响动态导入的性能表现。在高速网络下，动态导入的优势主要体现在按需加载减少初始包体积；而在弱网或高延迟环境下，动态导入的等待时间会显著增加。为了验证这一点，可以在 DevTools 的 Throttling 选项中模拟不同的网络条件（如 Fast 3G, Slow 3G），重新运行上述测试代码，观察 import() 耗时的变化。通常，在弱网下，网络传输时间占比会大幅上升，而编译执行时间相对固定。通过对比不同网络条件下的耗时数据，可以制定更合理的预加载策略或错误处理机制，例如在检测到弱网时提前加载关键模块或使用 Service Worker 缓存。
