Door 20 – Animation Performance

Animations are a powerful tool. They make interactions more understandable, create orientation, and lend UIs a noticeable elegance. But used incorrectly, they can have the opposite effect. Stuttering, poor performance, and unnecessary repaints are typical symptoms of non-performant CSS animations.

In large applications (SaaS, dashboards, enterprise UIs), animation performance is not a nice-to-have, but essential. This door explains what is really performant, what mistakes to avoid, and how to implement animations cleanly.

The Most Important Rule: Only Animate transform and opacity

The rendering pipeline of modern browsers is highly optimized, but only under certain conditions. The browser can truly only animate two CSS properties performantly: transform and opacity. These two properties have a fundamental characteristic that distinguishes them from all others – they can be rendered entirely on the GPU without the browser needing to recalculate the layout or repaint large portions of the page.

When you animate other properties like width, height, or margin, the browser goes through the complete rendering pipeline on every frame. This means concretely: layout calculation for all affected elements, paint operations for all visible areas, and finally compositing. In complex layouts with many nested elements, this can lead to significant performance degradation. Even on modern desktop computers, frame drops are noticeable; on mobile devices, the animation often becomes completely stuttered.

transform and opacity, however, don’t trigger a reflow. The browser automatically creates separate composite layers for animated elements, which can be processed independently from the rest of the DOM. These layers are rendered directly on the GPU, which is extremely efficient for such operations. The GPU can simultaneously move, scale, rotate, or fade many layers without the CPU even being involved. The result is smooth 60fps animations, even on low-end devices and that as long as you don’t overdo it and animate too many elements at once.

A practical example illustrates the elegance of this approach:

.element {
  opacity: 0;
  transform: translateY(6px);
  transition: opacity 150ms ease, transform 150ms ease;
}

.element[data-active="true"] {
  opacity: 1;
  transform: translateY(0);
}

This code animates an element when it appears. It starts slightly shifted downward and invisible, then glides upward to its final position while fading in. The entire animation runs on the GPU without triggering a single reflow. This is fast, stable, and robust, working reliably across all modern browsers and devices.

Properties You Should Not Animate

The list of CSS properties that trigger layout recalculations is long and surprising. Many properties that you would intuitively animate are problematic from a performance perspective. Understanding why certain properties are expensive helps enormously in developing performant animations.

Properties like width and height are classic performance killers. Every change to these values forces the browser to recalculate the layout of the entire document. This is because changes to an element’s dimensions can affect all surrounding elements. An element that grows wider can cause its container to reflow, sibling elements to shift, or even the entire page layout to rearrange. In the worst case, the browser must traverse the complete DOM tree and check every element to see if it’s affected by the change.

Positioning properties like top, left, right, and bottom have the same effect. They change the position of elements in the layout tree and force complete recalculations. margin and padding also fall into this category because they influence the available space for other elements. border-width is also problematic because changes in border width alter the effective dimensions of the element.

Even box-shadow should be animated with caution. Although shadows don’t trigger layout changes, they are paint-intensive. The browser must re-render the shadow on every frame, which can be expensive especially for large elements or blurred shadows. On modern desktop browsers this might be acceptable, but on mobile devices it often leads to visible frame drops.

filter is a special case. Filters like blur(), brightness(), or contrast() can be very expensive depending on the browser and device. Modern browsers try to render filters on the GPU, but not all filters can be efficiently accelerated. blur() is particularly expensive because it requires complex calculations for every pixel.

A typical anti-pattern found in many projects is animating height:

.panel {
  transition: height 300ms ease; /* Problematic */
}

On every frame of the animation, the browser must recalculate the layout. For a panel with many child elements, this can lead to significant performance issues. The better solution is a compromise with max-height:

.panel {
  max-height: 0;
  overflow: hidden;
  transition: max-height 300ms ease; /* limited layout costs */
}

max-height also triggers reflows, but is significantly more performant than animating height: auto. The trick is to set max-height to a value larger than the actually needed space. The panel then opens within this frame, and the browser can better optimize the changes.

