

Optimizing Rendering Performance - kinlan
https://developers.google.com/web/fundamentals/performance/rendering/

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

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

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

~~~
dheera
Yeah, I mean things like this:
[https://github.com/brutaldesign/swipebox/commit/235a0c1b213b...](https://github.com/brutaldesign/swipebox/commit/235a0c1b213bfb7fd4f8fb58d00245e51a55e18e)

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

