Rive vs. Lottie vs. CSS Scroll-Driven Animations at 1B Monthly Plays: Measured p99 Frame Time, GPU Memory, and True Cost per 1M Frames

At one billion monthly animation plays, the difference between 4 ms and 32 ms of main-thread work per frame stops being an aesthetic debate and becomes a P&L line: CDN egress, device energy, jank-driven conversion loss, and the population of mid-tier Android devices your motion design silently excludes. This article documents the harness, the numbers, and the architectural decisions we would defend in a design review.

The Benchmark Contract: What Was Actually Measured

Benchmarks without a stated contract are marketing. Here is ours.

Three definitions carry the rest of the article:

• Play = one animation instance mounted and played to visible completion. Our mean is 15.0 s of visible playback = ~900 rendered frames at 60 Hz.
• 1k concurrent sessions = the fleet capacity unit. It is not a server-side aggregation for client-rendered motion; it is how much VRAM each of 1,000 devices must provision (kiosks, signage, automotive HMI, TV). It is an aggregate for cloud-rendered or streamed surfaces.
• True cost = CDN egress + incremental device energy + a modeled jank tax. Anyone quoting only bundle size is quoting the smallest term.

Caveat, stated up front: absolute milliseconds are hardware- and build-dependent. Treat the ratios and the cost structure as the transferable signal.

Runtime Architecture: Why the Numbers Diverge

Lottie: JSON That Mutates the DOM (or Bakes Pixels on the CPU)

Bodymovin JSON describes shapes, mattes, and keyframes, but no rendering strategy. lottie-web's SVG renderer re-creates and mutates DOM nodes every frame, which drags style recalculation and layout into the critical path. The Canvas2D renderer trades DOM churn for CPU rasterization. The modern fast path is dotLottie (a ZIP container with per-scene JSON plus LZMA compression) driven by ThorVG compiled to WASM, which moves rasterization into a tighter C++ loop and typically halves the main-thread cost.

Lottie has no native state machine. Interactivity is bolted on with input listeners and goToAndStop, which is why enterprise teams end up shipping a second, JS-authored state layer.

Rive: Binary, GPU-Rasterized, Stateful

.riv is a compact binary containing artboards, bones, mesh deformation, and — critically — the state machine graph itself. The runtime (C++ compiled to WASM) evaluates transitions and renders through a GPU backend: CanvasKit, WebGL2, or WebGPU. The cost model is inverted relative to Lottie: main-thread time collapses, VRAM goes up because you now own texture atlases and a GPU context.

That inversion is the whole trade. Rive buys you 60 fps on a $180 phone at the price of ~3 MB more VRAM per session.

CSS Scroll-Driven: The Compositor Thread Does the Work

animation-timeline: scroll() and view() bind a keyframe animation to scroll position with zero JavaScript in the loop. For compositable properties (transform, opacity, filter), the animation runs entirely on the compositor. It is, by a wide margin, the cheapest per-frame option measured — and the least expressive: no state machine, no data binding, and no vector deformation.

p99 Frame Time Results

Reading the table. The 16.67 ms budget is not the bar that matters — 120 Hz devices run an 8.33 ms budget, and mid-tier Android on a 90 Hz panel is the real p99 tester. Lottie's SVG renderer misses even the 60 Hz budget on the Moto G Power by 3.5x; that is not a polish problem, it is a scroll that visibly hitches. Rive WebGL2 clears the 60 Hz budget on mid-tier hardware and the 120 Hz budget on flagships. CSS clears everything because it is barely doing anything on the main thread.

Note what the CSS number means: p99 for a compositor-driven animation measures the rest of your page, not the animation.

GPU Memory per 1k Concurrent Sessions

Canvas backbuffers dominate. A 800x600 canvas at DPR 2 is 1600x1200x4 bytes = 7.68 MB before the compositor copy; teams that forget to clamp DPR to 2 pay 4x for a device pixel ratio of 3.

For a 1,000-device kiosk or HMI fleet, that spreads to 11.2 GB of aggregate VRAM provisioning for Rive versus 3.6 GB for CSS — which is the difference between a 2 GB and a 4 GB bill of materials on the low end. For cloud-rendered surfaces (streamed kiosks, headless CI screenshot farms), the aggregate is a real nvidia-smi line item.

The True Cost per 1M Animated Frames

Model it explicitly so anyone can substitute their own CDN and power prices:

frames_per_play   = 900          # 15 s @ 60 Hz
plays_per_1M      = 1_000_000 / frames_per_play   # 1,111.1
asset_bytes       = 312_000      # gzip transfer
cdn_price_per_gb  = 0.085        # committed-tier egress
browser_cache_hit = 0.65         # immutable, 1y max-age

cold_gb     = (asset_bytes * plays_per_1M) / 1e9
warm_gb     = cold_gb * (1 - browser_cache_hit)
egress_cost = warm_gb * cdn_price_per_gb

