Skip to content
Journal

What we learned shipping WebGPU to real users

Innovara StudiosTechnical Director

Shader-driven backgrounds look extraordinary in a case study. Here is what happens when they meet a four-year-old laptop.

We have now shipped GPU-rendered backgrounds on six production sites. They are genuinely beautiful and they are genuinely a liability, and both facts have to be designed for from the first day rather than patched in before launch.

Assume it will not run

A meaningful share of real traffic cannot render a WebGPU canvas — older hardware, locked-down enterprise browsers, blocklisted drivers. The failure mode must be a designed state, not an empty rectangle.

Every shader surface we build now sits on a static fallback that is good enough to ship alone. If the canvas never initialises, the page still looks intentional, and nobody files a bug.

If the fallback embarrasses you, the effect is load-bearing, and load-bearing decoration is a bug.

The battery question

A continuously animating full-viewport canvas will drain a laptop. Pause when the tab is hidden, pause when the element scrolls out of view, and pause when the user has asked for reduced motion. These three checks cost an afternoon and remove most of the complaints.

Interactive means it does nothing when nobody moves

Pointer-driven effects have a property that surprises stakeholders in review: at rest, they are still. A demo recorded with a moving cursor promises motion that a real visitor, reading, will never see.

Show the resting state in the first review. If the design only works while the mouse is moving, it does not work.

Next steps

Tell us what changed.
We will tell you
what it will take.

A first call is thirty minutes, costs nothing, and ends with a straight answer about whether we are the right studio for this.