GSAP Animations lagging (ScrollSmoother + Optimisation?)

[DW92]

Hi,

 

I have a problem, that some of my co-workers experience lagging and stuttering while browsing a website, that was made using GSAP (ScrollSmoother, ScrollTrigger included).

The most problematic part is the Hero section with 3 parallax effects, so I included it, as a codepen here. It's just simply a code and some random pictures from the web, because I can't share my own assets on free CodePen plan, but the html/css/js structure is exactly the same, as in my project.

Can you please take a look and tell me, what can I do to optimize it, as much as I can, in terms of GSAP parameters? I am going a little blind here, because this works perfect on all of my machines (from newest to oldest, with dedicated GPU and integrated one), and all I have is someone else's experience.

The assets are optimised as well. I made sure, that the pictures are as small and lightweight as they can be, so I'm out of ideas now...

 

Thanks!

See the Pen GRXqxZe by DW922 (@DW922) on CodePen

[elegantseagulls]

This issue may be caused by the size of the image and certain browser/hardware's abilities to keep up with the repainting/hardware acceleration of the very large image: the browser has to keep track of the overflow of image off-screen as it doesn't have a concept of what part is going to be transformed. This is especially true with clip-path. Have you tried an image more cropped to fit or removing the clip-path to see if that helps?

[DW92]

Well, the images are mostly cropped to fit 1920p screens (I mean original images, not the ones from the example) and their size is between 400 - 800kb. Do you think it's still too heavy?

Yeah, I haven't tried without clip-path. That's a good idea.

[elegantseagulls]

20 minutes ago, DW92 said:

their size is between 400 - 800kb

I'd be less concerned about file-size than I would overall paint size (how much area/screen the image takes up), maybe try just putting a div in the image's place and see if that's the issue.

[DW92]

Good idea, I will check that too.

What about GSAP config itself? I think, the JS code is pretty slim.

Is there something else I can change to use GSAP better in this case?

[GreenSock]

Like @elegantseagulls said, the file size doesn't matter - it's all about how many pixels the browser has to repaint on every tick. Imagine drawing a rectangle around the areas that change on any given tick - the bigger the rectangle, the harder it is for the browser. This has absolutely nothing to do with GSAP or your JavaScript code. 

 

In my experience 95%+ of the time, graphics rendering in the browser is the performance bottleneck. GSAP code may account for 0.5% of the load on the processor while browser graphics rendering (and event management, etc.) accounts for the other 99.5% (not an exact number, I'm just trying to illustrate the point). So even if you made the JavaScript run 4x faster (very doubtful), you'd never even notice a difference because it's still less than 0.5% of the overall load. When it comes to performance, make sure you're focusing your attention where it actually matters most. 

 

Masks, filters, and large areas of change are pretty tough on the CPU. Avoid those where you can. And try setting will-change: transform on any elements that are moving. Sometimes that can make a big difference (other times it makes no difference - it depends on a lot of factors). 

 

Small note: it's almost always better to do yPercent: -10 instead of y: "-10%". Remember, y and yPercent can actually be combined to make advanced effects quite easy. Like you could center your element with xPercent/yPercent: -50 and then move it around in pixels with x and y.