CSS Animation Examples — Keyframes, Timing, Fill Mode, and Real UI Motion

A CSS animation has two required pieces: an @keyframes rule that defines what changes happen and at what percentage of the timeline, and an animation property on the element that references those keyframes by name. The name comparison is case-sensitive, so @keyframes Spin and animation-name: spin will not connect. If either piece is missing or misspelled, the browser silently skips the animation without producing an error.

The animation shorthand accepts up to eight values in a specific order: duration, timing-function, delay, iteration-count, direction, fill-mode, play-state, and name. The order matters for the first two time values — the browser assigns the first time value to duration and the second to delay. A common mistake is writing animation: spin 0.5s 1s when the intent was a 1-second animation with a 0.5-second delay; the browser reads it the opposite way.

Keyframe selectors can use from and to as aliases for 0% and 100%, or they can use explicit percentages for multi-step sequences. When you omit the 0% or from keyframe, the browser uses the element's current computed style as the starting point. This works for most entrance animations but can cause unexpected jumps when the element's style is not stable at the moment the animation begins.

The timing-function applies between each pair of keyframes, not across the entire animation. A cubic-bezier or steps() function defined on the @keyframes rule overrides the one on the element for that specific segment. This lets you create animations where the easing is fast in the first half and slow in the second half without needing JavaScript to split them.

Chrome DevTools includes a dedicated Animations panel. Open it by pressing F12, clicking the three-dot menu at the top right of the panel, selecting More tools, and choosing Animations. The panel records all animations that start while it is open and displays them as a timeline. You can scrub the playhead, slow down the playback to 10% or 25% speed, and inspect the exact easing curve for each property.

If the panel shows the animation but the element appears frozen, check the Computed tab in the Elements panel. Look for animation-play-state: paused — this is the most common reason an animation registers as active but produces no visible motion. JavaScript on the page may be setting element.style.animationPlayState to paused, or the element may have picked up the paused state through a CSS rule. Filter the Computed styles by typing animation to surface all animation-related declarations.

For animations that register as playing but look wrong, switch to the Rendering drawer (F12 → More tools → Rendering) and enable Paint Flashing. Properties like width, height, top, left, margin, and padding cause green flash overlays every frame they change. Seeing a full-page green flash on every animation frame means you are triggering layout on every frame, which is expensive. Replace those properties with transform equivalents: translateX instead of left, translateY instead of top, scaleX instead of width.

On mobile, open Chrome Remote Debugging over USB or use Android Studio's device mirroring to attach DevTools to the device's browser. The Animations panel works the same way remotely. Pay attention to the frame rate indicator in the Performance panel — sustained animation below 60fps on a mid-range device usually points to a non-composited property or a large repaint area.

The single highest-value fix for any CSS animation is switching from layout-triggering properties to transform and opacity. Animating width, height, top, left, margin, or padding forces the browser to recalculate layout and repaint the affected area on every frame. Animating transform: translate(), transform: scale(), transform: rotate(), or opacity skips both layout and paint — the GPU handles them at the compositor stage. The visual result is identical in almost every case, and the performance improvement on mobile can be dramatic.

For animations that snap back after finishing, add fill-mode: forwards or use the both keyword in the shorthand. forwards applies the final keyframe values after the animation ends. backwards applies the initial keyframe values during any delay before the animation starts. both does both. The most useful value for entrance animations is both because it prevents the element from flashing its original state during a delay and keeps it at the final state permanently.

When an animation needs to run only when a class is added (for example, on component mount in React or Vue), define the animation on the class rather than on the base element. Remove the class with a short JavaScript timeout after the animation-duration plus any delay has elapsed, or listen to the animationend event. Using animationend is more reliable because it fires at the exact moment the animation completes regardless of how long you set the duration.

For cross-browser compatibility, all modern browsers support @keyframes and the animation property without prefixes as of 2016. The one exception is Safari versions older than 9, which require the -webkit- prefix. If your target audience includes older iOS devices, add both the prefixed and unprefixed declarations. Most build tools including PostCSS with autoprefixer handle this automatically when you configure the browserslist target.

