Jerky CSS transform transition in Chrome

Question

I am using CSS3 transform on a background image to enlarge on hover.

I have tested in the latest browsers of Opera, Safari and Firefox and work nice and smooth, how

Answer 1

Transformations seem to work better than transitions in Chrome. Try this:

.social {
  position: relative;
  list-style: none;
}
.social > li > a {
  text-indent: 100%;
  white-space: nowrap;
  overflow: hidden;
  color: transparent;
}
.social > li > a {
  text-indent: 100%;
  white-space: nowrap;
  overflow: hidden;
  color: transparent;
}
.fbook,
.twit,
.tmblr,
.pntrst,
.insta {
  background: url(http://placehold.it/350x150) center center;
  width: 78px;
  height: 90px;
  background-size: cover;
  float: left;
  margin: 30px;
  -webkit-transform: translate(0px, 0);
  -webkit-transition: -webkit-transform 0.8s ease;
  -moz-transform: translate(0px, 0);
  -moz-transition: -moz-transform 0.8s ease;
  transform: translate(0px, 0);
  transition: -webkit-transform 0.8s ease;
}
.fbook {
  background-position: 0 0
}
.twit {
  background-position: -78px 0
}
.tmblr {
  background-position: -156px 0
}
.pntrst {
  background-position: -232px 0
}
.insta {
  background-position: -310px 0
}
.fbook:hover,
.twit:hover,
.tmblr:hover,
.pntrst:hover,
.insta:hover {
  -webkit-transform: scale(1.5);
  -moz-transform: scale(1.5);
  transform: scale(1.5);
}

<ul class="social">
  <li><a href="" class="fbook">Facebook</a>
  </li>
  <li><a href="" class="twit">Twitter</a>
  </li>
  <li><a href="" class="tmblr">Tumbler</a>
  </li>
  <li><a href="" class="pntrst">Pinterest</a>
  </li>
  <li><a href="" class="insta">Instagram</a>
  </li>
  <li><a href="" class="rss">RSS</a>
  </li>
</ul>

The flickering effect one quick mouse in/out should be gone too now.

Answer 2

Fundamental issue

When an animation runs slowly and looks uneven, it's simply exposing the limitations of the browser that are always there.

Browsers don't have a dedicated thread for rendering animations. Animations have to compete with other browser activities like UI events. And at times the browser is also competing with other software running on the computer. Plus the hardware acceleration available to browsers is likely somewhat limited.

Animations with easing run even slower at the start and/or end of the animation, which makes the natural unevenness of animations even more obvious.

Solutions

The simplest solution to prevent the unevenness from being so obvious is to increase the speed of the animation, and optionally remove or lessen the use of easing. It may be possible to use a type of easing that doesn't slow down quite as much at the beginning and end.

Going forward, another option is to use the hardware acceleration of WebGL (HTML5 canvas tag with a 3D context), which should lessen the issue. As hardware acceleration becomes more common and better-supported on browsers and devices, it should start to be feasible to make complex animations that run as smoothly as older Flash animations.

Answer 3

Update 2017

In response to @Matt Coughlin's post, browsers that natively support animation, now render CSS and JS animations on their own thread....

CSS-based animations, and Web Animations where supported natively, are typically handled on a thread known as the "compositor thread." This is different from the browser's "main thread", where styling, layout, painting, and JavaScript are executed. This means that if the browser is running some expensive tasks on the main thread, these animations can keep going without being interrupted.

https://developers.google.com/web/fundamentals/design-and-ui/animations/animations-and-performance

This developers doc also supports the currently accepted answer from @user1467267...

Where you can, you should avoid animating properties that trigger layout or paint. For most modern browsers, this means limiting animations to opacity or transform, both of which the browser can highly optimize; it doesn’t matter if the animation is handled by JavaScript or CSS.

The document also suggests implementing the use of the will-change property for the property which you will be animating so that the browser can perform additional optimisations for these properties. In my personal experience, this only seems to be noticeable in chrome for opacity and transform.

element{
  will-change: transform, opacity;
}