When a WebGL Site Is Worth It (and When It Isn't)

What Motion Actually Buys You

Motion buys three things, and it is worth naming which one you are selling. Retention: a reason to keep scrolling past the fold on a page where the alternative is a wall of copy nobody reads. Comprehension: showing a process, a physical product or a spatial idea in a way static images cannot. And positioning: signalling a price bracket before a single word has been read.

The third is the one clients pay for and almost never articulate. For a studio, a developer, a premium product or a firm selling expertise, the craft level of the website is read as evidence of the craft level of the company. That inference happens fast and it is difficult to undo with copy further down the page. When a client says the site should feel more expensive, this is the mechanism they are pointing at.

It is equally worth naming what motion does not buy. It does not fix a weak offer, and it does not make an unclear value proposition clear. If a brief arrives as the site feels flat, read the copy first. Quite often the flatness is a positioning problem, and a 3D hero would only make it a more expensive one.

The Cases Where It Doesn't Pay

Some audiences are made worse off by a heavy build, and recognising them early protects both your client and your reputation. High-intent utility traffic is the clearest case: someone searching for an emergency plumber at eleven at night wants a phone number above the fold and nothing between them and it. Every frame of animation is a frame of delay.

The same applies to audiences on constrained devices or networks, to content-heavy sites where the job is reading, and to sites a non-technical marketing team needs to edit weekly. A bespoke scene is code, and code is a request to your team rather than a field in a content editor. If the client's real constraint is publishing speed, a heavy build fights their operating model every week for years.

The productive compromise is rarely all or nothing. One bespoke moment on the home hero, one considered product sequence, and conventional well-built pages everywhere else delivers most of the positioning benefit at a fraction of the performance and maintenance cost. Spend the motion budget where the first impression happens.

Set a Performance Budget First

Agree numbers before anyone opens an editor. A total JavaScript budget for the page. A weight ceiling for the largest scene's assets. A frame-rate floor measured on a named mid-range test device rather than on whatever the designer happens to be holding. And a maximum acceptable time before something meaningful is painted on screen.

Choose the test devices from the client's own analytics rather than from preference. The device distribution on a site selling to construction firms is not the one on a site selling to design studios, and a budget set against the wrong hardware is worse than none, because it manufactures confidence.

Write the budget into the brief and into the review criteria. The point is not the specific numbers; it is that adding weight later becomes an explicit trade-off conversation rather than an accumulation nobody notices. Without a budget, every individual addition is defensible and the sum of them is not.

Core Web Vitals With a Heavy Scene

Three measurements matter, and heavy scenes threaten each differently. Largest Contentful Paint suffers when a canvas has to initialise before anything meaningful appears. Interaction to Next Paint suffers when a busy main thread makes taps feel dead for a moment users read as the site being broken. Cumulative Layout Shift suffers when motion reflows layout instead of transforming it.

The techniques that work are consistent across projects. Render meaningful HTML first and mount the scene afterwards, so the page is useful before it is impressive. Keep heavy work off the main thread where the workload allows. Cap device pixel ratio rather than rendering at full resolution on high-density screens. Pause rendering when the canvas leaves the viewport. Use one animation engine tied to one scroll system, and lazy-load everything below the fold.

Measure on the deployed build, on a throttled connection and a throttled CPU, on a real device. A development server on a fast laptop with a warm cache tells you nothing about the client's customers, and the gap between those two environments is where uncomfortable post-launch conversations come from.

Reduced Motion Is a Duty of Care

The prefers-reduced-motion setting is not a preference toggle for people who dislike animation. People enable it because motion makes them physically unwell: vestibular disorders, migraine triggers, motion sensitivity that turns a parallax scroll into an hour of nausea. Treat it as an accessibility requirement, because that is what it is.

Honour it properly, which means more than running the same animation faster. When reduced motion is requested, content should be fully present, legible and complete with no animation at all. The build order that gets you there: make the page correct without any script-driven motion, then animate from that state. If elements are hidden by default in CSS and only revealed by an animation, a reduced-motion visitor gets a blank page, and so does anyone whose script fails to load.

The same duty covers the rest of the interaction surface. Everything the scroll choreography controls must be reachable by keyboard. No content should exist only at a particular scroll velocity, or only after a sequence has completed. Text over moving backgrounds needs contrast that holds at every frame, not only at the one in the design file.

How to Brief One

A good brief for a motion-heavy build is short and specific. It names the one feeling the site should produce, in about ten words. It identifies the single hero moment worth real engineering rather than spreading effort evenly. It states the device targets and the performance budget, lists the content that must stay readable at all times, defines who edits what, and says what happens when the scene cannot run at all.

Reference sites are useful as vocabulary and dangerous as specification. Sending three links and asking for that is how you end up paying for effects whose original purpose does not apply to your client's content. Describe what the reference achieves and why it matters here, then let the build decide the mechanism.

Signature websites are one of three things we build at Kronx, alongside custom software and AI systems, and the briefs that run smoothly are consistently the ones that arrive with a named hero moment and an agreed performance budget rather than a mood board. The constraint is what makes the craft possible, because it tells everyone where to spend.

What to Ask For at Review

Review a motion build against evidence rather than against a screen recording. A video always looks good, because it was recorded on a fast machine with everything cached. The list below is what you should be handed before you show anything to a client.

One more test, informal but reliable: open the staging link on your own phone, on mobile data, while walking. That is closer to real conditions than any lab measurement, and it catches problems clean numbers hide.

• A staging link opened on a real mid-range device, not a video of one.
• A measurement of the deployed build with CPU and network throttled.
• The reduced-motion pass: every section complete and legible with animation disabled.
• A keyboard pass: everything reachable and operable without a mouse.
• Defined failure behaviour when WebGL is unavailable or the GPU is old.
• A walkthrough of exactly what the client's team can edit without a developer.