Jump to content
Search Community

Jumpy Animation - Am I implementing correctly?

Rich Deane test
Moderator Tag

Recommended Posts

Hi There,

 

I am working on site where there are two simple GSAP animations based on Page Scroll and one based on click event…


On some occasions, the scroll animations are a little jumpy and I wonder if I have implemented correctly or if there is a better way of doing things. I assume is due there being Timelines using ScrollTrigger.

 

Also, the menu animation on mobile is quite jumpy, I’m not sure if it’s speed or something else. I would love an expert to take a look at see if there was a better way of implementing.

 

https://motatapu.rdstudios.dev

 

if need be, I can create a minimal demo, but the animations themselves work just fine, it’s when being used on the same page. 


Thanks in advance,
 

Rich

Link to comment
Share on other sites

Wanted to make the same topic. 

 

This is problem which I fight for months with GSAP. Interesting that when I tried to make minimal demo, everything is working perfect. After many tests, I found that perfomance and jumping is going only on real sites where I have a lot of DOM elements. I found this on some testing environment, where I have enabled debug plugin which has a lot of containers with hidden information. And also on pages where I have huge mega menus. So, even if DOM elements are hidden (or sticky) I see huge perfomance drop and this weird jumping effect, especially on large blocks (like you have on your site) and especially if I have several animations close together (for example, big container with parallax and small blocks inside this container with simple reveal effect). 

 

here is my example https://refashion.wpsoul.net/ Animations on first screen are made on load (without Scrolltrigger) and it's more smooth than animations on second screen when I have parallax with Scrolltrigger

 

P.s want to add that Firefox, Opera work much better, the biggest issues are in Chrome

Link to comment
Share on other sites

3 hours ago, OSUblake said:

You can usually improve performance by adding will-change: transform; to elements you are animating. 

 

 

Problem is not in animation, because it works good if it's used on load or on other triggers (not Scrolltrigger). Also, will-change parameter can be used only on few elements on page, otherwise, it will make more problem that solve them. 

Link to comment
Share on other sites

9 hours ago, wpsoul said:

I found that perfomance and jumping is going only on real sites where I have a lot of DOM elements. I found this on some testing environment, where I have enabled debug plugin which has a lot of containers with hidden information.

Are you sure that the performance problem isn't actually being caused by your debug plugin? If you even open the browser's Dev Tools, there's a big performance hit just because it has to track a bunch of extra stuff (unrelated to GSAP). 

 

You said you don't think it's an animation problem - what do you think it is instead? Are you saying you think it's ScrollTrigger? If so, how many ScrollTriggers do you have on the page? I can't imagine you'd see any real-world slowdowns unless you have many hundreds or thousands. 

 

5 hours ago, wpsoul said:

Also, will-change parameter can be used only on few elements on page, otherwise, it will make more problem that solve them. 

Have you tried? 

 

Performance is a very deep topic and unfortunately we don't have the resources to do free performance audits on live web sites. I did glance at the performance profile and it looks like you've got a lot of CSS animations/transitions stacking up on top of each other as well as some slightly costly setTimeout() calls from something. And you've got 48 ScrollTriggers which really isn't terrible. I'd definitely recommend looking into those CSS animations/transitions and make sure you're not creating any conflicts with elements that GSAP is trying to animate too. That'll definitely hurt performance. 

 

Good luck!

Link to comment
Share on other sites

14 hours ago, GreenSock said:

You said you don't think it's an animation problem - what do you think it is instead? Are you saying you think it's ScrollTrigger? If so, how many ScrollTriggers do you have on the page? I can't imagine you'd see any real-world slowdowns unless you have many hundreds or thousands. 

 

I definetely know that problem in Scrolltrigger, because animation is working good without it. So, Scrolltrigger is very sensitive to DOM levels and number of items on page. Will-change parameter helps a bit if there are just several animations (near 5, but not more than 10). I have also some thoughts that this can be related on conflicts with Scroll trigger and libraries which are used in Wordpress. Maybe jquery which is not latest in WP? I will try to make tests on site without extra plugins and with simple theme + deactivate jquery.

 

Link to comment
Share on other sites

9 minutes ago, wpsoul said:

Will-change parameter helps a bit if there are just several animations (near 5, but not more than 10).

 

I've never seen that happen. Browsers allocate a certain amount of memory for will change, so the size of the element matters. If you have 10 full screen images that use will-change, then it might degrade performance. And you can toggle will-change on and off whenever you like. The browser does that internally for CSS animations and transitions.

 

Link to comment
Share on other sites

3 hours ago, wpsoul said:

I definetely know that problem in Scrolltrigger, because animation is working good without it. So, Scrolltrigger is very sensitive to DOM levels and number of items on page.

Nope. Sorry, that isn't true. ScrollTrigger is highly optimized for speed - it simply uses getBoundingClientRect() on refresh() to calculate the intersection points, records them, and then simply compares those start/end numbers with the scroll position. Pretty simple. Makes Having lots of nodes wouldn't really make any difference (for ScrollTrigger at least). Again, it does NOT call getBoundingClientRect() on every scroll or anything like that (which would be expensive). It's a super simple number comparison when you're scrolling. 

 

I think you're mistaken about your conclusions. 

 

If you do a performance audit in Chrome Dev Tools, you'll see that the problem isn't ScrollTrigger. You've got a bunch of other stuff going on, especially those CSS animations/transitions. 

 

Good luck!

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