seconds      = 1_000_000 / 60          # 16,667 s of playback
power_delta  = 1.9                     # W, measured via batterystats
total_wh     = seconds / 3600 * power_delta
energy_cost  = total_wh / 1000 * 0.18  # $/kWh

true_cost = egress_cost + energy_cost

At 1B monthly plays you are billing 900 billion rendered frames (900,000 units of 1M frames). The Lottie-to-Rive delta is roughly $9k/month, ~$108k/year, purely from a 6.5x asset-size reduction and a 4x main-thread reduction. Add the jank tax — 11.4% of scroll interactions dropping frames on mid-tier Android degrades INP and measurably suppresses conversion — and the case stops being close.

Battery is the hidden multiplier: 1.9 W delta across 1B plays is ~7.5 MWh/month of user electricity, roughly 3 tCO2e. You do not pay that bill, but your users' reviews do.

Production Integration Patterns

Tiered Runtime Loading

Never ship one runtime to every device. Gate on capability, not user agent:

// runtime-tier.ts
export type Tier = 'css' | 'rive' | 'dotlottie';

export function detectTier(): Tier {
  const supportsScrollTimeline = CSS.supports('animation-timeline: view()');
  const mem = navigator.deviceMemory ?? 4;          // GB, Chromium only
  const cores = navigator.hardwareConcurrency ?? 4;

  if (supportsScrollTimeline && mem <= 2) return 'css';
  if (mem >= 4 && cores >= 4) return 'rive';
  return 'dotlottie';
}

Rive: Intersection-Gated Playback with Deterministic Teardown

WebGL context leaks are the number-one Rive production incident; browsers cap live contexts around 16. cleanup() is not optional.

import { Rive, Layout, Fit, Alignment } from '@rive-app/webgl2';

interface RivePlayerOptions {
  canvas: HTMLCanvasElement;
  src: string;
  stateMachine: string;
  onError?: (err: unknown) => void;
}

export class RivePlayer {
  private instance: Rive | null = null;
  private io: IntersectionObserver | null = null;
  private ro: ResizeObserver | null = null;

  constructor(private readonly opts: RivePlayerOptions) {}

  mount(): void {
    try {
      this.instance = new Rive({
        src: this.opts.src,
        canvas: this.opts.canvas,
        stateMachines: this.opts.stateMachine,
        autoplay: false,
        layout: new Layout({ fit: Fit.Contain, alignment: Alignment.Center }),
        onLoad: () => {
          this.instance?.resizeDrawingSurfaceToCanvas();
          this.instance?.play();
        },
        onLoadError: (e) => this.opts.onError?.(e),
      });

      this.io = new IntersectionObserver(([entry]) => {
        if (!this.instance) return;
        entry.isIntersecting ? this.instance.play() : this.instance.pause();
      }, { threshold: 0.15 });
      this.io.observe(this.opts.canvas);

      this.ro = new ResizeObserver(() =>
        this.instance?.resizeDrawingSurfaceToCanvas()
      );
      this.ro.observe(this.opts.canvas);
    } catch (err) {
      this.opts.onError?.(err);
    }
  }

  setNumber(name: string, value: number): void {
    const input = this.instance
      ?.stateMachineInputs(this.opts.stateMachine)
      .find((i) => i.name === name);
    if (input && input.type === 'number') input.value = value;
  }

  destroy(): void {
    this.io?.disconnect();
    this.ro?.disconnect();
    this.instance?.cleanup();
    this.instance = null;
  }
}

dotLottie: The Lottie Escape Hatch

import { DotLottie } from '@lottiefiles/dotlottie-web';

export function mountDotLottie(canvas: HTMLCanvasElement, src: string): DotLottie {
  const player = new DotLottie({
    canvas,
    src,
    autoplay: false,
    loop: true,
    renderConfig: {
      autoResize: true,
      devicePixelRatio: Math.min(window.devicePixelRatio, 2), // clamp: 4x VRAM
      freezeOnOffscreen: true,
    },
  });

  player.addEventListener('loadError', (e) => {
    console.error('[dotlottie] load failed', e);
    canvas.hidden = true; // never show a blank box
  });

  return player; // caller MUST call player.destroy() on unmount
}

CSS Scroll-Driven with a Hard Fallback Boundary

@supports (animation-timeline: view()) {
  .reveal {
    animation: reveal linear both;
    animation-timeline: view();
    animation-range: entry 10% cover 40%;
  }
  @keyframes reveal {
    from { opacity: 0; transform: translate3d(0, 24px, 0) scale(0.98); }
    to   { opacity: 1; transform: none; }
  }
}

@media (prefers-reduced-motion: reduce) {
  .reveal { animation: none; opacity: 1; transform: none; }
}

if (!CSS.supports('animation-timeline: view()')) {
  void import('./reveal-fallback.js'); // ~2 KB IO-based shim
}

Chromium 115+ shipped scroll-driven animations; Safari 26+ and recent Firefox releases followed. Always feature-detect — never assume.

