Scroll-driven animations are everywhere right now. And for good reason — when done well, they transform a website from something you read into something you experience. But they're also one of the easiest things to get wrong. Either you end up with a gimmicky site that prioritises show over substance, or you spend a significant chunk of the budget on interactions that most visitors will scroll straight past.

After building scroll-driven experiences for clients ranging from creative agencies to trade union campaigns, here's how I think about it.

Animation as storytelling, not decoration

The most important question to ask before building any scroll interaction is: "does this help the user understand something, or does it just look impressive in a demo?"

On Ribbit.dk, the scroll animations weren't added to make the site feel premium. They were the whole point! Ribbit is a motion design agency — the site needed to demonstrate that they live and breathe motion. I built a custom PNG sequence player that responds to scroll position, essentially turning the homepage into a filmstrip the user controls. Each frame is a PNG toggled by visibility as you scroll, giving it a tactile, physical feeling that WebGL renderers couldn't match in terms of smoothness.

That's an example where the animation is the message. Removing it would remove the reason the site exists.

On the Din Fagforening (the subpages) on the other hand, we used scroll animations much simpler, but still with a great effect. We didn't want the design and experience to feel long, but we also wanted to have some depth in the content. So we used simple stacks and sticky images with content scrolling above. For many clients this is almost mindblowing, so you don't always have to invent something overly crazy and advanced — it's about the context.

What's actually worth the investment in 2026

Scroll-triggered reveals are cheap to implement and broadly effective. Fading or sliding content into view as it enters the viewport adds a sense of depth and pacing without much overhead. These are almost always worth doing.

Scroll-linked animations — where the animation state is directly tied to your scroll position — are more expensive to build and heavier on performance. They're worth it when they reveal or explain something: a product unfolding, a timeline progressing, a character reacting. On Ribbit.dk, the scroll-linked book-opening on the Process page gave users a physical metaphor for navigating content. That's meaningful. A hero section that just rotates a logo as you scroll, maybe not so much.

Parallax has been overused to the point of being a cliché, but it still works well when used sparingly — layered depths in a hero, a background element that drifts slightly. The mistake is applying it to everything and wondering why the site feels chaotic.

GSAP-based orchestration is what I reach for most often for complex sequences. It handles timing, easing, and scroll synchronisation cleanly, and degrades gracefully.

The performance question

Every animation you add is a potential performance problem. Scroll-linked animations in particular can cause janky experiences if they're touching layout properties like `width`, `height`, or `top`. The rule I follow: animate `transform` and `opacity` almost exclusively. They run on the compositor thread and don't trigger layout recalculations.

For the PNG sequence player on Ribbit, loading all frames upfront was a concern. We preloaded progressively and only toggled visibility — no repaints, no GPU texture uploads mid-scroll. It sounds simple but the implementation required careful testing across devices.

Performance isn't just about Lighthouse scores (though those matter for SEO). It's about whether the animation feels good on a mid-range Android phone at 60fps (the latest Pixel or iPhone running 120fps is rarely a concern). And it's very much about perceived performance in general.

So — is it worth it?

Scroll-driven animations are worth it when they serve the content. They're a liability when they're added because they look good in a Figma prototype.

The best projects I've worked on treat motion as part of the design language from day one — not a layer applied at the end. That's when the development is faster, the result is more coherent, and the client actually gets something that stands out for the right reasons.

If you're considering a website that needs to make an impression — and you want someone who's done this across award-winning agency sites, campaign tools, and creative portfolios — get in touch.

--

Michael Vestergaard is a freelance frontend developer and UX engineer based in Copenhagen. He specialises in highly customized productions that stand out from the crowd.