A full-viewport shader that listens to whatever the visitor is playing and reacts to it in real time, running under reduced motion, without WebGL, and without JavaScript, because a music site that only works in the best case is not done.
Problem and failure definition
This is front-end systems craft under constraint, not a demo of visual effects. The site’s audience skews technical, and a page that reads as decoration for its own sake works against the collective rather than for it. The actual engineering problem is narrower and harder: drive a real-time visual field off live audio without it reading as random noise, without tanking frame rate, and without breaking for a visitor who has disabled motion, lacks WebGL, or has JavaScript off entirely.
System
The visual field is a full-viewport fragment shader rendering black-and-white volumetric smoke, built from two layered, domain-warped fractal Brownian motion passes — one warp field distorts the coordinates fed to a second noise layer, which is what gives the smoke its folded, non-repeating look rather than the flat look of a single FBM pass.
Audio analysis is one AnalyserNode per media element. The hero and a cheaper, lower-detail
ambient field used elsewhere on the site share that same analyser architecture rather than
running independent audio graphs.
The mapping from audio to visual is a deliberate asymmetry: audio drives light, not geometry. Fast bass and mid-frequency envelopes modulate brightness directly, so the field pulses with the beat. Shape is driven by a heavily smoothed, slow-moving envelope instead. The reasoning is perceptual, not aesthetic: moving geometry on a fast envelope reads as glitch — the eye interprets sudden shape changes as an error — while brightness can move quickly and still read as responsive rather than broken.
The canvas measures and matches its own displayed box and re-checks that on every frame rather than trusting a resize event, so it recovers from layout changes a resize listener alone would miss. Audio state persists across page navigation, carried through Astro’s view transitions rather than restarting on every route change.
Verification
Three conditions are treated as separate, first-class acceptance targets rather than as one generic “degrade gracefully” requirement, because each has a different cause and a different correct fallback:
- Reduced motion requested — the shader does not run; the page shows a static frame.
- WebGL unavailable — the canvas is never initialized; a CSS gradient stands in.
- JavaScript disabled — nothing canvas-related loads; the page shows a wordmark.
Each path was checked directly rather than inferred from feature-detection code review, the same verification standard applied to every case on this site.
Result
The site is deployed and running at the shipped URL, with the shader field live for visitors who meet all three conditions and the appropriate fallback showing for visitors who do not.
Limits
Shader cost on low-end mobile GPUs is the main open risk — two layered FBM passes per pixel is not free, and there is no frame-rate budget enforced or measured across a device matrix. The Web Audio API also requires a user gesture before the audio context can resume, which is a browser policy rather than a bug, but it means the very first paint on load cannot be audio-reactive regardless of how the code is written. No performance measurement across real devices is published, and none is claimed. There is also no usage or outcome measurement published for this site — no visitor count, no engagement data — and none is claimed.