Glopzi
Sign up

Responsive

Responsive animations, done right.

Animations that look great on a 27-inch monitor often feel excessive on a phone. Five patterns and one guiding rule to make motion adapt without rebuilding it three times.

The trap of designing for desktop only

The most common mistake: design every animation against a desktop viewport, ship it, and discover on a phone that your hero takes up the entire screen mid-animation, the slide-up is excessive, and the WebGL background drains the battery.

The fix isn’t to rebuild the animation per device. The fix is to describe how it should adapt at design time, in the same editor session.

What actually changes by screen size

The variables that matter as screens shrink:

  • Travel distance. A 60-pixel slide is invisible on desktop, dramatic on mobile. Smaller screens need shorter motions to feel proportional.
  • Duration. Mobile users scroll faster relative to viewport. Animations that play for 1.5s on desktop scroll past entirely on mobile. Make them quicker.
  • Trigger. “In view” is the right default on desktop where elements peek before crossing the fold. On mobile’s short viewport many elements arrive already in view; load triggers can feel more deliberate.
  • Effect intensity. WebGL backgrounds and parallax effects are gorgeous on a quiet desktop. On a phone with thermal throttling, they cost battery and frame budget.

Five reliable patterns

The shortlist of overrides that pay off most often:

  • 1. Halve the travel. Set translate Y to 60 on desktop, override to 30 on tablet, 20 on mobile. The motion feels equally weighty across devices.
  • 2. Trim the duration. 1.2s on desktop, 0.9s on tablet, 0.6s on mobile. Faster motion on faster scroll feels right.
  • 3. Switch in-view to load on mobile. Hero elements often start in view on mobile. Override the trigger to load at the mobile breakpoint so the entrance plays deliberately.
  • 4. Disable WebGL on mobile. WebGL backgrounds are off-by-default on mobile in most polished sites. Override the animation to disabled at the mobile breakpoint and visitors get a flat background instead.
  • 5. Reduce stagger.A 0.1s stagger across ten cards is a delightful cascade on desktop. On mobile’s narrower viewport you only see two cards at a time; cut the stagger to 0.05s or remove it entirely so the visible cards arrive together.

All five are breakpoint overrides on the same animation. You don’t duplicate the animation per device.

When not to override

Overrides are powerful, but they’re not free:

  • Easing curves usually don’t need overriding. A cubic easing reads the same on any screen. Reach for an override when the timing changes; the curve typically stays.
  • Color and visual style usually don’t.Overriding color per breakpoint tends to mean “the original color was wrong” rather than “different screens want different colors”. Fix the underlying color.
  • If you find yourself overriding everything, the desktop version probably isn’t the right starting point. Start over with mobile-first values and let desktop be the override.

Note

Overrides should describe an exception, not the norm. If most properties differ per breakpoint, the animation isn’t responsive: it’s three different animations sharing a name.

Testing across breakpoints

Use the breakpoint switcher in the toolbar while editing. Switch to tablet, scrub the timeline, scroll the canvas. Repeat on mobile. The whole point of editing in the live canvas is that you can validate three viewports in 30 seconds.

For a final pass before publishing, also test on a real device. Browser dev-tools approximate mobile viewport but don’t simulate slower CPUs. Pick up your phone, load a preview, and watch a real entrance run.

Next steps