An important note: if the actual content is smaller than the specified max-height, the animation ends earlier than the defined duration. This can lead to uneven timings. In practice, however, this is often acceptable, especially when the approximate content height is known.

Even better is to completely avoid layout properties and work purely with transform and opacity:

.panel {
  opacity: 0;
  transform: scale(0.95);
}

This approach is maximally performant because no layout calculations are triggered at all. The panel appears to open, even though technically only a scale and opacity effect is running. For many use cases, this visual effect is completely sufficient and much better than a stuttering height animation.

Understanding Animation Performance

To develop truly performant animations, you must understand how the browser renders frames. Every time something changes in the DOM, the browser goes through a multi-stage rendering pipeline. Understanding this pipeline is the key to fast, smooth animations.

The first phase is Style Recalculation. The browser must calculate the final CSS values for all affected elements. This includes resolving cascading rules, property inheritance, and computing computed values. With complex selectors or large DOMs, this phase can already become expensive. Fortunately, for most animations, it’s relatively fast because only a few elements are affected.

The second phase is Layout Reflow, also called layout calculation. Here the browser calculates the geometric properties of all elements – their position, size, and spatial relationship to each other. This phase is extremely expensive because the browser potentially must traverse the entire DOM tree. When an element changes its width, it can affect all sibling elements, the container, and even completely independent parts of the page. In large, complex layouts, a single reflow can take several milliseconds, which eats up a significant portion of the frame budget at 60fps animations (about 16ms per frame).

The third phase is Painting. The browser rasterizes all visible elements into pixels. This means concretely: texts are rendered, backgrounds are drawn, shadows are calculated, and images are decoded. This phase can also be expensive, especially when large areas need to be redrawn or complex effects like box-shadow or gradients are involved. The browser tries to repaint only the changed areas (paint invalidation), but for animations affecting large parts of the page, this can still be expensive.

The fourth and final phase is Compositing. Here the browser combines all rendered layers and creates the final image displayed on the screen. This phase is the fastest because it can run entirely on the GPU. The GPU is optimized for moving, scaling, rotating, or changing the transparency of layers, and does this extremely quickly. Modern GPUs can manipulate hundreds of layers in real-time without affecting the framerate.

The art of performant animations lies in skipping as many of these phases as possible. Optimal performance means only going through the necessary phases. This is exactly what you achieve with transform and opacity. These two properties still go through style recalculation (which is relatively inexpensive), but skip the expensive layout and paint phases completely. The browser creates a composite layer for the animated element, and the GPU moves, scales, or fades this layer. This is the fastest form of animation possible on the web – compositing-only with minimal style recalculation.

The formula for maximum performance is therefore: transform + opacity = Compositing-only → maximum performance. All other properties cause at least one of the more expensive phases to be executed, which slows down the animation and can lead to frame drops.

Keyframes: When They Make Sense

The decision between transitions and keyframes is one of the fundamental questions in CSS animations. Both have their justification, but they serve different purposes and have different performance characteristics.

Transitions are ideal for simple state changes. They react to changes in CSS properties and automatically interpolate between start and end values. This makes them perfect for hover effects, focus feedback, or fading components in and out. The big advantage: they are declarative, simple to understand, and performant. The browser can optimally optimize them because it knows exactly that it only needs to interpolate between two states.

Keyframes, on the other hand, are useful when the animation is more complex or spans multiple states. When animations should run cyclically without a state change in the DOM, keyframes are the only option. Also when an animation should go through multiple steps, such as an element that first slides left, then up, and finally fades in, keyframes are the natural choice. They allow precise choreography of complex movement sequences and offer significantly more control over the timing curve.

Another use case is animations that should run independently of state. A loader that continuously rotates, an icon that gently floats, or a pulse effect that draws attention to an element. All of this can only be implemented with keyframes because there’s no state change that would trigger the animation.

A classic example of a subtle keyframe animation is a floating icon effect:

@keyframes subtleFloat {
  0%   { transform: translateY(0); }
  50%  { transform: translateY(-4px); }
  100% { transform: translateY(0); }
}

.icon--floating {
  animation: subtleFloat 3s ease-in-out infinite;
}

This animation makes an icon gently float up and down. The movement is minimal, but sufficient to create attention without being intrusive. The duration of 3 seconds makes the movement very slow and organic. The ease-in-out easing ensures the movement accelerates and decelerates smoothly, making the effect more natural. The infinite keyword makes the animation repeat endlessly.

Crucial here too: the animation uses exclusively transform. No layout is recalculated, no repaint triggered. The entire animation runs on the GPU and is thus extremely performant, even when multiple such icons are animated simultaneously. This is a model example of a keyframe animation that is visually effective but doesn’t impact performance.

will-change – Powerful, But Use Carefully

The will-change property is a powerful tool for performance optimization, but it’s also one of the most frequently misunderstood features in CSS. It explicitly signals to the browser that a specific CSS property will soon be animated or changed, and the browser can react by making optimizations in advance.

Specifically, this means: the browser creates a separate composite layer for the element even before the animation starts. This layer is kept directly on the GPU, so that when the animation actually starts, it can run without any delay. In certain situations, this can make the difference between a stuttering and a smooth animation, especially on mobile devices or with complex layouts.

.dropdown {
  will-change: opacity, transform;
}

This code tells the browser that opacity and transform of this element will soon be animated. The browser can now reserve a layer for it and allocate the necessary resources. When the animation then starts, everything is already prepared.

This sounds initially like only advantages, but will-change has a significant disadvantage. It costs memory. Every composite layer the browser creates must be kept in GPU memory. This means concretely that textures for the element must be rendered and stored. For large elements or high-resolution displays, a single layer can consume several megabytes of memory. If you apply will-change to many elements, GPU memory can quickly be exhausted, leading to significant performance problems, in the worst case even browser crashes on low-end devices.

Therefore, the golden rule for will-change. Only use for elements that are animated regularly and predictably. A dropdown menu that opens and closes on every click is a good candidate. A modal that is frequently faded in and out, also. A carousel that continuously animates, or a drag-and-drop interface where elements are constantly being moved, clearly benefit from will-change.

You should not use will-change for elements that are rarely or only once animated. A button that has a subtle transition on hover doesn’t need will-change. The transition is so short that the overhead of layer creation outweighs the benefit. Also, you should never apply will-change globally or to very many components. A selector like * { will-change: transform; } is catastrophic for performance because it would put every single DOM node on the GPU.

A sensible strategy is to set will-change dynamically via JavaScript, shortly before the animation starts, and remove it afterward. This way you benefit from the optimization without permanently blocking memory. For most cases, however, it’s sufficient to use will-change consciously and sparingly only on a few, frequently animated elements. The browser today is intelligent enough to optimize most animations well even without explicit will-change.

Pattern: Performant Slide-In

Slide-in effects are among the most common animations in modern UIs. Off-canvas menus, sidebars, drawer components, or mobile navigation panels all use this pattern. The naive implementation often found in older codebases uses positioning properties and is thus a performance nightmare.

The wrong variant looks like this:

.menu {
  left: -100%;
  transition: left 300ms;
}
.menu.open {
  left: 0;
}

At first glance, this seems logical. The menu is positioned outside the viewport (left: -100%) and pushed right when opening (left: 0). The problem: left is a layout property. Every change triggers a complete reflow. On every frame of the animation, the browser must recalculate the layout because the element’s position in the layout tree changes. This leads to noticeable frame drops, especially on mobile devices or when the menu contains many child elements.

The performant solution uses transform:

.menu {
  transform: translateX(-100%);
  transition: transform 300ms ease;
}
.menu.open {
  transform: translateX(0);
}

The visual effect is identical, but the technical implementation is fundamentally different. transform doesn’t change the element’s position in the layout, but only shifts its visual representation. The browser creates a composite layer for the menu, and the GPU moves this layer. No layout is recalculated, no repaint triggered. The animation runs smoothly at 60fps, even if the menu is complex or other animations are running simultaneously.

