Traducción al Español

He estado construyendo sitios de producción con Next.js y Gatsby desde 2019. Vi a Gatsby recaudar $46 millones, ser adquirido por Netlify y luego ser silenciosamente abandonado. Migré tres sitios empresariales de Gatsby a Next.js solo en 2025. Esta no es una comparación teórica — es una autopsia de un framework y una evaluación honesta del otro.

Si todavía estás ejecutando Gatsby en producción, necesitas un plan de migración. Si estás eligiendo un framework para un nuevo proyecto, la respuesta es directa pero matizada. Déjame guiarte a través de todo esto.

Tabla de Contenidos

Next.js vs Gatsby en 2026: La Guía Completa de Decisión para Producción

El Estado de Gatsby en 2026

Seamos claros. Gatsby está, para todos los propósitos prácticos, abandonado.

Netlify adquirió Gatsby Inc. en febrero de 2023. La promesa era desarrollo continuado e integración con la plataforma de Netlify. Lo que realmente sucedió fue un lento declive. El último lanzamiento significativo de Gatsby (v5.13) se envió a finales de 2023. El repositorio de GitHub ha tenido commits de mantenimiento mínimo desde mediados de 2024. Los mantenedores clave se fueron. El ecosistema de plugins se ha estancado — muchos plugins populares no han sido actualizados en más de 18 meses.

Aquí está la cronología que importa:

Fecha Evento
Feb 2023 Netlify adquiere Gatsby Inc.
Q3 2023 Se lanza Gatsby v5.13 (último lanzamiento significativo)
Q1 2024 Gatsby Cloud se cierra oficialmente
Q2 2024 Los miembros del equipo principal abandonan Netlify
Q4 2024 Las descargas semanales de npm caen por debajo de 150k (desde el pico de 800k+)
Q1 2025 Netlify elimina documentos específicos de Gatsby de la navegación principal
2026 Sin lanzamiento v6, sin roadmap, efectivamente en modo mantenimiento

Los números de descargas de npm cuentan la historia. En su pico en 2021, Gatsby estaba obteniendo más de 800,000 descargas semanales. A principios de 2026, ronda los 100,000 — y la mayoría de esos son pipelines de CI/CD existentes, no nuevos proyectos.

No digo esto para criticar a Gatsby. Realmente impulsó el ecosistema de React hacia adelante. La idea de una capa de datos en tiempo de construcción con GraphQL, optimización de imágenes en tiempo de construcción, la arquitectura de plugins — estas fueron innovaciones reales. Pero el framework perdió el argumento técnico cuando Next.js envió ISR a finales de 2020, y perdió el argumento comercial cuando Netlify dejó de invertir en él.

Si estás ejecutando Gatsby en producción en este momento, tus mayores riesgos son:

  • Vulnerabilidades de seguridad en dependencias no mantenidas
  • Incompatibilidades de versiones de Node.js a medida que el ecosistema avanza
  • Degradación de plugins — plugins de terceros rompiéndose sin correcciones ascendentes
  • Dificultad para contratar — los desarrolladores no quieren Gatsby en su currículum en 2026

Next.js en 2026: Qué ha Cambiado Realmente

Next.js 15 llegó a finales de 2024, y los lanzamientos iterativos a través de 2025 han consolidado el App Router como el modelo de desarrollo principal. Aquí está la situación:

React Server Components (RSC) ahora son la configuración predeterminada. Cuando creas un componente en el App Router, es un Server Component a menos que agregues explícitamente 'use client'. Esto no fue solo un cambio de sintaxis — alteró fundamentalmente cómo pensamos sobre la obtención de datos y la arquitectura de componentes.

Partial Prerendering (PPR) se hizo estable en Next.js 15.1. Esta es la característica que habría matado a Gatsby incluso si Gatsby todavía estuviera en desarrollo activo. PPR te permite servir un shell estático instantáneamente mientras transmites contenido dinámico. Obtienes la velocidad de SSG con la flexibilidad de SSR. Es lo mejor de ambos mundos, y es algo que la arquitectura de Gatsby nunca podría soportar.

