The old choice was brutal: build a static site and cache it forever at the CDN edge (fast, but stale), or go full dynamic SSR and lose the edge cache (always fresh, but slow). Astro 5 Server Islands end that false binary. Most of a page lives static and cached; a few components opt into per-request rendering, all without remounting the page chrome or destroying browser state.
The Problem Server Islands Solve
Velocity X hosts a pricing page cached at edge for 7 days — that's the fastest possible response. But availability tiers change hourly based on current job queue depth, and you can't show stale data. Enter server: directive: mark the tier-availability component as server-rendered, and only that component re-renders per request. The hero, the copy, the CTA buttons, the layout — all cached. The availability badge alone gets fresh data. Edge cache invalidation stays surgical.
How Server Islands Work
In Astro, wrap a component with server:
{`export const server = true;
export default function PricingAvailability() {
// This runs on every request
const queueDepth = await getJobQueueDepth();
return Available: {queueDepth} spots;
}`}Astro isolates it as a separate server render. The HTML around it stays static. The component re-renders server-side per request, returns HTML, and that HTML gets swapped into the page. No client-side hydration, no JavaScript bundle for this component, no state reset on navigation.
Three Real Examples in Velocity X
1. Pricing tier availability. The page is cached at edge, but the "3 spots left" badge queries the database fresh. Users see accurate inventory without waiting for a full page re-render.
2. Lead counter widget. The home page hero is static, but the "Join 2,847 other businesses" number increments in real-time. That number comes from a server component that counts rows in the leads table on each request. The rest of the page doesn't re-render.
3. SLT dashboard widget. The marketing site footer shows an embedded dash-snippet: "Revenue last 30d: $X, conversion rate: Y%". That widget pulls from Supabase on every page load. The footer HTML stays cached; only the widget data is fresh.
Cache-Control Headers & Edge Invalidation
Server islands don't change your cache headers — Netlify Edge still caches the full HTML response. The win is surgical re-renders: expensive dynamic parts stay inside their server-side boundary; cheap static parts stay on the CDN. If you need to invalidate an entire page immediately (new pricing), you still purge the whole thing. But most days, the stale cache is doing 99% of the work.
Six FAQs
Do server islands break ViewTransitions?
No. The page structure stays the same; only the component internals change. ViewTransitions animate the layout, not the component state.
Can I use useState inside a server island?
No. Server islands are server-render-only. If you need client interactivity, you mark a component as client:lazy instead, and accept the JavaScript bundle.
What if a server island is slower than edge cache?
Then don't make it a server island. Keep it static and purge the cache when data changes. Server islands are for components that need fresh data on most requests — lead counts, real-time inventory, SLT metrics.
Can I nest a server island inside a client island?
No. The nesting works the other way: static → server → client. You can't put fresh server logic inside a hydrated React component.
What's the render time budget?
Under 500ms total page render is the target. If a server island takes 2 seconds to query the database, move the query out of the render path (pre-compute, cache it in Redis, re-think the architecture).
How many server islands can one page have?
As many as needed, but each one adds per-request latency. Velocity X pages have 1–3 server islands per page. More than that and you're not actually using the edge cache effectively.
The Bottom Line
Server Islands are Astro's answer to "I need both static speed and dynamic freshness." They let you keep 95% of a page cached globally while 5% talks to the database every request. If you're building a marketing site with real-time data (inventory, metrics, leads), this is the pattern. Beats full-page SSR because you're not re-rendering the hero and the footer on every request; beats static because your data isn't stale by Tuesday.
For a deeper dive into the architecture that makes this efficient, see our AI-Ready Website Architecture guide. And when you're ready to price the performance gains, check Velocity X pricing to see this pattern in action.