shader compilation stutter in WebGL — is there actually a solution or do we just warn players?

yeah the combination space is the real problem and static analysis basically can't save you there. we had something similar with a lighting keyword system, manifest looked airtight, prewarming ran clean, and then someone picked up a specific item type under a specific weather condition and boom, first-time stutter.

the thing that finally helped: we added runtime logging that records every unique shader variant string as it actually gets compiled, session by session, and diffed those logs against our prewarming manifest after each playtest. tedious to set up once but it caught combinations that no amount of code review would have found. after a few weeks the manifest was genuinely complete for normal play patterns.

oh man the keyword variant thing is brutal. we had this exact problem, manifest looked complete, prewarming loop ran clean in testing, first internal playthrough was fine... until a player picked up a weapon that triggered a glowing emission keyword variant we'd never hit in our prewarming scene. one stutter. filed as 'not reproducible' for two weeks before someone finally connected the dots.

ended up writing a small editor tool that walks every material in the project, enumerates enabled keyword combinations, and spits out the full variant list to the manifest automatically. tedious to build but now at least the manifest is actually exhaustive.

Solid approach. One thing to watch: if your materials use shader keyword variants, you need to pre-warm each variant separately, not just each material. We had a manifest that covered all our base materials but missed that several had dedicated depth prepass and shadow caster variants that only compiled when those passes were actually triggered mid-frame. The fix was making the manifest generation step aware of variant permutations and issuing a draw call per variant. Still very much worth the effort, just make sure your manifest is exhaustive or you'll spend time hunting down which specific variant slipped through.

The keyword combination space is genuinely one of those problems that stays invisible until it detonates on you in a playtest. At some point I stopped treating it as a prewarming problem and started treating it as a variant reduction problem: auditing which keyword combinations actually occur at runtime and cutting the ones that don't. Unity's IPreprocessShaders interface lets you hook into the build and strip variants based on custom logic, and if you log which combinations actually get triggered during playtesting you can build a pretty accurate exclusion list over time.

It dropped our variant count enough that the prewarming manifest became manageable. Still tedious as the project grows, but at least it's a known set you can control rather than an exponential one that blows up every time someone adds a new keyword.

burned by this exact thing. spent two hours convinced my prewarming loop was working because I could see the materials loading and the editor showed no hitches. first browser test, stutter city. ended up adding an offscreen quad that renders every "prewarm" material for one frame before it can appear in the actual scene. feels wrong to do it that way but it works.

tbh after fighting the manifest approach for a while we gave up trying to enumerate combinations statically and just added a telemetry hook that records shader compile events in production: timestamp, variant keywords, frametime spike. when a real user hits a stutter we can see exactly what triggered it and patch the manifest retroactively. slightly embarrassing to ship but way more effective than trying to reason about the full combination space ahead of time.

the one thing that actually helped pre-launch: a QA pass specifically designed to trigger rare keyword combos, unusual lighting conditions, obscure powerup states, edge-case weather, run in a browser build with the devtools performance tab open. caught about 30% of the long-tail variants before players did.