vintage12

Performance Improvements For Transforms

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!

Share this post


Link to post
Share on other sites

Curious if tweening the `y` property (as opposed to the `transform` property) shows a noticeable difference for you.

 

 

Share this post


Link to post
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. 

Share this post


Link to post
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?

Share this post


Link to post
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. 

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

@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 if the star movement on your site is where you are seeing any jitter. Because I see none here.

  • Like 1

Share this post


Link to post
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%.

Share this post


Link to post
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. 

Share this post


Link to post
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.

 

 

 

Share this post


Link to post
Share on other sites

This is tough ... they both tween wonderfully smooth on anything I'm reviewing with (2013 MacBook Air , 2016 iMac , iPhone X, iPhone 6).

 

If I had to take a guess at what is computationally expensive on lower powered machines, it would be that all the stars are generated with box-shadow. 

Share this post


Link to post
Share on other sites

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

 

 

  • Like 1

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites
37 minutes ago, GreenSock said:

moving the rotation:0.01 to a simple set()

 

But Jack, that makes too much sense! 🤣

 

  • Haha 1

Share this post


Link to post
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

Share this post


Link to post
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.