Designing Motion Without Hurting Performance
It can also completely destroy performance, readability, and trust if used without restraint.
This article is about using motion as a UX tool, not a visual crutch—and how I approach animation decisions in real projects.
Why Motion Exists in the First Place
Motion should answer one of these questions:
- What just changed?
- Where should the user look next?
- How are two states connected?
- Is the system responding?
If an animation does not clearly answer at least one of these, it is likely unnecessary.
Most performance issues with animation don't come from how motion is implemented—but from why it exists at all.
When Motion Improves UX (And When It Doesn't)
Motion Improves UX When:
- ✓ A new element enters the layout and needs context
- ✓ State changes need continuity (e.g., expanding cards, route transitions)
- ✓ Hierarchy needs reinforcement (primary vs secondary actions)
- ✓ Feedback is required (hover, loading, success states)
Examples:
- • A card expanding smoothly into a detail view
- • Page transitions that confirm navigation
- • Buttons responding subtly on hover
Motion Hurts UX When:
- ✗ Text moves while being read
- ✗ Multiple animations compete for attention
- ✗ Motion exists purely for decoration
- ✗ Scroll animations never settle
These patterns increase cognitive load, especially for recruiters or users scanning content quickly.
"If motion draws attention to itself instead of the content, it's doing too much."
GSAP vs Framer Motion: Choosing the Right Tool
I use both GSAP and Framer Motion, but never interchangeably without intent.
Framer Motion
UI-Level Motion
Best for:
- • Component entry/exit
- • Page transitions
- • Hover and tap states
- • Simple scroll reveals
Why:
- • Declarative API fits React well
- • Easy to reason about
- • Lower risk of accidental performance issues
I use Framer Motion wherever motion is tied directly to component lifecycle.
GSAP
Timeline & Scroll-Driven Motion
Best for:
- • Cinematic hero sections
- • Scroll-linked narratives
- • SVG path animations
- • Ambient background motion
Why:
- • Fine-grained control
- • ScrollTrigger offers precise synchronization
- • Better for non-linear motion sequences
I reserve GSAP for intentional, isolated areas—never across the entire site.
ScrollTrigger Pitfalls I Actively Avoid
Scroll-based animation is powerful—and dangerous. Here are mistakes I've made early on, and now actively avoid:
1. Animations That Never Finish
Animations that continuously scrub with scroll can feel impressive but quickly become exhausting.
Fix:
Let animations complete. Use scroll to trigger, not to endlessly control.
2. Animating Text on Scroll
Moving paragraphs while reading breaks comprehension.
Fix:
Animate containers in, then let text remain static.
3. Too Many Triggers
Multiple ScrollTriggers firing simultaneously increases CPU usage and makes behavior unpredictable.
Fix:
Consolidate timelines. One section = one animation context.
4. Ignoring Reduced Motion Preferences
This is both an accessibility and professionalism issue.
Fix:
Respect prefers-reduced-motion and disable non-essential animations.
Performance Is a UX Feature
A smooth animation that drops frames is worse than no animation at all.
Some principles I follow:
- →Avoid layout-thrashing properties (top, left, width)
- →Prefer transforms and opacity
- →Lazy-load heavy animation libraries
- →Reduce motion on mobile
- →Never animate during critical interactions
Before keeping any animation, I ask:
"Would I remove this if it caused even a slight delay?"
If the answer is no, it doesn't belong.
Real Examples From My Projects
Product Landing & Portfolio Pages
- •Motion is used to introduce sections
- •Visual hierarchy is reinforced through timing
- •Animations complete quickly and never loop
Real-Time Applications (e.g., Medivue)
- •Motion is minimal
- •Feedback is immediate
- •Performance and clarity override visual flair
In real-time systems, animation should get out of the way.
My Rule of Thumb
If I had to reduce everything to one principle, it would be this:
Motion should make interfaces feel easier—not more impressive.
Well-designed motion is often invisible.
Poorly designed motion is unforgettable for the wrong reasons.
Closing Thought
As frontend engineers, it's tempting to show everything we can do.
Restraint is harder—and far more valuable.
Designing motion without hurting performance isn't about limiting creativity.
It's about earning trust—from users, and from the people reviewing your work.