Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
pjay79

Greensock performance

Recommended Posts

So i am new to front end development, self taught last 6 months, and got a job at a design agency where I was animating perhaps simple things like hamburger menu / overlay menus with gsap and was told that i should be using more css animations for these things for better performance. Does anyone work at a commercial level where they have been using gsap for all animations perhaps except simple hover / button transitions? How do you decide when to use gsap vs css?

 

 

Link to comment
Share on other sites

CSS animations are better if you close your eyes and believe hard enough. I honestly haven't heard anybody say that in a long time as it's kind of stupid argument. What makes a CSS animation running at 60fps better than a JavaScript animation running at 60fps?

 

There might be certain cases where CSS performs better, but overall? I think not. Bring out the bunnies!!!

http://www.goodboydigital.com/pixijs/bunnymark_v3/

 

Thank you. Case closed.

 

Some might say that's not a fair comparison because CSS can't animate canvas... exactly! And CSS can't animate a lot of stuff with SVG either.

 

Webpages are no longer made up of a bunch of these square things called divs. Check out these stats about the top 100 sites. Some pretty interesting stuff in there.

https://ihatetomatoes.net/awwwards/

 

 

.

  • Like 6
Link to comment
Share on other sites

How do you decide when to use gsap vs css?

Hi pjay79 :)

 

Welcome to the GreenSock forums.

 

As Blake talked about in his post - CSS has quite a long list of limitations. So, to answer your question: I'd recommend GSAP for everything except maybe those super simple things like a hover and even those can be made quickly and easily with GSAP. You just can't beat all the features and plugins of the GreenSock Animation Platform. 

 

There are a number of blog posts that would be some good reading for you. Here are a couple:

https://greensock.com/css-performance

https://greensock.com/transitions/

 

I have a feeling those people telling you to use more CSS animations probably don't have experience with anything else. I've said it in other posts and I'll say it again. There are two types of people in this world. Those who think CSS animations are a good thing and those who have tried GSAP.  ;) 

 

I'm a bit biased, but I don't think you'll find any better animation platform than GSAP. Of course, we also have the most helpful forum on the web with the best people. 

 

Hopefully that helps a bit.

 

Happy tweening.

:) 

  • Like 5
Link to comment
Share on other sites

If you had to choose one reason why CSS animations are not the best option for web animation. It would be the ease of changing timing without having to rewrite everything. 

 

For example, once you are done creating all these complex CSS animation keyframes with from and to, or percentages offsets with the @keyframe rule. And you need to make even the smallest of changes.. get ready for a nightmare of rewrite city. That was the biggest reason, I personally switched to GSAP. With GSAP i can make as many changes as possible without having to rewrite hundreds lines of CSS animation code.

 

Timing is the most important aspect of animation, so being able to quickly change properties without having to change @keyframe from, to and percentage time offsets is a glorious thing. GSAP gives you full control without all the bloat of CSS animation... oh and less banging your head on the keyboard.

 

:)

  • Like 3
Link to comment
Share on other sites

Great feedback everybody.

 

I totally understand why it's common for devs to suggest using CSS for everything until you really need something that only GSAP can deliver (shape morphing? custom easing? physics? canvas? there's a long list...). After all, CSS requires no loading of a 3rd party library, and it has a reputation for being fast. Who'd argue with that?

 

Well, I would (though not always). Here are some things to consider...

 

Why not just use CSS/WAAPI until a GSAP-specific feature is needed?

A very large global company (that shall remain unnamed) recently asked me about this as they’re figuring out how to equip their teams for animations. Here’s what I told them:

  • What is it worth to your team to have a consistent animation API to work with day-to-day, on all their sites? What would it cost in terms of training, documentation, etc. to have your teams split their efforts across multiple toolsets (CSS/WAAPI for some, GSAP for other situations)? Remember, GSAP can be used to animate ANYTHING including canvas, WebGL, scroll position, morphing, physics, SVG, etc. whereas CSS/WAAPI is just for DOM elements. You could learn GSAP and be done. No need to shift gears constantly.
  • How many times will someone on your team try animating sometimes hing with CSS/WAAPI and then bump into a wall, like “oh, shoot, I forgot that I can’t do an elastic or bounce ease. Does this mean I have to ‘upgrade’ this particular animation to use GSAP? Will my boss get mad at me? Ah, screw it, I’ll just use the more boring ease and keep it in CSS/WAAPI so I don’t get in trouble.” If you use GSAP, you protect your team from ever running into that wall because GSAP can do *everything* CSS/WAAPI can do plus a lot more. At the end of the day, you probably want your animators empowered to create amazing effects, not managing the technological deficiencies and gauging when they have sufficient reason to jump to GSAP.
  • If you build some animations with CSS/WAAPI and some with GSAP, fast forward a few months or a year when you need to add a new effect to a page that might require some advanced features in the old/existing animations. For example, on the main GSAP page, there’s a pretty complex animation at the top. What if your team builds something like that in CSS/WAAPI or some other library and then you need to add a modal window (like what our “Download” button triggers) and it should pause or gradually slow down those animations in the background to 1/10th the normal speed, and then speed up again when the user dismisses the modal? Uh oh. Or maybe you want to add something to the middle of that animation that does a morph or uses an advanced ease that CSS/WAAPI simply cannot accommodate - that’s going to be a major pain to try to shoe-horn in there. If, on the other hand, your team just uses GSAP consistently throughout your sites, it’s a breeze to handle things like this with a few lines of code. It makes future edits far less painful, saving you time and money.
  • Animation is an inherently experimental process. It never looks right the first time. It’s all about playing with the timings, the eases, etc. I’m pretty confident that if you have your team use GSAP for a while and then CSS/WAAPI for a while, they’ll report that it’s much faster and easier to “play” with animations in GSAP. Far more easing options, and the API is more concise and robust. If I was managing a team of animators and I wanted them to deliver innovative, expressive animations, I’d want to equip them with tools that are the most conducive to that end. Obviously I’d argue GSAP has the advantage, hands-down (but don’t take my word for it - ask around and see what experts say who are deeply familiar with GSAP and CSS/WAAPI).
