Same workload, three engines — same frames, 15× less JavaScript

Scroll-scrubbed elements (translate + opacity), scroll driven top→bottom→top over 12 s — three passes: 150 elements, 900, and 900 with 12 ms of synthetic "app work" burned per frame — the headroom test. Frame delivery is flat until the main thread saturates, so on fast machines every engine shows 60 fps; the last pass adds synthetic app work to probe headroom. On capable hardware all three engines deliver the same frames — that is the finding: the 46 KB engines buy no extra performance here, they buy API surface. The differences that persist are the bundle column, no-JS/SSR behavior, and cost on weak devices (to simulate one: DevTools → Performance → CPU 6× slowdown, then run again). Each engine runs in sequence below; frame times are measured identically. Keep this tab visible — browsers freeze background tabs.

Reference run (Apple-silicon Mac, headless Chrome via CDP — replace it with yours above)

The CPU cost for the same frames — measured, reproducible

The claim, stated precisely: scrollvars does not promise faster frames — frame delivery ties at 60 fps in every row, because every competent engine animates only the viewport. The claim is: the same frames for a ~12× smaller bundle, a fraction of the heap, zero React re-renders, and a fail-visible no-JS story — with total CPU trading blows (scrollvars wins the shallow scenarios, batched GSAP wins deep subtrees; both are below). Both GSAP variants are included: the idiomatic one-trigger-per-box page people actually write, and the batched expert build (one trigger per section), symmetric to scrollvars' one-tracker-per-section — compare against the batched row for the fair fight.

Measured by the committed harness (demo/bench/harness — clone the repo, npm i && npm run measure): headless Chrome Chrome/152.0.7977.64, median of 5 runs, engine order rotated per repetition. Raw output: results/latest.json.

The style-recalc curve (the honest cost of the CSS-variable mechanism)

Every box gets a realistic subtree (?deep=N spans with distinct selectors); vars written on the section invalidate it all. scrollvars vs the batched GSAP build, 150 boxes, medians:

Read the numbers honestly: scrollvars wins JS script and heap in both pairings and posts the worst style-recalc — an inherited custom property pays per-descendant on every change, a direct transform write pays per-element. The curve above is that cost growing with subtree size, and at the deep end the batched GSAP build wins total CPU. The authoring rule that keeps you on the cheap side: keep tracked elements thin — big static content lives next to the animated elements, not inside them (the var then never inherits through it). It is cheap, not free, and now it is measured.

Stress test (not a typical page): Lighthouse mobile (Moto G emulation, load-only) on the 900-element pages: scrollvars 100 · framer-motion 94 (LCP 2.8 s) · idiomatic GSAP 88 (TBT 230 ms — building 900 triggers on a throttled main thread). No real marketing page ships 900 individual triggers; the point is the shape of the load cost, not the delta you should expect on your page.