Astro Islands vs Server Components: What to Choose for Your Site

The Astro Islands vs Server Components comparison comes down to one question: where exactly does the JavaScript live in your architecture, and who decides when it loads. If your site is mostly content - a marketing landing page, a blog, a service catalog - Astro Islands give you a smaller page weight and faster TTI, because JS is never sent to the browser unless you explicitly add a client:* directive. Next.js Server Components win when the site is already tied to the React ecosystem and part of it is an interactive application, not a showcase.

In headless migration projects, we consistently see the same confusion: teams pick between Astro and Next.js by framework name rather than by rendering model. The performance difference almost always comes down not to the framework itself, but to how it hydrates components - the entire client runtime at once, or piece by piece on demand.

Below is a breakdown of Islands and Server Components architecture at the level of what actually happens to JavaScript bytes between server and browser, concrete scenarios where Server Islands (Astro 4.x+) beat RSC’s selective hydration and vice versa, and page weight and TTI numbers for a typical marketing site.

The pain usually shows up during an audit: PageSpeed reports LCP right at the edge of “good,” while the Coverage tab in DevTools shows 300+ KB of unused JavaScript on a landing page without a single form. For a marketing site, where most traffic is a one-time visit from an ad, every extra kilobyte of JS increases TTI and directly hits conversion on mobile networks.

How Astro Islands render a page

Astro renders the entire page as static HTML at build time or on the server, and by default ships zero lines of JavaScript to the browser.

Islands architecture: an approach where the page stays static HTML while interactive components hydrate independently of each other, like separate “islands” in a static “ocean” of markup.

Each component only gets JS if you explicitly ask for it via a directive: client:load (immediately on load), client:idle (once the browser is free), client:visible (when the island enters the viewport), or client:media (on a media query, for example only on mobile). If a page has 12 components and two of them are interactive - a price calculator and a subscription form - the JS bundle only gets built for those two islands. The other ten stay pure HTML with zero bytes of runtime and no risk of a hydration mismatch.

---
import PricingCalculator from '../components/PricingCalculator.jsx';
---

<PricingCalculator client:visible />

Server Islands are a separate technique Astro has been developing since version 4.x. A Server Island defers rendering of a specific section of the page and loads it in a separate request after the static part of the page has already been delivered to the browser, without blocking the first paint. While the Server Island waits for the server’s response, a predefined fallback is shown in its place - a skeleton or placeholder that gets swapped for the real content without a page reload. For details on the mechanics, see the Astro documentation on Server Islands.

How Next.js Server Components render a page

By default, Next.js treats every component as a server component unless you explicitly mark it with the ‘use client’ directive.

React Server Components (RSC): components that render exclusively on the server, whose code never makes it into the client bundle, connected to interactive parts of the page through an explicit ‘use client’ boundary.

The ‘use client’ directive doesn’t mark the component itself as a client component - it marks an entry point: the entire tree below that boundary hydrates in the browser, unless a Server Component is passed further down as a children prop. For details, see the official documentation for the use client directive.

'use client';

export default function PricingCalculator() {
  // useState, event handlers, window access
  return <div>...</div>;
}

An important detail that often gets missed when choosing a stack: the fact that some components are server components doesn’t make the page zero-JS. As soon as a page has at least one client component, the browser gets the React runtime and the hydration logic for the entire tree below the ‘use client’ boundary - Next.js still starts from the philosophy of full-page hydration, and selective hydration (React 18’s concurrent features) works on top of it as an optimization, not as the default architecture, unlike Astro, where zero JS is the starting point.

Server Islands vs RSC selective hydration: where each architecture wins

Both approaches solve the same problem - keeping a slow or personalized fragment from blocking the entire page - but they split the responsibility between server and client differently.

Server Islands win where an otherwise fully static page has one personalized or dynamic piece: a price adjusted for the user’s currency, a view counter, a “recommended for you” block based on a cookie. The Server Island renders exactly that fragment on every request, while the rest of the page stays static HTML cached on a CDN. For the same scenario, Next.js is usually forced to switch the entire page or route segment to dynamic rendering - Partial Prerendering (PPR) solves this problem more surgically, but as of mid-2026 it remains an experimental feature and requires an explicit flag to enable.

RSC selective hydration wins when the site isn’t a set of independent widgets but a connected application: an account dashboard, a multi-step form with shared state, a dashboard with filters that affect each other. Here, React’s model of a shared component tree, context, and hooks saves architectural complexity - you don’t have to artificially cut the interface into isolated islands with separate state and figure out how to keep them in sync.

Practical rule: if there are one or two dynamic sections on a page and they aren’t tied to each other by state, go with Server Islands. If there are many dynamic sections forming a single interface, RSC selective hydration works better, because it doesn’t require manual orchestration between isolated islands.

The difference also shows up in CDN caching. The static part of a page with a Server Island caches on the edge like a regular static file, while the server call for the island itself runs separately and doesn’t invalidate the cache for the whole page. With Partial Prerendering in Next.js, the boundary between static and dynamic is defined at the route segment level rather than the individual component, so cache configuration needs more attention early in the project, especially when several independent dynamic blocks sit on the same page.

Astro Islands vs Server Components: page weight and TTI on a marketing site

