I might have used a bad analogy there. I was not trying to suggest that the length of a timeline might be affecting performance, rather what's on a timeline and what's it's doing.
In this case, there are a bunch of callbacks that run most of the logic for the app. Putting all those callbacks on a timeline might seem benign, but it can create all sorts of problems, like unintentionally triggering other callbacks.
That could be what's happening here. Jumping around your timeline is triggering callbacks, creating new timeline and SplitText objects, resulting in a memory leak.
There's also a bunch of other stuff in your code that could be contributing to that or other problems. This is what your code looks like when I use it with TypeScript. All those red marks you see on the code map to the right are potential errors in your code, and there's about 270 of them.
Some of those errors are pretty basic, like not using a var to declare masterTL and prevPageID, resulting in global variables. You don't even need TypeScript to point that out. Had you been using JavaScript in strict mode, the browser would have thrown an error.
"use strict";
masterTL = new TimelineMax(); // => Error: masterTL is not defined
But most of the errors are caused by not checking for null and undefined values. $audioFile is an error because you're doing a strict null check, which won't catch undefined. To check for both null and undefined values, you should do it like this.
if ($audioFile != null) {
}
Using getLabelBefore() is an error because it can return null. If that happens, the value of prevPage will be "null-=1", which is probably not what you want. The browser will also throw an error when it tries to call replace on prevPageID.
There's just a bunch of stuff like that to go through and fix. That's why I recommended starting over.