Jump to content
Search Community

Performance Improvements For Transforms

vintage12 test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

Hi,

 

I've been having some performance issues with a feature on my website that uses Greensock. I've broken it down into the minimal parts on Codepen and the live website is here: https://lightspeed-digital.com

 

Is there any way I can improve on this? Using pure CSS isn't an option as I have a function to speed up the stars (not shown within codepen).

 

Thanks for any help!

See the Pen qgYNvy by Vintage (@Vintage) on CodePen

Link to comment
Share on other sites

It seemed to perform fine for me. For the record, box-shadows can be very tough for the browser rendering-wise and pseudo elements can also be challenging. The way you've set this up just may be CPU-intensive (unrelated to GSAP). 

 

And as @Shaun Gorneau suggested, y:1000 is definitely better than transform:"translateY(1000px)" because it can skip parsing, but it really shouldn't make much of a difference in this particular scenario. 

Link to comment
Share on other sites

Thanks for the advice, I've switched to using y instead of transform.

 

My original setup was pure CSS and that performed orders of magnitude better. I guess getting anything approaching that level of performance just won't be possible doing this with JS?

Link to comment
Share on other sites

6 minutes ago, vintage12 said:

My original setup was pure CSS and that performed orders of magnitude better. I guess getting anything approaching that level of performance just won't be possible doing this with JS?

 

Something smells fishy here. You're only using GSAP to animate 3 elements, right? That's dirt-cheap performance-wise (remember, GSAP is only responsible for updating properties which probably accounts for less than 5% of the overall load). I'm super curious to see a comparison. Can you send us the CSS-only version alongside the GSAP-driven one? I want to make sure we're comparing apples-to-apples. 

Link to comment
Share on other sites

7 minutes ago, vintage12 said:

Thanks for the advice, I've switched to using y instead of transform.

 

My original setup was pure CSS and that performed orders of magnitude better. I guess getting anything approaching that level of performance just won't be possible doing this with JS?

 

On the contrary ... GSAP can far outperform CSS. I haven't picked through what is going on within your site ... a typical issue is making use of CSS animations in conjunction with GSAP causing a bit of a battle. I'll see what I can find.

Link to comment
Share on other sites

25 minutes ago, GreenSock said:

 

Something smells fishy here. You're only using GSAP to animate 3 elements, right? That's dirt-cheap performance-wise (remember, GSAP is only responsible for updating properties which probably accounts for less than 5% of the overall load). I'm super curious to see a comparison. Can you send us the CSS-only version alongside the GSAP-driven one? I want to make sure we're comparing apples-to-apples. 

 

Yeah, just the three elements. Unfortunately I won't be able to get the CSS version uploaded until tomorrow now, but I'll reply here again when it's ready.

 

13 minutes ago, Shaun Gorneau said:

@vintage12 Nice site, by the way!

 

After the initial scroll in ( "Lets Go" click or user scroll ), the subsequent scroll navigation looks like it could use some debouncing.

 

But .. I'm curious is the star movement on your site is where you are seeing any jitter. Because I see none here.

 

Thank you! Yes, I'll need to take a look at the scroll navigation afterwards I think.

 

It's on the star movement, yes. It also only seems to adversely affect a small percentage of users, if their CPU can't handle it, they have too many tabs open or their browser tries to use hardware acceleration without a dedicated graphics card on their PC. (I fall into the latter of those and experience problems only part of the time).  Mobile performance I've never seen or had a report of a drop below 100%.

Link to comment
Share on other sites

33 minutes ago, vintage12 said:

It's on the star movement, yes. It also only seems to adversely affect a small percentage of users, if their CPU can't handle it, they have too many tabs open or their browser tries to use hardware acceleration without a dedicated graphics card on their PC. (I fall into the latter of those and experience problems only part of the time).  Mobile performance I've never seen or had a report of a drop below 100%.

 

Hm, have you tried any of the following? 

  1. Set will-change: transform in your CSS for the animated elements? Be careful, though: https://greensock.com/will-change. 
  2. Experiment with setting force3D:true or force3D:false in the tweens. Chrome on the Mac had a bug, for example, that caused it to go REALLY slow when things had 3D transforms (which historically boosted performance quite a bit because it forced layerization). This had nothing to do with GSAP. 
Link to comment
Share on other sites

19 hours ago, GreenSock said:

 

Something smells fishy here. You're only using GSAP to animate 3 elements, right? That's dirt-cheap performance-wise (remember, GSAP is only responsible for updating properties which probably accounts for less than 5% of the overall load). I'm super curious to see a comparison. Can you send us the CSS-only version alongside the GSAP-driven one? I want to make sure we're comparing apples-to-apples. 

 

Here is the CSS only version:

 

I'm seeing huge performance improvements when my browser is set to 2000px width, the CSS version runs smoothly while the JS version is very stuttery. I think it's down to my browser (Firefox) trying to use hardware acceleration with no graphics card present as Chrome handles that situation with no issues.

 

See the Pen qgKrRM by Vintage (@Vintage) on CodePen

 

 

Link to comment
Share on other sites

16 minutes ago, Shaun Gorneau said:

This seems to run even better on an old iPhone 6 ... wondering if you see the same.

 

 

There does seem to be an improvement yes, I just swapped out the box shadow stars for the ones you coded in that pen (thanks also for that, saved me a job!). Here's my PC's CPU usage showing the difference between the old version and the new version:

 

Old version: https://lightspeed-digital.com/

New version: http://lightspeed.ldstage.com/

 

There is still some stuttering, but I guess we're nearing full optimisation now.

cpu.PNG

Link to comment
Share on other sites

The only very minor improvement I'd suggest to Shaun's version is moving the rotation:0.01 to a simple set() call that you do initially. That way, it's not actually animating from 0 to 0.01 on every single tick. I doubt it'll make a noticeable difference, but every little bit helps :)

 

@vintage12, I never heard back from you as to whether or not you tried the will-change: transform or force3D:true (or false). Did any of those help the JS version? The only advantage CSS might have in this case is that since you're only animating transforms, some browsers can utilize a different thread for that when it's in CSS only, so perhaps that's what's happening in your Firefox. There are tradeoffs sometimes, though, which I discuss here: https://greensock.com/css-performance

  • Like 1
Link to comment
Share on other sites

3 hours ago, GreenSock said:

The only very minor improvement I'd suggest to Shaun's version is moving the rotation:0.01 to a simple set() call that you do initially. That way, it's not actually animating from 0 to 0.01 on every single tick. I doubt it'll make a noticeable difference, but every little bit helps :)

 

@vintage12, I never heard back from you as to whether or not you tried the will-change: transform or force3D:true (or false). Did any of those help the JS version? The only advantage CSS might have in this case is that since you're only animating transforms, some browsers can utilize a different thread for that when it's in CSS only, so perhaps that's what's happening in your Firefox. There are tradeoffs sometimes, though, which I discuss here: https://greensock.com/css-performance

 

I'll set that up tomorrow and report back.

 

I did add those but didn't see any noticeable improvements, sorry for not reporting back.

 

Shaun's version has improved performance to 100% on both machines that were causing me trouble, so overall I think we can call this one solved!

  • Like 1
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.
×
×
  • Create New...