Server Actions han madurado significativamente. Manejo de formularios, mutaciones, revalidación — los patrones ahora están bien establecidos y han reemplazado gran parte del boilerplate de rutas API que solíamos escribir.

// Next.js 15 - Ejemplo de Server Action
// app/actions.ts
'use server'

import { revalidatePath } from 'next/cache'

export async function updateProduct(formData: FormData) {
  const id = formData.get('id') as string
  const title = formData.get('title') as string
  
  await db.product.update({
    where: { id },
    data: { title }
  })
  
  revalidatePath(`/products/${id}`)
}

El bundler Turbopack ahora es el predeterminado para desarrollo (y estable para compilaciones de producción a partir de principios de 2026). Los tiempos de inicio en frío para next dev bajaron un 50-70% comparado con webpack. Las compilaciones de producción también son más rápidas, aunque la mejora allí es más modesta — alrededor de 20-30%.

Benchmarks de Rendimiento: Lighthouse, Tamaño de Bundle, Core Web Vitals

Ejecuté benchmarks en sitios equivalentes — un sitio de marketing con 50 páginas, blog con 200 posts, sección de portafolio con muchas imágenes. Mismo contenido, mismo hosting (Vercel para Next.js, Netlify para Gatsby). Aquí están los resultados de enero de 2026:

Puntuaciones de Lighthouse (Móvil, Mediana de 5 Ejecuciones)

Métrica Next.js 15 (App Router) Gatsby 5.13 Next.js 15 (Pages Router)
Rendimiento 96 88 93
Accesibilidad 98 97 98
Mejores Prácticas 100 95 100
SEO 100 100 100
LCP (segundos) 1.1s 1.8s 1.3s
FID/INP (ms) 45ms 120ms 85ms
CLS 0.02 0.08 0.03
TBT (ms) 120ms 380ms 190ms

Comparación de Tamaño de Bundle

Aquí es donde las cosas se vuelven realmente interesantes. Gatsby envía un runtime de lado del cliente que incluye React, el runtime de Gatsby y la capa de datos. Next.js con el App Router y RSC envía significativamente menos JavaScript al cliente porque los Server Components no contribuyen al bundle del cliente en absoluto.

Métrica Next.js 15 (App Router) Gatsby 5.13
JS de Primera Carga 87 KB (comprimido) 210 KB (comprimido)
JS de Ruta (promedio) 12 KB 45 KB
JS Total (sitio de 50 páginas) 145 KB 380 KB
Optimización de imágenes Integrada (a demanda) Tiempo de construcción (gatsby-plugin-image)
Optimización de fuentes Integrada (next/font) Manual o plugin

La diferencia de tamaño de bundle se debe principalmente a RSC. En un sitio típico de Gatsby, cada componente se envía al cliente incluso si solo renderiza contenido estático. En Next.js con Server Components, un componente que obtiene datos y renderiza HTML nunca llega al bundle del cliente. Esa es una victoria masiva.

Core Web Vitals en el Campo

Los benchmarks de laboratorio son útiles, pero los datos de campo importan más. Basado en datos de CrUX (Chrome User Experience Report) de sitios en los que he trabajado:

  • Sitios de Next.js: 85% aprobado en todos los tres umbrales de Core Web Vitals
  • Sitios de Gatsby: 62% aprobado en todos los tres (principalmente fallando en INP y TBT)

La métrica INP (Interaction to Next Paint) es donde Gatsby realmente lucha. El bundle de JavaScript más grande del lado del cliente significa más trabajo en el hilo principal, lo que significa interacciones más lentas. El modelo de hidratación de Gatsby requiere procesar los datos de toda la página en el cliente, mientras que Next.js con RSC evita esto completamente para contenido renderizado en el servidor.

Next.js vs Gatsby en 2026: La Guía Completa de Decisión para Producción - arquitectura

Comparación de Arquitectura: RSC, App Router, SSG, ISR

Estrategias de Renderizado

