Slow performance without inspector open

[ferriss]

Hi,

 

Got a really strange pinning issue where if I have chrome inspector docked and open I cannot replicate however when it’s closed scrub: true isn’t working as expect and I can hold down scroll on the Magic Mouse and the end will not trigger until I let go of the mouse. 
 

As if it’s listening to mouse up event, but this is only while the chrome inspector is closed. When it’s open the end triggers in the correct point regardless of whether I’ve taken my finger off the mouse after scroll.

 

Very odd?

[GSAP Helper]

It's pretty tough to troubleshoot without a minimal demo - the issue could be caused by CSS, markup, a third party library, your browser, an external script that's totally unrelated to GSAP, etc. Would you please provide a very simple CodePen or CodeSandbox that demonstrates the issue? 

 

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

 

Here's a starter CodePen that loads all the plugins. Just click "fork" at the bottom right and make your minimal demo: 

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

 

If you're using something like React/Next/Vue/Nuxt or some other framework, you may find StackBlitz easier to use. We have a series of collections with different templates for you to get started on these different frameworks: React/Next/Vue/Nuxt.

 

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

[ferriss]

Hmm, cannot really create a minimal demo as it's a built up example and to strip it back will probably loose the issue.

 

It's basically a nested scroll trigger, so something is always being triggered, so it's performance hungry.

 

On modern machines it seems ok, but on older machines/browsers it's extremely laggy. I suspect scroll thread is being maxed?

 

Are there quick performance wins here such as scroll proxy? Or is this going to need a re-architect? At what point are there too many animation going on, particularly on scrub?

[Cassie]

23 minutes ago, ferriss said:

Hmm, cannot really create a minimal demo as it's a built up example and to strip it back will probably loose the issue.

This is usually how we hunt down bugs - it's a good thing. Strip back until the issue disappears or layer on until you find it.

 

Quote

Are there quick performance wins here such as scroll proxy? Or is this going to need a re-architect? At what point are there too many animation going on, particularly on scrub?

There's absolutely no way to advise you without seeing the code. There are infinite numbers of things you could be animating in infinite different ways. I certainly can't advise you on whether you need to rearchitect your code without seeing the code. Sorry 🤷🏼‍♀️
 

Here's some generic performance info

 

• 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: 
• Try setting will-change: transform on the CSS of your moving elements. 
• Make sure you're animating transforms (like x, y) instead of layout-affecting properties like top/left. 
• Definitely avoid using CSS filters or things like blend modes. Those are crazy expensive for browsers to render.
• 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. 
• 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)
• 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.
• 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. 
• 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.