Islands Architecture: Cut JavaScript by 90%

Your homepage loads 400KB of JavaScript. Most of it powers a single dropdown menu. The rest of the page is static content that doesn't need interactivity at all. This is the problem islands architecture solves.

Instead of sending one massive JavaScript bundle that hydrates your entire page, islands architecture sends only the JavaScript needed for interactive components—"islands"—while everything else remains plain HTML. The result: faster pages, better Core Web Vitals, and significantly lower bandwidth costs.

What Islands Architecture Actually Is

Islands architecture treats your page as a collection of independent, interactive regions surrounded by static content. Each island hydrates independently, loads on its own schedule, and requires no knowledge of other islands.

Think of it like this: your marketing page is mostly static text and images. Only the contact form and testimonial carousel need JavaScript. Instead of bundling React to hydrate the entire DOM, you ship two small JavaScript bundles—one for the form, one for the carousel—and serve the rest as plain HTML.

How It Works in Practice

Frameworks like Astro implement this pattern natively:

typescriptCopy
// ContactForm.astro - interactive island
---
import ContactForm from '../components/ContactForm.jsx';
---

<ContactForm client:load />

// PageContent.astro - static HTML
---
const posts = await getLatestPosts();
---

<main>
  <h1>Welcome</h1>
  <p>Static content rendered at build time</p>
  {posts.map(post => <article>{post.title}</article>)}
</main>

The

client:load

Hydration Strategies

Islands support multiple loading strategies:

• codeCopy

  client:load

  : Hydrate immediately
• codeCopy

  client:idle

  : Hydrate when the browser is idle
• codeCopy

  client:visible

  : Hydrate when scrolled into view
• codeCopy

  client:only

  : Skip static rendering entirely

Choose based on priority. Hydrate critical interactions immediately. Defer the rest.

The Performance Impact

The numbers speak loudly. A typical SPA might send 250KB of framework code plus application logic. With islands, you're sending framework code only for components that need it—often reducing total JavaScript by 70–90%.

Real-World Results

A commerce site we worked on at LavaPi reduced its main bundle from 320KB to 45KB by identifying which components actually needed interactivity:

• Product listing: Static HTML generated at build time
• Shopping cart: Small React island (~15KB)
• Product filters: Lightweight Alpine island (~8KB)
• Checkout form: Focused vanilla JavaScript (~22KB)

PageSpeed Insights scores jumped from 52 to 89 on mobile. Time to interactive dropped from 4.2s to 1.1s.

The Trade-offs

Islands aren't free. You lose:

• Shared state across islands: Each island manages its own state. Cross-island communication requires custom solutions or APIs.
• SPA smoothness: Navigation typically causes full page reloads unless you add additional complexity.
• Development ergonomics: Debugging multiple isolated systems can be trickier than one unified application.

For content-heavy sites, marketing pages, and traditional server-rendered applications, these trade-offs are worth it. For highly interactive dashboards or collaborative tools, islands may add unnecessary friction.

When to Use Islands Architecture

Islands fit best when:

• Most of your page is static or server-rendered content
• You have isolated pockets of interactivity
• You care deeply about performance metrics
• Your users span a range of devices and network speeds

Skip islands if you're building:

• Single-page applications with constant state changes
• Real-time collaborative tools
• Applications where every UI element is interactive

The Bottom Line

Islands architecture isn't a universal solution, but for the sites it fits, it delivers measurable wins. You reduce JavaScript overhead, improve time-to-interactive, and keep the developer experience reasonable. Start by auditing your page: which components actually need JavaScript? Ship interactive code only for those, and let the browser handle the rest with plain HTML.

That's where most of the wins come from.