Gatsby fue construido alrededor de una estrategia de renderizado: Generación de Sitio Estático (SSG). Todo se construye en tiempo de compilación. Gatsby añadió DSG (Deferred Static Generation) en v4, que fue su respuesta a ISR de Next.js, pero requería Gatsby Cloud y nunca fue tan flexible.

Next.js te da todo:

// Generación Estática (equivalente al predeterminado de Gatsby)
// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await getAllPosts()
  return posts.map((post) => ({ slug: post.slug }))
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug)
  return <Article post={post} />
}

// ISR - revalidar cada 60 segundos
export const revalidate = 60

// O revalidación a demanda a través de ruta API
// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache'
import { NextRequest } from 'next/server'

export async function POST(request: NextRequest) {
  const { path } = await request.json()
  revalidatePath(path)
  return Response.json({ revalidated: true })
}

El Problema de la Capa de Datos

La capa de datos GraphQL de Gatsby fue innovadora pero finalmente se convirtió en una responsabilidad. Cada fuente de datos necesitaba un plugin de origen. Si el plugin no existía o no estaba mantenido, estabas atrapado escribiendo uno tú mismo. El esquema GraphQL en tiempo de construcción era poderoso pero agregaba una complejidad significativa y tiempo de construcción.

Next.js toma un enfoque diferente: simplemente obtiene datos. Usa lo que quieras — APIs REST, clientes GraphQL, consultas de base de datos, SDKs de CMS. No hay capa de datos impuesta por el framework. Esto es tanto más simple como más flexible.

// Next.js - obtener de cualquier fuente, de cualquier manera que quieras
async function getProducts() {
  // Consulta directa a la base de datos
  const products = await prisma.product.findMany()
  
  // O API REST
  const res = await fetch('https://api.example.com/products', {
    next: { revalidate: 3600 }
  })
  
  // O SDK de CMS sin encabezados
  const entries = await contentful.getEntries({ content_type: 'product' })
  
  return products
}

Para equipos que usan configuraciones de CMS sin encabezados — Contentful, Sanity, Storyblok, lo que sea — Next.js es dramáticamente más fácil de integrar. No necesitas un plugin de origen. Solo llama a la API. Cubrimos esto en profundidad en nuestro trabajo de desarrollo de CMS sin encabezados.

Los Server Components Cambian Todo

Sigo volviendo a RSC porque es genuinamente el cambio arquitectónico más importante en React desde hooks. Aquí está por qué importa para esta comparación:

En Gatsby, el árbol completo de componentes de tu página se envía al cliente. Incluso si un componente solo renderiza una lista de títulos de posts de blog obtenidos de un CMS, el código del componente y sus datos se serializan y se envían al navegador para hidratación.

En Next.js con RSC, ese mismo componente se ejecuta en el servidor, renderiza HTML, y el cliente nunca ve el código del componente ni los datos sin procesar. El navegador obtiene HTML. Eso es todo.

Esto significa:

  • Bundles más pequeños (como se muestra arriba)
  • Sin bugs de desajuste de hidratación para componentes solo de servidor
  • Puedes usar código solo de servidor (consultas de base de datos, acceso al sistema de archivos) directamente en componentes
  • Los datos sensibles (claves API, lógica comercial) permanecen en el servidor

Experiencia del Desarrollador y Ecosistema

Aspecto Next.js 15 Gatsby 5
Soporte de TypeScript De primera clase, tipos generados automáticamente Decente, pero faltan algunos tipos de plugins
Velocidad de recarga activa ~200ms (Turbopack) 1-3 segundos (webpack)
Tiempo de compilación (200 páginas) ~45 segundos ~3-5 minutos
Ecosistema de plugins Paquetes npm (universal) Plugins específicos de Gatsby (estancados)
Documentación Activamente mantenida Mayormente congelada desde 2023
Comunidad (Discord/GitHub) Muy activa Casi silenciosa
Demanda del mercado laboral Alta En declive rápido
Recursos de aprendizaje (2025-2026) Abundantes Escasos

La brecha en la experiencia del desarrollador se ha ampliado dramáticamente. Next.js con Turbopack te da recargas activas casi instantáneas. El servidor dev basado en webpack de Gatsby se siente lento en comparación, especialmente en sitios más grandes.

