Why Frequently Used Elements Should Not Be Animated: Performance-Based Rules from emilkowalski/skills

Frequently used UI elements should not be animated because every animation adds latency, visual noise, and cumulative performance costs that degrade perceived speed when triggered hundreds of times per day.

Animations on high-frequency interactions—keyboard shortcuts, hover effects, and command palette toggles—violate the core principle that motion must serve a purpose. The emilkowalski/skills repository codifies this through a strict frequency-based decision table that eliminates decorative motion from daily-use elements.

The Frequency-Based Animation Decision Table

The repository's animation standards in skills/review-animations/STANDARDS.md establish a clear hierarchy for when motion is justified:

Frequency	Decision	Rationale
100+ times/day (keyboard shortcuts, command palette)	No animation – ever	Cumulative delay becomes user-perceivable
Tens of times/day (hover effects, list navigation)	Remove or drastically reduce	Visual noise without informational value
Occasional (modals, drawers, toasts)	Standard animation	Motion communicates context and state
Rare / first-time (onboarding, celebrations)	Add delight if desired	Low repetition cost justifies polish

This table is not advisory—it is enforced architecture. The repository treats any "it looks cool" justification for high-frequency animation as explicitly invalid.

Why Animation Hurts High-Frequency Elements

Performance: The Cumulative Cost

Every animation forces the browser through repaint and re-layout cycles. A single 200ms fade-in appears trivial, but multiplied across 300 daily interactions, it introduces 60 seconds of cumulative wait time. The skills/review-animations/STANDARDS.md file documents this as the primary technical barrier to frequent-element animation.

Perceived Speed vs. Actual Speed

Users do not distinguish between network latency and animation latency. A button press with a 200ms fade-in feels slower than an instant state change, even when the underlying operation completes instantly. The repository emphasizes that perceived responsiveness directly correlates with business metrics—no animation beats "smooth" animation for frequent tasks.

Signal vs. Decoration

skills/review-animations/SKILL.md defines valid purposes for motion: spatial consistency, state indication, feedback, explanation, and preventing jarring changes. Decorative motion on frequently seen elements satisfies none of these. The standards explicitly reject "it looks cool" as a valid purpose for high-frequency interactions.

Implementation: Removing Animation from High-Frequency Elements

CSS Patterns for Instant Response

For keyboard-initiated toggles—used potentially hundreds of times daily—eliminate transitions entirely:

/* Completely remove animation for keyboard-initiated toggles */
.toggle[data-trigger="keyboard"] {
  transition: none;  /* No animation, instant response */
}

For press feedback on buttons, keep transitions under 150ms and strictly functional:

/* Only subtle scale for press feedback – no extra transition */
.button:active {
  transform: scale(0.97);
  transition: transform 120ms ease-out; /* short, responsive */
}

Respecting Reduced-Motion Preferences

The repository mandates prefers-reduced-motion compliance, which doubly protects frequent-element performance:

@media (prefers-reduced-motion: reduce) {
  /* Turn off any decorative motion */
  .hover-effect,
  .list-item {
    transition: none;
    animation: none;
  }
}

Programmatic Animation Gating

The shouldAnimate() utility in skills/review-animations/STANDARDS.md provides runtime enforcement:

/**
 * Returns true if the element's interaction frequency warrants animation.
 * Frequencies: 'high' (100+/day), 'medium' (tens/day), 'low' (occasional), 'rare'.
 */
export function shouldAnimate(frequency) {
  const rules = {
    high: false,   // never animate
    medium: false, // remove or drastically reduce
    low: true,     // standard animation
    rare: true,    // can add delight
  };
  return rules[frequency] ?? false;
}

// Example usage:
if (shouldAnimate('high')) {
  element.style.transition = 'opacity 200ms ease-out';
}

Where These Rules Are Enforced

The principle that frequently used elements should not be animated propagates across multiple skill files in emilkowalski/skills:

File	Enforcement Role
skills/review-animations/STANDARDS.md	Source of truth for frequency table and "it looks cool" invalidation
skills/review-animations/SKILL.md	"Justified motion" rule blocks decorative animation on frequent elements
skills/improve-animations/AUDIT.md	Audit runs flag high-frequency animations for removal
skills/find-animation-opportunities/SKILL.md	Decision matrix explicitly rejects high-frequency cases
skills/animate/SKILL.md	General guidance includes the "it looks cool" guard clause

Summary

• 100+ daily interactions should never have animation—latency compounds into user-perceivable delay
• Performance budget: every animation costs repaint cycles; frequent elements exhaust that budget immediately
• Valid motion purposes (spatial consistency, state indication, feedback) exclude decoration on high-frequency elements
• Implementation: use CSS transition: none, sub-150ms functional transitions, and the shouldAnimate() gate
• Repository source: skills/review-animations/STANDARDS.md defines the canonical frequency-based decision table

Frequently Asked Questions

How do I determine an element's interaction frequency?

Audit your analytics or instrumentation for raw event counts. The emilkowalski/skills repository suggests thresholds: 100+ daily uses is "high," tens per day is "medium," occasional use is "low," and first-time or rare experiences qualify as "rare." When in doubt, err toward no animation—removing it is cheaper than adding it back after performance complaints.

Does this rule apply to micro-interactions like button press feedback?

Yes, but with modification. Press feedback should exist but remain under 120-150ms and use transform-only properties (scale, translate) that avoid layout thrashing. The repository permits transform: scale(0.97) on :active states because it confirms user action without perceptible delay.

What about hover effects on navigation items?

Navigation hovers typically fall into "medium" frequency (tens per day) and should be drastically reduced or removed. Consider instant color changes without transition, or sub-100ms opacity shifts. The skills/improve-animations/AUDIT.md file specifically flags hover-heavy navigation for review.

Is respecting prefers-reduced-motion sufficient for accessibility?

No—prefers-reduced-motion is a user override, not a performance strategy. The repository requires unconditional removal of animation from high-frequency elements, then layers prefers-reduced-motion support on top. This protects all users from cumulative latency, not just those with motion sensitivity.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}