Astro vs Next.js: la verdad técnica detrás de un 40 % más rápido en sitios estáticos

Elegir framework para un blog técnico me tuvo dando vueltas un buen rato: Next.js viene de Vercel y tiene un ecosistema React potente; Astro tiene buena reputación en la comunidad, con titulares de «rendimiento brutal» y «Lighthouse al máximo». Leí montones de comparativas: unos decían que Astro es más rápido, otros que Next.js es más completo. Cuanto más leía, más confundido estaba.

Al final dediqué dos días a probar ambos: monté dos versiones del mismo blog, ejecuté Lighthouse, comparé tiempos de build y desplegué para medir velocidad real. Resultado: el Lighthouse de Astro pasó de 88 a 100 y la carga inicial fue casi la mitad de rápida.

Este artículo es mi resumen. Sin exagerar ni menospreciar: datos reales, análisis en profundidad desde rendimiento, arquitectura, ecosistema y despliegue. Al terminar sabrás cuál te conviene.

Duelo de rendimiento: ¿quién es el rey de la velocidad?

En cualquier comparación Astro vs Next.js, el rendimiento es inevitable. Si montas un blog o un sitio de documentación, ¿a quién no le gustaría cargar más rápido y posicionar mejor en SEO?

Diferencia de volumen JavaScript: un 90 % no es broma

Empecemos por lo más visible. Monté dos blogs con el mismo contenido (~30 artículos, resaltado de código e imágenes) y comparé el tamaño del bundle JavaScript tras el build:

• Next.js exportación estática: ~85 KB de JS en la home (gzip)
• Astro: ~8 KB de JS en la home (gzip)

La brecha es real. Astro afirma ~90 % menos JavaScript; mis pruebas coinciden.

¿Por qué? La clave está en la arquitectura. Next.js, incluso con SSG, empaqueta el runtime de React, la lógica de hidratación y el enrutamiento. Astro renderiza páginas como HTML puro por defecto y no envía JavaScript salvo que marques un componente con client:*.

En pocas palabras: Next.js te da el paquete completo de React aunque solo quieras contenido estático; Astro te da solo lo necesario.

Lighthouse: Astro alcanza el máximo con facilidad

El bundle no lo es todo; importa la experiencia real. Medí ambos sitios en producción (desplegados en Vercel) con Lighthouse de Chrome DevTools:

Blog Astro:

• Performance: 100
• Accessibility: 98
• Best Practices: 100
• SEO: 100

Blog Next.js (SSG):

• Performance: 88
• Accessibility: 98
• Best Practices: 96
• SEO: 100

La brecha en Performance viene sobre todo de FCP (First Contentful Paint) y TTI (Time to Interactive). Astro suele renderizar el primer contenido en ~0,5 s; Next.js necesita 1-1,5 s.

En móvil con red 3G simulada (Slow 4G de Lighthouse), la diferencia se amplía: Astro se mantiene en 95+, Next.js cae a ~75.

Para blogs y documentación, la ventaja de rendimiento de Astro es tangible.

Velocidad de build: en proyectos grandes la brecha crece

En la experiencia de desarrollo, el tiempo de build también cuenta. Probé un sitio de documentación de 1000 páginas (Starlight y Nextra):

• Astro (Starlight): ~18 s de build
• Next.js (Nextra): ~52 s de build

Astro fue casi 3 veces más rápido, en línea con la cifra oficial «3 veces más rápido que Gatsby».

Con honestidad, Next.js 15 mejoró mucho el build (antes 80+ s, ahora ~50 s con paralelización). Aun así, sigue por detrás de Astro.

Casos reales: ¿cómo eligen las grandes empresas?

Los números sueltos no siempre convencen; los casos reales ayudan.

Sitios conocidos con Astro:

• Documentación para desarrolladores de IKEA
• Blog oficial de NordVPN
• Sitio de documentación de Firebase
• Centro de desarrolladores de Cloudflare

En común: contenido primero, velocidad de carga y SEO al máximo.

Sitios conocidos con Next.js:

