How to initialize scroll triggers until scrolled near the animated container

[Ketaxis]

Or rather, how to be smart about initializing them?

 

Here is the adventure I am on right now:

 

I am using both slick sliders and images that are set to load lazy. Both are things that result in changes in the heights of objects. I could use scrollTrigger.refresh(), except that causes a scroll (why?). Some browsers do not like it when something else scrolls on its own, which required me to either handle the on scroll triggering on my own, or initialize the animations on scrolling.

But wait! Doesn't ScrollTrigger automatically refresh the start/end positions of objects when their sizes change?
Yes. Yes it does. But that is the key phrase - "when their sizes change". Not when their positions change. I did set a resize observer on the <main> element, but again - the refresh function causes a scroll.

 

The first solution, as I mentioned, was to make my own on-scroll event handling (on scroll, scan all objects if they are in the viewport), but that made the timings wrong, and I neither have any idea why, nor did I have a lot of time to figure out, nor did it work very efficiently - my old Nokia 6.1 really does not like it when JavaScript is moderately used (I am curious how ScrollTrigger handles the events).

 

Side note: on that same phone, it is funny to see how the slick sliders move smoothly, while the GSAP animations stutter and move a lot slower than they should. One more question would be how to further optimize the performance of animations.

 

The other solution, which I am using now, is to initialize the animations when the object gets close to the view port, allowing the ScrollTrigger to calculate the start and end positions based on the current location of the respected object. This is still done from a function that gets called on scrolling every 200ms. However, this still results in initializations happening in the wrong times.

 

I must also add, that I have one on-scroll function, which scans an array of functions, which I want to execute. This is to spare myself the trouble of writing the same code for everything that I want to happen on that event. I am not sure if that is efficient.

 

And so, how can I ensure the correct start/end positions of objects, without calling the refresh function, despite higher object being able to push lower ones down, and keep weaker devices happy?

 

Along with that, I will be really happy to get a better understanding of the mechanisms of GSAP, because when things start to interact in complex ways, knowing the inner workings is of tremendous help in optimizing and debugging.

[Cassie]

Hi there!

 

Quote

scrollTrigger.refresh(), except that causes a scroll (why?)

Refresh shouldn't cause a scroll, this sounds like the core of your issues so let's focus on solving that. Can you provide a minimal demo showing the scroll happening so we can see which version you're on and help you debug?

 

You should just be able to call refresh() after all your lazy loading and slick sliders are in the DOM. You certainly shouldn't have to roll your own scroll events or work arounds.
 

Performance-wise...

A lot of performance problems are down to how browsers and graphics rendering work. It's very difficult to troubleshoot blind and performance is a DEEP topic, but here are some tips: 

1. Try setting will-change: transform on the CSS of your moving elements. 
2. Make sure you're animating transforms (like x, y) instead of layout-affecting properties like top/left. 
3. Definitely avoid using CSS filters or things like blend modes. Those are crazy expensive for browsers to render.
4. Be very careful about using loading="lazy" on images because it forces the browser to load, process, rasterize and render images WHILE you're scrolling which is not good for performance. 
5. Make sure you're not doing things on scroll that'd actually change/animate the size of the page itself (like animating the height property of an element in the document flow)
6. Minimize the area of change. Imagine drawing a rectangle around the total area that pixels change on each tick - the bigger that rectangle, the harder it is on the browser to render. Again, this has nothing to do with GSAP - it's purely about graphics rendering in the browser. So be strategic about how you build your animations and try to keep the areas of change as small as you can.
7. If you're animating individual parts of SVG graphics, that can be expensive for the browser to render. SVGs have to fabricate every pixel dynamically using math. If it's a static SVG that you're just moving around (the whole thing), that's fine - the browser can rasterize it and just shove those pixels around...but if the guts of an SVG is changing, that's a very different story. 
8. data-lag is a rather expensive effect, FYI. Of course we optimize it as much as possible but the very nature of it is highly dynamic and requires a certain amount of processing to handle correctly.
9. I'd recommend strategically disabling certain effects/animations and then reload it on your laptop and just see what difference it makes (if any). 

Ultimately there's no silver bullet, like "enable this one property and magically make a super complex, graphics-heavy site run perfectly smoothly even on 8 year old phones" 

 

I hope this helps!  💚

 

If you need any more in depth help please provide a demo so we can actually see what you're animating, when and how.

✨ A demo speaks 1000 words ✨

 

 

[Ketaxis]

Weird...

In different browsers, refreshing would trigger the scroll event, without scrolling. Will have to experiment in the project more, as I could not replicate it in an example. I assumed that this is just a part of the basic functionality, and to reinforce that assumption, I also found this post: 

What happens in action, is that the viewport starts to stutter and teleport as I scroll down. But once all is scrolled through slowly, the same stuttering does not occur again. So far, I have seen this happening in Safari, my old phone's Chrome, my boss' iPhone and on his iOS laptop's Chrome. I am at a loss again...

 

Quote

A lot of performance problems are down to how browsers and graphics rendering work. 

That gives me an idea. The effects in question use opacity. A before and after objects, that are semi-transparent, get moved in opposite directions simulating in a curtains-like fade effect. This may be the actual problem - opacity is infamously hard to process. Maybe I should try manipulating the properties of a linear gradient instead.

 

The moving of the objects is done by using CSS variables, which are then used in transform: translate(). I have indeed read to try not to change the top, bottom, e.t.c. styles, but what about variables?

 

 

 

[Cassie]

Minimal demo please. We're happy to help but without seeing your code it's inevitably going to take 10x as long to figure out what's going on

 

Quote

This may be the actual problem - opacity is infamously hard to process. Maybe I should try manipulating the properties of a linear gradient instead.

Definitely not - 100% the opposite - opacity is hardware accelerated and linear gradients are going to be far far worse.

 

Quote

The moving of the objects is done by using CSS variables, which are then used in transform: translate(). I have indeed read to try not to change the top, bottom, e.t.c. styles, but what about variables?

no need to do this with GSAP, sounds like an overcomplication, but again, I can't see so I can't really judge.

This should be all you need to do to move elements and fade them.

gsap.to(element, {
  x: 100,
  opacity: 0
})

Also - Not sure what you want me to look at in that thread, sorry, that user didn't provide a demo to show the issue and nothing really got resolved or demonstrated effectively.

Here you go, maybe a starting point? Bop that refresh button as much as you like, it shouldn't move the scroll position at all.

 

See the Pen NWOJKYQ?editors=0011 by GreenSock (@GreenSock) on CodePen