#server:defer and viewtranisitons

13 messages · Page 1 of 1 (latest)

brave cryptBOT
#

Hi @zenith panther. 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 prescribe a “one layout with many server islands” vs “several separate server‑deferred routes” pattern, and they don’t mention any special interaction between server:defer and view transitions beyond normal behavior. So there isn’t a single “correct” answer in the sources.

Here’s what is documented and how it affects your decision:

  • server:defer turns a component into a server island that is rendered via its own special endpoint when the page loads. Each island is split into its own route, requested independently, and can run dynamic logic (cookies, fetch, etc.). [Server islands guide; Server directives]
  • The outer page can be static and aggressively cached, while dynamic/personalized parts are deferred into islands. [Server islands concept; Server islands guide]
  • View transitions with <ClientRouter /> switch navigation to client-side routing and add animations, but don’t change how server:defer works; they just affect how full-page navigations are intercepted and animated. [View transitions guide; Enabling SPA mode]
  • With <ClientRouter />, prefetch for all links is enabled by default (unless you change prefetch config). [Prefetch + view transitions]

Given that:

#
  • Each server:defer island becomes its own endpoint. Having more islands means more separate requests, but also better parallelization and more granular caching of dynamic bits. [Server islands guide]
  • A single “big” server island (or a single on‑demand page) means fewer requests but a larger piece of HTML and less granular caching.

The docs do not state performance thresholds or recommend “5 islands vs 1”, nor do they say that view transitions change this trade‑off.

So you can choose based on your needs:

  • If your static shell can be highly cached and the dynamic parts are independent (avatar, offers, reviews, etc.), multiple server:defer islands is aligned with the documented benefits (parallel loads, better cacheability). [Server islands concept]
  • If your dynamic content is tightly coupled and always needed together, one bigger island or an on-demand page may be simpler.

The knowledge sources do not provide more specific guidance than this on the optimal number of server-deferred routes or layouts with server:defer when view transitions are enabled.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@zenith panther Kapa.ai is still learning and improving, please let me know how I did by reacting below.

brave cryptBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

You do not need a unique hash in the HTML filename to cache a page aggressively, but you do need a good cache strategy that lets you update content when needed.

From the docs:

Examples where you explicitly control cache headers:

---
// On-demand / server-rendered page
export const prerender = false;
Astro.response.headers.set('Cache-Control', 'public, max-age=3600');
---
<html>...</html>

[On-demand Response]

# 
---
// Netlify example: override adapter default behavior
Astro.response.headers.set(
  'CDN-Cache-Control',
  'public, max-age=45, must-revalidate'
);
---

[Netlify caching pages]

So:

  • Yes, if you want your layout/page HTML to be cached aggressively, you do that via HTTP cache headers, not via hashed HTML filenames (those are only documented for assets).
  • No, the rendered HTML does not need a unique hash like assets do; instead, you rely on:
    • Cache headers with reasonable max-age,
    • Revalidation mechanisms (ETag, Last-Modified) when supported by your host, or
    • Host-specific modes like Vercel ISR / Netlify fine‑grained caching if you opt in. [Vercel ISR; Netlify caching pages]

The docs do not describe any automatic hashing of HTML output for cache-busting, only for built assets.

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:

#

@zenith panther Kapa.ai is still learning and improving, please let me know how I did by reacting below.

zenith panther
#

but if the layout changes should'nt the cached html be updated ?

#

@brave crypt but if the layout changes should'nt the cached html be updated ?

brave cryptBOT
#

Let me check the knowledge base for you again. One moment! :books:

#

For a prerendered (static) page, you don’t need to worry: when you change the layout and run a new build, Astro regenerates the HTML file(s). Your host will then serve the new HTML as the latest version; any stale cached copies are usually handled by your hosting platform’s deployment/caching logic (e.g. invalidation, new deployment ID, etc.). The docs don’t describe HTML hashing; they describe hashed assets and platform‑level caching. [Starlight caching]

Where you do control things directly is on-demand / server-rendered pages:

  • You can set HTTP cache headers on the page with Astro.response.headers (e.g. Cache-Control, CDN-Cache-Control) to tune how aggressively HTML is cached and revalidated. [Response headers; Netlify caching pages]
  • Some adapters add their own cache layers you can configure:
    • Netlify: cacheOnDemandPages and per-page headers like CDN-Cache-Control. [Netlify caching pages]
    • Vercel: ISR (isr option) caches on-demand pages and lets you set expiration or exclusions. [Vercel ISR]

So, practically:

#
  • Yes, when your layout changes and you redeploy, the generated HTML is updated.
  • Whether old HTML is still served depends on your hosting/cache configuration (headers, ISR/Netlify cache, CDN invalidation), not on an HTML filename hash—the docs only describe hashed filenames for assets, not for HTML. [Starlight caching]

Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: