Islands Architecture

A rendering pattern where a page is mostly static server-rendered HTML with small, independent interactive regions (“islands”) that hydrate individually on the client. The static sea between the islands ships no JavaScript at all; only the islands carry the code needed to make them interactive, and each boots on its own rather than as part of one page-wide application.

How it works

The two moves that define the pattern:

• Partial (selective) hydration — instead of re-rendering and hydrating the whole page on the client (attaching handlers to a full framework tree), only the marked components hydrate. Everything else stays inert HTML.
• Independent islands — each interactive region is its own isolated unit with its own hydration boundary, so a heavy widget in one corner never blocks or bundles with the rest.

In astro this is explicit through client directives that decide when (or whether) an island hydrates — load eagerly, when the browser is idle, when it scrolls into view, at a media breakpoint, or never (render to HTML only). That per-component control is what lets Astro keep a zero-JavaScript default while still dropping in React/Vue/Svelte components where genuine interactivity is needed. astro-server-islands extends the same idea to the server: server:defer renders a static shell immediately and fills dynamic fragments on demand, so personalization doesn’t force the whole page back to request-time rendering.

Why it matters here

Islands are the mechanism behind astro‘s strong core-web-vitals numbers: less shipped and booted JavaScript means faster interactivity and less main-thread work. The pattern sits between two contrasts:

• vs. SPA meta-frameworks (e.g. Next.js): those hydrate the entire page as one app — the all-or-nothing model islands react against.
• vs. eleventy: Eleventy emits plain HTML and leaves interactivity entirely to the author (classic progressive enhancement); islands are a structured, framework-managed way to reach a similar “mostly static, JS only where needed” outcome.

It is one layer of the static-site-publishing umbrella’s runtime-experience bet, and a recurring data point in the synthesis argument that architecture, not payload size alone, drives real-world performance.

Related

astro · astro-server-islands · eleventy · static-site-generator · jamstack · core-web-vitals · static-site-publishing · synthesis