SPIR-V would be fast to load into GPUs (in theory). You still need to translate to SPIR-V from some other language (like GLSL), which will incur a significant cost (the idea would be to do the compilation off-line).
1. If there is a work we can influence on making GPU compilation faster?
GLSL compilation is governed by the driver. Unless you can exchange everybodies driver, you can't make it any faster. HLSL compilation is governed by the D3D runtime in use, unless you can get Microsoft to make it faster, you can't make it faster (Microsoft has made it faster though, but it's still slow).
One suggestion would be to move to SPIR-V supplied shaders in OpenGL. There's a few roadblocks though:
OpenGL support for SPIR-V depends on 4.5 core, Vulkan, a vulkan extension, ARB_parallel_shader_compile, ARB_separate_shader_objects, ARB_program_interface_query, and would therefore be available to nearly nobody at the present time, and for the next few years. But you'd also have to advance to WebGL 4.5 or so before you could interact in a meaningful fashion with OpenGL through SPIR-V.
OpenGL ES does not have any support for SPIR-V, it would need to be added.
if SPIR-V would be supplied, it would have to compiled on the fly to DX bytecode (on d3d backends), but it would have to bypass the HLSL compiler (which causes slowness), which is something that Microsoft rules out (code signing). So either Microsoft would have to drop DX bytecode codesigning (quite unlikely), or Microsoft would have to supply a cross-platform library that quickly converts SPIR-V to DX bytecode (seeing as Vulkan is a D3D 12 competitor, that's unlikely too)
These limitations make it exceedingly unlikely that at SPIR-V (or any other kind of precompiled bytecode) could start to stand in for GLSL in WebGL and deliver the expected benefits (reduced compile times on-line through off-line compilation).