Astro 5 vs Next.js 15: cuál elegir en 2026 (comparativa real)

CA

Cris Artigas

Desarrollo web, consultoría digital y marketing & growth

La falsa rivalidad: Astro y Next.js no compiten

Empecemos por lo más importante: comparar Astro con Next.js es como comparar un cuchillo de chef con una batidora. Ambos están en la cocina, pero resuelven problemas fundamentalmente distintos.

Astro es un framework de contenido. Nació para generar sitios estáticos ultra-rápidos con zero JavaScript por defecto. Next.js es un framework de aplicaciones React. Nació para construir apps dinámicas con server-side rendering.

El problema es que en 2026 ambos han expandido sus capacidades hasta que se solapan en el medio. Astro 5 con Server Islands permite contenido dinámico. Next.js 15 con React Server Components envía menos JavaScript. Y ahí es donde la elección se complica.

He construido este mismo sitio (crisartigas.com) con Astro y he entregado aplicaciones con Next.js para clientes. Mi opinión no es teórica — es basada en horas reales de desarrollo, debugging y mantenimiento.

Rendimiento: las cifras no mienten

Astro 5

Astro envía 0 KB de JavaScript al cliente por defecto. Si escribes un componente Astro, se renderiza en el servidor y se envía como HTML puro. Solo los componentes que explícitamente marcas con client:load, client:visible o client:idle envían JS al navegador.

Resultado típico en Lighthouse para un sitio Astro estático:

Performance: 98-100
LCP: < 1.2s
CLS: 0
Total JS transferido: 0-15 KB

Next.js 15

Next.js 15 con React Server Components mejora mucho respecto a versiones anteriores. Los RSC se renderizan en el servidor y no envían su JavaScript al cliente. Pero Next.js sigue necesitando el runtime de React (~85 KB comprimido) para hidratar los componentes cliente.

Resultado típico en Lighthouse para un sitio Next.js optimizado:

Performance: 85-95
LCP: 1.5-2.5s
CLS: 0-0.05
Total JS transferido: 90-200 KB

La diferencia es real y medible. Para sitios de contenido donde el rendimiento en Core Web Vitals es crítico (SEO, conversiones), Astro tiene una ventaja estructural difícil de igualar.

Developer Experience (DX)

Lo que me gusta de Astro

Sintaxis de componentes: los archivos .astro mezclan frontmatter (JS del servidor) con HTML template. Es intuitivo y limpio
Agnosticismo: puedes usar componentes React, Vue, Svelte o Solid dentro de Astro. Ideal si tu equipo viene de diferentes ecosistemas
Content Collections: sistema nativo para gestionar contenido tipado con Markdown/MDX. Potente y type-safe
Simplicidad: menos conceptos que aprender. No hay hidratación parcial, streaming SSR, ni middleware complicado

Un componente de tarjeta en Astro:

---
interface Props {
  title: string;
  description: string;
}
const { title, description } = Astro.props;
---
<article class="card">
  <h2>{title}</h2>
  <p>{description}</p>
</article>

Lo que me gusta de Next.js

Ecosistema React: acceso a miles de librerías y componentes
App Router: routing basado en carpetas con layouts anidados, loading states y error boundaries
Server Actions: mutaciones de datos sin API routes explícitos
Middleware: lógica en el edge para auth, redirects, A/B testing

El mismo componente en Next.js (Server Component):

interface CardProps {
  title: string;
  description: string;
}

export function Card({ title, description }: CardProps) {
  return (
    <article className="card">
      <h2>{title}</h2>
      <p>{description}</p>
    </article>
  );
}

El factor decisivo: complejidad

Astro tiene una curva de aprendizaje más suave. Si sabes HTML, CSS y JavaScript básico, puedes construir un sitio Astro en una tarde. Next.js requiere entender React, el modelo mental de Server vs Client Components, y la diferencia entre rendering strategies (SSG, SSR, ISR).

Server Islands vs React Server Components

La feature más relevante de Astro 5 es Server Islands: puedes marcar componentes individuales para que se rendericen en el servidor de forma dinámica, mientras el resto de la página se sirve como HTML estático desde CDN.

---
import CartWidget from '../components/CartWidget.astro';
---
<html>
  <body>
    <h1>Producto increíble</h1>
    <!-- Este componente se renderiza dinámicamente -->
    <CartWidget server:defer />
    <!-- El resto es HTML estático -->
  </body>
</html>

Next.js resuelve algo similar con React Server Components, pero la implementación es diferente. En Next.js, todo componente es Server Component por defecto y necesitas "use client" para optar por renderizado en el cliente.

La diferencia clave: en Astro, el defecto es estático y optas por dinamismo. En Next.js, el defecto es servidor y optas por cliente. Parece sutil, pero afecta cómo piensas y diseñas tu aplicación.

Tabla comparativa rápida

Criterio	Astro 5	Next.js 15
JS al cliente (defecto)	0 KB	~85 KB (runtime React)
Lighthouse Performance	98-100	85-95
Curva de aprendizaje	Baja	Media-Alta
Ecosistema de componentes	Multi-framework	Solo React
CMS/Contenido	Content Collections nativo	Headless CMS + fetch
Apps dinámicas	Limitado (Server Islands)	Excelente
Auth/Estado	Necesita librerías externas	NextAuth, middleware nativo
Deploy gratuito	Vercel, Netlify, Cloudflare	Vercel (optimizado), Netlify
Hosting estático	Sí (por defecto)	Sí (con `output: 'export'`)

Cuándo elijo Astro en mis proyectos

Blogs y portafolios: como este mismo sitio. Rendimiento perfecto, SEO nativo, sin complejidad innecesaria
Landing pages de marketing: donde cada milisegundo de carga impacta en conversiones
Documentación: con Content Collections y Markdown es ideal
Sitios corporativos: 5-30 páginas de contenido que cambian poco
SEO programático: generar cientos de páginas estáticas desde datos (lo hice para mis páginas de servicios por ciudad)

Cuándo elijo Next.js en mis proyectos

Dashboards y paneles: con autenticación, datos en tiempo real, muchos formularios
E-commerce personalizado: donde necesitas carrito, checkout, gestión de usuario
SaaS: aplicaciones con lógica de negocio compleja en el frontend
Proyectos con equipo React: si el equipo ya domina React, no tiene sentido forzar otro paradigma

Mi recomendación honesta

Si tu proyecto es 80%+ contenido y necesitas rendimiento, SEO y simplicidad: Astro.

Si tu proyecto es 80%+ aplicación con interactividad, autenticación y estado complejo: Next.js.

Si estás en el 50/50 — un sitio de contenido con secciones dinámicas — Astro 5 con Server Islands probablemente te dé el mejor resultado con menos complejidad. Pero si tu equipo ya domina React, Next.js 15 con RSC también funciona.

El peor error es elegir por hype. He visto startups usando Next.js para un blog de 10 páginas y freelancers intentando construir un SaaS con Astro. Elige la herramienta que resuelve tu problema, no el problema de Twitter.

Compartir este artículo

Sigue leyendo