Los tiempos de compilación merecen una mención especial. Un sitio de Gatsby de 500 páginas con procesamiento de imágenes pesado podría tomar 15-20 minutos para compilar. El sitio equivalente de Next.js con optimización de imágenes a demanda se compila en menos de 2 minutos porque las imágenes se procesan en tiempo de solicitud (y luego se almacenan en caché), no en tiempo de compilación.

Nuestro equipo de desarrollo de Next.js ha visto esto suceder en docenas de proyectos. Los tiempos de compilación impactan directamente la productividad del desarrollador y los costos de CI/CD.

Costo Total de Propiedad

Hablemos de dinero. Aquí es donde la decisión se vuelve real para los stakeholders comerciales.

Costos de Hosting

Escenario Next.js en Vercel Gatsby en Netlify
Sitio pequeño (< 100 páginas, tráfico bajo) $0-20/mes $0-19/mes
Sitio mediano (500 páginas, 100k visitas/mes) $20-150/mes $19-99/mes
Sitio grande (5000+ páginas, 1M+ visitas/mes) $150-500/mes $99-300/mes*

*Los costos de hosting de Gatsby son más bajos porque es puro estático — sin cálculo de servidor. Pero pagas en tiempos de compilación y minutos de compilación.

Next.js también se puede implementar en otras plataformas: AWS (a través de SST o Amplify), Cloudflare, auto-hospedado con Node.js. La salida puramente estática de Gatsby le da más flexibilidad de hosting en teoría, pero en la práctica pierdes ISR y cualquier característica dinámica.

Costos de Desarrollo

Aquí es donde vive la verdadera diferencia de costo:

  • Tasas de desarrollador de Gatsby: $120-180/hr (escasos, premium por conocimiento heredado)
  • Tasas de desarrollador de Next.js: $100-200/hr (rango más amplio debido a un fondo de talentos más grande)
  • Costo de migración (sitio mediano de Gatsby → Next.js): $15,000-50,000 dependiendo de la complejidad
  • Mantenimiento continuo (Gatsby): Mayor debido a la gestión de dependencias, arreglos de plugins
  • Mantenimiento continuo (Next.js): Menor, caminos de actualización más directos

El costo oculto de permanecer en Gatsby es deuda técnica acumulándose diariamente. Cada mes que esperas, la migración se vuelve ligeramente más difícil a medida que el ecosistema de Gatsby se deteriora aún más.

Para una evaluación detallada de cuál podría ser el costo de una migración para tu situación específica, consulta nuestra página de precios o ponte en contacto.

Ruta de Migración: Gatsby a Next.js

Lo he hecho lo suficiente como para tener un proceso repetible. Aquí está el enfoque de alto nivel:

Fase 1: Auditoría (1-2 semanas)

  • Inventariar todos los plugins de Gatsby y sus equivalentes de Next.js
  • Mapear la capa de datos GraphQL a llamadas API directas o uso de SDK
  • Identificar lógica de gatsby-node.js (creación de página, personalización de esquema)
  • Catalogar toda la funcionalidad dinámica (búsqueda, formularios, autenticación)

Fase 2: Fundación (1-2 semanas)

  • Configurar proyecto de Next.js con App Router
  • Configurar TypeScript, ESLint, Tailwind (o tu enfoque CSS)
  • Configurar la integración del CMS directamente (sin plugins de origen necesarios)
  • Implementar la estrategia de optimización de imágenes usando next/image

Fase 3: Migración de Páginas (2-6 semanas, dependiendo del tamaño)

  • Convertir plantillas de página a componentes de página de Next.js
  • Reemplazar gatsby-image / gatsby-plugin-image con next/image
  • Reemplazar <Link> de Gatsby con <Link> de Next.js (API similar, afortunadamente)
  • Migrar lógica de gatsby-node.js createPages a generateStaticParams
  • Convertir cualquier lógica de gatsby-browser.js / gatsby-ssr.js a componentes de layout

