Animation has a uniquely unforgiving performance contract. A slow page load is annoying; a stuttering animation is visible failure, sixty times per second, on the most polished part of your site. Which is why web animation historically came with an asterisk — fine for a hover state, risky for anything ambitious, and the first thing cut when the performance audit came back.

We wanted animation that scales from a button micro-interaction to an animated product scene without that asterisk — on any customer's website, on whatever device their visitor happens to hold. This post is the engineering story of how the renderer under the visual motion editor works, and why it's built like a game engine rather than a script. It's the third in our engineering series, after workspaces as repositories and email at scale.

The job: one runtime, any website

A design constraint shapes everything downstream: animations in Faster are files played by a runtime, not code embedded in a site. The editor's output is a portable animation document; the runtime is a single script that any page — a Faster site, or anyone else's — can include to play it. No editor dependency, no build step, no framework assumption.

That portability raises the bar brutally. We don't control the pages our runtime lands on — it has to share a browser with whatever else the page is doing, hold frame rate on a mid-range phone, and never be the reason a site feels slow. A runtime you ship to other people's websites doesn't get to have bad days.

The frame budget, and why JavaScript spends it badly

Sixty frames per second gives you 16.7 milliseconds per frame — for everything: evaluating which properties changed, computing transforms, and drawing. Miss the window and the frame drops; drop frames in a pattern and humans perceive it instantly. Average performance is irrelevant here — animation is judged by your worst frame.

JavaScript's problem isn't speed — modern engines are remarkably fast — it's predictability. Allocation-heavy per-frame math produces garbage, and eventually the garbage collector takes its pause. A few milliseconds of GC at the wrong moment is a skipped frame, and per-frame animation math is exactly the allocation pattern that invites it. You can fight this in JavaScript with heroic object pooling and allocation discipline; at some complexity, you're hand-building a memory manager inside a language designed to hide one.

What Rust and WebAssembly actually buy

The pipeline, and the art of the boundary

Each frame: the animation graph — the same one you author by describing — evaluates time, inputs like scroll and pointer, and produces the current state of every animated property. The Rust core turns that state into draw commands, and the GPU renders to the page's canvas through WebGL2. Visual effects run as GPU passes chained on the graphics card — the image never round-trips back through the CPU to get blurred or glowed.

The unglamorous part that makes it fast: respecting the JavaScript↔WebAssembly boundary. Crossing it has a cost, so the design rule is to cross rarely and in bulk — state flows across as packed typed arrays, once per frame, not as thousands of chatty property calls. Most of "why is WASM slow for some teams" is boundary chatter; most of making it fast is designing the data layout so there's almost nothing to say across it.

What the performance looks like in practice

• Flat frame times, not just good averages. The whole architecture optimizes for the worst frame — no GC spikes, no JIT warm-up wobble, GPU doing the pixel work. Smoothness is a variance property, and variance is what we removed.
• Cost that scales with the scene, not the page. Canvas rendering sidesteps the way DOM animation costs compound with page complexity — the renderer's work is proportional to what's animating, not to what the rest of the page is doing.
• A one-time startup cost, paid efficiently. The WebAssembly module compiles as it streams in and is cached after; steady-state is where the budget went. For below-the-fold animations, loading defers until they matter.
• Graceful degradation. On weaker devices the right move is simpler motion, not slower motion — which is a design decision surfaced in the mobile preview, backed by a runtime that respects reduced-motion preferences.

The same renderer, without the browser

Because the core is Rust, it also runs server-side — same evaluation, same rendering logic, no browser attached — which is what powers exporting an animation as video. The guarantee that matters to users: the export is rendered by the same code that played the preview. There's no "it looked different when we rendered it" class of bug, because there's no second renderer to disagree with the first. One animation document, one rendering core, two destinations: your webpage in real time, or a video file rendered frame-perfect in the cloud.

What all this means if you never read this far

You describe a motion, tweak it in the visual editor, publish, and it's simply smooth — on your customers' phones, on pages with other things happening, at scene complexities that used to require an asterisk. The engineering's job was to make itself unnoticeable; the taste rules remain yours.

Frequently asked questions

If you're building frame-budget systems of your own, the transferable lessons are the boring ones: optimize the worst case, make memory boring, and design your boundaries so there's nothing to chat about. And if you just want the animations — describe one; the machine room will hold the frame rate.