(loading) speed of Storyline 360 slides

I created a clumsy 2D platformer prototype by using a virtual "sprite" object to use a Storyline image object for its graphics, and then added gravity and some top-down collision detection. I wrestled for a bit with the graphics since I didn't want to get too crazy, but landed on some freely available animated gifs of a pixel-style ninja character. All of the jump, idle, and running animation loops are easy to drop into states.

Key-down on arrow left triggers the sprite object to change its corresponding Storyline object to its running-left state, and that shows a looping animated gif of the character running, and key-up changed the state to its idle-left animation. Using animated looping gifs in this way was new to me but I'm really glad with how it turned out. I wonder what could've been through the hidden portal...

I mention it here though because testing revealed (I thought) an interesting aspect of Storyline's image states (which function more like entire new objects) in that they don't seem to actually load until called to display. I don't think I'd ever really even considered it, but I expect it'll have later implications for how I design, so maybe you too?

After my level loads, the character will be standing on its starting platform, its idle animation looping, other GSAP-animated elements in the level also doing their thing; however, when I begin pressing the arrow keys to move and jump around, there's a slight gap between when I press a key and a yet-to-be-displayed gif begins to play. To me, having some distant familiarity with the pre-loading of assets, I suspect the other-state gifs aren't fully display-ready on slide load.

Because when that sprite's state is revisited, such as RE-activating the jumping-right state, the animated gif displays pretty soon after without any break. I could understand some delay if each state's gif was megabytes each, but my source gifs are only between 1 and 6 KB.

In the short-term, a practical adjustment could be scripting a secondary "pre-loader" to cycle off-screen through all of the states of any similar "sprite" object so they're actually ready when the need arises and don't need to be retrieved, as I assume creates the delay. Longer-term, knowing the reason for the delay/gap would probably show even better (or no) workarounds.