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, however in Chrome the transition is very jerky.

Heres is the link, hover over the social icons to see what I mean.. http://www.media-flare.com/pins/ - I have noticed as you resize the browser down to mobile view, it gets worse.

I have done a jsfiddle version here and slowed down the transition as it is harder to see.

http://jsfiddle.net/wsgfz/1/ - This seems jerky in chrome and firefox, smooth in safari and opera.

Is there anything I can do to make the transition smoother?

Here is the code if you cannot view jsfiddle

.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-transition: all 0.8s ease;
   -moz-transition: all 0.8s ease;
   transition: all 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>

Solution 1

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;
}

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