Elements with display: none cannot be animated. The browser removes them from the layout tree entirely, so there is no computed geometry to interpolate. If you want to animate an element into view, start with visibility: hidden or opacity: 0 and then transition or animate to the visible state. Alternatively, keep the element in the DOM with its final dimensions already applied, offset it off-screen with transform: translateX(-100%), and animate it into position.

Tab visibility affects running animations. When the user switches to a different tab or the page is hidden by the Page Visibility API, most browsers pause all CSS animations to conserve battery. This is intentional and correct behavior. If your animation controls a UI element that must remain accurate during tab-switching, such as a countdown timer, use JavaScript with requestAnimationFrame and Date.now() deltas rather than pure CSS animation.

The will-change: transform declaration instructs the browser to promote the element to a separate compositor layer before the animation begins. This avoids the one-frame compositor layer creation cost that can cause a visible stutter at animation start on mobile. Apply will-change only to elements that will actually animate — applying it to all elements wastes GPU memory. A practical pattern is to add will-change in a :hover or a JavaScript class that fires just before the animation starts, then remove it with another class after the animationend event.

Multiple animations on the same element are comma-separated in the animation shorthand. Each animation is independent and can have its own duration, delay, and iteration count. Conflicts between animations targeting the same property are resolved by the order of the comma list — the last animation in the list wins for any given frame. This allows you to combine a looping background pulse with a one-shot entrance fade without either overriding the other.

Mismatched keyframe names are by far the most common silent failure. The browser does not throw an error when animation-name references a nonexistent @keyframes block — it simply does nothing. Always confirm the name appears in exactly the same casing in both places. If you are using a CSS preprocessor like SCSS with a mixin that generates animation names dynamically, print the compiled output and verify the name before debugging further.

Animating background-color instead of opacity causes a repaint on every frame because color changes cannot be composited by the GPU. If you need a color change effect, consider crossfading between a white and colored overlay using opacity on the overlay, or using a box-shadow with a color transition (also repaint-expensive but confined to the shadow area). For performance-critical animations, prefer opacity and transform exclusively and achieve color effects through color stops in gradients or SVG elements.

Forgetting animation-fill-mode on entrance animations is a classic mistake. The element appears, the animation plays, and then the element vanishes or snaps to its pre-animation position. This happens because fill-mode defaults to none, meaning the animation applies only while it is actively running. Setting fill-mode to forwards or both is almost always the correct choice for entrance animations.

Using animation: none to reset an animation in JavaScript does not always work as expected when the same animation needs to be retriggered. The browser sees the same element with the same animation and may skip the restart. The correct pattern is to remove the class that applies the animation, force a style recalculation with void element.offsetWidth, and then re-add the class. This flushes the animation state and lets it restart from the beginning.

Always include a prefers-reduced-motion media query for every animation that moves content across the screen. The @media (prefers-reduced-motion: reduce) block should either disable the animation entirely with animation: none or replace it with a simple opacity fade that communicates the same state change without vestibular-disturbing motion. Screen reader users and people with vestibular disorders depend on this. In some jurisdictions, failing to honor this preference in certain digital products can create accessibility liability.

Limit the number of simultaneously animating elements on mobile. Each animated element that is on its own compositor layer consumes GPU texture memory. A page with dozens of independently animating components can exhaust the GPU memory budget on low-end phones, causing the browser to fall back to software rendering and drop frames. A good rule is to animate no more than five to ten elements simultaneously on a given screen, and to strip will-change declarations from elements once their animations complete.

For animations that are triggered by JavaScript events, define the animation in CSS and control it by toggling a class. This keeps the animation logic in CSS where it belongs, lets DevTools inspect it with the Animations panel, and avoids the overhead of JavaScript-driven style mutations on every animation frame. Use the Web Animations API (element.animate()) only when you need precise programmatic control over playback, such as scrubbing an animation to match a scroll position.

Test animations on real devices, not just desktop simulators. Modern iPhones and Pixel phones are fast enough to make any animation feel smooth, but mid-range Android devices running at 60Hz with a limited GPU are where most animation bugs manifest. Install Chrome on an Android device, enable USB debugging, and use chrome://inspect to attach DevTools for remote profiling. The Performance panel will show you exactly which frames are dropping and which properties are causing the slowdown.