CODEWITHSUNDEEP
javascriptcsscss-transitions
Chri.s
Chri.s

Reputation: 1456

CSS performance - how to evaluate - animation (transition) of floating button size on scroll (transform scale vs height/width)

Introductory information: I've made a fixed menu button to show the navigation menu when using a mobile device. For this application I'm using the Headroom.js script to make the button smaller when scrolling downwards to ensure that it doesn't block too much of the content. The animation/transition is applied by adding a class with the given changes.

In the original method i changed the size and look of the button by changing height/width of the parent element and padding of the child element with CSS (and css transition).

The new method, which I've read could/should be better according to various sites, is changing the size of the button by using transform: scale(). Note that i'm also moving the element a bit by also applying translate3d(20px,20px,0) in this method. However, it feels a bit smoother when scrolling using the transform: scale() method (could be a placebo effect though), but using chrome dev tools' timeline gives me seemingly inconclusive results.

Therefore a part of my question is also how I should evaluate the best method. Is timeline in Chrome Dev tools the best option, or is there a better way to do it? And which elements of the timeline should I base my choices on? and the other thing is, based on your interpretation of the images and/or tests combined with your knowledge, which method performs the best (or should perform the best in theory)?

Beneath you can see two examples of the timeline with each method. Changing height/width and padding (original method): Height/width method





Method using transform: scale() to change the size:

Transform scale method

Also you can try the different methods in fiddles here:
link: Original method changing height/width and padding
link to new method: using transform:scale

Please ignore the poor layout of everything; especially the button. The ugly image inside the menu button is just to show, that there's an image included in the layout on my own page and to take that into performance considerations. The images in the back is also included since it's a webshop with a lot of images which could influence performance.

CSS for added class that makes the changes in the original method: 

.mobile-nav.headroom--unpinned {
    height: 40px;
    width: 40px;
}
.headroom--unpinned .mobile-content{
  padding-top:4px;
}


CSS for the added class using transform:scale():

.mobile-nav.headroom--unpinned {
transform:scale(.5) translate3d(20px,20px,0);
}


So to summarize my questions:
How do I evaluate which methods has the best performance, and which method would you say performs the best?

A final note: I know that the methods are different (animating different things and more elements in the original method) but these are the 2 options which i prefer as it is right now.

Upvotes: 1

Views: 1043

Answers (1)

tao
tao

Reputation: 90227

I believe you are missing the point, Chris: the reason why no other property but transform and opacity should ever be animated is because they don't trigger a repaint in anything else, even if the element is in the document flow (and because you can basically do anything with these two alone in like 95% of the cases).

From the "hit-on-performance" point of view, there are two types of animations:

  • those that trigger a repaint in other elements than the animated element
  • those that do not.

That's the main reason behind recommending animations by transform, opacity or position:relative;left|right|top|left. Because they don't actually move the element in flow, thus not triggering a repaint to every single other element in flow after the one being animated.

Now, if the said parent was positioned absolute (which I assume to be the case), it wouldn't have triggered a repaint to the rest of DOM anyway so the differences between that method and transform would have been minor. Inconclusive, as you put it. In theory, repainting two elements instead of one should be slower.

If you need to test, make 10k clones and trigger animation on all of them, with each method.

That will be conclusive.

If you really want to min-max this (as in spend absurd amounts of time on hardly noticeable improvements, as I do) you will find plenty of resources that will recommend:

  • replacing any .animate() with .velocity()
  • never animating anything but transform or opacity, although Velocity claims they animate anything without a hit on performance (i find that debatable/arguable, at best) - but it's a net improvement over .animate()
  • sticking to CSS transitions, if possible (basically if you don't need chains)
  • using Web Animations API

Personal advice: never count on synced CSS animations, especially when you have many of them. If you change tabs or the system does something extremely resource heavy for a while, your animations will be way off. If you need chains, chain.

Upvotes: 1

Related Questions