Ghost/demon lag in Next.js + GSAP website

[iknownothing]

Hi GreenSock,

 

To provide context:

I am an amateur developer trying to code a portfolio website (I am a Product Manager). Over the last 5 weeks, I coded the site in TypeScript using Next.js and GSAP.

 

My problem:

There is a very noticeable site-wide jank/jitter/lag occurring on mobile. I have been debugging it for more than a week. The very strange thing is sometimes I deploy could-be fixes, the lag goes away and I think I solved it finally, and then it comes back some other time (without any new deployments or code changes!).

 

Things I've tried:

I'm an amateur developer, so it's difficult for me to dive too deep in advanced concepts like browser rendering and memory management. I've been studying the profiler in Chrome DevTools for the past week and I did try the following fixes:

• Rewrote many animations that forced layout reflow into transforms (i.e. scale, yPercent, xPercent instead of width, height, top, left)
• Removed an x-transform sprite animation from the home page that was based on a 16000x350 368KB PNG. My biggest bet was on this causing the lag, I really did not want to remove it because my website looks too plain without it -> but even removing it didn't help!
• Removed a vh hack I was using to subtract the mobile browser address bar height from containers using 'height: 100vh' in CSS (using a globally set root variable with the height of the address bar, then using 'height: calc(var(--vh, 1) * 100)'. I believe this was causing a layout reflow and on elements that were being animated, I believed it might be causing an issue. I removed it, lag was gone, I celebrated, lag came back (no joke - true story).

 

I am convinced there is a memory leak happening in my code (the only thing I can think of) due to possibly incorrect usage of GSAP with React. My website is fairly small (5 pages), my code is straightforward and well-documented, and I am not doing anything fairly complex.

 

My request:

Is it possible to get someone to audit my repo, who has knowledge of Next.js/React? So I can exorcise this lag demon from my code. I am willing to pay a fee, of course, I don't expect it to b done for free.

 

I am sure someone like OSUBlake or Cassie can spot the root issue in minutes. I could really use the tips too, as I plan to continue using a Next.js + GSAP setup for future projects.

 

Please help me. I am a little crushed/demoralized that I spent 5 weeks coding this, only to be defeated by this ghost on/off lag.

 

EDIT: Silly me, forgot to include the website. You can check it here: https://mbmg.studio

 

Steps to Reproduce:

1. Open the website on a mobile browser (Chome/Safari)

2. Navigate to "Resume" section

3. Scroll

4. Observe how the conic-gradient animation is jittery.

5. Scroll further down

6. Observe the rows jumping/jittering while animating

 

Note that this is not always the case - so this is not an issue of mobile not being able to handle those animations. Those animations used to run super smoothly. There is something else at play here, a "Kaelago" in the code.

 

 

 

 

[Cassie]

Heya there pal!

 

Before jumping into discussions about audits and payments and stuff, let's see if we can step back and solve this in a more simple way.

 

First up.

🚨 This is a bit of a red flag to me conic-gradient animation

Could you possibly make a super small reduced test case of this animation in codepen  for us to have a look at. There's certain properties that can be animated, but really shouldn't, and gradients are in that bucket!

Let's see if there's a better approach for you!

[iknownothing]

Hi Cassie,

 

Thanks for responding.

 

I don't believe the issue is in this animation (it was running smoothly for several weeks as I kept adding more things) but I've isolated it in a codepen for you: 

See the Pen qBVqOdL by mmgamal (@mmgamal) on CodePen

 

It did use to glitch on mobile (it would introduce a yellow color not in my code) but when I stacked the tweens as .fromTo() instead of .to() it behaved correctly as it does on desktop.

 

 

[GreenSock]

Sounds pretty frustrating, @iknownothing. Unfortunately performance audits and optimization are very time-consuming and deep topics. My gut says the same things Cassie's did - that gradient is likely rough on the browser rendering-wise. I'd experiment with just creating a big .jpg or .png instead and just animate that to see if it makes any difference. It'd look exactly the same, but you're not asking the browser to dynamically fabricate all those pixels over and over on every tick. 

 

I'd guess that 98%+ of the time, performance bottlenecks are related to graphics rendering in the browser (totally unrelated to GSAP). 

 

We do offer paid consulting help on a limited basis, so if you'd like to pursue that feel free to contact us directly. 

[iknownothing]

@GreenSock, I understand how it can be taxing on the browser - I just felt the issue had to be something else because it did run smoothly most of the time with no jank. I was inclined to think creating multiple timelines with ScrollTriggers on one page + React's re-rendering lifecycle could be leading to some kind of memory leak that was causing the site-wide lag. I mention this because in other libraries, like r3f for example (a React helper library for three.js) it is common to wrap expensive computations such as shaders or geometries with React.useMemo. That makes sense in 3D stuff - but I don't know what's happening under the hood with GSAP.

 

A simple question is - is it ok for me to create multiple GSAP timelines with scroll triggers on one page, without having to worry about memory management? I'm talking around 15 timelines, each with a ScrollTrigger attached.

 

I've removed the conic-gradient animation for the time being. The lag seems to be gone, but I'll confirm after 24 hours at least (could be another false positive lol).

 

Thanks for the help, Jack.

 

 

[GreenSock]

5 minutes ago, iknownothing said:

A simple question is - is it ok for me to create multiple GSAP timelines with scroll triggers on one page, without having to worry about memory management? I'm talking around 15 timelines, each with a ScrollTrigger attached.

 

Absolutely. No problem. 

 

I've literally had many thousands of animations going simultaneously and the browser barely broke a sweat from the GSAP stuff (it's almost always the RENDERING that's the challenge, not the GSAP code execution). And ScrollTriggers are optimized for performance - they do their calculations up front to figure out the intersection points with the scrollbar position and then every time you scroll it's a simple comparison of the scroll value and the start/end. There are no expensive getBoundingClientRect() calls on every scroll or anything. 

 

You could also experiment with adding will-change: transform (css) on your elements that animate. 

[iknownothing]

Awesome - that makes me feel tons more confident. My animations are performant rendering-wise (mostly transforms and opacity) so my concern was the initializations and code exec, but you've confirmed this is a non-issue.

 

I can't thank you enough for the info. Much appreciated.