Animating SVG on scroll

01The verdict

For a diagram-heavy scroll explainer in 2026, the correct answer is boring and it got cheaper: SVG in the DOM, geometry generated by D3, choreographed by GSAP ScrollTrigger, with everything else brought in surgically and code-split. The interesting news is that this stopped being a compromise — in April 2025 Webflow made every GSAP plugin free for commercial use, which handed the SVG lane the two tools it was always missing: MorphSVG and DrawSVG.

The one-line rule that decides most of this: if the explainer has labels, axes, annotations and legible type — and a diagram-heavy explainer does — the renderer must be SVG. Canvas and WebGL runtimes (Rive, PixiJS, Three.js, Spline, dotLottie) are opaque to screen readers, invisible to search engines, cannot be selected or translated, and render text as either SDF glyphs or baked outlines. That's an acceptable trade for one hero moment. It's an unacceptable trade for the body of a public explainer.

02What SVG + scroll actually does

Four live demos, each in its own scroll pane — scroll inside the boxes. All four run on zero libraries: hand-written vanilla JS on a requestAnimationFrame loop, which is exactly what GSAP ScrollTrigger does under the hood, minus the ~48 KB of edge-case handling you'd want in production.

The workhorse move for any explainer that draws a trend, a route, a connection or a process arrow. Requires a live stroke on an open path — if your Figma or Illustrator export outlined the stroke into a filled shape, this is impossible and you have to re-export. That single fact drives half of §09.

Note what is being animated: transform and opacity only, never x/y/width/d. Attribute animation forces the browser through Style → Layout → Paint every frame; transform and opacity run on the compositor. This is the single biggest performance lever in SVG animation, and it's a discipline your artwork has to be built for — every bar sits in its own <g> with an explicit transform-box: fill-box.

Shape-to-shape transition is where the tools genuinely diverge. GSAP MorphSVG is the only option in this review that morphs between paths with different point counts — it re-samples and re-indexes automatically. Motion tells you to install Flubber; Anime.js requires identical point counts; CSS d interpolation requires identical command counts and Safari parses it but doesn't apply it. If your explainer says "this chart is really that chart," this one capability is the whole decision.

The peer-reviewed number to plan against comes from Schwab et al., Scalable Scalable Vector Graphics (IEEE TVCG 2022): ~2,500 animated SVG nodes lands around 30 fps, and 15,000–20,000 nodes collapses to ~6 fps. Because rendering and interaction share the main thread, 6 fps also means ~250 ms of input lag — a janky scroll explainer doesn't read as "slow," it reads as broken. Practical bands: under 1,000 nodes is safe everywhere including mid-tier mobile; 1,000–2,500 is fine on desktop and degrading on phones; above ~5,000 go to canvas; above ~50,000 go to WebGL. Your slider above is a desktop-class machine — divide by roughly three for a four-year-old Android.

03Three tiers, one question

The fourteen tools in scope aren't really competing with each other — they occupy three different layers of the stack, and most "which should we use" arguments are people comparing across layers. Sorting them first makes the decision almost mechanical.

The single question that resolves the tier

Does a human need to read words inside the animation? If yes → Tier 1, SVG, non-negotiable. If no — an illustrated character, a product beauty shot, an abstract hero — Tier 2 or 3 is on the table, and should be code-split so it costs nothing for the 60% of visitors who bounce before reaching it.

04Comparison matrix

Sizes are gzip −9, measured from published npm tarballs on 18 Aug 2026. Brotli in production runs roughly 15–25% lower. "Weight" for Tier 2 includes the WASM payload where applicable, which is where the surprises live.

The Tier-1 shortlist, in one paragraph each

05The rendering engines

You asked about physics/3D frameworks specifically, and given the explainer has spatial ambition this is where the money question sits: when is leaving the DOM justified?

Physics, specifically

Nothing in this list needs a physics engine, and adding one is the most common way a scroll explainer gets slow and unpredictable. Three tiers of "physics" worth distinguishing:

• Spring easing — what you almost always actually want. Free in Motion (type: "spring"), in Anime.js, in Svelte's built-in spring store, and in Figma Motion's own easing set. Zero extra bytes.
• Inertia / momentum — GSAP's InertiaPlugin (now free, 4.3 KB) for flick-and-settle interactions. Worth it for a draggable exploration step; pointless on a scrubbed timeline.
• Rigid-body simulation — Rapier (via @react-three/rapier) or Spline's physics module. Note Spline's physics bundle alone is 709 KB gzip, larger than its already-huge runtime. Simulation is fundamentally at odds with scrubbing: you can play a simulation forward on scroll, but you cannot scrub it backwards deterministically without baking it to keyframes first. For an explainer, bake it.

06The design-tool runtimes

07Performance budget & the escalation ladder

