CSS animations and transitions are great. They give us the power to spice up web experiences and help to make them feel more 'alive'. However, at the same time, animations and transitions can make a web experience far worse, when done the wrong way.
Beware of 'junk' from bad performing animations
If you do just a bit of research, you will quickly notice, that you have to be very careful about which CSS properties you should animate and which you should not. To understand why you need to have a basic understanding of how the rendering process in the browser works.
There are three phases that are important for us: Layout. Paint and Composite.
Layout
In the layout phase, the browser is pretty much figuring out which elements will go where, considering their widths and heights, as well as margins, paddings, borders, positioning and so on.
Paint
In the paint phase, the browser starts filling in pixels. It basically means bringing every visual part of an element onto the screen. This involves things like text, colors, images, borders, box-shadows, etc. Typically, the painting is done onto multiple 'layers', which will be important for the next step.
Composite
At this time, we already have visual elements painted onto various layers. In this last step, all layers need to be drawn to the screen in the correct order. The order is important to make sure that elements that overlap each other, have the correct element sitting on top.
We don't have to get into this too much, but what you should keep in mind is, that during a transition, the browser has to calculate stuff repeatedly to update what is on the screen.
Now, depending on which properties you change during your animation, this might involve more or less work. Imagine you would do the following:
.box {
transition: width .3s ease-out;
}
If you were to change the width of that box, this would effect all of its surrounding elements as well. E.g. the box in the following example would be pushed to the side by the growing box, which would in turn trigger other elements to reposition as well. If we go back to the three phases we discussed, you will quickly realize that the browser has to recalculate the layout for every step of the animation, followed by the other two phases. This is quite a lot work and the main reason why badly done animations can cause a lot of junk on the page.
See the Pen Box pushing another box by Philipp Nowinski (@kaesetoast) on CodePen.
Change properties that trigger the least amount of work
There is an excellent website that lists for each css property which phase when it gets change: https://csstriggers.com. I highly recommend checking it out. There are a few properties that will always be safe to use and the most performant animations try to stick to those: opacity and transform. Whenever I do animations or transitions, I try to translate whatever effect I want to achieve back to those two properties.
Avoid unwanted side-effects
Being aware of the junk that might get caused by transitioning the wrong set of properties, you might get an idea of why I consider the usage of the all keyword a bad practice. Sure, you can set transition: all .3s ease-out; and still have a well-performing animation if you make sure to only change opacity and transform, but there is a good chance that someone else is going to change a property along the way, without knowing that this will trigger an animation.
Be explicit about what your code does
Another aspect that you should consider when writing animations and transitions is maintainability. I encountered a lot of legacy codebases that made heavy use of the all keyword, probably because it was easier to write. But changing this back to a more explicit transition can be very frustrating if you don't exactly know what the author wanted to achieve. You have to examine the animation to find out which properties actually do change and which do not. Writing transitions and animations only for explicit keywords, will not only prevent unwanted junk but also help others (and yourself in the future) to understand your code more easily.
Let the computer yell at you
I always like to put rules like that into my build-process or have them integrated into my text editor. I'd rather have the computer yelling at me at the moment I write bad code than my co-workers (or most likely myself) in a year. If you are using stylelint for checking your CSS, here is a neat little rule that will do exactly that: https://github.com/kristerkari/stylelint-high-performance-animation