Another advantage of the transform variant is the relative positioning with -100%. This means the menu is shifted left by its own width, regardless of how wide it actually is. This makes the code more flexible and reusable. With the left variant, you would have to either define a fixed width or work with JavaScript, which means additional overhead.

This pattern is universally applicable. Whether off-canvas menu from the left, sidebar from the right, notification panel from the top, or bottom sheet from the bottom, in all cases, transform is the more performant and elegant solution.

Pattern: Fade-In / Fade-Out

The fade pattern is the simplest and at the same time one of the most performant animations. It’s suitable for countless use cases. From fading in tooltips to switching content areas to overlay effects. The beauty lies in the reduction to the essentials.

.fade {
  opacity: 0;
  transition: opacity 120ms ease;
}

.fade[data-visible="true"] {
  opacity: 1;
}

This minimalistic code is enough to create a smooth fade-in and fade-out effect. In the initial state, the element is invisible (opacity: 0). As soon as the data-visible attribute is set, it fades in. The transition lasts only 120 milliseconds, which is fast enough to feel responsive but slow enough to consciously perceive the change.

The performance is excellent. opacity is, alongside transform, the second property that can be rendered entirely on the GPU. The browser doesn’t need to recalculate layout or perform paint operations. It simply changes the transparency of the composite layer, which is extremely fast. Even when dozens of elements fade in and out simultaneously, the framerate remains stable.

The pattern is universally applicable. Notification toasts, modal overlays, dropdown contents, loading states, or dynamically loaded content – in all cases, this simple fade pattern works reliably. It’s also combinable with other effects. If you want additional movement, simply combine opacity with transform, as shown in earlier patterns.

Another advantage is accessibility. A pure fade adds no spatial movement, making it significantly more tolerable for people with vestibular disorders than complex slide or scale effects. Combined with prefers-reduced-motion, you can even completely disable the fade without affecting functionality.

The combination of simplicity, performance, and universality makes the fade pattern one of the most important tools in the animation toolkit. It’s proof that often the simplest solutions are the best.

Pattern: Performant Modal Effect

Modals are among the central UI patterns in modern web applications. They draw attention, signal a context switch, and highlight important content. The way a modal appears significantly influences how professional and polished an interface feels. An abrupt fade-in feels cheap, a well-choreographed animation conveys quality.

The classic modal pattern combines fade and scale for a subtle but effective effect:

.modal {
  opacity: 0;
  transform: scale(0.96);
  transition:
    opacity 150ms ease,
    transform 200ms ease;
}

.modal[data-open="true"] {
  opacity: 1;
  transform: scale(1);
}

In the closed state, the modal is invisible (opacity: 0) and minimally scaled down (scale(0.96)). When opening, it fades in while simultaneously growing to its full size. The two transitions run with different durations:

• opacity changes in 150ms,
• transform in 200ms.

This minimal difference creates a subtle effect. The modal fades in quickly but grows slightly slower, giving the animation depth and naturalness.

The scaling from 0.96 to 1.0 is deliberately kept minimal. It’s not about the modal “jumping out,” but about a subtle suggestion of depth and space. The modal appears to move from back to front without the effect being intrusive. This subtlety is crucial. Too strong scaling (say 0.8 or less) appears exaggerated and distracts from the content.

The great advantage of this pattern is performance. Both opacity and transform: scale() run entirely on the GPU. There are no layout recalculations, no paint operations on surrounding content. Even if the modal is large or contains many child elements, the animation remains smooth. This is especially important because modals are often used on mobile devices where performance is more critical.

The scale effect significantly reinforces the opening feeling without causing any layout costs. It establishes a visual hierarchy. The modal comes “forward” into focus. This spatial metaphor is intuitively understandable and makes the interface more tangible and responsive. It’s a perfect example of how minimal animations can have maximum impact.

Pattern: Skeleton Loading Animation

Skeleton screens have established themselves as the standard pattern for loading states. Instead of showing a generic spinner, placeholders are displayed in the form of the actual content, gently pulsing or shimmering. This approach makes loading more tangible and gives the user a clear idea of how the content will be structured. Skeleton screens significantly reduce perceived loading time and make the interface feel more responsive.

The classic implementation uses an animated gradient that runs across the skeleton block:

@keyframes shimmer {
  0% { background-position: -200% 0; }
  100% { background-position: 200% 0; }
}

.skeleton {
  background: linear-gradient(
    90deg,
    #eee 25%,
    #ddd 37%,
    #eee 63%
  );
  background-size: 400% 100%;
  animation: shimmer 1.4s ease infinite;
}

The mechanics are clever. The gradient is significantly wider than the element itself (background-size: 400%). By animating background-position from -200% to 200%, the gradient is pushed across the element, creating the impression of a light reflection moving from left to right. The three color stops (#eee, #ddd, #eee) create a subtle brightness difference that makes the shimmer effect visible in the first place.

The duration of 1.4 seconds is deliberately chosen. It’s long enough to make the effect smooth and calming without being hectic. The ease easing ensures smooth acceleration and deceleration, making the effect more natural. The infinite keyword makes the animation run endlessly until the real content is loaded.

From a performance perspective, this animation is a special case. It’s paint-heavy because the gradient must be re-rendered on every frame. background-position triggers a paint operation, but no reflow. This means the layout remains stable, but the affected area must be redrawn on every frame. For large skeleton areas or many simultaneous skeleton elements, this can be expensive.

Nevertheless, the pattern is acceptable for several reasons. First, it doesn’t cause layout changes, which would be the most expensive operation. Second, the movement is flat and simple, which keeps paint costs manageable. Third, the effect typically runs only for a few seconds until the real content is loaded. The performance costs are therefore time-limited. And fourth, the pattern is so established that it works well in practice, as long as you don’t animate too many skeleton elements simultaneously.

For maximum performance, you can also implement the effect with opacity pulsing instead of gradient shimmer. Simple pulsing between different opacity values is significantly more performant but looks less polished. For most use cases, the gradient shimmer is the better compromise between aesthetics and performance.

Motion & Accessibility: prefers-reduced-motion

Animations are a powerful tool, but for certain user groups they can do more harm than good. People with vestibular disorders, epilepsy, or certain cognitive impairments can experience dizziness, nausea, or disorientation from too much movement in the interface. For this reason, modern operating systems have the ability to reduce animations system-wide, and browsers expose this preference via the prefers-reduced-motion media query.

The implementation is technically simple but fundamental in its impact:

@media (prefers-reduced-motion: reduce) {
  * {
    animation: none !important;
    transition-duration: 0ms !important;
  }
}

These few lines of code disable all animations and set all transition durations to zero. The result is an interface that is still fully functional but contains no movement whatsoever. Elements appear and disappear immediately, without transitions or animations. The !important is justified here because this rule must have absolute priority, regardless of the specificity of other styles.

It’s important to understand that prefers-reduced-motion: reduce doesn’t mean the user wants no animations at all. It means the user prefers fewer or more subtle animations. In some cases, it can make sense not to completely disable animations but only to strongly shorten them. Instead of 200ms, you could reduce to 20ms. This maintains a minimal visual flow without triggering the problems that longer animations can cause.

A more nuanced approach could look like this:

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}

Here animations are not completely removed but reduced to an absolute minimum. This is technically cleaner because it prevents animations triggered via JavaScript from completely breaking. Also, @keyframes animations that set certain states remain functional. They just jump immediately to the end state instead of animating.

Supporting prefers-reduced-motion should be standard in every modern project. It’s a simple but effective step to make the interface accessible to a broader spectrum of users. It shows respect for users’ needs and preferences and is an essential component of modern web accessibility. A small addition in the code that makes a big difference to the user experience.

Typical Mistakes in Real Projects

