Motion that earns its frame rate.

1. 01Scroll-scrubbed frame sequence90 frames · 1.05 MB
2. 02Blend-mode compositing1 CSS property
3. 03SVG mask knockout961 bytes of SVG
4. 04Cursor-tracked 3D149 KB gzipped
5. 05Scroll-pinned transitionno library
6. 06Reveal choreography & magnetic hover3,315 bytes of script

§ 01

Decoding 90 frames

Frame 001 / 090 Scroll 0% Decoded 0 / 90 Draws issued 0

Static poster — frame 008, the brightest of the ninety. The other 89 were not requested on this device; see “What it costs” below for exactly what was.

What it is

Ninety numbered JPEGs preloaded into Image objects, then blitted to a <canvas> sized by devicePixelRatio. Scroll position inside a pinned section maps to a frame index; drawing happens inside requestAnimationFrame, never in the scroll handler, and only when the target index actually changed. On a still scrollbar this costs zero draws.

Why not a video

This is the whole reason the technique exists. Setting video.currentTime seeks to the nearest keyframe, then decodes forward to the requested time. Scrub it and the picture holds, jumps, holds — the exact stutter you were trying to buy your way out of. A frame sequence has no keyframes. Every index is an exact, independent picture, so a one-pixel scroll produces a one-frame change.

What it costs

1.05 MB over the wire for these 90 frames — 1,049,581 bytes, counted off the files. The number that actually matters is the decoded one: 960 × 540 × 4 bytes is 2.07 MB of bitmap per frame, so roughly 187 MB of RAM if the browser keeps all ninety uncompressed. That is why the sequence is never requested below 820 px or under reduced-motion. Being exact about what that does and does not cover, because an earlier draft of this note was not: the sequence is skipped, but four static poster frames are fetched on every device, always — 48,972 bytes for the four of them. So this page does fetch frames on a phone. Four, and they are the pictures you are looking at. They are members of the same ninety, so on a device that qualifies the browser already has them and they add nothing on top.

Build cost

Estimate: half a day if usable footage already exists. Two to three days if it has to be sourced or commissioned, then graded and conformed first — and the footage, not the code, is where that time goes.

When not to use it

Anywhere the visitor needs to read while scrolling, because pinning takes the scrollbar away for the length of the section. Once per page, never above the thing you actually want them to do, and never on a phone — and this page itself breaks the once-per-page part, which specimen 05 owns up to with the numbers. If the arc of the footage is not legible in ninety frames, it will not be legible at three hundred either — the fix is the footage, not the frame count.

Payoff

What this does for your customer: Their story on your homepage plays out exactly as fast or slow as they scroll it — no video to buffer, no autoplay to wait through, and it holds still the instant they stop.

§ 02

Blend screen exclusion difference lighten normal

Plate flat busy

Applied screen Plate flat Source poster

What it is

A single CSS property, mix-blend-mode, on the layer holding the footage. The colour underneath is ordinary markup — solid blocks, no image, no export.

Why screen is correct here

Screen never darkens, and pure black is its identity value: black leaves the plate exactly as it was. With white-on-black footage the background disappears completely and only the flame adds light — a free matte, with no alpha channel and no rotoscoping. Exclusion is what you reach for over a busy photo, because it inverts where the plate is bright, so the subject stays legible instead of blowing out to white in the light areas. Press “busy” above and compare the two.

What it costs

Nothing measurable. One property, composited on the GPU, no extra bytes. The cost is upstream: the footage has to be authored against black, which is a decision made when it was shot, not in the browser.

When not to use it

Over text. A blend mode composites against whatever happens to be behind it, and what is behind it changes the moment your copy reflows at a width you did not test. Also isolate it — a mix-blend-mode with no isolation:isolate parent blends through the entire stacking context and will happily eat your header. This stage sets that isolation explicitly.

Payoff

What this does for your customer: One piece of licensed footage can carry your brand colour instead of the stock colour it shipped with, so the site reads as built for you specifically — without paying for a new shoot every time the palette changes.

§ 03

Mask 1 rect + 1 use Type Fraunces 600 · live text Raster assets 0

What it is

An SVG <mask> holding a white rectangle and a black <use>. White keeps the covering panel; black punches it away. The panel is a flat fill of #0D1411, the same ink as the page, so the knockout reads as a hole rather than a box.

Why not export it flat

Because a flattened SVG from a design tool is a picture of a word. Doing it in code keeps the type real: it reflows with the viewport, it re-renders crisply at any density, a crawler can read it, and changing the headline is a text edit rather than a round trip through the design file. The word exists as exactly one <text> node — the mask points at it with <use> rather than repeating the string, so what a crawler reads and what you can select are the same node, and there is no second copy to fall out of sync. Try selecting across the word.

What it costs

Measured rather than estimated, because “about 2 KB” is what this note said before anyone counted: 961 bytes of SVG exactly as it ships, comments and all — 636 with the explanatory comments stripped — plus 504 bytes across the five CSS rules that position it. 1,465 bytes in total, and no image request at all. It is one of the few genuinely free moves on this page.

