Technically there are no "precompiled shaders" in any 3D API (outside game consoles). Even in D3D/Vulkan/Metal, shaders are passed into the API as an intermediate bytecode format, which is then compiled to the actual native instructions in the GPU driver, and that's why you get the infamous 'shader compilation stutter' even in the latest AAA PC games.
The expensive part isn't parsing text into an intermediate bytecode format like SPIRV (especially for WGSL which mostly just maps SPIRV-semantics to text), but what happens after that.
And specifically in WebGPU, even when it takes SPIRV as input, that SPIRV is taken apart, validated and then translated into bytecode formats for D3D, Metal or reassembled into another SPIRV blob for Vulkan.
From what I'm understanding from lurking in the WebGPU discussion group, the current main problem with shader compilation is that some innocent looking shaders may unexpectedly 'explode' due to loop unrolling down in the backend 3D API and a few lines of input may take seconds to compile in the worst case - and for that problem, WGSL vs SPIRV input would be irrelevant.
The expensive part isn't parsing text into an intermediate bytecode format like SPIRV (especially for WGSL which mostly just maps SPIRV-semantics to text), but what happens after that.
And specifically in WebGPU, even when it takes SPIRV as input, that SPIRV is taken apart, validated and then translated into bytecode formats for D3D, Metal or reassembled into another SPIRV blob for Vulkan.
From what I'm understanding from lurking in the WebGPU discussion group, the current main problem with shader compilation is that some innocent looking shaders may unexpectedly 'explode' due to loop unrolling down in the backend 3D API and a few lines of input may take seconds to compile in the worst case - and for that problem, WGSL vs SPIRV input would be irrelevant.