How to Ensure a Smooth CSS Transition Performance

1. Scripts

Firstly, changes can be requested by Javascript, CSS animations and transitions or by altering the DOM structure.

2. Style Calculations

Your browser then calculates which CSS rules apply to which elements based on matching selectors. Once these rules are known, the final styles for each element can be calculated.

3. Layout

Your browser then starts to determine the shape and positioning of the elements, calculating the geometry of those elements.

Changes to the geometric properties such as width and height, left and right all trigger layout operations. It’s important to realise that animating an element’s position can affect the geometry of others, meaning your browser needs to check all elements, and reflow the page, which can be expensive. Affected areas then need to be repainted and the finalised elements composited back together. For instance, when you animate an element with a container, be wary of changing the child elements that live on that container too. In general, in your transition, it is better to refrain from animating properties that trigger these layout operations, which can be costly and result in a sub-par performance for your CSS transition.

4. Paint

Painting is the process by which your browser fills in pixels into different layers, drawing out text, colors, images, and borders that are then composited to a screen.

Triggering a paint property in your CSS transition is not recommended, as it can be the most expensive part of the Pixel Pipeline. This can cause all layers to change, necessitating re-painting which is particularly expensive for mobile devices that don’t have the same memory or CPU power as desktops. To optimise your transition experience, the browser should ensure that the animated CSS doesn’t cause a repaint.

5. Composite

After all your layers have been painted, you need to position them. Compositing involves deciding where to place things on the screen, and in which order, so the page renders correctly.

The most effective way to avoid excess work for your CPU is to animate low-cost properties that only affect compositing - those being transform and opacity. A key concept to remember is that for the use of transform and opacity, the element on which properties are changed needs its own compositor layer.

In Blink and WebKit browsers, new layers are automatically created for elements with CSS transitions on opacity, but many developers choose to employ translateZ(0) or translate3d(0,0,0) to manually force layer creation. This means your browser can prepare itself by pre-creating compositor layers, bypassing the layout render or painting in the process. This ensures that the layer is already ready to go when the animation starts (so there won’t be delays to your transition).

Animating Height vs ScaleY: Comparing CPU activity with using transform versus without

This technique can be visualized in terms of travel. The more stops you make on a journey, the more likely it is to be disrupted. Similarly, in progressing straight to the composite and removing rendering stages, you reduce the potential for skipped frames and a negative user experience, much like a hassle-free direct flight.

Therefore, performance is the art of minimising rendering work. This is achieved by understanding the processes involved in rendering, and working with the browser to avoid it carrying out unnecessary work that you could do it. This results in a low-cost CSS transition that delivers a smooth performance to users.

For more information please visit the following links:
Rendering Performance

Stick to Compositor