Scroll Image Sequence, you've probably seen it on Apple's product pages or Terminal Industries. As you scroll, what looks like a video playback is actually an image sequence playing on scroll which gives off that cinematic experience.

It's one of a practical alternative to 3D storytelling. Pre-rendered frames instead of WebGL or Three.js — same visual impact, without the runtime complexity.

How We Got Here

We've been using scroll image sequences across our recent projects — most notably in WowFactories, where it became central to the storytelling. Building it pushed us to figure out what actually works in production and what falls apart under real conditions: different devices, slow networks, multiple sequences on the same page.

We tested three approaches and each one taught us something.

Approach 1: Spritesheet

A spritesheet stitches every frame into a single large image. Instead of loading hundreds of files, you load one. CSS background-position shifts the visible area to reveal each frame as scroll position changes — the same technique behind classic 2D game animation.

‍

However, the problem shows up fast. Even at 30 frames, the sheet becomes enormous. All frames packed into one fixed canvas means each frame shrinks to fit — lower resolution, visible quality degradation. The more frames you add, the worse it gets.

Going beyond 100 frames is not even worth attempting.

Approach 2: Draw on Canvas

All animation frames are preloaded as JavaScript Image objects, then the HTML5 Canvas API draws them one by one on each scroll tick. We used GSAP's ScrollTrigger to drive the frame updates. This video really helped us get it running.

However under pressure, it breaks in a frustrating way: it fails silently. When the draw function is called on an image that hasn't finished loading, it draws nothing. Slow network, fast scroll, any CDN latency; blank frames appear throughout.

Every frame requires clearing the canvas, recalculating dimensions, and painting pixels through JavaScript before anything reaches the screen. On mid-range mobile at scroll speed, that overhead adds up.

Canvas is worth it if you need frames to be interactive — shaders, blend modes, per-frame colour grading. For just showing images in sequence, it's unnecessary overhead.

Approach 3: Image src Swap

On each scroll tick, the src is updated to the current frame's URL. The browser handles decoding and rendering natively — no canvas, no pixel painting.

Two things make this reliable at scale:

Two quality tiers. Low-res frames load first at higher concurrency, high-res load quietly in the background. While scrolling, you see low-res. When you stop, high-res swaps in silently. Something is always visible, quality improves when it matters.

Nearest frame fallback. Instead of trying to show a specific frame and drawing nothing on failure, the logic scans outward to find the closest loaded frame. A frame that's one or two positions off is imperceptible at scroll speed. A blank frame isn't.

So What's Right for You?

Spritesheet — if your sequence is under 80–100 frames and you want the simplest possible setup. Great for hover animations, icon loops, or small decorative moments where you don't want the overhead of a full loading pipeline.

Draw on Canvas — when the frame itself needs to be interactive. Shaders, blend modes, colour grading, compositing effects — if you need to manipulate what's being rendered at a per-frame level, canvas gives you that control. Just need to ensure that images are fully preloaded before the animation becomes interactive.

img src swap — when you're building something that needs to hold up in production. No per-frame interaction, just reliable smooth playback across devices, network conditions, and multiple sequences on the same page. The setup is more involved, but the reliability ceiling is far higher.