Next.js vs Astro: ¿cuánto de tu página es interactivo?

La forma honesta de plantear esta comparación es una sola pregunta: ¿qué proporción de tu página necesita hacer algo después de cargar?

Contesta a eso y la comparación se resuelve prácticamente sola.

El punto de partida de cada uno

Astro renderiza a HTML y no envía JavaScript. La interactividad se activa componente a componente - una isla - y todo lo que queda fuera de ellas es marcado estático. Una página con un buscador envía el buscador.

Next.js renderiza a HTML y envía un runtime de React. Los Server Components permiten mantener componentes fuera del cliente, así que el bundle puede ser pequeño, pero la línea base no es cero y la disciplina es tuya. Dónde está la frontera del cliente es toda la diferencia entre una página Next.js ligera y una pesada.

Es decir: Astro empieza en cero y tú añades. Next.js empieza con un runtime y tú restas. En una página mayoritariamente estática, empezar en cero gana, y no por poco.

La diferencia es medible, no retórica. Esta web no envía JavaScript propio en ninguna ruta y aun así arrastra unos 186 KB comprimidos de runtime del framework en la primera visita. Eso está cerca del suelo para un framework de React, y es un suelo que una página de Astro sin islas sencillamente no tiene. Que eso importe depende por completo de quién te visita: en una conexión rápida desaparece, y en un Android de gama media en un mercado al que intentas entrar es una parte visible del tiempo hasta la interactividad.

Cuánto control te da cada uno sobre la hidratación

Aquí es donde los dos modelos se diferencian en la práctica y no en el principio.

Las islas de Astro se declaran con una directiva que dice cuándo hidratar: de inmediato, cuando el navegador esté ocioso, o cuando el componente entre en pantalla. Lo último es lo interesante: un componente por debajo del pliegue no cuesta nada hasta que alguien llega a él, y expresarlo es un solo atributo.

Next.js no tiene un interruptor equivalente por componente. Un componente de cliente hidrata como parte del árbol al que pertenece. Controlas qué se envía, que es la palanca más potente, pero no consigues «envía esto y arráncalo más tarde» sin recurrir a importaciones dinámicas y escribir tú el comportamiento de carga.

Ninguno de los dos modelos es mejor en abstracto. El de Astro es más fino para una página hecha de contenido casi estático con unas pocas partes vivas. El de Next.js es mejor cuando las partes interactivas son la página.

Dónde Astro es la mejor respuesta

• Documentación, blogs, webs de marketing. Contenido con unas pocas partes interactivas. Las content collections de Astro manejan frontmatter, contenido tipado y markdown de forma nativa, que si no es un montoncito de pegamento.
• Donde el presupuesto de JavaScript es la restricción. Redes lentas, dispositivos baratos, mercados grandes donde el móvil mediano no es reciente.
• Sitios con componentes de más de un framework. Astro es genuinamente agnóstico. Un widget de React y otro de Svelte en la misma página es algo normal, no una hazaña.

El punto de las content collections merece desarrollo, porque es lo que más tiempo ahorra en un sitio de contenido. Frontmatter tipado, validado en el build, con el fallo llegando como error de build en lugar de como un titular en blanco en producción: eso acaba construyéndolo todo sitio de contenido. En Next.js es una elección de librería más pegamento - la capa de contenido de esta misma web son unos cientos de líneas exactamente de eso. En Astro es el framework.

Dónde Next.js es la mejor respuesta

• Estado de cliente compartido en toda la página. Un carrito, un panel de filtros que gobierna una cuadrícula, un editor. Las islas de Astro están aisladas por diseño; hacer que se hablen significa recurrir a un store fuera del framework, y en ese punto estás construyendo lo que React ya hace.
• Superficies de aplicación autenticadas. Todo aquello donde la mayor parte de la página cambia por usuario y la estrategia de renderizado hay que decidirla por ruta y no por componente.
• Estático y dinámico mezclados en una base de código. Un catálogo que debe generarse en el build y un checkout que no. El modelo de renderizado está diseñado exactamente para esa división.

La trampa del medio

El caso que sale mal es el sitio que empieza siendo contenido y va desarrollando una aplicación dentro. Una web de documentación añade un playground. Una web de marketing añade un configurador, y luego un área de cliente.

Las islas resuelven una de esas cosas. Tres compartiendo estado es donde los equipos empiezan a escribir su propio puente, y una capa de estado hecha a mano entre islas aisladas es peor que la respuesta de cualquiera de los dos frameworks.

Si al elegir puedes ver esa trayectoria, pondérala. Si de verdad no puedes, Astro es el error más barato: es más fácil salir de un sitio estático que de una aplicación.

Esa asimetría es el corazón práctico de la decisión. Mover contenido de Astro a Next.js es sobre todo mover archivos Markdown y reescribir plantillas: el contenido en sí es portable y las URLs no tienen por qué cambiar. Sacar una aplicación de un framework es una reescritura. Cuando dos opciones están igualadas, debería ganar aquella en la que equivocarse sale más barato.

De qué no va esto

SEO. Los dos producen HTML renderizado en servidor. Ninguno tiene ventaja inherente, y lo que de verdad decide el posicionamiento - canonicals y sitemaps, datos estructurados, Core Web Vitals - es trabajo tuyo en ambos.

Velocidad. La ventaja de Astro en peso de página es real y va de JavaScript, no de renderizado. Un sitio Next.js bien construido, con una frontera de cliente disciplinada, es rápido. Uno descuidado no lo es, y tampoco lo es un sitio Astro descuidado con cinco islas innecesarias.

Si la respuesta a la pregunta inicial es «casi nada», puede que no necesites un framework de React.