Performance API 是浏览器内置的高精度性能测量工具，能精准捕获 WASM 模块从加载、编译、实例化到函数调用的全过程耗时，是定位初始化瓶颈和 JS/WASM 交互延迟的关键手段。
捕获 WASM 初始化全链路时间点
WASM 初始化包含多个异步阶段：fetch 加载字节码、compile 编译为可执行代码、instantiate 实例化并运行 start 函数。这些阶段无法靠 console.time 精确覆盖，需用 performance.mark 和 performance.measure 手动打点：
- 在
fetch开始前打标记：performance.mark('wasm-fetch-start') - 在
WebAssembly.compile回调中打标记：performance.mark('wasm-compile-end') - 在
WebAssembly.instantiate成功后打标记：performance.mark('wasm-instantiate-end') - 首次调用导出函数前/后分别打点，如
'wasm-first-call-start'和'wasm-first-call-end'
随后用 performance.measure 关联起止标记，即可获得各阶段毫秒级耗时。例如：performance.measure('wasm-compile-time', 'wasm-fetch-start', 'wasm-compile-end')
区分编译耗时与实例化耗时
很多性能问题被笼统归为“WASM 启动慢”，但实际瓶颈可能在不同环节：
-
编译耗时高（>50ms）：通常因 WASM 文件过大或浏览器未启用 JIT 缓存。可通过
WebAssembly.compileStreaming直接编译 Response 流，跳过内存解包，减少中间拷贝；同时确保服务器开启Content-Encoding: gzip压缩 - 实例化耗时高（>30ms）：常由模块内大量全局变量初始化、start 函数逻辑过重，或内存预分配过大导致。建议将非关键初始化逻辑延迟到首次函数调用时执行，而非放在 start 段
通过 Performance API 分离这两段耗时，能快速判断该优化文件体积，还是重构模块生命周期。
监控高频调用的 JS/WASM 边界开销
JavaScript 频繁调用 WASM 导出函数（如每帧调用图像处理函数）会因跨边界序列化、参数复制、上下文切换带来显著延迟。Performance API 可配合自定义标记量化这部分开销：
- 在 JS 调用前打点：
performance.mark('js-to-wasm-call-start') - 在 WASM 函数内部第一行插入 JavaScript 胶水回调（如通过
emscripten_run_script或导出回调函数），触发performance.mark('wasm-entry') - 在 WASM 函数返回前再次触发 JS 回调，打点
'wasm-exit' - 最后用
performance.measure('boundary-overhead', 'js-to-wasm-call-start', 'wasm-entry')提取纯边界延迟
若该值持续 >0.2ms，说明调用太细碎——应合并批量数据传入 WASM，在内部完成循环，而非在 JS 层 for 循环调用。
结合 Navigation Timing 对比首屏体验影响
WASM 初始化不应脱离用户感知孤立优化。可将关键 Performance API 标记与 navigationStart 对齐，计算其占首屏渲染关键路径的比例：
- 获取
performance.getEntriesByType('navigation')[0].domContentLoadedEventStart - 读取
performance.getEntriesByName('wasm-instantiate-end')[0].startTime - 若后者接近甚至晚于前者，说明 WASM 阻塞了 DOM 就绪——需改为异步加载（
import('./module.wasm')动态导入），或拆分非首屏依赖的 WASM 模块
这种对比能让优化决策回归真实用户体验，避免“局部快、整体卡”。
