This drastically reduces the amount of repainting and the overall work the CPU does in running the animation. The last option is to animate not the box-shadow but a pseudo element that provides a shadow. This solution is visually pleasing, and performant, even with the extra shadow. Another approach is to animate two box-shadow layers. The catch is you’ll loose that illusion of depth that shadows are meant to provide. If you really want to animate the box-shadow property, changing just the opacity as opposed to changing the offset values will reduce repainting. The ideal solution would be to not animate shadows at all (since they look fine as they are!). Animating shadows triggers three events - painting, layout changes, and compositing - with the first being the most tasking. In this article, we’ve tested various methods on animating shadows and compared their performance. Shadows can enhance your site visually, but they also affect performance - especially when it comes to animation. This will reduce the workload of the CPU and greatly improve performance. There’s no need to animate anything that has no function. Secondly, only animate the interactive elements. Don’t throw shadows on every element for the sake of it. Now, all you have to do is change the opacity of the pseudo element on :hover:įirst, keep them minimal. So, after the basic styling for the box, create an :after pseudo element and give it a box-shadow, which will be the final state of the shadow after animation. It will involve more lines of code, but we’ll achieve more performant shadow animations.

You’ll see at the end of this section that painting will be almost completely eliminated. If you’re changing the box-shadow values, you can’t avoid this process. From the previous demos, we can see that there’s still a lot of repainting going on during shadow animation. This time, we’re going to replicate the shadow animation without changing the box-shadow property.

Compositing is the least tasking process out of all three. This will mean fewer style recalculations, and smoother animations. CSS properties like opacity and transform affect just the element they’re applied to. In compositing, only parts of the page change. Simply put, if the animated property affects other elements, it will change the layout of the page, causing recalculations - which uses a lot of system resources.Ĭompositing. The CSS properties that cause this include padding, margin, border. A good example would be a sidebar pushing other elements out of the way when expanding.

Some animations change the structure of a page, which can lead to many style recalculations. According to Mozilla, the ideal CSS animation should run at 60fps. Basically, it creates a new shadow at every frame of the animation. In painting, the browser fills in the pixels with color, and box-shadow is one of the CSS properties that triggers this event. These events are painting, layout, and compositing. There are three main processes, or events, that are triggered during box shadow animation (or any form of animation, for that matter). Three Main CSS Box Shadow Animation Eventsīecause of what’s happening behind the scenes, CSS box-shadow animation can be resource heavy. Web elements with shadow animation by SitePoint ( CodePen.

Animated drop shadow after effects