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.

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.

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.

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.