Astro and Islands: The Web That Sends Less JavaScript

Actualizado: 2026-05-03

For a decade the default reflex when starting any new website has been to open Next.js, Gatsby or a Create React App SPA and start writing components. The result is familiar: a ten-page blog ends up shipping two hundred kilobytes of JavaScript to render text that could have been served as plain HTML in a tenth of the time. Astro was built against that reflex. Its premise is brutally simple: if ninety per cent of your page is static content, you should ship static HTML and reserve JavaScript only for the bits that genuinely need it.

Key takeaways

• Astro ships zero JavaScript by default; the bundle grows only with the number of interactive islands, not with application size.
• Client directives (client:load, client:visible, client:idle) give granular control over when each component hydrates.
• For blogs, documentation, marketing sites and content-led e-commerce, performance numbers are consistently better than Next.js SSG or Gatsby.
• Astro accepts components from React, Vue, Svelte, Solid and Preact in the same project, facilitating incremental migration.
• It is not the right choice for applications where interactivity is the product: SaaS dashboards, collaborative editors, apps with state shared across routes.

What islands actually change

The islands architecture rewires the mental model. In a classic SPA the entire component tree lives on the client, and the server delivers an empty shell that React hydrates once the bundle loads. In a traditional SSR framework like Next.js or Remix the server renders HTML but then hydrates the full tree. Astro breaks that contract: the server renders HTML, and hydration is opt-in per component. Each interactive component is an autonomous island that hydrates on its own, with its own runtime, without dragging the rest of the page.

The practical consequence: the JavaScript bundle stops being a function of application size and becomes a function of how many islands exist. A blog with a static header, static article, static footer and a single React search box ships only the React runtime plus the search code. No article hydration, no footer reconciliation, no live component tree waiting for events. It is HTML, and that is that.

Client directives: controlling hydration

Where Astro gets genuinely clever is in controlling when each island hydrates:

• client:load: hydrates as soon as the page finishes loading. For critical elements like a cart or language selector.
• client:idle: defers hydration until the browser has spare cycles. Ideal for secondary widgets.
• client:visible: waits for the component to enter the viewport before loading JavaScript. A below-the-fold carousel is free until someone scrolls.
• client:media: ties hydration to a media query. A mobile menu that only hydrates on mobile.
• client:only: skips server rendering entirely. For components depending on browser-only APIs.

This granular control lets a site carry dozens of potentially interactive components yet only load three or four during the user’s first interaction.

Content Collections and the content model

Starting with Astro 2.0, the framework ships content collections with Zod-validated schemas. You declare a collection in content/config.ts, define the frontmatter schema, and the rest of the project gets strict typing on every post:

// content/config.ts
import { defineCollection, z } from 'astro:content';

const blog = defineCollection({
  type: 'content',
  schema: z.object({
    title: z.string(),
    date: z.date(),
    tags: z.array(z.string()),
  })
});

export const collections = { blog };

If a file’s frontmatter violates the schema, the build fails with a clear message. getCollection('blog') returns typed posts. Compared to Next.js getStaticProps or Gatsby’s gatsby-node.js, this is refreshingly direct.

Measured performance: where it wins and by how much

On a mid-sized blog the numbers are consistent. The JavaScript bundle drops from 100–200 KB (Next.js SSG, Gatsby) down to 2–10 KB. Time To Interactive falls from 1.5 seconds to around 300 ms. Largest Contentful Paint shrinks from over a second to half a second. Lighthouse hits 100 on performance effortlessly. These numbers are what you get when the page literally has no JavaScript to execute.

Honesty demands a caveat: those figures apply to sites where content dominates. A dashboard with charts, filters, reactive tables and state shared across views gains nothing from moving to Astro.

When to pick it and when not to

Astro shines on:

• Blogs, documentation, marketing sites, portfolios.
• Product landing pages and content-led e-commerce.
• Any case where interactivity is limited to search boxes, carts and simple filters.

It clearly loses on:

• SaaS dashboards with complex state.
• Real-time collaborative tools.
• Apps with SPA-like navigation and state shared across routes.
• Real-time chat clients.

The islands architecture assumes islands are few and relatively independent. When every page is a giant island with shared state, the model breaks. For those cases, HTMX can be an interesting middle ground if the team is small and the backend is expressive.

Deployment and portability

Astro compiles to static output by default, hostable on any CDN: Netlify, Vercel, Cloudflare Pages, GitHub Pages, an S3 bucket behind CloudFront. With the right adapter it emits SSR for Node, Deno, Cloudflare Workers or Vercel. Hybrid mode allows mixing static and SSR routes in the same project.

Astro 3.0 added native View Transitions, giving SPA-like transitions between pages using the browser API with no extra JavaScript cost.

Conclusion

The web framework conversation has been dominated for years by the wrong question: which React framework should I use? Astro reframes it: how much React do you actually need? For most of the content-heavy sites that populate the web, the honest answer is “very little, and only in specific places”. Astro turns that observation into default architecture, and the result is sites that are faster, cheaper to maintain and easier to serve. It is not a silver bullet — its author, Fred K. Schott, has been explicit that Astro is not trying to replace Next.js for applications. For everything else, which is most of the web, it offers a more sensible path than pushing React into every corner.