Compatibility & Other Issues
  • Two of the BIGGEST problems I see with CSS/WAAPI:
    • Easing. Ouch! You’re stuck with cubic bezier. No elastic, no bounce, no wiggle, no rough, etc. Even most Penner eases can’t be reproduced accurately. Nothing like http://greensock.com/custom-ease/
    • Independent transforms. The most commonly animated things are position, rotation, and scale (all transform-related) but you cannot control them independently with CSS or WAAPI. For example, try moving something and halfway through start rotating it and stagger a scale at the end. No-can-do. Animators NEED to be able to independently control these things in their animations.
    • By the way, the to deficiencies above are what make it virtually impossible to use CSS/WAAPI under the hood in GSAP.
  • If/When you run into a bug, GSAP can have a fix in a matter of hours/days whereas with CSS/WAAPI, you’ll be stuck waiting for the browser(s) to fix it. Could take months. Heck, I just stumbled across a bug today in Chrome that hasn’t been fixed since being reported in 2013! That’s no fun when you’ve got deadlines and a site to launch.
  • Compatibility (enough said). GSAP solves a bunch of inconsistencies and bugs in browsers. You just write your animation code and let GSAP worry about making it "just work".
Isn’t GSAP really “heavy”?
  • It’s all relative. A single image on many sites is heavier. This is another very commonly misunderstood issue...
  • It’s a ONE-TIME cost, then it’s cached and free on every page thereafter. It’s on 2.5 million sites, so it's pervasively cached. Point at the CDN, and it'd completely eliminate the load time issue for anyone who has visited a GSAP-powered site previously.
  • Even with the initial load (assuming it's not cached), there’s a very good chance you’d see a net positive effect on load times overall across a site because the unique animation code on each page would likely be less due to the compact GSAP API. In other words, if you’ve got 5,000 pages and each one has even 10% more animation code due to WAAPI’s (or CSS’s) more verbose syntax, and each page averages 15kb of animation code, GSAP would actually save you about 7,465kb…for one visit across those pages! Multiply that by however many thousands upon thousands of page loads you get across those sites, and the savings can be immense.
  • The “real-world” cost for the average user time-wise is perhaps a few hundred milliseconds…once, and then never again.
  • It’s the only robust animation library that’s on every major ad network’s CDN and exempt from file size calculations (meaning it’s FREE in terms of kb).
Performance-wise, you'd probably never notice a real-world difference. In some scenarios, GSAP is actually faster. CSS/WAAPI has an edge in a very particular scenario (if the main thread is really bogged down and you're ONLY animating transforms or opacity...and only on certain devices/browsers). If you animate another property at the same time, that advantage evaporates (moves everything back to the main thread). But again, in the real world it's doubtful you'd ever notice a difference.

 

I could say a lot more, but I'll hold my tongue.

 

It's easy to fall into the "well CSS is baked into the browser and doesn't cost anything to load, so of course I should use them" mindset and miss a lot of the factors that could affect you longer-term.

 

This isn't meant to bash CSS/WAAPI at all. I think there's a time and place for them, without a doubt. As others have said, simple rollovers and things like that are a perfect use case (though it's totally fine to do with GSAP instead, especially if you're already loading it).

 

Other reference articles:

http://greensock.com/why-gsap/

http://greensock.com/kilobyte-conundrum/

 

Thanks for asking the question and giving us a chance to address the topic. Happy tweening!

  • Like 7
Link to comment
Share on other sites

Thanks for all your feedback. Much appreciated. 

Link to comment
Share on other sites

Great feedback @GreenSock. I think this feedback and this thread may become my favourite one to point to the next time I am having a debate on this topic with anyone; along-with the why-gsap and kilobyte-conundrum links of course. This thread has addressed a number of great points from all of you. Thanks everyone.

 

And massive thanks, again, for this really important tool that you introduced years ago, that you have put so much effort into it over the years and still are continuously doing so.

 

Two thumbs up.

  • Like 5
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×