Smooth and Performant Animations

This creates one of our main challenges. Since experiences can run on any hardware with a browser, it's important the features of an experience, like design and animations, are suited for devices that are not particularly powerful. Such devices with limited resources can turn designed, animated content into a choppy, jumpy experience. We want to engage the largest audience possible without compromising on design and interactivity.

How can we maintain the quality of the interactive experience across all devices? Let's take a look at one of our technical strategies:

Composite versus Layout animations

Not all CSS animations are treated equally by the browser. An order of precedence determines how the browser sorts elements and where they should render. Specifically I am interested in the difference between a Layout and Compositeanimations. Without getting into too many details, both types of animation are used in CSS rules except that browser precedence will always calculate Layout before Composite.

Layout animations are CSS properties that affect the position and size of an element. For example width, height, position, top, left, float, padding, margin to name a few are all layout properties. These familiar properties are important to the browser but when they change as a result of animation the browser has to recalculate the layout of the element plus all the visible children elements and potentially parent and sibling elements depending on overlap and wrapping.

Composite is limited to opacity and transforms (scale, translate, rotate). Browsers are able to optimize these CSS animations using the dedicated graphics processing available on the machine. The browser interprets the CSS by predicting which single, visible elements will change and animating them accordingly. Because a single element is the focus of this animation the browser spends no time recalculating positions for parent or children elements.

List of common CSS properties and their browser property.

As an example, suppose you have an active element that disappears when it's the child of an alternative layout .alt-layout.

#element {
  left: 0;
  position: absolute;
  top: 0;
  transition: all 500ms ease;
  width: 200px;
}

.alt-layout #element {
  left: -200px;
}

Because left is a layout property it will tax our browser resources more than a composite rule, like transform:

.alt-layout #element {
  transform: translateX(-200px);
}

This rule effectively performs the same visual animation by reducing resources costs. As your animations grow more complex, contain more elements, and contain image and video the benefits are measurable.

In Practice

So what does performance improvement look like when we adopt this practice to prefer Composite over Layout animation? It may not always be obvious, especially if you work on a powerful workstation with ample resources to handle many simultaneous browser animations. An illuminating tool is the Chrome Browser Performance profiler. It has two features that are particularly useful when you want to test how well your animations are optimized for slower devices.

The first tool is a simple CPU throttle. In the Performance Options we can throttle the CPU to 4x or 6x slower. This will cause your site or application to render similarly to smaller and slower devices and if your CSS is heavily animated you will visually notice choppy or slow animations in the throttled browser.

The other tool is the Recorder. Rather than trusting our eye we can record our animations and Chrome will notify us of any dropped frames during animations. Now we have a nice record of when exactly frames are dropped as a result of heavy resource costs. Furthermore we can save and make new recordings to compare versions of our application as we optimize the user experience.

In the figure above the Performance profiler shows the dropped frames and the individual layout shifts in red color. Using this tool and the information it provides we can now revisit our CSS and optimize the animations most likely to slow devices.

Conclusion

Hopefully this simple primer explains some of the underlying concepts that browsers use to paint your content onto visitors' screens. By further understanding why and how HTML and CSS can tax a browser and hardware we can further improve our products so that people on a variety of different platforms and hardware share the same experiences.