Fase 4: Optimización (1-2 semanas)

  • Implementar ISR donde sea apropiado
  • Añadir Server Components para secciones con muchos datos
  • Configurar webhooks de revalidación a demanda desde tu CMS
  • Pruebas de rendimiento y optimización
// Patrón común de migración: consulta de página de Gatsby → obtención de datos de Next.js

// ANTES (Gatsby)
export const query = graphql`
  query BlogPostBySlug($slug: String!) {
    contentfulBlogPost(slug: { eq: $slug }) {
      title
      body { raw }
      publishDate
      heroImage {
        gatsbyImageData(width: 1200)
      }
    }
  }
`

// DESPUÉS (App Router de Next.js)
import { createClient } from 'contentful'

const client = createClient({
  space: process.env.CONTENTFUL_SPACE_ID!,
  accessToken: process.env.CONTENTFUL_ACCESS_TOKEN!
})

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const entries = await client.getEntries({
    content_type: 'blogPost',
    'fields.slug': params.slug,
    limit: 1
  })
  
  const post = entries.items[0].fields
  
  return (
    <article>
      <h1>{post.title}</h1>
      <Image
        src={`https:${post.heroImage.fields.file.url}`}
        width={1200}
        height={630}
        alt={post.title}
      />
      <RichText content={post.body} />
    </article>
  )
}

export const revalidate = 3600 // ISR: revalidar cada hora

La mayor trampa en la migración es el manejo de imágenes. El pipeline de imágenes de Gatsby fue genuinamente excelente — el placeholder con desenfoque, srcsets responsivos, carga perezosa. La buena noticia es que next/image ahora maneja todo esto, pero la API es diferente y tendrás que actualizar cada referencia de imagen.

Cuándo Next.js No es la Respuesta

Quiero ser justo aquí. Next.js no es la opción correcta para cada proyecto.

Si necesitas absoluta simplicidad para un blog o sitio de documentación, considera Astro. Astro envía cero JavaScript por defecto y tiene soporte excelente de colecciones de contenido. Para sitios puramente impulsados por contenido donde no necesitas la interactividad de React, Astro te dará mejor rendimiento con menos complejidad.

Si estás construyendo un sitio estático simple sin características dinámicas, incluso 11ty o Hugo podrían servirte mejor. No lleves un framework a una batalla de markup.

Si estás bloqueado en el ecosistema de Vue o Svelte, Nuxt y SvelteKit son alternativas fuertes en sus respectivos ecosistemas.

Pero si necesitas React, necesitas una mezcla de contenido estático y dinámico, necesitas un excelente rendimiento, y necesitas un framework que será activamente mantenido durante años por venir — Next.js es la opción obvia en 2026.

El Veredicto

Next.js gana. Ni siquiera está cerca, y no ha estado cerca desde 2022.

Gatsby pioneró ideas importantes en el ecosistema de React: optimización en tiempo de construcción, pipelines de procesamiento de imágenes, el concepto de una capa de datos unificada. Estas ideas viven en diferentes formas en frameworks modernos. Pero como un framework de producción en 2026, Gatsby es una responsabilidad.

Los argumentos técnicos son abrumadores:

  • RSC y el App Router dan a Next.js una ventaja arquitectónica que Gatsby no puede igualar
  • Los tamaños de bundle son 40-60% más pequeños
  • Las puntuaciones de Core Web Vitals son consistentemente mejores
  • ISR y PPR proporcionan flexibilidad de renderizado que Gatsby nunca logró
  • El ecosistema está prosperando vs. estancado

Los argumentos comerciales son igualmente claros:

  • Menor costo total de propiedad
  • Fondo de talentos más grande
  • Desarrollo y soporte activo de Vercel
  • Rutas claras de actualización para el futuro previsible

Si estás comenzando un nuevo proyecto, usa Next.js (o Astro si no necesitas React). Si estás ejecutando Gatsby en producción, comienza a planificar tu migración ahora. Cuanto más esperes, más difícil y costoso se vuelve.

¿Necesitas ayuda con esa migración? Nuestro equipo lo ha hecho muchas veces. Hablemos.

