What is Island Architecture?

What is Island Architecture?

Island Architecture is a web rendering pattern where a server-rendered HTML page contains isolated "islands" of interactivity that hydrate independently, while the rest of the page stays as zero-JavaScript static HTML. The term was coined by Etsy frontend architect Katie Sylor-Miller in 2019 and popularized by Preact creator Jason Miller's 2020 blog post. Astro, first released in June 2021, became the first major framework to build island architecture into its core.

The key insight: most of a typical web page — headers, footers, body text, images — doesn't need JavaScript at all. Only specific components like carousels, search bars, or interactive forms require client-side hydration. By scoping hydration to those islands, you ship dramatically less JavaScript.

Pages built with island architecture routinely score 95-100 on Lighthouse performance. The browser only parses and executes JS for the parts that actually need it. We use this pattern on content-heavy marketing sites and blogs where Time to Interactive matters for SEO.

How it works

In a traditional SPA or even a server-rendered React app, the entire component tree hydrates on the client. Every component gets re-attached to the DOM with event listeners, even if it never changes after first render. Island Architecture flips that default.

Here's the mental model:

1. Server renders the full HTML page. Every component outputs static markup.
2. Islands are marked for hydration. Only components that need interactivity get a hydration directive.
3. Each island hydrates independently. There's no shared component tree. One island can be React, another Svelte — they don't know about each other.
4. Static regions ship zero JS. The navigation, content blocks, and footer just stay as HTML.

In Astro, this looks like:

---
import Header from '../components/Header.astro';
import SearchBar from '../components/SearchBar.tsx';
import ArticleBody from '../components/ArticleBody.astro';
import Newsletter from '../components/Newsletter.svelte';
---
<Header />  <!-- Static, no JS -->
<SearchBar client:load />  <!-- Hydrates immediately -->
<ArticleBody />  <!-- Static, no JS -->
<Newsletter client:visible />  <!-- Hydrates when scrolled into view -->

The client:load, client:visible, and client:idle directives tell Astro when to hydrate each island. This is partial hydration with explicit opt-in. Static parts never touch a JS runtime on the client. The result: pages that feel like static HTML but have interactive pockets exactly where you need them.

When to use it

Island Architecture shines in specific scenarios. It's not a universal answer.

Use it when:

• You're building content-first sites: blogs, marketing pages, documentation, e-commerce product listings
• SEO and Core Web Vitals are priorities — less JS means better LCP and INP scores
• Your page is mostly static with a few interactive widgets scattered around
• You want to mix frameworks — say, a React widget alongside a Svelte form — without bundling both into a monolith
• Your team maintains a design system with components in different frameworks

Don't use it when:

• You're building a highly interactive app (dashboards, collaborative editors, real-time tools) where most of the page is stateful
• You need deep shared state between many components — islands are isolated by design, so cross-island state management adds friction
• You're already committed to a full-stack React framework like Next.js and your pages are predominantly interactive

We've shipped this on 50+ projects. Our rule of thumb: if more than 60% of the page is interactive, a traditional SSR/SPA is probably simpler.

Island Architecture vs alternatives

React Server Components (RSC), introduced in Next.js 13 and now stable in Next.js 15, solve a similar problem — reducing client JS — but they're React-only and operate within a single component tree. Island Architecture is framework-agnostic by design. You can mix React, Svelte, Vue, Solid, and Lit islands on the same page. That flexibility is why we prefer Astro with islands for content sites.

Real-world example

We built a SaaS company's marketing site using Astro 4.x with island architecture. The site had 47 pages: landing pages, a blog with 200+ articles, pricing, and docs. Interactive components included a pricing calculator (React), a live demo widget (Svelte), and newsletter signup forms (Preact).

The result: median page weight dropped from 380 KB of JS (their previous Next.js site) to 22 KB. Lighthouse Performance scores went from the low 70s to a consistent 98-100. LCP improved from 2.8s to 1.1s on mobile. INP stayed under 100ms across all pages.

The blog pages shipped literally zero JavaScript — they were pure static HTML and CSS. The pricing page, which had the heaviest island (the calculator), still only shipped 34 KB of JS. Build times for all 247 pages: about 12 seconds.