Delay in page transition on mobile

[kooalab]

Describe your problem 🧐

HI there,
I have an issue with a basic page transition, specifically when accessed on mobile devices and in situations where the site is not cached (e.g., in private browsing mode). The website I'm working on : https://koppk.netlify.app

Configuration:

`I have set up Swup with the following configuration:

const swup = new Swup({    
animateHistoryBrowsing: true,
linkToSelf: "scroll",
plugins: [
    new SwupHeadPlugin({
        awaitAssets: true,
        persistAssets: true
    }), 
    new SwupScriptsPlugin(), 
    new SwupPreloadPlugin({ preloadVisibleLinks: true }), 
    new SwupDebugPlugin()
],
});   

CSS Used:

The CSS for page transitions is as follows:

 html.is-changing .transition-overlay {
      transition: all 0.6s ease;
       }
html.is-animating.is-leaving .transition-overlay {
    backdrop-filter: blur(20px);
    -webkit-backdrop-filter: blur(20px);
    background-color: rgba(7, 8, 11, 1);
}
html.is-rendering .transition-overlay {
    backdrop-filter: blur(0px);
    -webkit-backdrop-filter: blur(0px);
    background-color: rgba(7, 8, 11, 0.001);
}
.transition-overlay {
    position: fixed;
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
    z-index: 5;
    background-color: rgba(7, 8, 11, 0.05);
    pointer-events: none;
    z-index: 5;
    }

On mobile devices, for the first-time visit to the site when no pages are cached, the transition animation behaves unexpectedly. Specifically, after navigating from the homepage to another page, the transition overlay performs normally, but once it fades out, the homepage remains visible for an additional half a second to a second before abruptly switching to the new page. This delay disrupts the smoothness of the transition. Notably, this issue does not occur on subsequent visits when the pages are cached, where the transitions work as intended.

77e657a6-643d-4e77-acdb-be1d6a19faa1.mp4

What is your question? 🙋‍♀️

I would appreciate any insights or guidance on resolving this issue. Could this be a problem with Swup's handling of transitions on uncached pages, or is there an adjustment needed in my configuration or CSS?

What I don't understand is that the " html.is-rendering" class should only be applied when the content has been replaced so I don't it why the old main element is visible after the transition....

Thanks in advance for your help !

URL to minimal reproduction 🔗

Don't have it yet

Checked all these? 📚

• I have read and searched the official docs
• I have checked discussions and existing issues for answers to my question
• I agree to follow this project's Code of Conduct
• I have provided all necessary information to the best of my knowledge

[hirasso]

Hi @kooalab !

I'd try two things:

1. remove the .is-leaving class from your out-animation:

html.is-animating .transition-overlay {
    backdrop-filter: blur(20px);
    -webkit-backdrop-filter: blur(20px);
    background-color: rgba(7, 8, 11, 1);
}

.is-animating should be enough. If that doesn't have an effect, you could also...

2. Check if your issue persists if you set awaitAssets to false in SwupHeadPlugin

[kooalab]

Additionally, I have pushed the changes to a live production environment for more straightforward testing: https://debug-swup.netlify.app/. The same glitch occurs there, and it can be observed under the same conditions – on the first visit in an incognito window on both mobile and PC platforms.

Looking forward to your feedback and thanks again for your support.

[kooalab]

I don't know if this helps, but what I've realized is that it executes the content:replace and then it says that it's waiting for 2 assets to load which may lead to finishing the animation before the page is ready....

Screen.Recording.2024-01-05.at.11.15.53.mov

[hirasso]

Seems to be related to the head plugin and Astro, as you already suspected. I'm afraid I have not used HeadPlugin with stylesheets specific to pages yet, so no experience here. @daun, I think you have used this feature in the past?

I was able to reliably reproduce the issue in chromium like this:

1. in the dev tools, disable the cache and throttle the network speed to "Fast 3G"
2. run npm run preview
3. Navigate between the pages

Observation: There are multiple stylesheets being loaded for the subsequent pages (e.g. /creation-de-site-internet). The delayed content replacement seems to happen simultaneously with the new CSS files being loaded.

[hirasso]

I don't know if this helps, but what I've realized is that it executes the content:replace and then it says that it's waiting for 2 assets to load which may lead to finishing the animation before the page is ready...

This actually sounds like a good pointer towards the problem!

[daun]

The order in the console logs is a bit misleading. It logs the hook name at the beginning of the hook, however long it takes. So if the head plugin correctly delays the content replacement, it will look like content:replace has already happened even though it's actually still running.

[daun]

I have a feeling this has to do with the CSS transition defined on the overlay. Can you try this CSS based on the official overlay demo?

.transition-overlay {
  position: fixed;
  top: 0;
  left: 0;
  right: 0;
  bottom: 0;
  z-index: 999;
  background-color: rgba(7, 8, 11, 1);
  opacity: 0;
  transform: translate3d(0, -100%, 0);
  pointer-events: none;
}

html.is-changing .transition-overlay {
  transition: transform 400ms ease-in-out;
  opacity: 1;
}

html.is-animating .transition-overlay {
  transform: translate3d(0, 0, 0);
}

html.is-rendering .transition-overlay {
  transform: translate3d(0, 100%, 0);
}

[hirasso]

@daun I just tried your CSS, without success (the bug persists) let's take a few minutes next week to debug this together, should noone have had an epiphany until then :)

[daun]

Does enabling/disabling the backdrop filter do anything? And yes, let‘s debug this together next week!

[kooalab]

Hey @daun,

With or without the backdrop filter its the same behavior....

Thanks guys, means a lot 🙌🏼

[hirasso]

@kooalab I can confirm that this is a bug with swup itself. I've created a PR with a fix in #858

[kooalab]

Wow that was incredibly fast, thank you so much for the quick turnaround!

[hirasso]

@kooalab this should be fixed in 4.5.1. Could you check it out and report back? Thank you!