— Aaron Mitchell, Ingeniero Senior de Headless en Social Animal

FAQ

¿Está Gatsby completamente muerto en 2026? Gatsby no ha sido oficialmente declarado fin de vida por Netlify, pero está efectivamente en un estado de solo mantenimiento. No ha habido ningún lanzamiento significativo desde v5.13 a finales de 2023, el equipo principal se ha dispersado, y el ecosistema de plugins se está deteriorando. Para nuevos proyectos, no es una opción viable. Para proyectos existentes, deberías estar planeando una migración.

¿Cuánto tiempo tarda migrar de Gatsby a Next.js? Para un sitio de marketing típico con 50-200 páginas, espera 4-8 semanas de tiempo de desarrollo. Los sitios más grandes con relaciones de datos complejas, plugins personalizados, o uso pesado de GraphQL pueden tomar 8-16 semanas. Las variables más grandes son el número de plugins personalizados de Gatsby que estés usando y qué tan profundamente has integrado la capa de datos GraphQL de Gatsby.

¿Es Next.js más difícil de aprender que Gatsby? El App Router y los Server Components sí tienen una curva de aprendizaje, especialmente si vienes del modelo basado en páginas de Gatsby. Sin embargo, el modelo mental es en última instancia más simple — obtienes datos directamente en lugar de pasar por una capa GraphQL, y escribes componentes que se ejecutan en el servidor o el cliente. La mayoría de los desarrolladores encuentran Next.js más intuitivo una vez que superan los conceptos iniciales de RSC.

¿Puedo implementar Next.js sin Vercel? Absolutamente. Next.js se puede implementar en AWS (usando SST, Amplify, o una configuración personalizada), Cloudflare Pages, DigitalOcean, Railway, Fly.io, o auto-hospedado en cualquier servidor de Node.js. Vercel proporciona la experiencia más optimizada, pero no estás bloqueado. El comando next start ejecuta un servidor estándar de Node.js.

¿Qué hay de Astro vs Next.js para sitios estáticos? Para sitios puramente impulsados por contenido (blogs, documentación, páginas de marketing con interactividad mínima), Astro a menudo es una mejor opción. Envía cero JavaScript por defecto y admite múltiples frameworks de UI. Si necesitas la interactividad de React, enrutamiento dinámico, endpoints de API, autenticación, o una mezcla de contenido estático y dinámico, Next.js es el mejor ajuste. Trabajamos con ambos — consulta nuestra página de desarrollo de Astro para más sobre cuándo lo recomendamos.

¿Cuánto cuesta migrar de Gatsby a Next.js? Los costos de desarrollo típicamente varían de $15,000 para un sitio de marketing simple a $50,000+ para aplicaciones complejas con pipelines de datos personalizados, integración de comercio electrónico, o internacionalización. El costo depende fuertemente del número de plugins de Gatsby que necesiten reemplazo, la complejidad de tus consultas de GraphQL, y si quieres modernizar la arquitectura (añadiendo ISR, Server Components) durante la migración.

¿Next.js admite exportación estática como Gatsby? Sí. Ejecutar next build con output: 'export' en tu next.config.js genera un sitio completamente estático que se puede hospedar en cualquier lugar — S3, GitHub Pages, cualquier CDN. Pierdes ISR y características del lado del servidor, pero obtienes el mismo modelo de implementación que Gatsby. La mayoría de los equipos encuentran que no quieren puro estático una vez que experimentan los beneficios de ISR y Server Components, sin embargo.

¿Qué pasó con Gatsby Cloud? Gatsby Cloud se cerró en Q1 2024, aproximadamente un año después de la adquisición de Netlify. Los usuarios fueron migrados al hosting estándar de Netlify. Este fue un golpe significativo porque Gatsby Cloud proporcionaba compilaciones optimizadas, compilaciones incrementales, y funcionalidad de vista previa que estaban estrechamente acopladas con la arquitectura de Gatsby. Sin Gatsby Cloud, los tiempos de compilación en plataformas de CI/CD estándar son notablemente peores.