Jump to content


improve performance of slide animation

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 = () => {

  TweenLite.to(viewportOverlay, .5, {
    opacity: 1,
    onComplete: () => {
      TweenLite.to(checkout, .5, { 
        xPercent: -100, 
        ease: Power4.easeOut

const closeModal = () => {

  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


There is no fluid animation when mixing css and js animations.

Try to handle the css animations also using GSAP.
Put it in a reduced CodePen and we'll see ...


Nice Saturday



  • Like 1
Link to comment
Share on other sites

Hi @flowen :)


You can pre-record the values like this:



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

Your animation was really smooth for me, and I didn't see anything unusual from Chrome's Rendering dev tools. 

  • Like 2
Link to comment
Share on other sites

Thanks for the replies, everyone!


Some good tips there, which I saved for future reference :) 


Strangely, the animation is smooth now for me as well.... so ehm, ?‍♂️





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.