#Does ClientRouter animations make the charge of newer pages sloweR?
9 messages · Page 1 of 1 (latest)
Hi @rare wadi. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
Astro’s docs don’t state that <ClientRouter /> animations themselves make new pages load slower, but they do describe what extra work happens when you enable it:
<ClientRouter />intercepts navigation, fetches the next page, swaps the<head>/<body>, waits for new stylesheets, then runs scripts before firingastro:page-load.[Client-side process]- It also adds some accessibility helpers (like a route announcer) and respects
prefers-reduced-motionby disabling animations for users who request reduced motion.[Accessibility] - When
<ClientRouter />is present, link prefetching is enabled by default (prefetchAll: true), which can actually make perceived navigation faster because the next page is often already fetched.[Using with View Transitions]
So:
- There is some extra client-side work compared to a plain full-page reload (routing logic, DOM swap, animations).
- At the same time, automatic prefetching and SPA-style navigation can make transitions feel faster to users.
The docs do not provide concrete performance benchmarks or say that animations significantly slow down page loads, only that enabling <ClientRouter /> turns your MPA into an SPA with client-side routing and view transitions.[View transitions intro]
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
@rare wadi Kapa.ai is still learning and improving, please let me know how I did by reacting below.
@proud void When using ClientRouter in a dashboard and we have a nav item things take a long time to swap, although the website might be ready in 30ms according to dev tools the actual swap takes ages, without ClientRouter it is fast
Let me check the knowledge base for you again. One moment! :books:
Astro’s docs don’t give specific performance numbers, but they do explain why navigation with <ClientRouter /> can feel slower even if the new page is fetched very quickly.
With <ClientRouter />, a navigation involves several extra steps beyond “request → response → paint”:
-
Client-side routing & fetch
The router intercepts the click and fetches the next page itself instead of letting the browser do a full reload.[Client-side process] -
View transition snapshot
It callsdocument.startViewTransition, which makes the browser snapshot the current page before the DOM is changed.[Client-side process] -
DOM swap work
Inside that transition, Astro performs a “swap”:- Diffs and swaps
<head>content (keeping some styles/scripts to avoid FOUC). - Replaces the entire
<body>with the new body. - Moves any
transition:persistelements. - Restores scroll position.
- Fires lifecycle events like
astro:before-swap/astro:after-swap.[[Client-side process]](https://docs.astro.build/en/guides/view-transitions/#client-side-navigation-process; `astro:before-swap]
- Diffs and swaps
-
Stylesheets & scripts
After the swap, the router:- Waits for any new stylesheets to load before resolving the transition.
- Executes any new scripts added to the page.
- Only then fires
astro:page-load.[Client-side process]
All of this happens after the HTML is fetched, so DevTools might show the network done in ~30 ms, but the visible swap is delayed by:
- Time to parse the new document.
- Time to run the swap (head diff, body replace, persist elements).
- Time to load any new CSS.
- Time to run any new scripts.
On a dashboard with heavier DOM, CSS, or JS, these steps can be noticeable.
A few levers the docs mention that can affect perceived speed:
- Prefetching: With
<ClientRouter />, prefetch is enabled by default with{ prefetchAll: true }, so the fetch is often done early, but the swap still waits on CSS/JS.[Using with View Transitions] - Fallback mode: In browsers without View Transitions support, you can change the
fallbackprop (animate/swap/none) to reduce animation work, though this doesn’t change the core swap logic in supporting browsers.[Fallback control]
The docs do not provide a direct fix for “swap takes ages” or specific tuning tips for heavy dashboards. They only describe:
- The lifecycle events you can hook into (
astro:before-preparation,astro:after-preparation,astro:before-swap, etc.) to observe or customize behavior.[Lifecycle events] - The ability to override the swap implementation via
astro:before-swapandevent.swap, including usingswapFunctionsto build a custom, possibly lighter swap.[[astro:before-swap]](https://docs.astro.build/en/guides/view-transitions/#astrobefore-swap; `swapFunctions]
So, based on the docs:
- Your observation (fast network, slow visible swap with
<ClientRouter />) is consistent with the extra client-side work Astro performs during the view transition. - The documentation does not give a ready-made “performance mode” or concrete optimization recipe for this; it only exposes hooks and utilities if you want to customize or replace the default swap.