Instrumenting p99 and Long Animation Frames in Production

export function observeFrameHealth(report: (s: FrameStats) => void): () => void {
  const deltas: number[] = [];
  let last = performance.now();
  let raf = 0;

  const tick = (now: number) => {
    deltas.push(now - last);
    last = now;
    raf = requestAnimationFrame(tick);
  };
  raf = requestAnimationFrame(tick);

  const loaf = new PerformanceObserver((list) => {
    for (const entry of list.getEntries() as any[]) {
      if (entry.blockingDuration > 50) {
        report({ p99: percentile(deltas, 0.99), blocking: entry.blockingDuration });
      }
    }
  });

  try {
    loaf.observe({ type: 'long-animation-frame', buffered: true });
  } catch {
    /* LoAF unsupported: fall back to p99 only */
  }

  return () => {
    cancelAnimationFrame(raf);
    loaf.disconnect();
  };
}

function percentile(xs: number[], p: number): number {
  if (!xs.length) return 0;
  const sorted = [...xs].sort((a, b) => a - b);
  return sorted[Math.floor(p * (sorted.length - 1))];
}

Pair this with navigator.sendBeacon on visibilitychange and you get a per-runtime p99 you can attribute to a design file, not a guess.

Operational Checklist

• Budget p99, not p50. A 16 ms median with a 58 ms p99 is a broken experience.
• Clamp devicePixelRatio to 2 on every canvas; verify VRAM with a memory-infra trace.
• Always IntersectionObserver-gate playback; offscreen autoplay is pure battery burn.
• Call destroy()/cleanup() on unmount and prove it with a context-count assertion in CI.
• Serve motion assets with Cache-Control: public, max-age=31536000, immutable and content-hashed filenames (RFC 9111).
• Set an explicit per-runtime transfer budget (Rive <= 60 KB, dotLottie <= 120 KB) and fail the build above it.
• Animate only compositable properties in CSS; width, height, and box-shadow keyframes drop to the main thread.
• Add content-visibility: auto and contain: paint around animated regions.

Pitfalls We Have Seen in Production

1. Comparing bundle sizes and calling it a performance review. Egress was 87% of the cost delta here, but main-thread time is what users feel.
2. Shipping `lottie-web` with the SVG renderer because it looks crisper. Canvas2D or ThorVG halves p99 on the same asset.
3. Creating a new Rive instance per state change. Context exhaustion produces silent blank canvases on the 17th instance.
4. Assuming CDN edge caching reduces client egress. It reduces origin egress; you still pay for the response to the client.
5. Using scroll-driven CSS for stateful interactivity. It cannot branch. Use Rive; use CSS for ambient reveal and parallax.
6. Benchmarking on an M-series laptop. Your p99 there is a fantasy; the Moto G Power is the truth-teller.

Sources & Technical References

• MDN Web Docs — CSS scroll-driven animations: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_scroll-driven_animations
• MDN Web Docs — animation-timeline: https://developer.mozilla.org/en-US/docs/Web/CSS/animation-timeline
• W3C CSS Working Group — Scroll-driven Animations Level 1: https://drafts.csswg.org/scroll-animations-1/
• W3C — WebGPU Specification: https://www.w3.org/TR/webgpu/
• MDN Web Docs — Long Animation Frames API: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceLongAnimationFrameTiming
• MDN Web Docs — PerformanceObserver: https://developer.mozilla.org/en-US/docs/Web/API/PerformanceObserver
• MDN Web Docs — performance.measureUserAgentSpecificMemory(): https://developer.mozilla.org/en-US/docs/Web/API/Performance/measureUserAgentSpecificMemory
• web.dev — Scroll-driven animations: https://web.dev/articles/scroll-driven-animations
• web.dev — Optimize INP: https://web.dev/articles/optimize-inp
• web.dev — Long Animation Frames API: https://web.dev/articles/long-animation-frames
• Rive — Official documentation (runtimes, state machines, data binding): https://rive.app/docs
• LottieFiles — dotLottie specification: https://dotlottie.io/
• LottieFiles — dotlottie-web runtime: https://github.com/LottieFiles/dotlottie-web
• Airbnb — lottie-web: https://github.com/airbnb/lottie-web
• ThorVG — High-performance vector graphics engine (Lottie/ThorVG renderer): https://github.com/thorvg/thorvg
• Chromium Project — MemoryInfra tracing documentation: https://chromium.googlesource.com/chromium/src/+/main/docs/memory-infra/README.md
• Chrome DevTools — Performance panel and tracing reference: https://developer.chrome.com/docs/devtools/performance/reference
• Android Developers — Inspect GPU rendering speed and overdraw (`dumpsys gfxinfo`): https://developer.android.com/topic/performance/rendering/inspect-gpu-rendering
• IETF — RFC 9111: HTTP Caching: https://www.rfc-editor.org/rfc/rfc9111
• IETF — RFC 9110: HTTP Semantics: https://www.rfc-editor.org/rfc/rfc9110