How I run 34 shader backgrounds on a single Framer homepage without crashing. Here’s how:
Browsers have a hard limit on how many WebGL contexts you can run at once — usually 10 to 15 before things start freezing or the page just dies. That’s not a Framer thing, it’s a GPU safety net. So if you tried to give 34 shader backgrounds their own component, you’d hit the wall in seconds.
Here’s what I did inside Uneo to safely offer 34 presets (and keep switching instant):
1. One context, one canvas, 4 active programs
I cache all shader data upfront for the presets you can cycle through, then only compile and keep hot what’s really needed. That dropped my footprint from 26 separate shader instances down to just 4 active GPU programs. The rest are on standby no extra contexts piling up, no limit hit.
2. Single massive shader file = instant switching
Yeah, putting everything into one huge code file felt challenging at first, but it makes cycling instant. Switching presets is just binding a different pre-compiled fragment program and updating uniforms. No reload, no recompile, no stutter.
3. Toggle the cache off in production
The cache is great while you’re exploring, but once you pick a single shader for your site, you don’t need 33 extras sitting in memory. A simple property toggle turns the cache off so only your chosen shader compiles, your published site stays lean.
4. Removable lazy-load with distance controls
I added an optional lazy-load system. You can tell the canvas to only initialize when the user scrolls within a specific distance, and destroy itself when they scroll far enough away. Great for keeping long pages snappy if the shader isn’t always in view.
No crashes, no context limits, and switching feels like flipping a switch.
Live: Uneo
Hope this helps someone hitting the same GPU limits in Framer. If you’ve found a different way to manage multiple shaders at scale, I’d genuinely love to hear it.
How I run 34 shader backgrounds on a single Framer homepage without crashing. Here’s how:
Browsers have a hard limit on how many WebGL contexts you can run at once — usually 10 to 15 before things start freezing or the page just dies. That’s not a Framer thing, it’s a GPU safety net. So if you tried to give 34 shader backgrounds their own component, you’d hit the wall in seconds.
Here’s what I did inside Uneo to safely offer 34 presets (and keep switching instant):
1. One context, one canvas, 4 active programs
I cache all shader data upfront for the presets you can cycle through, then only compile and keep hot what’s really needed. That dropped my footprint from 26 separate shader instances down to just 4 active GPU programs. The rest are on standby no extra contexts piling up, no limit hit.
2. Single massive shader file = instant switching
Yeah, putting everything into one huge code file felt challenging at first, but it makes cycling instant. Switching presets is just binding a different pre-compiled fragment program and updating uniforms. No reload, no recompile, no stutter.
3. Toggle the cache off in production
The cache is great while you’re exploring, but once you pick a single shader for your site, you don’t need 33 extras sitting in memory. A simple property toggle turns the cache off so only your chosen shader compiles, your published site stays lean.
4. Removable lazy-load with distance controls
I added an optional lazy-load system. You can tell the canvas to only initialize when the user scrolls within a specific distance, and destroy itself when they scroll far enough away. Great for keeping long pages snappy if the shader isn’t always in view.
No crashes, no context limits, and switching feels like flipping a switch.
Live: Uneo
Hope this helps someone hitting the same GPU limits in Framer. If you’ve found a different way to manage multiple shaders at scale, I’d genuinely love to hear it.
