ScrollTo in horizontal gallery lags

[Meireis]

I have a horizontal gallery in which I use scrollTo to animate the scroll for the next/previous element.

My issue is that when a new element comes into the viewport, the animation "stops" as if it was rendering the new element. Once it "renders", it runs the remaining of the animation. The images don't have lazy loading and the images are dowloaded from the page load already.

Then, once I run the whole gallery completely, it doesn't happen anymore while I'm in this same page.

Weirdly, if I open the Developer Tools on Chrome, then the animation runs smoothly, with no breaks... 

On Firefox, the behaviour is different. The element comes into the viewport blank and loads the element during the animation.

 

You can check for yourself on the staging link:

http://warren-garrett.meireis.com

 

Any help would be really appreciated

Thanks!

[GSAP Helper]

Hi @Meireis and welcome to the GSAP Forums!

 

Without a minimal demo, it's very difficult to troubleshoot; the issue could be caused by CSS, markup, a third party library, a 3rd party script, etc. Would you please provide a very simple CodePen or Stackblitz that illustrates the issue? There is not a lot we can do in a live sample.

 

Please don't include your whole project. Just some colored <div> elements and the GSAP code is best. See if you can recreate the issue with as few dependencies as possible. Start minimal and then incrementally add code bit by bit until it breaks. Usually people solve their own issues during this process! If not, at least we have a reduced test case which greatly increases your chances of getting a relevant answer.

 

See the Pen aYYOdN by GreenSock (@GreenSock) on CodePen

that loads all the plugins. Just click "fork" at the bottom right and make your minimal demo: 

 

Using a framework/library like React, Vue, Next, etc.? 

CodePen isn't always ideal for these tools, so here are some Stackblitz starter templates that you can fork and import the gsap-trial NPM package for using any of the bonus plugins: 

• React (please read this article!)
• Next
• Svelte
• Sveltekit
• Vue
• Nuxt

 

Please share the StackBlitz link directly to the file in question (where you've put the GSAP code) so we don't need to hunt through all the files. 

 

Once we see an isolated demo, we'll do our best to jump in and help with your GSAP-specific questions. ✅

 

Finally I saw that you have a lot of classes with scroll-snap-align. I'm not 100% sure, but maybe that could be causing this. Have you tried without those?

[GSAP Helper]

Yeah, that's definitely a browser graphics rendering issue, unrelated to GSAP. Here's a quick recording from Dev Tools that makes it clear - notice the huge "paint" time: 

 

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!

[Meireis]

will-change: transorm solved the issue!

I'll take in consideration what you suggested nonetheless. Thank you, you're a life saver 🙌