The engine

Why an engine

Most pages that use more than one animated piece pay for each one separately: a WebGL context per canvas, a frame loop per effect, a resize listener per component. Motion's pieces share a small engine instead, so the fifth piece on a page costs far less than the first.

What it does

• Capability probe. Live WebGL runs only on hardware WebGL2. Software renderers and old devices get the poster, which is always the first thing on screen.
• Frame guard. If a device misses its frame budget for a sustained stretch after the intro, the piece settles into still frames instead of stuttering.
• Visibility. Pieces stop drawing offscreen and in hidden tabs, and start again when they come back.
• Shared surfaces. The liquid orb draws once on a single WebGL2 context and copies the frame into every orb canvas on the page, so ten orbs cost what one does.
• Lazy stages. three.js and a sculpture load only when the sculpture nears the viewport (about 141 KB gzip for three.js and the stage, once per site); each sculpture adds 2 to 5 KB.

Budgets

Every item has a JavaScript budget (gzip, its own code only) in its metadata, and CI fails the build when an item goes over. Shared runtimes such as React, Motion and three.js are counted once per site, not per item. Each item page shows its budget under At a glance.

Motion levels

Items declare which motion levels they offer, from 0 (none) to 3 (expressive), and what they do under reduced motion. A site can pick a level for itself and use only the pieces that fit.

What we build with

Motion (motion/react), three.js, raw WebGL2, Canvas 2D and CSS scroll-driven animation. No GSAP: its free licence rules out no-code builders, and Motion pieces end up in sites VibeBox Launchpad assembles.