Even in professionally developed applications, the same animation mistakes keep appearing. These mistakes are often not immediately obvious, but they subtly impair the user experience and make an interface less professional. Understanding these typical mistakes helps avoid them from the start.

Mistake 1: Animating Everything

The most common mistake is, paradoxically, animating too much. When every element flies in when appearing, when every hover effect is exaggerated, and when the entire interface is constantly in motion, animation becomes an end in itself. The result is an interface that seems restless and distracts from the actual content. Users feel overwhelmed and can’t focus on their task.

Good animation is selective. It highlights important state changes, provides feedback on interactions, and supports navigation. But it should never be intrusive. A button that animates wildly on every hover is distracting. A card that bounces into view while scrolling becomes annoying over time. A sidebar that opens dramatically slows down the workflow. When an app feels “too moved,” it’s a clear sign that too much is being animated.

The solution is restraint. Only animate what really needs to be communicated. A hover effect should be minimal – 2 pixels of movement are enough. A modal should fade in gently, not jump in. Content should appear, not fly in. Less is more, and this applies especially strongly to animations.

Mistake 2: Long Animations

Animations that are too long make an interface sluggish. Users have to wait until the animation is complete before they can continue working. This frustrates, especially for actions that are frequently performed. A button that takes 500ms to react feels slow, even if the actual action happens immediately. A modal that takes 800ms to open unnecessarily interrupts the workflow.

Buttons shouldn’t “fly” but respond. Their animations should last 120-180ms, no longer. Loaders shouldn’t “go crazy” but inform. Their movement should be clear but not exaggerated. Cards shouldn’t “float around” but react subtly. Their hover effects should last 150ms, maximum.

The rule of thumb is: the more frequently an interaction occurs, the shorter the animation should be. A button clicked hundreds of times per session needs an animation of 120ms. A modal that opens once per session can take 200ms. An onboarding flow that runs once in a user’s lifetime may be somewhat more elaborate. But even then, you shouldn’t exceed 300ms.

Mistake 3: Too Many Keyframes

Keyframe animations are powerful, but they are often overused. Developers create complex @keyframes definitions with many steps, even though a simple transition would be completely sufficient. The result is code overhead, worse maintainability, and often no better UX.

In 90% of cases, transitions are enough. They are simpler to understand, easier to maintain, and the browser can optimize them better. A button hover doesn’t need keyframes. A modal opening doesn’t need keyframes. A fade-in doesn’t need keyframes. Keyframes should only be used when the animation truly has multiple steps, runs cyclically, or needs to choreograph complex movement sequences.

If you’re asking yourself: “Do I need keyframes here?”, the answer is usually no. Transitions are the default, keyframes the exception. This mental reversal leads to cleaner, more maintainable code and often even better performance.

Mistake 4: Animations Without Purpose

The most subtle but perhaps most important mistake is animation without purpose. Animations should always fulfill a function. They should provide feedback, communicate state changes, create orientation, or direct attention. Animation without functional added value is nothing more than unnecessary distraction.

Before adding an animation, ask yourself: “What problem does this animation solve?” If the answer is “It looks cool,” leave it out. If the answer is “It shows the user that their action was successful,” it’s justified. If the answer is “It makes clear where the new element comes from,” it serves a purpose. If the answer is “It makes the interface livelier,” it’s questionable.

Good animation is targeted, minimalistic, and functional. It supports the UX without pushing itself to the forefront. The best animations are those you hardly consciously perceive but would miss if you removed them.

Best Practices for Performant Animations

Developing performant animations is not an art but a craft. There are clear principles and best practices that have proven themselves in practice. Those who follow these principles create animations that are not only fast but also professional and improve the user experience.

Animate Only What Communicates

The first and most important principle. Animations should have a clear function. Every movement in the interface should tell the user something, that an action was successful, that a state has changed, that a new element has appeared, that feedback is being given. Animations without communicative purpose are pure decoration and distract from the actual content.

Before adding an animation, ask yourself: “What does this animation communicate?” If you don’t have a clear answer, leave the animation out. The interface won’t become poorer but more focused.

