Building Motion-Heavy Websites Without Destroying Mobile Performance

Jiant Ramadan — Tue, 08 Sep 2026 17:40:34 +0000

Lessons from building animation-heavy web experiences with GSAP, WAAPI, SVG, lazy mounting, and device-aware motion.

Animation is easy to add to a website.

Making a website feel heavily animated without making it feel heavy is a different problem.

I ran into this while building Enviory, a digital wedding invitation platform where motion isn't just decoration. Each invitation is designed more like a small interactive experience: animated typography, layered illustrations, scroll-driven scenes, image transitions, and decorative elements all have to work together.

On desktop, this is relatively forgiving.

On a mid-range phone, it isn't.

A theme that looks perfectly smooth on my development machine can suddenly become a collection of dropped frames, delayed images, and expensive repaints on mobile.

Over time, I stopped treating animation performance as an optimization step and started treating it as part of the animation architecture itself.

Here are some of the lessons that made the biggest difference.

1. Not Everything Needs an Animation Library

My first instinct was to put most motion behind the same animation system.

That makes orchestration convenient, but it also means you're reaching for a relatively powerful abstraction even for things the browser can already do extremely well.

I eventually settled on a simpler division:

CSS for simple loops and state transitions
WAAPI for lightweight imperative animation
GSAP for timelines, complex sequencing, and scroll-driven interactions
JavaScript only when the animation actually needs application state or runtime calculation

A decorative flower gently floating forever doesn't need a GSAP timeline.

A sequence where multiple layers enter, overlap, react to scroll position, and hand control to another scene probably does.

The goal isn't to use the smallest amount of JavaScript possible.

It's to use the cheapest tool that still expresses the motion correctly.

2. The Best Optimization Is Sometimes Not Rendering

One of the biggest improvements came from changing how scenes were mounted.

A long interactive page might contain many sections with images, decorative SVGs, animation timelines, observers, and event handlers.

Even if most of them aren't visible, they can still contribute to initialization cost.

Instead of initializing the entire experience immediately, I started treating scenes outside the viewport as future work.

Conceptually:

const observer = new IntersectionObserver(
  entries => {
    for (const entry of entries) {
      if (entry.isIntersecting) {
        mountScene(entry.target)
      }
    }
  },
  {
    rootMargin: "600px"
  }
)

The extra margin is important.

Waiting until something actually enters the viewport is often too late. By mounting slightly ahead of the user, expensive work happens before the scene is needed without initializing the entire page upfront.

This ended up being useful for more than animation.

It also helped with images, scene-specific logic, and other resources that didn't need to exist during initial render.

3. SVG Can Be Surprisingly Expensive

I love SVG for interactive design.

It's scalable, editable, scriptable, and works beautifully when transferring visual systems from design tools into the browser.

But "vector" doesn't automatically mean "cheap."

This became particularly obvious with SVG filters.

Effects involving things like:

<feTurbulence />
<feDisplacementMap />

can look harmless in a static design but become surprisingly expensive when the affected element is moving.

A textured illustration that was perfectly smooth on desktop could become one of the most expensive parts of a scene on mobile.

My rule became:

Keep the vector representation when being vector actually provides value.

Simple paths, shapes, masks, gradients, and shadows can stay SVG.

Complex texture/displacement effects that don't need to change dynamically can often be rasterized.

You lose some theoretical flexibility.

You gain a much cheaper frame.

For an effect nobody will edit independently, that's usually a good trade.

4. Animate Compositor-Friendly Properties Whenever Possible

This one is well known, but it becomes much more important once several animations run simultaneously.

Prefer:

transform
opacity

over properties that repeatedly affect layout or paint.

That doesn't mean every transform animation is automatically cheap. Huge layers, filters, excessive compositing, and large transparent images can still hurt.

But it gives the browser a much better starting point.

I also became much more conservative with will-change.

It's tempting to put:

will-change: transform;

on every animated element.

Don't.

Promoting everything can increase memory usage and eventually work against you. I use it for elements that genuinely benefit from compositor promotion rather than as a global "make animation fast" switch.

5. Mobile Should Be a Motion Tier, Not a Smaller Desktop

This was probably the biggest architectural change.

Originally, responsive motion mostly meant adjusting values:

desktop movement: 120px
mobile movement: 70px

But mobile performance isn't just a question of distance.

A phone has different constraints: GPU capability, memory, viewport behavior, touch interaction, thermal limits, and potentially battery-saving modes.

So I started thinking in motion tiers.

A high-performance environment can receive the full experience.

A constrained device can receive fewer simultaneous effects, simpler transitions, reduced parallax, cheaper decorative animation, or different timing.

And prefers-reduced-motion remains a separate accessibility concern rather than being treated as a performance mode.

This means the visual language stays consistent while the implementation cost changes.

6. Optimize the Frame, Not the Lighthouse Score

Lighthouse is useful.

But an animation can pass Lighthouse and still feel terrible.

For motion-heavy interfaces, I care about questions like:

Does scrolling stay responsive while a scene initializes?
Are images already available when their animation starts?
Does returning to a previous section trigger expensive work again?
Are multiple animations competing during the same frame?
Does an iframe or embedded preview behave differently from the full page?
Does performance degrade after several minutes of interaction?

Some of the worst issues I've encountered weren't obvious in a synthetic performance report.

They were obvious after using the site on an actual phone for thirty seconds.

7. Design and Performance Can't Be Separate Systems

The biggest lesson wasn't about GSAP, SVG, React, or any particular API.

It was about workflow.

If a designer creates an effect without considering how it will be rendered, the developer eventually has to choose between reproducing it faithfully and keeping it performant.

If performance constraints are part of the design system from the beginning, that conflict becomes much smaller.

My current workflow is closer to:

Design
  ↓
Determine visual primitives
  ↓
Choose rendering strategy
  ↓
Choose motion primitive
  ↓
Define device tiers
  ↓
Implement
  ↓
Test on real mobile hardware

Instead of:

Design → Implement everything → Optimize later

That small change in thinking has saved me a lot of time.

Final Thoughts

Building Enviory changed the way I think about web animation.

I used to think about motion mostly in terms of timing, easing, choreography, and visual hierarchy.

I still care about all of those things.

But now I also think about rendering cost as another design constraint.

A beautiful animation that consistently drops frames isn't finished.

Sometimes the best optimization is a different API.

Sometimes it's rasterizing one decorative layer.

Sometimes it's mounting a scene 600 pixels before it's needed.

And sometimes it's simply deciding that an effect doesn't deserve to run on every device.

The goal isn't maximum animation.

It's maximum perceived experience for the rendering budget you have.

DEV Community: Jiant Ramadan