Optimizing Rendering Performance

developers.google.com

30 points·kinlan··5 comments

One really big thing they don't mention is that (AFAIK) CSS transitions jump straight to the compositing layer. I see a lot of developers jQuery-animating 'left' and 'top' which triggers a huge chain reaction and ends up looking like crap on mobile, instead of using CSS3 animations which don't affect the layout of the page and jump straight to the compositing step.

That's not quite true. Using a CSS transition on left, top, width etc requires a trip to the main thread, so it's no better of worse to do it with CSS than JavaScript. It is bad in both cases and should be avoided.

Equally animating transform and opacity changes with JS or CSS is normally the same. The only time we can do compositor only is when it's something like an infinite animation of something like a transform; that can be done without hitting the main thread. That rarely happens in real life though. Most apps and sites have way more complex anims going on.

I suspect the OP was referring to 'transform: translate3d()' transitions rather than left/top ones, which AFAIK still get a big performance boost.

Yeah, I mean things like this: https://github.com/brutaldesign/swipebox/commit/235a0c1b213b...

(This was my pull request to Swipebox which turned choppy swiping action into almost-native feel. Their latest release seems to have gotten a bit choppy again though, I'll have to investigate the more recent commits later. You can test drive at http://dheera.net/photos/abstract/dancelight using a mobile device).

Google Image Search on mobile also does a good job of achieving almost-native tracking feel.

Yes those do: http://www.html5rocks.com/en/tutorials/speed/high-performanc... I was just clarifying on the remark of JS / jQuery as the cause of poor performance rather than what specifically was animated.

Reply on news.ycombinator.com