• E-commerce de Nike
• Páginas de marketing de Spotify
• Plataforma de contenido de Hulu
• Parte de las páginas de TikTok

Next.js brilla donde hay funciones dinámicas, interacción o personalización.

La conclusión de fondo: contenido puramente expositivo → Astro; escenarios con interacción dinámica → Next.js.

Arquitectura técnica: ¿Islands o RSC para escenarios estáticos?

Tras los datos de rendimiento, la pregunta natural es: ¿qué hay bajo el capó en Astro y Next.js para generar tanta diferencia?

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

Astro Islands: la página es océano, la interacción son islas

El núcleo de Astro es la arquitectura Islands. Suena raro al principio, pero la idea es simple.

Imagina tu página como un océano: la mayor parte es agua estática (HTML puro). Solo unas islas (componentes interactivos) necesitan JavaScript para «activarse»: buscador, comentarios, botón de like.

Astro renderiza toda la página como HTML estático; con client:* activas islas concretas:

---

import SearchBox from '../components/SearchBox.jsx'
import StaticHeader from '../components/Header.astro'

---

<StaticHeader /> <!-- HTML puro, sin JS -->
<SearchBox client:load /> <!-- Isla: carga JS -->

Tres ventajas:

1. JS bajo demanda: solo los componentes interactivos envían JavaScript
2. Hidratación independiente: cada isla está aislada y puede cargarse en paralelo
3. Estrategias flexibles: client:load (inmediato), client:idle (cuando el navegador está ocioso), client:visible (al entrar en viewport)

Ejemplo real: en la home de mi blog hay resaltado de código y toggle de modo oscuro.

• Resaltado con CSS puro (sin JS)
• Modo oscuro con client:load (interacción inmediata)
• Resultado: solo ~5 KB de JS en la home

En Next.js, aunque el resaltado sea estático, se empaqueta todo el runtime de React.

Next.js RSC: aligerar con componentes de servidor

Next.js 15 responde con React Server Components (RSC): «lo que se puede renderizar en servidor, que no viaje al cliente».

RSC divide los componentes en dos tipos:

1. Server Components (por defecto): render en servidor, sin JS al navegador
2. Client Components (con 'use client'): interactivos, se empaquetan y envían

// app/components/Header.jsx
// Server Component por defecto, sin JS
export default function Header() {
  return <header>My Blog</header>
}

// app/components/SearchBox.jsx
'use client' // Declara que necesita JS en cliente
import { useState } from 'react'
export default function SearchBox() {
  const [query, setQuery] = useState('')
  // ...
}

¿Suena parecido a Astro Islands? Sí, pero hay diferencias clave:

1. Comportamiento por defecto

• Astro: cero JS; activas islas manualmente
• Next.js: sigue enviando el runtime de React; solo reduce código de componentes

2. Escenarios

• Astro Islands: estático con interacción puntual
• Next.js RSC: mucho contenido dinámico y datos en servidor

3. Acoplamiento

• Astro: agnóstico; mezcla React, Vue, Svelte
• Next.js: ligado a React

¿Cuál conviene en escenarios estáticos?

Si tu sitio es contenido puramente estático (blog, docs, portfolio), Astro Islands es más ligero. Caso extremo: blog solo Markdown → Astro puede no enviar JS; Next.js necesita al menos 40-50 KB de runtime base.

Si necesitas actualizaciones dinámicas, ISR de Next.js gana. Conectado a un CMS, una publicación nueva puede regenerar páneas concretas sin rebuild completo.

Desde Astro 4.0 existen Server Islands para contenido dinámico diferido, pero aún no están tan maduros como ISR de Next.js.

Mi recomendación:

• Más del 90 % estático: Astro, beneficio claro en rendimiento
• Actualizaciones frecuentes: Next.js, ISR más flexible
• Escenario mixto: depende del stack; ambos pueden servir

Ecosistema y funciones: experiencia de desarrollo y extensibilidad

Pasemos a lo práctico: ¿cómo se sienten al usar y tienen lo que necesitas?

