Astro o Next.js: una decisión de 30 segundos que se reduce a contenido o aplicación
Astro y Next.js no compiten de verdad por el mismo trabajo, así que la decisión suele tomar unos treinta segundos: ¿tu proyecto es principalmente contenido o principalmente una aplicación? Astro es content-first y envía cero JavaScript por defecto — un blog, sitio de documentación, sitio de marketing o portafolio construido con él puede enviar una fracción del código, marcar puntajes Lighthouse casi perfectos sin mucho esfuerzo, y quedar legible para todo crawler porque el contenido es HTML estático. Los benchmarks independientes de 2026 ponen una página de documentación de Astro en alrededor de 9 KB de JavaScript contra cerca de 463 KB de una comparable de Next.js, con builds cerca de tres veces más rápidos. Next.js es app-first: un framework full-stack de React con Server Components, server actions, rutas de API y streaming, hecho para tableros, productos SaaS y e-commerce con cuentas y estado en tiempo real — trabajos donde una base de JavaScript es una inversión que vale la pena en vez de peso muerto. Ambos son amigables con el SEO porque ambos renderizan HTML en el servidor, pero Astro tiene ventaja en los Core Web Vitals que alimentan el ranking, y en ser legible para los crawlers de IA que no corren JavaScript. El error clásico es elegir Astro por la velocidad y luego atornillarle islas React para una caja de búsqueda, un banner de cookies, un formulario de newsletter y una tabla de precios interactiva hasta que has reconstruido Next.js en silencio y perdido la ventaja por la que viniste. Así que decide según la forma del sitio, mantén las islas con moderación, y ajusta la herramienta al trabajo — que para un sitio de contenido que necesita ser rápido y encontrado es exactamente por qué este sitio corre en Astro.
No compiten por el mismo trabajo
La mayoría de los debates de Astro contra Next.js salen mal al tratarlo como un concurso por una sola corona, cuando los dos frameworks están hechos para trabajos distintos. Astro es un framework enfocado en contenido: renderiza tus páginas a HTML en el momento del build o en el servidor y envía casi nada de JavaScript. Next.js es un framework full-stack de React: asume que quieres React en todos lados y te da la lógica del lado del servidor, el enrutamiento y la maquinaria de obtención de datos para construir una aplicación completa (Cosmic, 2026). Hacen apuestas arquitectónicas opuestas, y esas apuestas convienen a tipos de proyecto opuestos.
Por eso la decisión se resuelve tan rápido una vez que haces la pregunta correcta. ¿Tu proyecto es principalmente contenido — algo que la gente en su mayoría lee — o principalmente una aplicación, algo en lo que la gente en su mayoría hace cosas? Un blog, documentación, sitio de marketing o portafolio es contenido, y el terreno propio de Astro. Un tablero, producto SaaS, o tienda con cuentas de usuario y estado en tiempo real es una aplicación, y el terreno propio de Next.js (Kunal Ganglani, 2026). Los frameworks no son rivales sino herramientas para mitades distintas de la web, y saber en cuál mitad estás es la mayor parte de la decisión.
Astro: content-first, cero JavaScript por defecto
La elección definitoria de Astro es que no envía JavaScript del lado del cliente a menos que lo pidas explícitamente. Cada página es HTML estático, y la interactividad es opcional a nivel de componente a través de su arquitectura de islas — marcas un componente con una directiva como client:load o client:visible, y solo esa pieza se hidrata mientras el resto de la página queda como HTML simple (Cosmic, 2026). Un blog de cincuenta artículos puede enviar apenas unos pocos kilobytes de JavaScript en total a menos que agregues algo interactivo.
El pago es un rendimiento que llega casi gratis. Las páginas de contenido rutinariamente marcan puntajes Lighthouse en el rango de 95-100, con Largest Contentful Paint bajo un segundo y efectivamente ningún desplazamiento de diseño, porque hay poco o nada de JavaScript que bloquee el renderizado o retrase la interacción (InstaPods, 2026). Astro además es agnóstico al framework, así que esas islas pueden ser React, Vue, Svelte o Solid — incluso mezcladas en la misma página — y sus Content Collections te dan contenido type-safe y validado por schema de fábrica (PkgPulse, 2026). Para blogs, docs, sitios de marketing y portafolios, esto es casi ideal: rápido sin pelear por ello, y flexible donde necesitas interactividad.
Next.js: app-first, full-stack React
Next.js parte de la suposición opuesta — que estás construyendo una aplicación React — y te equipa acordemente. Te da React Server Components, server actions, rutas de API, middleware, regeneración estática incremental y streaming, un kit completo para construir tanto el frontend como la lógica del backend de una app real en una base de código (Cosmic, 2026). Los React Server Components han recortado el bundle del cliente de forma significativa comparado con versiones anteriores, pero el framework aún envía una base — más o menos 45 a 70 KB de JavaScript comprimido en una carga en frío — porque necesita React en el navegador para la navegación del lado del cliente y la hidratación (Nayan Kyada, 2026).
Para una aplicación, esa base es una inversión que vale la pena, no overhead: los tableros, productos SaaS, e-commerce con cuentas, y cualquier cosa con autenticación, feeds en tiempo real o estado interactivo complejo genuinamente necesitan esa maquinaria, y Next.js es excelente proveyéndola (Kunal Ganglani, 2026). También maneja bien los sitios muy grandes en un aspecto específico: para miles de páginas, su regeneración estática incremental te deja pre-construir un subconjunto y calentar el resto bajo demanda, evitando los largos rebuilds completos que un sitio enteramente estático puede topar pasada cierta escala. Si tu proyecto tiene forma de aplicación, Next.js es la elección más fuerte, y su costo de JavaScript deja de ser un costo.
Los benchmarks, y qué significan
Los números vuelven concreta la división, siempre que los leas en contexto.
| Astro | Next.js | |
|---|---|---|
| JavaScript (página de docs) | ~9 KB | ~463 KB |
| JS base por página | Casi cero | ~45-70 KB (con RSC) |
| Lighthouse (contenido) | 95-100 de fábrica | Fuerte con optimización deliberada |
| Velocidad de build | ~3× más rápido | Base |
| Mejor ajuste | Contenido: blogs, docs, marketing | Aplicaciones: tableros, SaaS, comercio |
| Frameworks de UI | React, Vue, Svelte, Solid | Solo React |
Los benchmarks independientes de 2026 muestran un sitio de docs de Astro enviando alrededor de 9 KB de JavaScript contra cerca de 463 KB de uno comparable de Next.js, cargando de forma notablemente más rápida y construyendo cerca de tres veces más rápido (Tech Insider, 2026). En un blog real, la brecha de Lighthouse en móvil comúnmente corre de 15 a 25 puntos (InstaPods, 2026). El contexto que mantiene esto honesto: esas brechas son más grandes para páginas de contenido y se encogen para aplicaciones interactivas, donde estarías enviando JavaScript de todos modos y el overhead del framework es una porción menor del total. Los benchmarks no son un veredicto de que Astro sea “mejor” — son una medición de cuánto peso carga cada framework por defecto, lo que importa enormemente para contenido y mucho menos para apps.
Ambos están bien para SEO — pero Astro tiene ventaja
Ninguno de los dos frameworks es malo para SEO, y vale decirlo con claridad porque el mito persiste. Ambos renderizan HTML en el servidor o en el momento del build, así que ambos producen páginas rastreables, y ambos pueden soportar un fuerte desempeño de búsqueda cuando se configuran bien (Cosmic, 2026). Si construyes cualquiera de los dos correctamente, los buscadores verán tu contenido.
Donde Astro tiene una ventaja genuina es en los Core Web Vitals y la legibilidad ante la IA. Como envía mucho menos JavaScript, tiende a marcar mejor Largest Contentful Paint y puntajes de interacción sin trabajo extra, y esos son insumos directos de ranking — la preocupación en el corazón de nuestro pilar sobre Core Web Vitals. También emite HTML estático que todo crawler puede leer, incluidos los crawlers de IA detrás de ChatGPT y Perplexity que no ejecutan JavaScript, que nuestra guía sobre ser legible para la IA cubre a fondo. Next.js puede igualar esto en páginas de contenido, pero toma optimización deliberada obtener lo que Astro provee por defecto. El default más ligero también es uno más bajo en carbono, una conexión que nuestra guía sobre la huella de carbono de un sitio saca a la luz — menos JavaScript es menos energía en cada visita. Para los méritos específicos de Astro en búsqueda, nuestra guía sobre si Astro es bueno para SEO va más a fondo.
El error clásico: reconstruir Next.js sin querer
Hay un modo de falla que vale nombrar porque es muy común, y es lo más útil de toda esta comparación. Los equipos eligen Astro porque quieren rendimiento, y luego le atornillan gradualmente islas React — un widget de búsqueda aquí, un banner de cookies allá, un formulario de newsletter, una tabla de precios interactiva — hasta que han reintroducido la mayoría del JavaScript que trataban de evitar (Nayan Kyada, 2026). En ese punto tienen la complejidad de una app de JavaScript y la torpeza de un framework de contenido al que se le pide comportarse como una, habiendo reconstruido Next.js en silencio sin los beneficios de usarlo de verdad.
La disciplina que previene esto es la misma que hace rápido a Astro en primer lugar: agrega interactividad solo donde se gane su lugar. Gran parte de lo que los equipos alcanzan islas para construir — un poco de comportamiento de navegación, un formulario, una pequeña animación — a menudo puede hacerse con unas pocas líneas de JavaScript o CSS simple, sin isla de framework requerida. Cada componente que hidratas es JavaScript que estás enviando de nuevo, así que la pregunta honesta en cada uno es si esta pieza de verdad necesita ser interactiva, o si solo se siente que debería serlo. Mantener las islas con moderación es cómo un sitio Astro sigue siendo un sitio Astro. Este es el principio de “hacer menos” en la práctica: la versión rápida de casi cualquier página es la que corre menos código, y la tentación de agregar de vuelta lo que quitaste es lo que hay que resistir.
Qué te diríamos
Si estás construyendo un sitio de contenido — un blog, documentación, un sitio de marketing, un portafolio — Astro es muy probablemente la decisión correcta, y las ventajas de rendimiento, SEO, carbono y costo son reales y en su mayoría gratis. Si estás construyendo una aplicación con cuentas, datos en tiempo real o interactividad pesada, Next.js es la mejor herramienta, y su base de JavaScript es una inversión en vez de desperdicio. El error es elegir el framework por reputación en vez de por la forma de tu proyecto, o elegir Astro y luego erosionar su ventaja una isla a la vez.
Decimos esto desde la experiencia en vez de la teoría: este sitio corre en Astro, generado estáticamente, casi perfecto en Lighthouse, y deliberadamente moderado con el JavaScript del lado del cliente — porque es contenido que necesita ser rápido y encontrado, que es exactamente el trabajo de Astro. Si tu proyecto fuera una aplicación, alcanzaríamos Next.js sin dudar y te lo diríamos. El framework no es una lealtad; es un ajuste. Decide contenido o app, mantén la interactividad honesta, y elegirás bien en cualquier caso. Si estás sopesando el enfoque de fondo en vez de la herramienta específica, nuestra guía sobre qué es un generador de sitios estáticos y, para sitios de contenido que salen de WordPress, nuestra guía de migración son las lecturas siguientes naturales.
Frequently asked
- ¿Astro o Next.js — cuál debería usar?
- Hazte una pregunta: ¿tu proyecto es principalmente contenido o principalmente una aplicación? Si es un blog, documentación, sitio de marketing o portafolio — contenido que la gente en su mayoría lee — elige Astro, porque envía casi nada de JavaScript por defecto y logra un rendimiento casi perfecto sin mucho esfuerzo. Si es una aplicación web — un tablero, un producto SaaS, o algo con cuentas de usuario, datos en tiempo real o estado interactivo complejo — elige Next.js, porque sus funciones full-stack de React son lo que ese trabajo necesita. Los dos no compiten de verdad por el mismo trabajo, así que la decisión suele tomar unos treinta segundos una vez que eres honesto sobre qué tipo de sitio estás construyendo.
- ¿Astro es más rápido que Next.js?
- Para sitios de contenido, de forma medible, sí. Astro envía cero JavaScript por defecto y lo agrega solo donde optas por ello, así que una página de contenido típica puede ser una fracción del tamaño — los benchmarks independientes de 2026 muestran alrededor de 9 KB de JavaScript en un sitio de documentación de Astro frente a cerca de 463 KB en uno comparable de Next.js, con Astro cargando notablemente más rápido y construyendo cerca de tres veces más rápido. En un blog real la brecha de Lighthouse suele ser de 15 a 25 puntos en móvil. Para aplicaciones interactivas la diferencia se estrecha, porque una app necesita JavaScript de todos modos y el overhead del framework importa menos. Así que la ventaja de velocidad de Astro es real y grande para contenido, y mucho menor para apps.
- ¿Astro o Next.js es mejor para SEO?
- Ambos son amigables con el SEO, porque ambos pueden renderizar tu contenido a HTML en el servidor o en el momento del build, que es lo que los buscadores y los crawlers de IA necesitan. Astro tiene ventaja en los Core Web Vitals que alimentan el ranking — Largest Contentful Paint y las métricas de interacción — porque envía mucho menos JavaScript por defecto, así que tiende a marcar buenos puntajes sin optimización extra. También emite HTML estático que los crawlers, incluidos los de IA que no corren JavaScript, siempre pueden leer. Next.js puede rankear bien también, por supuesto, pero en páginas de contenido toma más optimización deliberada igualar lo que Astro te da gratis.
- ¿Puedo usar componentes React en Astro?
- Sí. Astro es agnóstico al framework y soporta React, Vue, Svelte, Solid y otros como islas interactivas. Agregas React y renderizas componentes con una directiva como client:load o client:visible, que hidrata solo ese componente mientras el resto de la página queda como HTML cero-JavaScript. Esto significa que puedes reutilizar una biblioteca de componentes React existente dentro de un sitio Astro, y vuelve mucho menos doloroso migrar un sitio de contenido de Next.js a Astro que una reescritura completa. La disciplina clave es agregar islas con moderación — cada una que hidratas es JavaScript que estás enviando de nuevo.
- ¿Cuándo le gana Next.js a Astro?
- Cuando construyes una aplicación en vez de un sitio de contenido. Next.js gana para tableros, productos SaaS, e-commerce con cuentas de usuario, y cualquier cosa que necesite autenticación, datos en tiempo real, server actions o estado de cliente complejo — su App Router y los React Server Components están hechos exactamente para eso. También maneja mejor los sitios muy grandes en un aspecto: para miles de páginas, su regeneración estática incremental evita los largos rebuilds completos que un sitio Astro totalmente estático puede topar. Si tu proyecto tiene de verdad forma de aplicación, el JavaScript base de Next.js es una inversión que rinde en vez de peso muerto — que es lo que sería en una simple página de contenido.