#On View Transitions and expected loading behaviors

6 messages · Page 1 of 1 (latest)

kindred gyro
#

Couple not so favorable behaviors with vt implemented (many in my case/project https://sayings.cc) and observations from others in the wild

  1. Page loading takes a lagging. I've tested a couple times by turning off and on vt and notice the page load speed drops when vt enabled (erratic but can be observed if you spend time clicking around, when you see (4) below sometimes you then click multiple times forgetting you already clicked because there's an obvious pause before action, maybe a loading state can fix this (Astro can make this opt-in, if using vt)).

  2. Certain scripts would not re-trigger. In my specific case, following the doc, I've had to try to re-trigger gsap astro:after-swap and instead of playing on subsequent page visit, it errors, without which it plays it only on full refresh. Mind you all such scripts are loaded astro:page-load.

  3. Despite having this snippet document.addEventListener('astro:after-swap', () => window.scrollTo({ left: 0, top: 0 })) Astro still "remembers" the scroll position of the last page and returns scroll there when go back. My expectation is that I'm "after-swapping" the page back to top, drag the scroll all the way top before/while loading page. Of course, refreshing present page would be browser's default of taking down your former scroll position so that would be expected.

  4. Following from (1) there's this "batch loading" behavior where as if because of the lag, when Astro eventually wakes up, it remembers all the clicks then it doesn't just load the last page click but cycles through, so the page just keeps changing.

  5. My suggestion for preventing (4) is not necessarily vt related but Astro generally. I think before Astro should load/swap a page (dunno if this goes against Astro's philosophy, since not wanting to load scripts to client, then it can be opt-in), it should check if the url matches with the initiating click/link and if it does - either do nothing or prevent pointer events.

grizzled bloom
#

Good feedback! You could also post a link to this in #feedback-ideas

for 1. you can create your own loading state with the new lifecycle events

I have noticed the perceived lag of navigation, I think it can be mitigated by optimistically changing things like link color or using focus state to signal to use their click is received

woven hemlock
#

Browsing without view transitions feels so fast with Astro because the browser can already display the page in parts during loading. The perceived delay with view transitions is largely independent of Astro and applies to the browsers view transition API in general.

  • Prefetch target page (Astro specific)
  • Click on link (user)
  • Load target page completely (Astro specific)
  • Create a screenshot of the current page (browser)
  • Stop interactivity of the page (browser)
  • Update DOM (Astro just swaps in DOM of loaded target page)
  • Start animations (browser)
  • Wait for animations to finish (browser)
  • Allow interactivity again (browser)
    If the time for the animation is set to 0.5 sec, the page is not responsive for 0.5 sec. You will notice this, especially if there is an additional loading time for the page.
kindred gyro
#

Damn, thanks so much to both of you @grizzled bloom x @woven hemlock I'm even better educated yet

#

And your summary, @woven hemlock is quite helpful. Would you say, at this time, except with the loading animation (intercept) as suggested by @grizzled bloom, there's no way to optimize the browser side of things?

woven hemlock
#

Afk, will answer later 😁