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

> Discover why animating frequently used UI elements degrades performance. Learn about latency, cumulative costs, and perceived speed issues from emilkowalski/skills.

- Repository: [Emil Kowalski/skills](https://github.com/emilkowalski/skills)
- Tags: performance
- Published: 2026-08-06

---

**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`](https://github.com/emilkowalski/skills/blob/main/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`](https://github.com/emilkowalski/skills/blob/main/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`](https://github.com/emilkowalski/skills/blob/main/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:

```css
/* 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:

```css
/* 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:

```css
@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`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/STANDARDS.md) provides runtime enforcement:

```js
/**
 * 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`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/STANDARDS.md) | Source of truth for frequency table and "it looks cool" invalidation |
| [`skills/review-animations/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/review-animations/SKILL.md) | "Justified motion" rule blocks decorative animation on frequent elements |
| [`skills/improve-animations/AUDIT.md`](https://github.com/emilkowalski/skills/blob/main/skills/improve-animations/AUDIT.md) | Audit runs flag high-frequency animations for removal |
| [`skills/find-animation-opportunities/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/skills/find-animation-opportunities/SKILL.md) | Decision matrix explicitly rejects high-frequency cases |
| [`skills/animate/SKILL.md`](https://github.com/emilkowalski/skills/blob/main/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`](https://github.com/emilkowalski/skills/blob/main/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`](https://github.com/emilkowalski/skills/blob/main/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.