CSS3 transforms and animations — the end of jQuery animate

For the past five years we have been animating web elements using jQuery — fadeIn, slideDown, animate. It worked, but at a performance cost. Every frame of animation required layout recalculation and a repaint in JavaScript. CSS3 brings transitions, transforms and animations that move animations into the browser — with hardware acceleration, smoother performance and cleaner code.

CSS3 Transitions¶

A transition is the simplest way to add animation. You tell the browser: when this property changes, animate the transition. Just four properties are needed — transition-property (what to animate), transition-duration (how long), transition-timing-function (easing curve) and transition-delay (delay). In practice we mostly use shorthand: transition: opacity 0.3s ease.

Transitions react to state changes — typically :hover, :focus or adding a CSS class via JavaScript. When a user hovers over a button, the background color changes smoothly. When a dropdown menu opens, the opacity animates from 0 to 1. No JavaScript for the animation itself — just adding a class and CSS handles the rest.

The difference compared to jQuery animate is dramatic. jQuery animates by setting a new inline style via JavaScript on every frame. That means style recalculation, layout and paint for every frame. A CSS transition runs in the browser’s compositor thread, often with GPU acceleration. On mobile devices the performance difference is enormous — jQuery animations stutter, CSS transitions are smooth.

CSS3 Transforms¶

Transform lets you transform an element without affecting layout — translate (move), rotate, scale (resize) and skew. The key point is that transform does not affect surrounding elements. When you move an element with translate, other elements stay in place. This is the fundamental difference from changing margin or position.

Because transform does not trigger layout recalculation, it is ideal for animations. Animating transform: translateX(100px) is significantly faster than animating left: 100px. The browser can animate transforms on the GPU as a composited layer, while changing left forces layout recalculation for the entire document.

3D transforms (translate3d, rotate3d, perspective) open up further possibilities. You can create a card flip effect, a 3D carousel or parallax effects. And there’s an important trick — even when you don’t need 3D, adding transform: translateZ(0) forces the creation of a composited layer and GPU acceleration. It’s a hack, but it works great for improving animation performance.

CSS3 Animations¶

While transitions animate the transition between two states, animations allow you to define more complex sequences with multiple steps. Using @keyframes you define keyframes — from 0% to 100% with any number of intermediate steps. You then assign the animation to an element via the animation property with parameters for duration, iteration count, direction and more.

Typical uses are loading spinners, pulsing notifications, infinite icon rotations or complex page intro animations. Unlike transitions, animations can run automatically on page load, repeat in an infinite loop and be paused via animation-play-state.

For more complex scenarios we combine animations with transitions. Page intro animations use @keyframes, interactive hover effects use transitions. We use JavaScript only for adding and removing classes — the animation itself is always in CSS. This separation of concerns makes code more maintainable.

Vendor prefixes — a necessary evil¶

The least popular part of CSS3 development is vendor prefixes. Each browser implements new CSS properties with its own prefix — -webkit- for Chrome and Safari, -moz- for Firefox, -ms- for IE, -o- for Opera. That means for one transition you have to write four or five lines. It’s tedious but necessary for compatibility.

Fortunately there are tools. CSS preprocessors like Sass and LESS allow defining mixins that automatically generate all prefixes. And projects like Prefix Free by Lea Verou automatically add prefixes at runtime via JavaScript. In the future, prefixes will gradually be removed as specifications stabilize.

Practical animation patterns¶

The most common animations in our projects are hover effects on buttons (color change, shadow, slight enlargement via scale), opening and closing menus (opacity + translateY), loading states (infinite rotation) and page transitions (fade in on content load). For each of these patterns we have utility classes prepared in our CSS framework.

An important principle is restraint. Animations should serve the user interface — providing feedback, indicating relationships between elements, directing attention. Too many animations distract and slow things down. We recommend keeping duration to 200–300ms for micro-interactions and a maximum of 500ms for larger transitions. The timing function ease-out feels the most natural for most interactions.

Performance — what to measure and how to optimize¶

Chrome DevTools has an excellent panel for analyzing animation performance. The Timeline tab shows how much time the browser spends in each phase — Scripting, Rendering, Painting, Compositing. An ideal animation spends most of its time in the Compositing phase, which means GPU acceleration. If you see a lot of time in Rendering and Painting, something is wrong.

The rule is simple — only animate transform and opacity. These two properties can be animated purely on the GPU without affecting layout. Animating width, height, margin, padding, top, left — all of these properties force layout recalculation and are significantly slower. If you need to animate size, use transform: scale instead of width/height.

On mobile devices performance is even more important. Slower processors and limited memory mean that poorly optimized animations literally drain the battery. Test on real devices, not just a desktop browser. Chrome DevTools can emulate a slower CPU, which helps reveal problems.

Animation accessibility¶

Not every user wants animations. Some people suffer from vestibular disorders and moving elements cause nausea. The media query prefers-reduced-motion (coming to browsers soon) will allow detecting that a user prefers reduced motion. Even now we should design animations so they are not essential to using the application — they are enhancements, not requirements.

Conclusion¶

CSS3 transitions, transforms and animations are the future of web animations. Better performance thanks to GPU acceleration, cleaner separation of concerns (CSS for animations, JS for logic) and native support in modern browsers. Start replacing jQuery animations with CSS transitions today — your mobile users will thank you.