The difference in hydration architecture translates directly into kilobytes of JavaScript and seconds of TTI - for ad traffic on mobile networks, that’s not an abstraction, it’s money per click spent on a page that isn’t interactive yet.

These numbers are benchmarks for typical projects, not a guarantee: the exact figure depends on the weight of the React or Vue components inside the islands and how much data moves between server and client. The general principle doesn’t change: less JS in the main thread means fewer long tasks, which means better INP. The <200 ms INP threshold and how long tasks hurt it are covered in the article on INP optimization for Astro and Next.js.

Real case: migrating a landing page from Next.js to Astro

In a typical migration project moving a B2B landing page from Next.js (App Router, default hydration) to Astro with islands, we usually see the same pattern: the homepage’s JS bundle drops from 200-250 KB (gzip) to 25-40 KB, because out of roughly fifteen components, only two or three turn out to be interactive - the lead form, a testimonial carousel, and an FAQ accordion.

LCP on these projects typically improves from 3-3.5 seconds to 1.2-1.6 seconds on an average mobile device - not so much because of the Islands architecture itself, but because static HTML gets delivered immediately, without waiting for the entire tree to hydrate. This is a range from typical projects, not a single case with exact figures: the precise result depends on hosting, CDN, and the weight of the media on the page.

When to choose Astro Islands

• The site is mostly content: landing pages, a blog, a service catalog, documentation - pages where 80%+ of the markup is static.
• The priority is the fastest possible TTI on paid mobile traffic, where every extra second before interactivity lowers conversion.
• The interface is built from independent widgets (a form, a calculator, a carousel), not a single connected application.
• The team is choosing a headless CMS for a content-centric site - see the breakdown of options in Sanity vs Contentful vs Strapi for a B2B site.

When to choose Next.js Server Components

• The site is part of a larger React codebase: an account dashboard, a product dashboard, a shared repository with the application itself.
• The team has already invested in the React ecosystem - components, hooks, an internal design system - and isn’t ready to duplicate it on another framework.
• You need nested layouts with shared state between sections, rather than a set of isolated widgets.
• You’re planning to use Partial Prerendering or a tight integration with Vercel Edge Functions and ISR.

Which sites this decision matters most for

The choice between Astro Islands and Server Components is especially important for startups and SaaS teams building a marketing site from scratch while also thinking about a future product application. If the marketing site and the product will live in separate codebases, the site’s rendering architecture doesn’t have to match the product’s stack, and Astro often wins on this particular site. If a shared monorepo with a React-based product is planned, choosing Next.js Server Components removes some of the architectural overhead of duplicating components.

For landing pages built for paid traffic, the difference is felt fastest: the technical requirements checklist for such a page is in the article on the technical checklist for a landing page built for paid traffic.

Frequently asked questions

What’s the main difference between Astro Islands vs Server Components?

Astro Islands don’t send any JavaScript to the browser by default, unless you explicitly mark a component with a client:* directive. Next.js Server Components remove server-only code from the client bundle, but as soon as a page has at least one client component, the browser gets the React runtime and the hydration logic for the entire tree below the ‘use client’ boundary. The difference isn’t that RSC is “less advanced” - it’s that they start from different baselines: Astro starts at zero JS, Next.js optimizes on top of a full-hydration model.

Can you use Server Islands and client hydration at the same time?

Yes. A Server Island is only responsible for deferring the rendering of a specific dynamic fragment to a separate server request. Inside the island itself, you can have a regular interactive component with a client:load or client:visible directive - deferred server-side rendering and client-side hydration work at different levels and don’t conflict with each other.

Do Next.js Server Components completely eliminate client-side JavaScript from a page?

No. RSC removes from the client bundle code that only runs on the server - database calls, secrets, heavy dependencies. But the React runtime and hydration logic still load if the page has at least one component with ‘use client’, and in practice, marketing sites almost always have one - a form, a menu, an accordion.

Which architecture is better for Core Web Vitals on a marketing site?

For purely content-driven pages, Astro Islands typically deliver lower LCP and TTI thanks to a smaller JS weight and no hydration where it isn’t needed. Next.js gets closer when the page already requires a lot of client-side interactivity - the weight gap narrows, and the deciding factor becomes how carefully the ‘use client’ boundaries are drawn and whether Partial Prerendering is in use.

Can you move from Next.js Server Components to Astro Islands without rewriting the entire front end?

Components built in React, Vue, or Svelte can be moved into Astro with almost no changes - Astro supports several UI frameworks at once and simply wraps them in an island with the right hydration directive. You’ll have to rewrite the routing, the data layer, and how the page assembles into HTML, but the interactive components themselves are reusable in most cases.

What to do next

• First, count how many pages on the site actually need deep client-side interactivity, and how many are showcases with a single form.
• If the share of showcase pages is above 70-80%, Astro Islands will almost always give you a smaller weight and faster TTI without losing functionality.
• If the site is technically part of a React-based product with shared state across sections, Next.js selective hydration removes unnecessary architectural complexity.
• Don’t choose a framework by name - compare the hydration model against your specific set of pages.

If you’re choosing a stack for a new marketing site or rebuilding a slow Next.js landing page around an islands architecture, describe your current page structure to the Exceltic.dev team. We’ll work out which components should stay client-side, which ones to move into Server Islands, and estimate the scope of work, including if the site needs to be built from scratch.