When not to use it

When the word is long. A knockout headline is one line of type at display size; at four words it either shrinks below legibility or wraps, and a wrapped knockout looks like a rendering bug rather than a decision. Pick a word, not a sentence.

Payoff

What this does for your customer: The first word your customer reads is also the thing that catches their eye first — a live headline, not a picture of one, so it stays sharp on any screen and a search engine can still read it.

§ 04

What it is

three.js r128, self-hosted, no build step, no module graph. Two InstancedMesh draws — 46 extruded fins standing on a shallow arc, plus a lit cap on each, against a curved open cylinder. 92 boxes in three draw calls: two instanced, plus the backing arc. Rotation eases toward the pointer and falls back to a slow idle drift after 1.6 s of stillness. Rendering pauses entirely when the canvas scrolls out of view or the tab is hidden.

The trap everybody hits

A metallic material with no environment map renders pure black, because metal has nothing to reflect. The usual fix ships an HDR file over the wire. This page builds the environment in-page instead: four coloured planes inside a box, run through PMREMGenerator, zero bytes downloaded. The mean-luminance figure in the readout above is measured off the actual canvas pixels every couple of seconds — it is there so the claim “it is lit” is something you can check rather than something I asserted in a caption.

What it costs

603 KB raw — 603,445 bytes on disk — and 149 KB gzipped, for the library alone, before a single triangle. Then battery: a canvas that renders every frame keeps the GPU awake for as long as it is on screen. This one is capped near 40 fps and stops dead when it leaves the viewport, and it is never fetched on a phone.

When not to use it

As decoration. 149 KB gzipped is roughly the entire budget of a genuinely fast site, and spending it on ambience that a still image would have covered is the most common way a beautiful site becomes a slow one. If the 3D is not the point of the page, use a photograph.

Payoff

What this does for your customer: A hero section that feels responsive under the cursor on a capable laptop — and on a phone or an older device it quietly steps down to a still image instead of stuttering, so nobody gets a worse experience than the page can actually deliver.

§ 05

What it is

A tall track with a sticky child. Scroll progress through the track is normalised to 0–1 and driven straight into a clip-path: inset() on the upper panel. Everything runs inside the same requestAnimationFrame loop as the rest of the page, so there is one ticker, not six.

What it costs

Almost no bytes. It costs the visitor's scroll instead, which is the more expensive currency: for the height of the track, the page is not going anywhere and they cannot make it.

When not to use it

More than once per page. Two pinned sections in a row and a visitor concludes the page is broken and leaves — and they are not wrong, because from their side a scroll that does not scroll is a bug. Then this page pins twice, so the rule is one you can watch me break: specimen 01 sticks its stage inside a 340 vh track, and this one sticks its panels inside a 230 vh track. 5.7 screens of page height between them, 3.7 of which are spent standing still. A lab that demonstrates pinning has to pin, and a page selling something does not — on a client build I would ship one of these or neither, and the claim above is the rule, not a description of this file. Below 820 px both pins are dropped entirely and the panels stack, which is also what happens under reduced-motion.

Payoff

What this does for your customer: Their attention gets held on the one sentence you most need them to read, for exactly as long as it takes to read it — then the page lets go and gives the scrollbar back.

§ 06

The stall guard

IntersectionObserver does not fire in every context — some in-app browsers, some print paths, some restored bfcache states. If your content only becomes visible when the observer fires, then in those contexts your content never becomes visible. So a 1.4 s timer reads one flag — did the observer ever deliver an entry — and reveals everything only if it did not. One line, and it turns a catastrophic failure into a missed animation. It has to be that flag rather than a bare timer: an unconditional version also fires on a page where nothing is wrong, and 1.4 s after load it would flatten the reveal on everything still below the fold, which here is most of the page — including the one specimen whose entire job is to show you the choreography.

Magnetic hover, and the bug in it

The button leans toward the cursor by up to 9 px across and 6 px down, easing back on exit. The trap: reveals animate transform, and magnetic hover animates transform. Put both on the same node and whichever runs second silently erases the other — a nav centred with translateX(-50%) will fly off screen the instant it reveals. Here the reveal is on an outer wrapper and the magnetism is on the button inside it. Ask me how I know.

What it costs

Measured, because “about a kilobyte” is what this note claimed until someone counted it. The reveal engine and its stall guard are 2,262 bytes of script exactly as shipped — 1,499 with the explanatory comments stripped — plus 190 bytes of CSS for the two [data-reveal] rules. Magnetic hover adds 1,053 bytes. 3,315 bytes for both, and no bytes of library. The replay button costs a further 1,259 and does not count, because it is a demonstration control that exists only on this page. Magnetic hover is disabled outright on touch, where there is no cursor to lean toward and the effect only ever fires as a confusing jump on tap.

When not to use it

On anything the visitor came for. A reveal on a phone number is a phone number that is not there yet. Reveals belong on supporting material, never on the price, the address, the hours or the button.

Payoff

What this does for your customer: The page feels calm and considered as they scroll through it, without a single animation ever standing between a visitor and your price, phone number, hours, or booking button.