Markdown: Astro listo, Next.js requiere trabajo

Para blog o documentación, Markdown es obligatorio. Aquí Astro va muy por delante.

Markdown en Astro:

• Coloca .md en src/pages/ y se renderiza
• MDX integrado para componentes dentro de Markdown
• Content Collections API con tipado:

// src/content/config.ts
import { defineCollection, z } from 'astro:content'

const blog = defineCollection({
  schema: z.object({
    title: z.string(),
    date: z.date(),
    tags: z.array(z.string())
  })
})

export const collections = { blog }

Consultas con autocompletado TypeScript, RSS y Sitemap automáticos.

Markdown en Next.js:

• Instalar @next/mdx o next-mdx-remote
• Configurar remark/rehype
• Gestión de contenido con librerías como contentlayer

Next.js puede, pero con configuración extra. Para principiantes, Astro es más directo.

Compatibilidad de frameworks: Astro como «unificador»

Aquí Astro destaca mucho.

En un mismo proyecto puedes mezclar React, Vue, Svelte, Solid, Preact… Por ejemplo:

• Nav en React (el equipo lo conoce)
• Formulario en Vue (componente existente)
• Gráficos en Svelte (rendimiento)

---

import ReactNav from './ReactNav.jsx'
import VueForm from './VueForm.vue'
import SvelteChart from './SvelteChart.svelte'

---

<ReactNav client:load />
<VueForm client:visible />
<SvelteChart client:idle />

Next.js está ligado a React; otros frameworks casi no encajan. No es un defecto: apuesta por la experiencia React completa.

Para elegir framework de sitio estático, la flexibilidad de Astro permite reutilizar componentes sin reescribir todo.

Ecosistema de plugins: Next.js gana en volumen, Astro en enfoque

Next.js:

• Cientos de miles de paquetes React en npm
• Integraciones Vercel (Analytics, Edge Config, KV)
• Comunidad enorme

Astro:

• 400+ integraciones oficiales y comunitarias
• Starlight para documentación
• Imágenes, Sitemap, RSS con soporte oficial

Para blog o docs, Astro basta. Para apps complejas, el ecosistema React de Next.js pesa más.

Experiencia de desarrollo: curvas de aprendizaje

Curva Astro:

• Si sabes HTML/CSS/JS, casi cero fricción
• Sintaxis .astro simple, tipo SFC de Vue
• Documentación clara; en 10 minutos arrancas

Curva Next.js:

• Requiere conocer React
• App Router con Server/Client Components, layouts anidados, fetching…
• Muchas opciones; fácil abrumarse

Next.js es potente y complejo. Si solo quieres un blog rápido, la simplicidad de Astro se nota.

Documentación: Starlight vs Nextra

Astro Starlight:

• Oficial, integración profunda
• Sidebar, búsqueda e i18n automáticos
• Rendimiento extremo, Lighthouse al máximo
• Tema moderno, listo para usar

Next.js Nextra:

• De Vercel, sobre Next.js
• Muy personalizable
• Ecosistema React, muchas librerías de UI
• Rendimiento inferior a Starlight, pero suficiente

Monté un sitio de docs con Starlight: de cero a producción en ~2 h, despliegue incluido. Muy fluido.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

Escenarios de uso: árbol de decisión

Tras tanto detalle técnico, la pregunta central: ¿cuál te conviene?

Aquí va un flujo de decisión según tus necesidades.

¿Cuándo elegir Astro?

Si encajas en 2 o más de estos puntos, Astro encaja muy bien:

1. Contenido primero, interacción secundaria

• Blog personal, documentación, web corporativa, landing
• Más del 90 % estático
• Poca interacción: buscador, comentarios, modo oscuro

2. Rendimiento y SEO son requisitos duros

• Lighthouse cerca del máximo
• Core Web Vitals afectan al ranking
• Mucho tráfico móvil en redes lentas

3. Gestión de contenido en Markdown

• Artículos en Markdown, imágenes locales
• Content Collections con tipado
• RSS y Sitemap sin configurar