Set the budget before choosing the tool, and most arguments resolve themselves. A marketing explainer that loses users to a 3-second LCP has failed regardless of how good the animation is.

Fix these before you change renderer — they're usually worth more than a rewrite

1. Animate transform and opacity only. Changing x, cx, width or d mutates geometry and forces Layout + Paint every frame; transform and opacity run on the compositor. This is the single biggest lever, and per the TVCG paper the browser-side cost of that pipeline is "often greater than the time spent in the visualization's JavaScript code."
2. Kill animated SVG filters. feGaussianBlur and feDropShadow are per-frame raster work, frequently not GPU-accelerated for SVG, and the number-one silent killer of mobile frame rate.
3. Precompute path d strings at build or step time and swap rather than interpolate. Per-frame d rewrites are where most D3 scrollytelling dies.
4. Cull off-screen scenes and use content-visibility: auto on steps that aren't visible.
5. Measure p95/p99 frame time against the 16.7 ms budget, not mean fps. Mean fps hides exactly the stutter users notice.

08What it costs

The commercially interesting finding: the recommended stack costs $0 in licensing, and the two paid tools worth considering are $9/mo (Rive) and $0 (Cavalry, free since April). The expensive options — Spline at $120–150/seat/mo, LottieFiles at ~$50/mo — are also the two least suited to this brief. That's a rare alignment, and it's worth putting in front of the startup explicitly: the technology recommendation and the budget recommendation point the same way.

09Figma / Illustrator → Claude → React & Svelte

The framework choice is maybe a third of the problem. The other two thirds is whether the SVG that comes out of your design tool is animatable at all, and whether Claude can work on it without drowning in path data. Both are solvable at the artwork stage and nearly unfixable afterward.

Four tracks, not one pipeline

Two export presets, permanently

These are mutually incompatible and it's worth saving them as named presets rather than rediscovering the conflict each time. Rive wants inline styles; the web/CSS path wants presentation attributes.

The five artwork rules that decide whether animation is possible

1. One moving thing = one path. Figma collapses multiple shapes merged into a single vector into one d string, which cannot be animated per-part. Fix it at design time: duplicate the layer and delete points from each copy so each animatable element exports as its own path.
2. Live strokes on anything that draws. fill="none", a real stroke attribute, open path. Never Outline Stroke a path you intend to draw. Variable-width brush strokes must be outlined — so those can never be drawn; use a mask reveal instead.
3. Name for the selector you'll write. Kebab-case ASCII, no spaces, no leading digits: scene2__bar-01 … bar-12. Zero-padded indices mean one line of code ([id^="scene2__bar-"] with a stagger) instead of twelve.
4. Group what moves together; flatten what never moves. Every extra <g> is a nested transform to reason about and tokens Claude has to read.
5. Set transform-box: fill-box on anything that rotates or scales. SVG's transform origin defaults to the 0 0 of the whole canvas, not the shape — the classic bug where a rotating icon swings across the screen. transform-box: fill-box has been Baseline since 2020; GSAP additionally offers svgOrigin in user-space coordinates for elements that must share one pivot.

SVGO config that doesn't destroy your animation

SVGO's default preset will delete your viewBox and minify your ids to a, b, c — deterministically, which makes collisions between two optimised files more likely, not less.

// svgo.config.js — for animation assets
export default {
  multipass: true,
  plugins: [
    { name: 'preset-default', params: { overrides: {
      removeViewBox:        false,  // #1 cause of lost responsiveness
      cleanupIds:           false,  // your ids ARE the animation API
      collapseGroups:       false,  // groups are your animation wrappers
      mergePaths:           false,  // never merge separately-animated paths
      convertShapeToPath:   false,  // keep rect/circle for x/y/r animation
      removeHiddenElems:    false,  // layers that start hidden then animate in
      moveElemsAttrsToGroup:false,
      convertPathData:      { floatPrecision: 2 },
      removeUnknownsAndDefaults: { keepDataAttrs: true },
    }}},
    { name: 'removeDimensions' },   // drop width/height, keep viewBox
    { name: 'prefixIds' },          // gradient/clip id collision guard
    // reusePaths: OFF — turns paths into <use>, which can't be animated separately
  ],
};

The part that actually matters for working with Claude

The dominant failure mode isn't the animation code — it's token cost. A detailed illustration or map can be 50k–200k tokens of pure path data. It floods the context window, and worse, Claude cannot tell which sub-curve is which limb. Nothing recovers this after the fact. Three habits fix it permanently:

1. Keep the timeline in a separate file from the SVG markup. scene-03.svg and scene-03.motion.ts. Claude edits the timeline and never loads a single path. This is the single biggest token win available and it costs nothing.
2. Split into one file per beat — scene-01.svg … scene-06.svg, all sharing one viewBox so coordinates stay comparable across scenes. Halves the context per edit and makes review tractable.
3. Ship a MOTION.md next to the scenes listing the id inventory and the intended beat for each. Cheap to write, and it makes every subsequent Claude run consistent rather than re-derived. When you do need Claude to reason about structure, hand it a skeleton — grep -o 'id="[^"]*"' — not the geometry.

