Jump to content
Search Community

improve performance of slide animation

flowen test
Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

hi guys,

 

I created a checkout that slides in from the side of the page. It all makes sense if you go to https://www.shinbyeong.com/ scroll down a bit and click on 'pre-order' on the bottom. 

 

So the first time you open the slider it's a bit chucky, then after performing more times it get's better. I guess that's some cache right there. 

I added a will-change: transform; on the elements affected. But I didn't see any improvements.

 

When I use chrome dev tools to record the performance I'm not sure how to analyse it. I don't see large chunks of delayed properties (in ms). 

 

 

My question: 

  • Can I pre-cache this animation somehow?
  • What else can I do to improve it?

 

 

 

Here is the code, quite simple is my guess:

 

.viewport--locked adds overflow hidden on outer element.

.animate-out transitions some transforms on translateX. Nothing special, except that I fire 2 with a delay and try to create a parallax like effect.

 

const showModal = () => {
  viewport.classList.add('viewport--locked')

  TweenLite.to(viewportOverlay, .5, {
    opacity: 1,
    onComplete: () => {
      checkoutContainer.classList.add('animate-out')
      
      TweenLite.to(checkout, .5, { 
        xPercent: -100, 
        ease: Power4.easeOut
      })
    }
  })
}

const closeModal = () => {
  checkoutContainer.classList.remove('animate-out')

  TweenLite.to(checkout, .45, {
    xPercent: 100,
    ease: Power4.easeIn,
    onComplete: () => {
      TweenLite.to(viewportOverlay, .25, {
        opacity: 0,
        onComplete: () => viewport.classList.remove('viewport--locked')
      })
    }
  })
}

buyButton.addEventListener('click', () => showModal())
checkoutClose.addEventListener('click', () => closeModal())

 

 

 

Link to comment
Share on other sites

Hi @flowen :)

 

You can pre-record the values like this:

tl.progress(1).progress(0);

 

That will make the virtual playhead move to the end and then back to the beginning of the timeline. That can sometimes help with a slight stutter on the first play. If that doesn't fix it for you, a demo would be most helpful.

 

Happy tweening.

:)

 

  • Like 3
Link to comment
Share on other sites

I agree with all the answers/suggestions provided but I also just wanted to say that if you're having performance problems, it's very unlikely that it's related to GSAP. Typically less than 5% of the CPU load has anything to do with GSAP - the vast majority is the browser's graphics rendering/painting and reflow calculations. So, for example, if you're animating a bunch of huge objects that require repainting millions of pixels on each frame, you might want to consider reworking things so that you're not putting so much of a load on the browser in terms of graphics rendering. 

 

If you still need some help, please provide a reduced test case in codepen so we can see what's going on. 

 

Happy tweening!

  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...