Jump to content


Timeline performance question

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

Hey guys,


I've noticed that when certain portions of my timeline *first* plays out, that there can be a hiccup, or stutter (especially on mobile). Once the animation has played it runs super smooth (forward and back) from that point on.


I was wondering if anyone else experienced this and had a solution?


I assume it has to do with the asset potentially being in memory or cached?


I am almost wondering if I could just play my timeline out very quickly (1 second) right at page load, then set it back to the beginning.



Link to comment
Share on other sites

Yep, this sounds like expected behavior - let me explain...


When a tween renders for the FIRST time, it must read all the current values and record the start/end values so that it can interpolate inbetween during the course of the tween. 


So let's say you've got 100 tweens in a timeline and you seek() to the very end. It must loop through all 100 tweens, initialize them in the proper order, and render them accordingly. That means reading and writing any values you're tweening. But then if you rewind and play again, since the start/end values are all recorded internally now (which happens the first time each tween renders), none of the reading must occur. It only has to write the values which is faster.


The thing that's probably causing the most problems for you has to do with layout thrashing which is discussed here: https://www.greensock.com/gsap-1-12-0-performance/ where some browsers (most notably Webkit) exact a steep performance penalty for doing read/write/read/write on a single tick. It's impossible to avoid this if you've got a bunch of uninitialized tweens in a timeline that you're seek()-ing because in order to render properly, everything must happen in a very particular order. It can't do "lazy" rendering in that scenario (GSAP will automatically handle all this for you), but if you just run the tweens normally (not jumping forward), lazy rendering can happen (again, GSAP does this automatically since v 1.12.0). 


So here's my advice:

  1. Make sure you're using the latest version of GSAP so that you get the benefits of the lazy rendering and lagSmoothing when possible
  2. If you want to eliminate that initial CPU spike, you could do what you said and jump to the very end of the timeline immediately and then rewind it, thus causing everything to initialize at once. That doesn't actually reduce the CPU effort required, but it allows you to decide WHEN you take the hit (in this case, you choose to do it as soon as the page/app loads so that it isn't noticeable later when the user is interacting). 

Does that help?

  • Like 4
Link to comment
Share on other sites



I am using #1, and I will give #2 a shot.


How do you recommend I jump the timeline and reverse?






Link to comment
Share on other sites



There are several options:

var tl = new TimelineLite();

//then jump to the end



//by default the time() method doesn't suppress callbacks

//then go to the start


  • Like 1
Link to comment
Share on other sites

Good advice Rodrigo, but just to clarify, the timeline.progress(1).progress(0) suggestion would certainly work just as well.

  • Like 1
Link to comment
Share on other sites

Yep, as usual I forgot to mention something useful :P


Luckily there's a plethora of good folks here to patch when my neurons don't make the full spin...


Cheers Jamie!!!

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.