Astro y las islas: la web que envía menos JavaScript
Actualizado: 2026-07-07
Durante una década, el reflejo por defecto al arrancar cualquier sitio web nuevo ha sido abrir Next.js, Gatsby o una SPA con Create React App y empezar a escribir componentes. El resultado es conocido: un blog de diez páginas termina enviando doscientos kilobytes de JavaScript al cliente para renderizar un texto que podría haberse servido como HTML plano en un décimo del tiempo. Astro nace precisamente contra ese reflejo. Su premisa es brutalmente simple: si el noventa por ciento de tu página es contenido estático, deberías enviar HTML estático y reservar el JavaScript solo para los trozos que de verdad lo necesitan.
Puntos clave
-
Astro envía cero JavaScript por defecto; el bundle crece solo con el número de islas interactivas, no con el tamaño de la aplicación.
-
Las directivas de cliente (
client:load,client:visible,client:idle) dan control granular sobre cuándo se hidrata cada componente. -
Para blogs, documentación, marketing sites y e-commerce centrado en contenido, los números de rendimiento son consistentemente mejores que Next.js SSG o Gatsby.
-
Astro acepta componentes de React, Vue, Svelte, Solid y Preact en el mismo proyecto, lo que facilita la migración incremental.
-
No es la elección correcta para aplicaciones donde la interactividad es el producto: paneles SaaS, editores colaborativos, apps con estado compartido entre rutas.
Qué cambia con las islas
La arquitectura de islas reordena el modelo mental. En una SPA clásica todo el árbol de componentes vive en el cliente, y el servidor entrega un shell vacío que React hidrata tras cargar el bundle. En un framework SSR tradicional como Next.js o Remix el servidor renderiza el HTML, pero luego hidrata el árbol completo para que cualquier componente pueda volverse interactivo. Astro rompe ese contrato: el servidor renderiza HTML, y la hidratación es opt-in por componente. Cada componente interactivo es una isla autónoma que se hidrata sola, con su propio runtime, sin arrastrar al resto de la página.
La consecuencia práctica: el bundle de JavaScript deja de ser función del tamaño de la aplicación y pasa a ser función del número de islas. Un blog con cabecera estática, artículo estático, footer estático y un único buscador React acaba enviando solo el runtime de React más el código del buscador. No hay hidratación del artículo, no hay reconciliación del footer, no hay árbol de componentes vivo esperando eventos. Es HTML, y ya está.
Directivas de cliente: control sobre la hidratación
Donde Astro se vuelve especialmente fino es en el control de cuándo se hidrata cada isla, tal y como detalla la documentación oficial de islands[1]:
-
client:load: hidrata en cuanto la página termina de cargar. Para elementos críticos como carrito o selector de idioma. -
client:idle: difiere la hidratación hasta que el navegador tiene ciclos libres. Ideal para widgets secundarios. -
client:visible: espera a que el componente entre en viewport antes de cargar su JavaScript. Un carrusel below-the-fold es gratis hasta que alguien hace scroll. -
client:media: condiciona la hidratación a una media query. Un menú móvil que solo se hidrata en móvil. -
client:only: salta el renderizado del servidor por completo. Para componentes que dependen de APIs exclusivas del navegador.
Este control granular permite que un sitio tenga decenas de componentes potencialmente interactivos pero solo cargue tres o cuatro en la primera interacción.
Content Collections y el modelo de contenido
A partir de Astro 2.0, el framework incorpora content collections con esquemas validados por Zod. Declaras una colección en content/config.ts, defines el schema del frontmatter, y el resto del proyecto obtiene tipado estricto sobre cada 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 };Si el frontmatter de un archivo incumple el schema, el build falla con un mensaje claro. getCollection('blog') devuelve posts tipados. Astro lo presentó como el primer framework grande en ofrecer seguridad de tipos completa para Markdown y MDX (nota de la versión 2.0[2]). Comparado con el sistema de getStaticProps de Next.js, cuyas lecciones de migración cubrimos aparte, o el gatsby-node.js de Gatsby, esto es refrescantemente directo.
Rendimiento medido: dónde gana y cuánto
Astro mismo lo resume así: una web hecha con Astro puede cargar un 40% más rápido y con un 90% menos de JavaScript que el framework de React más popular (documentación «why Astro»[3]). En comparativas independientes la diferencia se nota igual de claro: un blog típico en Gatsby arrastra 200 KB o más de runtime de React en cada página, frente a los 5 KB que necesita Astro para hidratar solo el componente interactivo, una diferencia de unas 40 veces (comparativa Astro vs Gatsby de Strapi[4]); en un caso de migración de un sitio de 40 páginas, el tiempo de build bajó de 2 minutos 45 segundos a menos de 50 segundos. Frente a Next.js SSG la brecha es algo menor pero sigue siendo notable, con un mínimo habitual de 80-180 KB de JavaScript por página. Estos números no son casualidad: son lo que sale cuando la página literalmente no tiene JavaScript de framework que ejecutar.
La honestidad exige matizar: esas cifras son para sitios donde el contenido domina. Un dashboard con gráficos, filtros, tablas reactivas y estado compartido entre vistas no gana nada moviéndose a Astro; si acaso complica la arquitectura.
Cuándo elegirlo y cuándo no
Astro brilla en:
-
Blogs, documentación, marketing sites, portfolios.
-
Landing pages de producto y e-commerce centrado en contenido.
-
Cualquier caso donde la interactividad se limite a buscadores, carritos y filtros simples.
Pierde claramente en:
-
Paneles SaaS con estado complejo.
-
Herramientas colaborativas en tiempo real.
-
Apps con navegación tipo SPA y estado compartido entre rutas.
-
Clientes de chat en tiempo real.
La arquitectura de islas asume que las islas son pocas y relativamente independientes. Cuando cada página es una isla gigante con estado compartido, el modelo se rompe. Para esos casos, HTMX puede ser un punto intermedio interesante si el equipo es pequeño y el backend es expresivo.
Despliegue y portabilidad
Astro compila a output estático por defecto, hosteable en cualquier CDN: Netlify, Vercel, Cloudflare Pages, GitHub Pages, un bucket S3 detrás de CloudFront. Con el adapter correcto puede emitir SSR para Node, Deno, Cloudflare Workers o Vercel. El modo híbrido permite mezclar rutas estáticas y SSR en el mismo proyecto.
Astro 3.0 añadió View Transitions nativas, que dan transiciones tipo SPA entre páginas usando la API del navegador con solo dos líneas de código (nota de la versión 3.0[5]). La sensación es de aplicación fluida sobre una base estática, algo que Astro 5 lleva más lejos al difuminar la frontera entre contenido y aplicación.
Conclusión
La conversación sobre frameworks web lleva años dominada por la pregunta equivocada: ¿qué framework de React usar? Astro la reformula: ¿cuánto React necesitas realmente? Para la mayoría de los sitios con mucho contenido que pueblan la web, la respuesta honesta es que hace falta muy poco, y solo en partes muy concretas. Astro convierte esa observación en arquitectura por defecto, y el resultado son sitios más rápidos, más baratos de mantener y más fáciles de servir. No es una bala de plata: su creador, Fred K. Schott, lo describe como un framework centrado en sitios de contenido, no como un aspirante a sustituir a Next.js en aplicaciones completas (entrevista en Whiskey Web and Whatnot[6]). Para todo lo demás, que es la mayor parte de la web, ofrece un camino más sensato que llevar React a cada esquina.
¿Lees en inglés? Versión completa: Astro and Islands: The Web That Sends Less JavaScript.
