Islands Architecture
Date: 2026-08-16
Ship the page as static HTML and hydrate only the bits that actually do something. It attacks the assumption underneath most framework performance problems — that a page needs to be interactive because parts of it are.
What it is
Islands architecture renders a page as static HTML on the server, then hydrates independent interactive components — the islands — separately, each with only the JavaScript it needs.
CONVENTIONAL SSR ISLANDS
┌────────────────────────┐ ┌────────────────────────┐
│ header │ │ header (static) │
│ hero │ │ hero (static) │
│ product grid │ all │ product grid (static) │
│ ▸ size selector │ hydr- │ ┌──────────────────┐ │
│ ▸ add to basket │ ated │ │ size selector │ │ ← island
│ reviews │ as │ └──────────────────┘ │
│ footer │ one │ ┌──────────────────┐ │
└────────────────────────┘ tree │ │ add to basket │ │ ← island
│ └──────────────────┘ │
600 KB, one long task │ reviews (static) │
│ footer (static) │
└────────────────────────┘
40 KB, two small tasks
The static parts never become JavaScript at all. They’re HTML, and they stay HTML.
Why it works on retail sites
The observation it rests on: most of a commerce page is content, not application. A product page is imagery, description, specification, price, reviews and breadcrumbs — all static — plus two or three genuinely interactive controls.
Conventional hydration treats all of that as one interactive tree because a few parts of it are. Islands treats the page as a document that happens to contain widgets.
The consequences follow directly:
- Less JavaScript, so less parse, compile and execute — JavaScript Execution Cost
- No single long hydration task, so interactions aren’t queued behind it — Interaction to Next Paint
- Failure is contained. A broken island leaves the rest of the page working, where a hydration error in a monolithic tree can take the whole page down
- Loading is independent. Each island can hydrate on visibility, on idle, or on interaction
Loading strategies
The real gain comes from when each island hydrates, not just that they’re separate:
load immediately — the basket button
idle when the thread is free — a newsletter signup
visible on intersection — a reviews widget below the fold
media only above a breakpoint — a desktop-only mega menu
interaction on first click/hover — a size guide modal
never never — it was never interactive
interaction is the strongest: the component’s JavaScript isn’t downloaded until someone actually engages with it, so the majority of visitors pay nothing.
What it costs
Not free, and the tradeoffs are real:
- No shared client state between islands. Two islands can’t share a store directly — you need custom events, a signals library, or URL state. A basket count in the header and an add-to-basket button in the body are two islands that need to talk, and that’s the recurring friction
- Framework support required. Astro is built around it; several others support it partially. Retrofitting onto a conventional SPA is a rewrite
- Genuinely app-like pages don’t suit it. A checkout with interdependent steps and shared validation is one application, not a document with widgets
- More things to reason about. Per-component hydration strategy is a decision surface that didn’t exist before
Where it sits
Related approaches solving the same problem differently:
| Approach | |
|---|---|
| Islands | Static page, selectively hydrated components |
| Server Components | Components that render server-side and never ship to the client; client components are the exception |
| Progressive hydration | Whole tree hydrated, but prioritised and split over time |
| Resumability | Serialise the framework’s state so the client resumes rather than re-executing — no hydration pass at all |
All four are reactions to the same finding: hydration is the dominant JavaScript cost on server-rendered sites, and most of it is spent on content that will never respond to anything. See Hydration and Rendering Strategies.
For a retail front end where most pages are documents, islands is the option with the best ratio of gain to disruption — provided cross-island state is designed for up front rather than discovered later.