One Scrolltrigger or several? Patterns for animating elements across multiple components but on the same page

[granularclouds]

Asking the following with a concern for performance, rather than code cleanliness or reusability:

 

Is one better off using a single Scrolltrigger, or multiple, when animating elements across different components, but all on the same page?

 

Some context — I'm using useGSAP in React (Next) to animate a timeline with Scrolltrigger that runs the length of a landing page. The elements animated are contained across several components, representing different sections of the page.

 

On one hand, it is obvious to me that a single Scrolltrigger is less overhead than multiple (less initialization etc.).

 

On the other hand, I'm unsure what GSAP does behind the scenes as far as ignoring out of viewport elements and so on. So - if I am using a single Scrolltrigger (less overhead), could I still be incurring more cost, since GSAP is tracking elements I no longer care about? Am I just better off using multiple Scrolltriggers and aggressively scoping?

 

If anyone has any repos or sandboxes demonstrating suggested patterns that'd be much appreciated.

 

(Hopefully higher level/concept questions are okay - and sorry if this is something touched on already - I tried searching for several minutes but couldn't find anything satisfactorily clarifying. Thanks!)

[Rodrigo]

Hi,

 

I would always try to keep the animations for each component inside the component. Often is said as a best practice in React that a component should do just one thing, so I'm not really into the approach of having a component handling animations of elements that are not rendered by that component.

 

I have a couple of code bases but those are protected by NDAs so I can't share them. One is this:

https://wiredave.com/artificial-intelligence

 

That's GSAP & Next(12), the project manager always talked about moving away to Nuxt for several reasons I won't share here but it seems they're still using Next. Every section in that site, regardless how small and simple it is, is a component and the animation resides inside the component and you can see that there is no lag, FOUC or any other issue with the initial load.

 

There is no real gain in terms of creating a number of GSAP instances rather than just one, unless you create thousands of them at the same time, which rarely is the case. Also is always better to make your files more concise and smaller in order to make maintenance easier down the road. In 3 to 6 months or perhaps a few years down the road, it'll be far easier to decipher what you're doing in a smaller file rather than a large one.

 

Those are my two cents on the subject.

Hopefully this helps.

Happy Tweening!

[granularclouds]

Thanks, Rodrigo! And oof, that AI landing page is actually fairly heavy on the machine I use for perf testing, tho I feel it's likelier due to the assets than the scrolltriggers. (Run down late 2010s macbook pro with lots of browser tabs/windows open.)

 

Anyway, I massively fixed my own perf since posting here, tho the solution is unrelated to GSAP. I  have 14 SVGs with identical paths but differing in fill and stroke, and using GSAP to stagger them. Perf was not acceptable before — when I was inlining the SVGs (also tried importing them as component but no change - background-image is a no-go because I need dynamic styling from CSS variables). But! I finally tried out sprites in React/Next - was a little finnicky getting the styles to apply correctly, but wow, buttery smooth scrolling now.

 

I probably no longer need to worry about multiple or single scrolltriggers now. Like you say, it's far better to maintain components with scoped functionality, with the exception of state or ref props or whatever.

 

Good to know that multiple scrolltriggers are not really an issue tho.

 

 

[Rodrigo]

14 hours ago, granularclouds said:

And oof, that AI landing page is actually fairly heavy on the machine I use for perf testing, tho I feel it's likelier due to the assets than the scrolltriggers. (Run down late 2010s macbook pro with lots of browser tabs/windows open.)

Yeah, there is a bunch of huge SVG elements with filters and when you do that performance is out the window. I remember talking to the owner and project manager about going with WebGL but the designs were already made in SVG and paid so there was no turning back from that. At the end some things were made in order to improve performance a bit, but yeah is no bueno 😬. At the end we're paid to do what the client wants to do, even if the result is like this, not to convince clients about the best approach, so the moral of the story is: "The client is right even when is wrong" 🤷‍♂️

 

Great to hear that you were able to solve your issues 🥳

 

Happy Tweening!

[granularclouds]

Hey Rodrigo - totally understood, and hope my comment wasn't rude. The machine I mentioned indeed struggles (when my hundred+ tab browsers are open anyway). Since perf is my north star, it comes in handing for testing and setting a reliable criterion for acceptable frames.

 

But woah, yeah, I would've def gone with canvas or three - didn't realize that was all SVG! Totally get it with clients sometimes tho - dealing with a headache right now as well (unrelated to the SVG question above).