WebGPU 首次绘制为什么卡顿：Shader 编译、Pipeline 缓存与渐进加载边界

WebGPU 页面第一次出现画面时短暂卡住，很多时候并不是绘制命令数量太多，而是浏览器正在准备着色器模块、渲染管线和绑定资源。等这些对象完成校验与编译后，后续帧可能恢复流畅，所以只看平均帧率很容易漏掉问题。

把“首次绘制”拆成设备初始化、着色器准备、管线创建和真正提交四段，再决定哪些对象提前准备、哪些资源延后加载，通常比单纯减少 draw call 更有效。

先把首帧卡顿拆成四个阶段

一个典型的 WebGPU 初始化流程，至少包含 adapter/device 请求、着色器模块创建、管线创建和命令编码器提交几个环节。它们在不同浏览器实现里表现可能有差异，但排查时仍可以按这个边界记录耗时。

建议在页面打开后记录几个明确的时间点：请求设备结束、着色器模块创建完成、管线就绪、第一帧提交和第一帧真正可见。这样才能分辨是网络资源晚到、编译准备慢，还是首帧提交时塞入了太多资源导致的问题。

Pipeline 不是越早创建越好

提前创建管线能把一部分成本移到加载阶段，但“把所有材质和所有变体都提前预热”也会制造新的长任务。更稳妥的做法是按首屏必需、首屏后高概率使用、低频功能三组排队处理。

const essential = ["basic-unlit", "textured-sprite"];
const later = ["shadowed-mesh", "post-process"];

for (const key of essential) {
  await preparePipeline(key);
}
requestIdleCallback(() => {
  for (const key of later) preparePipeline(key);
});

示例中的分组只是加载策略，不代表浏览器一定会把管线永久缓存。页面刷新、设备变化、驱动更新或实现策略调整都可能让准备成本再次出现，因此线上仍要保留失败和超时记录。

缓存应该缓存什么，不能缓存什么

应用层可以缓存着色器文本、材质描述和自己的管线配置键，避免重复构造同一份对象；但不要把某次运行中的 GPU 对象当成跨设备、跨页面可序列化的长期缓存。真正有价值的是稳定的键值、版本号和失效条件。

例如可以用着色器版本、顶点布局、颜色格式和功能开关组成缓存键：

const key = [shaderVersion, vertexLayout, colorFormat, featureFlags].join("|");
const pipeline = pipelineMemory.get(key);
if (pipeline) {
  return pipeline;
}
return prepareAndRemember(key, descriptor);

当画布尺寸、输出格式或设备能力改变时，旧缓存键应主动失效。否则缓存命中数据看起来很漂亮，实际却可能在重建交换链或切换设备时暴露错误。

设备丢失和失败回退要提前设计

WebGPU 初始化失败不应只显示一个空白画布。页面可以先展示静态预览或普通 Canvas 版本，再把 WebGPU 作为增强路径。设备丢失后重新请求设备时，也要重新准备依赖设备的管线，而不是继续引用旧对象。

验收时至少覆盖三种情况：首次进入的冷启动、返回页面后的再次进入，以及设备能力不足或初始化失败。每种情况都记录首屏可交互时间、第一帧可见时间和回退路径，不要只测开发机上的高端显卡。

一份适合上线前的检查清单

• 是否能区分着色器、管线、纹理上传和首帧提交的耗时。
• 首屏管线数量是否有限，低频变体是否延后准备。
• 缓存键是否包含着色器版本、布局和输出格式。
• 设备丢失、请求失败和超时是否都有用户可见的回退方案。
• 低端设备和移动端是否测过冷启动，而不是只看连续运行帧率。

常见问题

WebGPU 首次卡顿是不是一定要改着色器？

不一定。先用时间线确认成本所在位置；如果主要耗时在资源上传或图片解码，改着色器反而会偏离问题方向。

把管线全部提前创建会更稳定吗？

它可能减少交互中的突发准备，但会把等待集中到进入页面时。首屏优先、其余延后的分层策略通常更容易兼顾可用性。

浏览器缓存能保证下一次打开不再编译吗？

不能把它当成跨环境的必然保证。应用应把缓存当作优化手段，并继续保留冷启动测量和失败回退机制。

结语

WebGPU 首次绘制的关键不是追求“零准备时间”，而是让准备成本出现在用户能接受的阶段，并且可测量、可回退。先建立首帧时间线，再给管线做有限预热和明确失效条件，通常能比盲目压缩渲染代码更快找到真正的卡顿来源。