CSS animation overloads CPU

Question

I have an animation and JS for alternating 2 divs and change their background images (from an array of a few dozens images), sort of interchangeable divs. Everything works just fine, however when the animation runs I can see that my CPU is at 100%. At first I thought it might be due to setInterval, however when I changed the code from alternating the images to just increase a number with each iteration and log it to console - I saw dramatic CPU overload decrease, of about 40-50%. So I understood it might be due to animation.

Here's my HTML code:

<div class="wallpaper wallpaper-1" id="wallpaper-1"></div>
<div class="wallpaper wallpaper-2" id="wallpaper-2"></div>

CSS:

.wallpaper {
    width: 100%;
    height: 100%;
    position: absolute;
    opacity: 0;
    background-repeat: no-repeat;
    background-position: center;
    background-size: cover;
    -webkit-transform: translateZ(0);
    -webkit-animation-timing-function: linear;
}

.animate {
    -webkit-animation-name: fadeInOut;
    -webkit-animation-duration: 6s;
}

@-webkit-keyframes fadeInOut {
    0% {
        opacity: 0;
        -webkit-transform: scale(1);
    }
    16% {
        opacity: 1;
    }
    90% {
        opacity: 1;
    }
    100% {
        opacity: 0;
        -webkit-transform: scale(1.1);
    }
}

And JS that makes it all tick:

Wallpapers.get().then(function(list) {
    var wp1, wp2, divs = [], path, bgs = [], counterBgs = 0, bgsLength, currentId, doInterval;
    wp1 = document.getElementById('wallpaper-1');
    wp2 = document.getElementById('wallpaper-2');
    divs = [ wp1, wp2 ];
    path = 'assets/img/wallpapers/';
    bgs = list.data;
    bgsLength = bgs.length;

    //Preload images
    for(var i = 0; i < bgsLength-1; i++) {
        var wp = new Image();
        wp.src = path+list.data[i];
    }

    function manageBg() {
        setInterval(function(){
            doInterval();
        }, 4000);
    }

    doInterval = function doInterval() {
        currentId = counterBgs % bgsLength;
        if (counterBgs % 2 === 0) {
            wp1.style.backgroundImage = "url(" + path + bgs[currentId] + ")";
            wp1.classList.add('animate');
            wp1.style.zIndex = 1;
            wp2.style.zIndex = 0;
            setTimeout(function() {
                wp1.classList.remove('animate');
            }, 5950);
        } else {
            wp2.style.backgroundImage = "url(" + path + bgs[currentId] + ")";
            wp2.classList.add('animate');
            wp1.style.zIndex = 0;
            wp2.style.zIndex = 1;
            setTimeout(function() {
                wp2.classList.remove('animate');
            }, 5950);
        }
        counterBgs++;
    };
    doInterval();
    manageBg();
});

Any ideas how to reduce the CPU overload?

Answer 1

The answer is will-change property of css.

will-change is a property that optimizes animations by letting the browser know which properties and elements are just about to be manipulated, potentially increasing the performance of that particular operation.

Article Source: will-change - css tricks

The will-change property will use Hardware Acceleration in order to reduce load of your CPU and allocating your CSS3 animation/transformation to the GPU.

The Old: The translateZ() or translate3d() Hack

For quite some time now, we’ve been using what has been known as the translateZ() (or translate3d()) hack (sometimes also called the null transform hack) to trick the browser into pushing our animations and transforms into hardware acceleration. We’ve been doing that by adding a simple 3D transformation to an element that will not be transforming in three-dimensional space. For example, an element that’s animated in two-dimensional space can be hardware-accelerated by adding this simple rule to it:

transform: translate3d(0, 0, 0);

Hardware-accelerating an operation results in the creation of what is known as a compositor layer that is uploaded to and composited by the GPU. However, force-hacking layer creation may not always be the solution to certain performance bottlenecks on a page. Layer creation techniques can boost page speed, but they come with a cost: they take up memory in system RAM and on the GPU (particularly limited on mobile devices) and having lots of them can have a bad impact (especially on mobile devices), so they must be used wisely and you need to make sure that hardware-accelerating your operation will really help the performance of your page, and that a performance bottleneck is not being caused by another operation on your page.

In order to avoid layer-creation hacks, a new CSS property has been introduced, that allows us to inform the browser ahead of time of what kinds of changes we are likely to make to an element, thus allowing it to optimize how it handles the element ahead of time, performing potentially-expensive work preparing for an operation such as an animation, for example, before the animation actually begins. This property is the new will-change property.

The New: The Glorious will-change Property

The will-change property allows you to inform the browser ahead of time of what kinds of changes you are likely to make to an element, so that it can set up the appropriate optimizations before they’re needed, therefore avoiding a non-trivial start-up cost which can have a negative effect on the responsiveness of a page. The elements can be changed and rendered faster, and the page will be able to update snappily, resulting in a smoother experience.

For example, when using CSS 3D Transforms on an element, the element and its contents might be promoted to a layer, as we mentioned earlier, before they are composited in (drawn onto the screen) later. However, setting up the element in a fresh layer is a relatively expensive operation, which can delay the start of a transform animation by a noticeable fraction of a second, causing that noticeable “flicker”.

In order to avoid this delay, you can inform the browser about the changes some time before they actually happen. That way, it will have some time to prepare for these changes, so that when these changes occur, the element’s layer will be ready and the transform animation can be performed and then the element can be rendered and the page updated in quickly.

Using will-change, hinting to the browser about an upcoming transformation can be as simple as adding this rule to the element that you’re expecting to be transformed:

will-change: transform;

You can also declare to the browser your intention to change an element’s scroll position (the element’s position in the visible scroll window and how much of it is visible within that window), its contents, or one or more of its CSS property values by specifying the name of the properties you’re expecting to change. If you expect or plan to change multiple values/aspects of an element, you can provide a list of comma-separated values. For example, if you’re expecting the element to be animated and moved (its position changed), you can declare that to the browser like so:

will-change: transform, opacity;

Specifying what exactly you want to change allows the browser to make better decisions about the optimizations that it needs to make for these particular changes. This is obviously a better way to achieve a speed boost without resorting to hacks and forcing the browser into layer creations that may or may not be necessary or useful.

Article Source - Everything You Need to Know About the CSS will-change Property

Your css will be

.wallpaper {
    width: 100%;
    height: 100%;
    position: absolute;
    opacity: 0;
    background-repeat: no-repeat;
    background-position: center;
    background-size: cover;
    will-change: transform, opacity;
    -webkit-animation-timing-function: linear;
}

.animate {
    -webkit-animation-name: fadeInOut;
    -webkit-animation-duration: 6s;
}

@-webkit-keyframes fadeInOut {
    0% {
        opacity: 0;
        -webkit-transform: scale(1);
    }
    16% {
        opacity: 1;
    }
    90% {
        opacity: 1;
    }
    100% {
        opacity: 0;
        -webkit-transform: scale(1.1);
    }
}

---

Other Useful Sources:

• Everything You Need to Know About the CSS will-change Property
• CSS-TRICKS Article
• SNOOK.CA
• W3C Editors Draft
• Mozilla Developer Network
• Browser Support
• will-change: update browser support