CSS keyframe animation CPU usage is high, should it be this way?

I use following keyframe animation on several elements:

@keyframes redPulse {
	from { background-color: #bc330d; box-shadow: 0 0 9px #333; }
	50% { background-color: #e33100; box-shadow: 0 0 18px #e33100; }
	to { background-color: #bc330d; box-shadow: 0 0 9px #333; }
}
@-webkit-keyframes redPulse {
	from { background-color: #bc330d; box-shadow: 0 0 9px #333; }
	50% { background-color: #e33100; box-shadow: 0 0 18px #e33100; }
	to { background-color: #bc330d; box-shadow: 0 0 9px #333; }
}
.event_indicator {
	display: inline-block;
	background-color: red;
	width: 5px;
	margin-right: 5px;

	-webkit-animation-name: redPulse;
	-webkit-animation-duration: 1s;
	-webkit-animation-iteration-count: infinite;

	animation-name: redPulse;
	animation-duration: 1s;
	animation-iteration-count: infinite;
}

On my computer I am getting around 40% CPU usage both in Chrome and Firefox. Is it the current state of animations (nice but not usable for now) or am I missing some magic property?

You can check the following sample with the same animation: http://jsfiddle.net/Nrp6Q/

Yes, this is normal because you have several infinite-loop animations on the page. The CPU is therefore continually doing work while these elements are rendered. There is a "magic" property that will significantly cut-down the CPU usage and that is:

transform: translateZ(0);

This will composite the elements into their own layers (by tricking the browser into thinking it will be doing 3D transforms) and the browser should, in most cases, take advantage of GPU acceleration, lessening the burden on the CPU. For me this cut it down by about 20% (almost half).

To read more about this technique take a look at: http://ariya.blogspot.com/2011/07/fluid-animation-with-accelerated.html

Additionally, the more keyframes you have in the animation, the more taxing it will be as well. Just try the animation with the middle keyframe cut out and you will see another substantial (~10-12%) drop in CPU usage.

Lastly, not all properties are equal -- box-shadow is much harder for the browser to animate smoothly than, say, background-color. Leaving all of the keyframes intact but dropping the box-shadow property, using the translateZ(0) trick had my CPU usage hovered at only 10-11%.

As much as it pains me to say this, for infinite-loop animations an animated .gif is going to perform much, much better than CSS3 in the current state of browser animation, especially if you plan for many of them to remain rendered on the page for some time.

Update 2017:

For those still finding their way to this question and answer, translate3d(0, 0, 0) provides the same benefit as translateZ(0), you're just also setting translateX() and translateY() at the same time. Please ignore the comment by @Farside as he uses translate3d(X, Y, Z) in his demo but does not compare it to translate(X, Y), which would show that using this technique still makes a significant difference.

According to this question, some people have found better performance across all browsers, especially Chrome, with transform: rotateZ(360deg).

One of the possible ways to reduce the load on CPU, is to use a so called null transform hack, which is often hailed as something of a silver bullet. In many cases it will drastically improve rendering performance in WebKit and Blink browsers like Chrome, Opera and Safari.

Usage of the "Null transform hack" (a hardware compositing mode)

The null transform hack basically does two things:

1. It switches on the hardware compositing mode (assuming it's supported for the platform)
2. It creates a new layer with its own backing surface

To "force" a browser, simply add one of these CSS properties to the element:

transform: translateZ(0);

/* or its friend: */
transform: translate3d(0, 0, 0);

When working with 3D transforms, it's good to have these properties as well to improve the performance:

backface-visibility: hidden;
perspective: 1000;

Caveats of the "null transform hack"

Enabling a hardware acceleration in CSS3 for a lot of objects may slow down performance! Apparently, each null 3D transform creates a new layer. 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. So even if the GPU does a good job, the transfer of many objects might be a problem so that using GPU acceleration might not be worth it. The cite from W3C:

> 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.

Moving a few big objects has a higher performance, than moving lots of small items when using 3D-acceleration. 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.

Moreover, a GPU is designed specifically for performing the complex mathematical/geometric calculations, and offloading operations onto the GPU can yield massive power consumption. Obviously, when hardware kicks in, so does the battery of the target device.

The modern way: the will-change property

The progress is not standing on the one place... W3C introduced the will-change CSS property. To cut the long story short, 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.

Here's what they say in the the draft:

> The will-change property defined in this specification allows an author to declare ahead-of-time what properties are likely to change in the future, so the UA can set up the appropriate optimizations some time before they’re needed. This way, when the actual change happens, the page updates in a snappy manner.

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;

When developing for mobile, developers are forced to take the wide array of device constraints into consideration while writing mobile web apps. Browsers are becoming smarter, and sometimes, it's better to leave the decision to the platform itself, instead of overlapping acceleration and forcing the behavior in a hacky-way.

I had a similar case of high CPU usage when animating some elements with CSS3. I was animating the "left"-property of ~7 elements, with some opacity- and shadow-properties used in my whole page. I decided to switch to jQuery.animate, which sadly didn't improve the performance at all. My CPU (i7) was still at ~9-15% while displaying the page, several tricks (translateZ, etc) didn't really improve the performance either - while having my layout messed up (some absolute-positioned elements were involved, ouch!).

Then I stumbled upon this wonderful extension: http://playground.benbarnett.net/jquery-animate-enhanced/

I simply referenced the .js-file, didn't make a single change at the jQuery transitions, and my CPU usage is now 1-2% on the very same page.

My recommendation: when facing CPU issues using CSS3 transitions, switch to jQuery + the animate-enhanced-plugin.

You can also use this on any of the following class elements where you want to use GPU instead of CPU

.no-cpu {
    transform: translateZ(0);
    -webkit-transform: translateZ(0);
    -ms-transform: translateZ(0);
}

<element class="event_indicator no-cpu">animation...</element >

To a particular case of 'pulsing' background animation, reported here, I've come up with a css+js solution.

In my case the background animation was on background-position property rather than on the background-color, but the principle is the same.

Ok, let's say you have a block with a particular background:

<div class="nice-block">...</div>

Let's style it: (scss)

.nice-block {
  background-color: red;
  //or it can be: background: linear-gradient(45deg, #red, #white, #red);
  //and:          background-size: 600% 600%;

  //the transform and will-change properties
  //are here to only enable GPU
  transform: translateZ(0);
  -webkit-transform: translateZ(0);
  -ms-transform: translateZ(0);
  will-change: transform;
  
  transition: background-color 5s ease;
  //if you want to add a pulsing effect 
  //to a gradient, see the following two lines:
  // background-position: 0% 50%!important;
  // transition: background-position 5s ease;

  &.animated {
    background-color: white;
    //and in case of gradient animation:
    // background-position: 100% 50%!important;
  }
}

Now it's time to make the effect happen by adding a class 'animated' to the block with some JavaScript:

var bgAnimateTimer;
function animateBg () {
  clearTimeout(bgAnimateTimer);
  bgAnimateTimer = setTimeout(function () {
    clearTimeout(bgAnimateTimer);
    bgAnimateTimer = setTimeout(function () {
    
      document.querySelector('.nice-block').classList.toggle('animated');
      
      //jQuery alternative is:
      // $('.nice-block').toggleClass('animated');

      animateBg ();
    }, 5000); //5 seconds for the animation effect
  }, 2500); //2.5 seconds between each animation
}

animateBg ();

This improved performace in my case by ~15 times.

(i) Note to calculate seconds for transition and timeouts correctly both in css and js if you want values different from 5 seconds.

Animate endless loops with JS instead of CSS infinite to increase CPU perfomance

Method 1 - Change animation to ''

@keyframes comet4Translate {
  0% {
    transform: translateX(0%) translateY(-50%);
  }

  100% {
    transform: translateX(100%) translateY(100%);
  }
}

@keyframes comet1Opacity {
  0% {
    opacity:1;
  }

  100% {
    opacity:0;
  }
}

#XMLID_640_{
  transform: scale(.8) translateX(-20%) translateY(-20%) translateZ(0);
  animation: comet4Translate 7.5s 3s ease-in-out alternate, comet1Opacity 8s .5s ease-in-out alternate;
  will-change: transform;
  will-change: opacity; 
}

createAnimation = (selector, intervalDelay) => {
    setInterval(() => {
	$(selector).css('animation', 'none')

	setTimeout(() => {
	    $(selector).css('animation', '')
	}, 3000)
    }, intervalDelay)
}

// first comet
createAnimation('#XMLID_640_', 16000)

Method 2 - Use transition instead of animation

#XMLID_640_{
  transform: scale(.8) translateX(-20%) translateY(-20%) translateZ(0);
  animation: comet4Translate 7.5s 3s ease-in-out alternate, comet1Opacity 8s .5s ease-in-out infinite alternate;
  will-change: transform;
  will-change: opacity; 
  opacity: 1;
}

#XMLID_640_.animated {
  transform: scale(.8) translateX(150%) translateY(150%) translateZ(0);
  opacity:0;
}

let switcher
const animateViaJs = selector => {
	setInterval(() => {
	    if (!switcher) {
		switcher = true
		$(selector).css('transition', 'opacity 3s ease-in-out, transform 4s ease-in-out')
	    } else {
		switcher = false
		$(selector).css('transition', 'none')
	    }

	    document.querySelector(selector).classList.toggle('animated')
	}, 5000)
}

animateViaJs('#XMLID_640_')

Method 3 - AnimeJs

#XMLID_640_{
  will-change: transform;
  will-change: opacity; 
  translateZ: 0;
}

const createAnimeJsLoop = (selector, intervalTimer, cfg) => {
	const tl = anime({ loop:true, targets: selector, easing: 'easeInQuad', ...cfg })

	setInterval(() => {
	    tl.pause()
	    setTimeout(() => tl.restart(), 5000)
	}, intervalTimer)
}

createAnimeJsLoop('#XMLID_640_', 30000, {
opacity: [
    { value: 1, duration: 0 },
    { value: 0, duration: 2000 }
],
translateX: [
    { value: '-20%', duration: 0 },
    { value: '150%', duration: 3000 }
],
translateY: [
    { value: '-20%', duration: 0  },
    { value: '150%', duration: 3000 }
],
translateZ: 0
delay: 3000
})