Forum Discussion
Serious Lag and Memory Buildup in Long Storyline360 Course – Suspected Media Unloading Issue
Why “lag” means different things in Storyline
There are a number of discussions here in which people say their course is “lagging,” but they are often talking about very different things. It helps to separate them into three categories:
- Slow screen loads / navigation delays
- Example: clicking Next takes several seconds before the slide appears.
- Usually related to file size, media preloading, or memory bloat.
- Timeline desynchronization
- Example: the narration plays fine, but Storyline’s timeline (seek bar, animations, triggers) starts running behind.
- Audio and visuals drift apart over time.
- Video/audio sync drift
- Example: lips don’t match speech in a video.
- Typically an encoding or streaming issue.
Which one applies here?
From what you describe — “the audio finishes playing, but the seek bar lags significantly, especially after 30 minutes” — this is timeline desynchronization (2).
It’s not about slide loading or video playback. It’s specifically the Storyline timeline struggling to keep up during long runtimes.
Why this happens:
OrvinCastanha 's original hypthesis is on the right track: Storyline does not aggressively unload assets once they’re in memory. Instead, it tends to cache everything the learner has already visited. That leads to:
- Memory bloat from accumulated images/audio.
- Laggy transitions and slower interactions as the session goes on.
- Worse drift when slides have many layers, long audio clips, or embedded video.
- Extra strain if you try to preload media (you’re right to stop doing this).
Unfortunately, there’s no way within Storyline to force a “memory clear” between slides or scenes. Once a course is running in the browser, only a tab refresh resets memory.
What you can do
- Break the course into smaller modules. 80 slides / 150 MB in a single SCORM is on the heavy side; splitting into 20–30 minute topics dramatically reduces drift.
- Chunk audio and sync to audio completion. Instead of one long timeline, use shorter narration files and trigger layers/animations off “media completes.” This masks drift because each chunk realigns timing.
- Reduce slide complexity. Avoid very long timelines with multiple layered interactions. Fewer layers = fewer objects left in memory.
- Test across browsers. Chrome is often worst at memory management; Edge or Firefox may perform better.
- Avoid unnecessary preloading. It frontloads memory use and accelerates bloat.
Bottom line
What you’re running into is a known limitation: Storyline’s browser-based player holds onto assets rather than releasing them. The visible symptom is timeline drift after 20–30 minutes.
I'm not aware of a silver-bullet fix, but design strategies (smaller modules, shorter audio chunks, simpler slides) can mitigate it and keep performance at a level stakeholders can accept.
Sorry to jump in on this old thread but I am at my wits end experiencing timeline desynchronization on a short module (only 11 slides, runtime all up about 8 minutes). No videos, no large images. The desynchronization occurs when I preview in Storyline itself, or when I personally view it in Review 360, but it does not seem to occur when other people view it in Review 360.
Because the module is already very short and simple, I am a bit lost on how to address this. Could you explain what 'preloading media' means and how to avoid it please? I appreciate any tips you can provide!
Hi Jessica — no problem at all jumping into an old thread.
From what you describe, your situation actually sounds a bit different from the long-course memory drift I was describing earlier.
The key clue is this:
You see the desynchronization when previewing locally or in Review 360, but other people viewing the Review link do not.
That usually means the issue is environment-specific rather than course-design related.
A few things I would check first.
1. CPU load during previewStoryline preview runs inside the authoring environment and is much less efficient than the published player.
If your machine is under load (Teams, browsers, antivirus scans, screen recording, etc.) the timeline clock can drift behind audio playback, which creates exactly the effect you're describing.
Try:
- Closing other heavy apps
- Restarting Storyline
- Publishing to Web and running the story.html locally instead of using Preview
If the drift disappears in the published version, then it's just preview performance, not a real learner issue.
2. Check the audio encodingEven small files can cause sync problems if the encoding is odd.
Storyline behaves best with:
- MP3
- Constant bitrate (CBR)
- 44.1 kHz
- 128–192 kbps
Variable bitrate audio can occasionally produce slight timeline drift. But I don't think this matches the symptoms you describe here.
If you're unsure, you can re-encode the audio in something like HandBrake, Audacity, or Shutter Encoder and re-import it.
3. What I meant by “preloading media”Some developers intentionally load audio/video early using tricks like:
- placing media on a hidden layer
- setting it to play automatically
- immediately pausing it with a trigger
This forces the browser to cache the media before it is needed so playback starts instantly later.
This technique can help with streaming delays, but it increases memory use, which is why I mentioned avoiding it in long courses.
If you haven't intentionally built anything like that, then you're probably not preloading media anyway.
4. One more small thing to checkIf you are triggering animations based on timeline positions (e.g., "at 3.2 seconds start animation"), try triggering them instead using:
When Media Completes
That keeps visuals aligned with the narration even if the timeline clock drifts slightly.
My guessBased on your description, my strong suspicion is Preview performance on your machine, especially since:
- the course is only 8 minutes
- there are no videos
- other viewers don't see the issue
That combination almost always points to a local playback issue rather than a Storyline build problem.
If you want to test further, publish to Web and run the output locally — that will tell you very quickly whether the timeline is actually drifting or whether it's just Preview behaving badly.
Give me a "like" if that helps...
Good luck, John