Use Exclusively transform and opacity

This rule has been mentioned multiple times, but its importance cannot be emphasized enough. transform and opacity are the only properties that can be rendered entirely on the GPU without triggering layout recalculations or paint operations. All other properties lead to performance degradation that is especially noticeable on mobile devices.

The good news: with transform and opacity, almost all common UI animations can be implemented. Translations, scaling, rotations, fading in and out. All this is possible without ever touching a layout property. It sometimes requires some creativity, but the result is always more performant.

Use Central Motion Tokens

In professional design systems, animations are not defined individually but follow a central token system. Just like colors, spacing, and typography, durations and easings should also be standardized. This creates consistency across the entire interface and makes changes significantly easier.

A typical motion token system defines three to five duration levels (e.g., --motion-fast: 120ms, --motion-medium: 180ms, --motion-slow: 250ms) and two to three easing functions. All components use these tokens instead of defining individual values. The result is an interface that feels consistent and where motion is understood as part of the design language.

Work with Small, Clear Movement Amplitudes

Subtlety is the key to good animations. Large, dramatic movements distract and appear unprofessional. Small, precise movements, on the other hand, communicate clearly without being intrusive. A button that glides 2 pixels upward on hover is a clearly noticeable effect without being exaggerated. A modal that starts with scale(0.96) and grows to scale(1) creates the impression of depth without being too dramatic.

The rule of thumb is: as little movement as possible, as much as necessary. If you’re unsure whether an animation is too strong or too weak, reduce the amplitude by 50% and test again. Often the more subtle variant is the better one.

Respect prefers-reduced-motion

Accessibility is not an option but a basic requirement. Supporting prefers-reduced-motion should be standard in every project. It’s a simple but effective step to make the interface accessible for people with vestibular disorders or other limitations.

The implementation is trivial. A single media query is enough. But the impact is enormous. Users who need reduced motion receive a calmer, more focused interface without functionality suffering.

Less Is More – But Zero Is Often Too Little

The last principle is a balance. Too many animations make an interface restless, too few make it static and lifeless. The art lies in finding the right amount. An interface with no animations at all feels dead. Buttons that don’t react, modals that fade in harshly, content that simply appears. All this seems cheap and unfinished.

The solution is selective animation. Animate state changes, provide feedback on interactions, create orientation through movement. But keep it minimal. A well-designed interface might have a dozen different animations, but all are targeted, subtle, and functional. The result is an interface that feels alive without being restless.

Conclusion

Animation performance is not a side issue or a detail to be optimized retroactively at the end of a project. It is a fundamental component of high-quality user experiences and directly measurable in the perceived quality of a product. An interface can be functionally perfect and visually appealing, but if animations stutter, if transitions jerk, or if the interface feels sluggish, the entire user experience suffers.

The good news is: performant animations are not difficult to develop when you know the basic rules. The most important rule is: animate exclusively transform and opacity. These two properties can be rendered entirely on the GPU without requiring layout recalculations or paint operations. With these two properties, almost all common UI animations can be implemented and that from button hover effects to modal openings to complex page transitions.

The second rule is: keep animations short and targeted. Users want to work with the interface, not wait for animations. Durations of 120-200ms are ideal for most interactions. They are long enough to consciously perceive the movement and interpret it as feedback, but short enough not to slow down the workflow.

The third rule is: only animate what communicates. Every animation should have a purpose, whether it’s feedback on an interaction, communication of a state change, or orientation in the interface. Animation without functional added value is nothing but distraction.

The fourth rule is: respect prefers-reduced-motion. Accessibility is not an option but a basic requirement. People with vestibular disorders or other limitations must receive a fully functional interface, even if it contains no animations.

If you follow these rules and work consciously with motion, you create an interface that not only looks good but feels good. An interface that responds immediately, runs smoothly, and provides feedback to the user through subtle movement. An interface that radiates precision, quality, and technical maturity. That is the difference between a mediocre and an excellent product and this difference often lies in the details of animation performance.