Five questions before you add WebGL to a marketing site

WebGL on a marketing site is seductive. A shader backdrop signals craft, separates you from template land, and gives designers a playground. It also ships fragile: GPU blacklists, battery drain, accessibility gaps, and a maintenance bill nobody budgets until the hero breaks on a three-year-old Android phone.

Before I add WebGL—or a canvas stand-in like the spider graph on satanilabs.com—I run through five questions. They are not a buzzkill; they are how the effect survives contact with production.

1. What job is this doing?

Decoration, data visualization, and product interaction are different jobs. Decoration must never block comprehension. If removing the canvas leaves the page empty of meaning, the effect failed. I write one sentence: “This layer communicates X.” If X is only “looks cool,” I cap complexity and budget time accordingly.

On satanilabs.com the spider graph is atmosphere: it signals systems thinking without carrying data. That classification matters when prioritizing bugs—a stutter on scroll is annoying but not a compliance issue. A WebGL heatmap of occupancy on a hotel marketing page would be different; I would need legends, tables, and copy that restate the insight for users who never see the canvas.

2. Who pays the performance cost?

Marketing traffic spikes on mid-tier phones over hotel Wi-Fi. I measure Time to Interactive with and without the canvas, and I profile GPU frame time on a throttled device. Effects that run continuously need pause hooks—document.visibilityState, prefers-reduced-motion, and intersection observers when off-screen.

function shouldRunCanvas() {
  if (window.matchMedia("(prefers-reduced-motion: reduce)").matches) return false;
  if (navigator.hardwareConcurrency && navigator.hardwareConcurrency < 4) return false;
  return true;
}

Not every guard belongs in code—sometimes the answer is a static poster image for mobile breakpoints.

I also watch main-thread contention: heavy fragment shaders plus React hydration on first paint compete for the same budget. Deferring canvas initialization until after requestIdleCallback or first user scroll is often enough to protect Largest Contentful Paint. Lighthouse scores are not the goal; perceived speed when a creative director opens the link on a phone in a lobby is.

Bundle size matters when wrapping Three.js or regl. Tree-shake aggressively, lazy-load the WebGL chunk on routes that need it, and never import a math library twice because two effects teams shipped in parallel.

3. What is the accessible story?

Canvas is not semantic HTML. Screen readers should ignore decorative layers via aria-hidden and never trap focus. Motion must respect reduced-motion preferences with an equivalent layout, not a broken one. If the effect conveys information—heatmap, topology—provide a text/table alternative.

Pointer events on full-screen canvases are another trap. Decorative layers should set pointer-events: none so clicks reach links beneath. Interactive WebGL—orbiting a product model—needs visible controls with labels, not gesture-only discovery.

4. What is the fallback when WebGL is unavailable?

Context loss happens. Extensions differ. I ship a CSS or SVG fallback path tested in CI, not discovered in prod. For brand backdrops, a dark gradient plus grain often suffices; users still get the editorial tone without the graph.

Safari private mode, corporate locked-down GPUs, and remote desktop streaming can all disable or throttle WebGL. Detect failure once, swap to fallback, and log at debug level—do not spam errors to users. A webglcontextlost handler that rebuilds the scene sounds elegant until you loop on lost contexts during sleep/wake on laptops.

5. Who maintains this in twelve months?

Shaders do not upgrade themselves when dependencies bump. I document uniforms, node counts, and safe ranges. I prefer effects with no external asset pipeline over ones that require Blender exports per deploy.

Handoffs matter: designers should know which parameters are safe to tune (color, density, speed) versus which require engineering (topology, simulation stability). Without that split, someone will ask for “just one more branch” on a recursive L-system and you will own a forest nobody can regression-test.

Canvas without the WebGL tax

Not every effect needs a full 3D stack. The spider backdrop on my site is 2D canvas: O(n²) proximity checks, capped nodes, no shaders to compile. It delivers most of the brand intent at a fraction of the risk profile. Before reaching for WebGL, I ask whether CSS gradients, SVG filters, or lightweight canvas already communicate the idea.

When WebGL is worth it

Answer “yes” with confidence on most questions when the effect is core to the product story—configurators, scientific viz, creative portfolios where interactivity is the pitch. For studio sites, I bias toward lightweight canvas or CSS unless the concept demands three dimensions.

A ten-minute review before you merge

Paste the five answers into the pull request description. If any answer is “we will fix in prod,” downgrade the effect or gate it behind a feature flag. Future you—and every guest on hotel Wi-Fi—will be glad you did.

Five questions take ten minutes and save weeks of firefighting. The goal is not to avoid WebGL—it is to earn it.