The component shape to standardise on

<!-- Scene.svelte — the pattern; React is the same with useGSAP() -->
<script>
  import { onMount } from 'svelte';
  import gsap from 'gsap';
  import ScrollTrigger from 'gsap/ScrollTrigger';
  gsap.registerPlugin(ScrollTrigger);

  let root, stage;
  onMount(() => {
    const mm = gsap.matchMedia();
    mm.add('(prefers-reduced-motion: no-preference)', () => {
      const tl = gsap.timeline({ scrollTrigger: {
        trigger: root, start: 'top top', end: 'bottom bottom',
        scrub: 0.5,                 // scrub IS the explainer — never toggleActions
        invalidateOnRefresh: true,
      }});
      tl.from('#scene1__arrow', { drawSVG: '0%' })
        .from('[id^="scene1__bar-"]', { scaleY: 0, transformOrigin: 'bottom', stagger: .05 })
        .to('#scene1__callout', { autoAlpha: 1 }, '<');
      return () => tl.scrollTrigger?.kill();   // HMR + StrictMode leak guard
    });
    // reduced-motion branch: render the final state, create no timeline at all
    return () => mm.revert();
  });
</script>

<section bind:this={root} class="scroll-root">
  <div bind:this={stage} class="stage"><Scene1 /></div>
  <div class="steps"><!-- text steps establish the scroll length --></div>
</section>

<style>
  .stage { position: sticky; top: 0; height: 100svh; }  /* svh, not vh — mobile URL bar */
</style>

Four structural rules embedded in that snippet, each of which prevents a specific recurring bug: prefer CSS position: sticky over ScrollTrigger's pin: true where you can, because pin rewrites the DOM by injecting a pin-spacer and that surprises both agents and layout assumptions; use 100svh not 100vh, or mobile URL-bar resize will retrigger everything; one timeline per scene component, composed by the page; and always kill on unmount, because React StrictMode's double-mount and Svelte HMR both leak ScrollTriggers otherwise.

Getting the SVG into the component

• Whole-element motion only (fade/slide/scale the graphic as a unit) → keep it as <img src="scene.svg"> and animate the wrapper. Zero token cost, zero inlining. Most scenes qualify for at least part of this.
• Path geometry animates (draw, trim, morph, per-part) → must inline. React: vite-plugin-svgr with svgrOptions: { ref: true } (you need the ref for GSAP) and an explicit svgoConfig, or SVGR's default SVGO run strips your ids. Svelte: @poppanator/sveltekit-svg, or for a handful of hero scenes just paste the SVG into the .svelte file — you get bind:this, reactive bindings and scoped-CSS id handling for free, and Claude sees the markup in the same file it's editing.
• An icon used 50 times → sprite plus <use>, with the caveat that two <use> of the same path can't be animated independently.

Two Figma MCP details worth knowing before you rely on it

• Exact nodeId match beats fallbackNodeId. The fallback is the backing component, shared across every instance — matching on it applies your motion to all of them.
• Interleaved transforms need offset maths. If a node has a static base transform (rotate-45) and animated transforms, get_motion_context returns the absolute value. Animate the offset on the wrapper, or 45° at rest silently becomes 90°.

Where D3 sits in all this

Worth being explicit since it's the house tool: in this architecture D3 is the geometry generator, not the animator. d3-shape, d3-scale, d3-hierarchy, d3-geo, d3-sankey emit the d strings and coordinates; GSAP moves them; ScrollTrigger decides when. Import submodules, never the bundle — the modular subset is 31 KB gzip against 90 KB for full d3.min.js. And for morph transitions, generate both end-state paths with D3 at build time and hand the pair to MorphSVG, rather than interpolating d per frame at runtime.

10Risk register & open items

What I'd do in the first week

1. Build one scene end-to-end — Illustrator artwork → "web" export preset → SVGO → scene-01.svg + scene-01.motion.ts → GSAP scrub in the actual framework. One scene proves the whole pipeline and surfaces every export pathology at once.
2. Decide React vs Svelte on the animation evidence, not just the app. React gets first-party Motion, R3F/drei and Rive hooks; Svelte gets a thinner Three wrapper (Threlte), better native ergonomics for hand-rolled scrollytelling, and the only official dotLottie wrapper — but no official Motion or Rive binding. If the answer is Svelte, GSAP becomes near-mandatory rather than merely recommended.
3. Set the performance budget before the storyboard, so "can this scene be 8,000 dots" is answered by a number rather than an argument.
4. Write the MOTION.md id convention before any artwork is drawn. It's ten minutes and it's the difference between Claude writing your timelines and Claude drowning in path data.