4. Mezcla de frameworks

• Equipo con React y Vue
• Reutilizar componentes de distintos stacks
• Evitar quedar atado a uno solo

5. Empezar rápido

• Sin conceptos pesados de framework
• Sitio usable en 10 minutos
• Stack heterogéneo en el equipo

¿Cuándo elegir Next.js?

Si tu caso es así, Next.js encaja mejor:

1. Contenido dinámico

• Headless CMS (Contentful, Sanity)
• Regeneración programada o bajo demanda (ISR)
• Contenido generado por usuarios (comentarios, likes, favoritos)

2. Rutas dinámicas complejas

• E-commerce (ficha, carrito, checkout)
• Foros (perfil, hilos, respuestas)
• Mucha obtención de datos en servidor

3. Integración profunda con React

• Equipo ya en React
• Dependencia de librerías del ecosistema
• Auth, Analytics, Edge Functions del stack Next.js

4. Renderizado híbrido

• Parte estática, parte SSR
• Personalización según sesión
• API Routes como capa BFF

5. Ecosistema Vercel

• Ya usas Vercel
• Integraciones de la plataforma
• Despliegue y optimización en un clic

Casos reales: cómo decidieron otros

Migraciones de Next.js a Astro:

• Blog de situ2001: contenido estático; Lighthouse de 88 a 100, build a la mitad
• Sitio de docs (~1000 páginas): build de 80 s a 20 s, carga inicial ~40 % más rápida

Motivos:

1. No necesitaban el runtime pesado de React
2. Buscar rendimiento extremo
3. Mejor experiencia con Markdown

Casos que siguen con Next.js:

• Plataforma educativa: login, progreso, recomendaciones
• E-commerce: catálogo que cambia a menudo, ISR
• Marketing SaaS: páginas estáticas + demo dinámica

Motivos:

1. SSR y funciones dinámicas
2. Equipo con experiencia React
3. Despliegue integrado en Vercel

Evaluación del costo de migración

¿Migrar de Next.js a Astro cuesta mucho?

Bajo costo (1-2 días):

• Blog solo Markdown
• Sin componentes React complejos
• Sin APIs específicas de Next.js

Costo medio (1-2 semanas):

• Componentes React (conservables con Islands)
• Ajustar optimización de imágenes
• Reescribir layout y rutas

Alto costo (no migrar):

• Muchos Hooks y estado global
• API Routes, Middleware
• Lógica compleja de datos en servidor

Si el 90 % es estático, compensa; si lo dinámico supera el 30 %, no merece la pena complicarse.

Lista de decisión: 3 preguntas

P1: ¿Con qué frecuencia actualizas contenido?

• Diario/semanal → Next.js (ISR)
• Cada meses → Astro (rendimiento)

P2: ¿Cuánta interacción tiene el sitio?

• Solo comentarios/búsqueda → Astro (Islands bastan)
• Mucha interacción de usuario → Next.js (ecosistema React)

P3: ¿Qué stack usa el equipo?

• Varios frameworks / HTML puro → Astro
• React profundo → Next.js

Con las respuestas, la elección debería estar clara.

Recomendaciones prácticas: inicio y despliegue

Teoría aparte, esto te ayuda a arrancar con cualquiera de los dos.

Inicio rápido: Hello World en 10 minutos

Astro:

# Crear proyecto
npm create astro@latest my-blog

# Elegir plantilla (Blog o Empty)
cd my-blog
npm install
npm run dev

Abre http://localhost:4321. Edita src/pages/index.astro y verás cambios al instante.

Next.js:

# Crear proyecto
npx create-next-app@latest my-blog

# Sigue el asistente (TypeScript, App Router, Tailwind...)
cd my-blog
npm run dev

Abre http://localhost:3000. Edita app/page.tsx.

Ambos arrancan rápido; la plantilla por defecto de Astro encaja mejor con blogs; la de Next.js, con apps.

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Plantillas starter recomendadas

Astro:

• Astro Blog: plantilla oficial
• AstroPaper: blog completo con búsqueda, tags y RSS
• Starlight: documentación lista para usar

Next.js:

• Next.js Blog Starter: ejemplo oficial
• Nextra: documentación
• Contentlayer Blog: con Contentlayer

Recomiendo AstroPaper: completo, rápido y con buen diseño.

Comparación de despliegue

Vercel (recomendado):

• Astro: cero config, npm run build
• Next.js: soporte nativo, optimización automática
• Pros: rápido fuera de China, HTTPS, previews
• Contras: más lento en China; free tier 100 GB/mes

Netlify:

• Ambos, configuración simple
• Pros: más cuota gratuita, Functions
• Contras: builds algo más lentos que Vercel

Cloudflare Pages:

• Ambos, despliegue veloz
• Pros: CDN global, ancho de banda ilimitado en free
• Contras: entorno de build a veces inestable

GitHub Pages:

• Astro: soporte excelente
• Next.js: export estático (output: 'export'), funciones limitadas
• Pros: gratis, Actions
• Contras: lento en China; sin Server Components

Optimización para acceso desde China

Si tu audiencia está en China:

1. CDN: Cloudflare Pages suele ir mejor que Vercel
2. Fuentes: locales o CDN nacional (evita Google Fonts)
3. Comentarios: Giscus (GitHub) en lugar de Disqus
4. Imágenes: OSS de Alibaba o COS de Tencent, no Imgur

Mi blog en Cloudflare Pages rinde bien dentro de China.

Problemas frecuentes

Limitaciones de Astro:

• ❌ Apps muy interactivas (dashboard, SaaS)
• ❌ Actualizaciones en tiempo real menos flexibles que Next.js
• ✅ Estático en Astro, dinámico en servicio aparte

Sobreingeniería en Next.js:

• ❌ Demasiado para un blog simple
• ❌ App Router con curva pronunciada
• ✅ Si solo necesitas estático, valora Astro

Checklist de rendimiento (general):

• ☑ Imágenes WebP y lazy load
• ☑ font-display: swap
• ☑ Scripts de terceros diferidos (Analytics, ads)
• ☑ HTTP/2 y compresión Brotli
• ☑ Cabeceras Cache-Control adecuadas

Recursos de aprendizaje

Astro:

• Documentación oficial
• Tutorial de blog
• Starlight

Next.js:

• Documentación oficial
• Next.js Learn
• Guía de migración a App Router

Con estos recursos puedes empezar a desarrollar.

Conclusión

Resumiendo:

Astro vs Next.js no tiene un ganador absoluto. Depende del escenario:

¿Qué elegiría yo?

• Blog personal, documentación técnica: Astro, sin dudarlo
• Web corporativa, landing: Astro; el rendimiento compite
• Integración CMS: según frecuencia; baja → Astro, alta → Next.js
• Apps complejas, e-commerce: Next.js
• Equipo ya en React: Next.js, menos fricción

Yo terminé con Astro porque:

1. El 95 % del blog es estático; no necesito el runtime pesado de React
2. Lighthouse al máximo mejoró el SEO de verdad
3. Markdown y Content Collections aceleraron escribir

Si montara la web de un SaaS con demo y dashboard, elegiría Next.js: con mucha dinámica, Astro se queda corto.

Acción inmediata:

No te quedes solo leyendo: prueba 10 minutos. Monta un Hello World en cada uno, ejecuta Lighthouse y mira los números. La experiencia directa vale más que diez artículos.

# Astro
npm create astro@latest test-astro
cd test-astro && npm install && npm run dev

# Next.js
npx create-next-app@latest test-nextjs
cd test-nextjs && npm run dev

Abre Chrome DevTools, corre Lighthouse y compara. Los datos no mienten.

Última frase: el framework es herramienta; el contenido manda. Da igual Astro o Next.js: lo importante es publicar calidad. No dejes que elegir framework sea excusa para no escribir.

Si tienes dudas, comenta; intentaré responder. ¡Mucho éxito con tu sitio!