Astro y las islas: la web que envía menos JavaScript

javi
Islas tropicales desde vista aérea sobre océano turquesa representando arquitectura de islas

Astro propone filosofía diferente a React-everywhere: HTML-first con islas de interactividad. El 90% de tu sitio es HTML estático; solo los componentes interactivos mandan JavaScript al cliente. El resultado: sitios content-heavy con performance drásticamente mejor que SPAs completos. Ideal para blogs, docs, marketing sites, e-commerce content-led. Este artículo cubre cuándo Astro gana y cuándo no.

El concepto de islas

Tradicionalmente:

  • SPA (React, Vue): todo client-side, bundle grande.
  • SSR (Next.js, Remix): server renders + hydration de todo.
  • SSG estático: HTML puro, no interactividad.

Islas (Astro, Fresh):

  • HTML renderizado estático.
  • Componentes interactivos específicos “hidratan” independientemente.
  • Resto del DOM es HTML plano sin JS.

Bundle sent solo para las islas — frecuentemente 10-50x menos JS.

Ejemplo simple

// Header.astro (0 JS shipped)
<header>
  <h1>Mi sitio</h1>
  <nav>
    <a href="/">Home</a>
    <a href="/blog">Blog</a>
  </nav>
</header>
// Page.astro
import Header from './Header.astro';
import ReactCounter from './Counter.jsx';
<html>
  <body>
    <Header />
    <!-- Isla interactiva React -->
    <ReactCounter client:load />
    <!-- Static content -->
    <article>
      <h2>Artículo</h2>
      <p>Solo HTML, cero JS...</p>
    </article>
  </body>
</html>

El cliente descarga JS solo para ReactCounter. El resto es HTML puro.

Client directives

Control fino sobre cuándo cargar islas:

  • client:load: cargar inmediatamente.
  • client:idle: cargar cuando browser está idle.
  • client:visible: cargar cuando entra viewport (lazy).
  • client:media: cargar según media query (e.g., mobile only).
  • client:only: solo client-render, skip SSR.

client:visible es muy útil para below-the-fold content interactivo.

Multi-framework

Astro soporta componentes de múltiples frameworks en el mismo proyecto:

  • React.
  • Vue.
  • Svelte.
  • Solid.
  • Preact.
  • Lit.
  • Alpine.

Puedes tener <ReactChart /> y <SvelteForm /> en la misma página. Útil para migración gradual o equipos con stacks mixtos.

Content collections

Astro 2.0+ introdujo content collections — sistema para organizar markdown/MDX con type safety:

// 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 };
import { getCollection } from 'astro:content';
const posts = await getCollection('blog');

Type-checked frontmatter, tooling excelente.

Performance medido

Comparison real en blog site:

Metric Astro Next.js SSG Gatsby
JS bundle 2-10KB 100-200KB 100-200KB
TTI 0.3s 1.5s 1.8s
LCP 0.5s 1.2s 1.4s
Lighthouse perf 100 85-95 85-95

Para sites content-heavy, Astro domina performance.

Cuándo Astro gana

  • Blogs, docs, marketing sites: content es 90% del site.
  • E-commerce content-led: landing pages, product descriptions.
  • Portfolios y showcases.
  • Landing pages de apps (app real está en otro subdomain).
  • Performance-critical: Lighthouse 100 scores.

Cuándo Next.js/Remix ganan

  • Apps con mucha interactividad: dashboards, SaaS UIs.
  • State management complejo: multiple views sharing state.
  • SPA-like navigation: si quieres transiciones smooth.
  • Real-time: WebSockets, streaming.

Deployment

Astro compila a:

  • Static output: hosteable en Netlify, Vercel, Cloudflare Pages, GitHub Pages, cualquier CDN.
  • SSR output: con adapter para Node, Deno, Cloudflare Workers, Vercel, Netlify.
  • Hybrid: algunas páginas static, otras SSR.

Muy portable — no Vercel lock-in.

View Transitions

Astro 3.0 añadió View Transitions API nativo:

  • SPA-like transitions entre páginas.
  • Zero JavaScript overhead.
  • Usa browser native API (con fallback).

Combina ventajas static (performance) con UX tipo SPA.

Ecosystem

  • Starlight: framework docs sobre Astro.
  • Accessible Astro: templates con a11y.
  • Astro DB: database layer integrada.
  • Hundreds of integrations: Sentry, Analytics, CMS, etc.

Community pequeña pero muy activa.

Casos reales

  • Docusaurus alternatives en Starlight.
  • Bloggers tech: muchos migrating de Gatsby/Hugo.
  • Empresa marketing sites: Cloudflare docs, por ejemplo.
  • Astro showcase con casos.

Migración desde Gatsby/Hugo

Desde Gatsby:

  • Similar model (static + React).
  • Content transformation similar.
  • Performance gain meaningful.

Desde Hugo:

  • Ambos static-first.
  • Astro añade componentes reactivos.
  • Content collections parecidos a Hugo content types.

Migración de site mediano: días, no semanas.

Integraciones populares

  • CMS headless: Contentful, Sanity, Strapi, Storyblok.
  • Markdown con componentes: MDX, Markdoc.
  • Image optimization: built-in Astro Image.
  • Analytics: Plausible, Umami, GA.
  • Auth: Clerk, Auth.js.
  • Sitemap + RSS: integrations oficiales.

Limitaciones

Honestly:

  • No SPA: si quieres full SPA app, Astro no encaja.
  • SSR overhead: si ruta es SSR, performance similar a otros.
  • Ecosystem menor: less tutorials, plugins que Next.js.
  • Learning curve: paradigma islands diferente si vienes de pure React.

Conclusión

Astro es la opción correcta para sites content-heavy donde JavaScript debería ser aditivo, no fundamental. Su approach islands entrega performance que SPAs no pueden igualar. Para blogs, docs, marketing sites, e-commerce content-led, es probablemente la mejor opción moderna. Para apps interactivas complejas, Next.js/Remix siguen siendo mejores. La elección es clara según caso de uso. Para equipos con mix de tipos de site (app + marketing), Astro puede ser excelente para la parte content sin cambiar la app principal.

Síguenos en jacar.es para más sobre Astro, performance web y frameworks modernos.

Entradas relacionadas