Inconsistent performance for page load animation on reload


Hello :waving_hand: everyone. I hope you have a wonderful New Year :slight_smile:

I’m having trouble with a page load animation in my site.

You can see in the link it is a pretty straightforward page load animation. Or that’s what I thought.

First time you load the page, it works perfectly fine in every device, browser and OS I’ve tried (Safari, Chrome, iOS, MacOS, Windows…).

  1. It works without any issue in desktop.
  2. However, in devices such as iPhone or iPad (Safari and Chrome), if you try to reload the page from the reload button, it will fail randomly at some point. It always works when reloading the page using the pull down interaction (which drives me crazy), but with the browser’s reload button… sooner or later (specially if you’ve done some scrolling) the animation will crash and some elements of the animation will be invisible until you start scrolling again, as if the animation ocurred but with invisible elements. The full animation won’t work again until I reload the page using the pull down option.

I believe it has something to do with the fact that one of my initial states for the animation is to set the cover-section to 100svh in order to prevent the user to scroll while the load animation is happening. That’s something I want/need to happen, but maybe there is another way?

My concern is I’m not sure about what’s failing and I definetly don’t know how to solve it even though I’ve been trying different things for the last days before sharing it with you. I’ve also tried switching between the new GSAP animation UI (very nice, btw) and the classic animation UI in case there was some buggy performance going on, and still the same issue.

Am I doing something wrong? Is there a better way to build this load animation?

Thanks a lot! :slight_smile:

Here is my site Read-Only: LINK

Hi there,

When page load animations behave inconsistently, it’s typically due to competing animation triggers or timing conflicts. Here’s how to resolve this:

Using separate elements for each animation will prevent conflicts and give you more precise control over the animation sequence. If that’s not feasible, try restructuring your animations to ensure they all start from the same initial state. Switching to “Animate to” tweens instead of “Animate from” tweens can also provide more predictable results.

For animations involving images, make sure they’re set to Eager: loads with page rather than lazy loading. This ensures proper page height calculations and smoother animation behavior.

Hopefully this helps! If you still need assistance, please reply here so somebody from the community can help.

Hi there, thanks for the tips.

I’ve tried these things before thanks to other forum threads but it is still not working properly :frowning:

I’ll keep digging while someone can help me solve it :slight_smile:

Hey, I have the same problem and I am also facing the GSAP Bug FUOC, so the original page flashes in shortly and then the animation starts. Have you considered this in IX3?

Hi! :slight_smile:

I dealt with the “flickering” when I was using the new interaction panel by making sure that the final CSS states would not flash bejore JS would load. Is this what you meant? I got rid of the flashing but the random reload issue is always there and it only happens when I use the reload button in the mobile or tablet browser.

Nevertheless, right now I’m not using the new interactions panel. I decided to try it with the old one to check if it was some IX3 bug but… Unless there is something I’m missing, I guess it is not.

Please, let me know if I understood correctly your question.

Thanks for the answer :slight_smile:

Hey! Thanks for your fast response. @MikeNohales

How did you fix it? The page wrapper is set on display flex, but gets somehow rendered away and then the animation starts

Well… I’m not sure to be the right guy to help you :grin: but I can tell you what I did.

I just made sure that every single section that was not part of the load animation was set to hidden and, as part of the load animation, right when it finishes, I would add a set action to switch everything to their desired display setting. I know, but I didn’t try it, that for you to keep working on the editor mode without changing display states over and over again, you can add a little CSS to help with that. But again, I didn’t try it.

And for those elements that are part of the load animation that may interfere (if they do), you do basically the same with display, opacity or anything that ensures that they cannot flash before the animation starts.

I followed some youtube videos and threads here and there to understand what was going on. It’s just a workaround to deal with the fact that CSS may load faster than JS so there may be a more elegant solution that I don’t know :slight_smile:

Is this helpful?

I won’t count my chickens before they are hatched but… I may have a solution for the reload thing :sweat_smile:

I used this piece of code in the head section of my homepage:

<script>
  // Force scroll to top on page reload to prevent animation conflicts
  if (history.scrollRestoration) {
    history.scrollRestoration = 'manual';
  }
  
  window.scrollTo(0, 0);
</script>

Basically, it seems like it is a conflict of interest situation between the animation, that I want to start at the top of the page, and the mobile/tablet browsers doing their biggest effort to reload the page at the exact point where I was when I hit the button (not necessarily at the top).

The difference with reloading the page with the pull down interaction is that this one actually makes a fresh start, and that’s why it always worked fine in contrast to the reload button.

Still, I’m not an expert and any correction and/or advice on this subject is more than welcome :slight_smile:

I’m going to keep this thread open for a couple of days to make sure it works or someone has a better suggestion and then, hopefully, I will mark it as solved :slight_smile: