Next.js 16.3 y Turbopack: de 21,5 GB a 2 GB de memoria en desarrollo

Hay una cifra que resume mejor que cualquier benchmark por qué Next.js 16.3 merece una actualización: 21,5 GB de RAM en el servidor de desarrollo. Eso es lo que consumía el dashboard de vercel.com después de compilar 50 rutas con Turbopack. Con la versión publicada el 3 de agosto de 2026, ese mismo escenario baja a unos 2 GB, alrededor de un 90 % menos.

No es un caso aislado. nextjs.org pasó de 4.600 MB a 840 MB, un 82 % menos. Y todo ello sin tocar una línea de configuración, porque las dos palancas principales vienen activadas por defecto.

En este artículo explico de dónde salía ese consumo, qué hace exactamente Turbopack para reducirlo, cómo se configura si necesitas afinar el comportamiento y qué otras mejoras trae la versión. También los avisos que pueden hacer que la ganancia desaparezca en tu entorno.

Por qué el servidor de desarrollo se comía la RAM

Un servidor de desarrollo no es solo un compilador. Mantiene un grafo de módulos, los resultados de las transformaciones, el estado del HMR y una parte importante del output en memoria para responder rápido. Cuanto más grande es la aplicación y más rutas se han visitado, más crece ese estado.

El modelo de Turbopack, basado en compilación incremental, tiende a retener todo lo que ha calculado: si un módulo puede volver a necesitarse, ¿para qué tirarlo? En aplicaciones pequeñas eso es irrelevante. En un dashboard con decenas de rutas, cientos de componentes y librerías pesadas, se convierte en un proceso que se acerca a los 20 GB y obliga a reiniciar el portátil cada pocas horas.

La clave de 16.3 es que ese estado deja de ser intocable. Se puede desalojar lo que ya no se usa y persistir en disco lo que sí conviene conservar entre arranques.

Desalojo de memoria: soltar lo que ya no hace falta

La opción turbopackMemoryEviction controla cuándo Turbopack libera memoria del grafo en ejecución. En 16.3 su valor por defecto es 'auto', y solo actúa en next dev.

El modo 'auto' es el que produce la mejora del 90 % sin intervención. El modo 'full' puede interesar en máquinas con muy poca RAM, a costa de reconstrucciones más lentas tras cada cambio. Y false es una herramienta de diagnóstico, no una configuración de producción.

Un detalle importante: el desalojo de memoria requiere la caché de sistema de ficheros activa. Si la desactivas, no hay nada a lo que recurrir cuando se libera memoria, y la opción deja de tener sentido.

Caché de sistema de ficheros: también en las builds

La otra mitad de la ecuación es la caché en disco. En 16.3 hay dos flags independientes, y ambos vienen activados por defecto:

Que la caché de build esté activa por defecto es la novedad más rentable para CI y para builds locales repetidas. Los números que publicó Vercel:

La horquilla es amplia y depende de cuánto del grafo se reutilice. El caso de geist, con 5,5 veces menos tiempo, muestra el techo; el 1,4× de la home muestra que en aplicaciones con mucha invalidación la ganancia es más modesta.

La configuración exacta

Lo primero que hay que entender: en 16.3 no necesitas añadir nada para obtener la reducción de memoria. Los valores por defecto ya son los agresivos. Esta configuración solo es útil si quieres dejarlo explícito o ajustar los límites:

// next.config.ts
import type { NextConfig } from 'next';

const nextConfig: NextConfig = {
  experimental: {
    // Ya activos por defecto en 16.3 — explícitos solo por claridad
    turbopackFileSystemCacheForDev: true,
    turbopackFileSystemCacheForBuild: true,
    turbopackMemoryEviction: 'auto', // false | 'auto' | 'full'

    // GC del cache persistente (experimental; requiere FS cache)
    turbopackGc: {
      minProgressMs: 100,
      rootTtlMs: 259200000, // 3 días, valor por defecto
    },
  },
};

export default nextConfig;

turbopackGc es la pieza menos conocida. Está en false por defecto, es experimental y limpia entradas antiguas de la caché persistente. Sus dos parámetros son:

• minProgressMs (por defecto 100): tiempo mínimo de progreso antes de recolectar.
• rootTtlMs (por defecto 259200000, es decir, 3 días): vida máxima de una raíz de caché.

Si tu caché de disco crece sin control en un monorepo grande, tiene sentido activarlo con un TTL más corto, por ejemplo un día. Si no, déjalo desactivado: no aporta nada mientras el tamaño sea razonable.

Para depurar un problema de rendimiento y descartar que el desalojo esté afectando a tus medidas, puedes desactivarlo temporalmente:

const nextConfig = {
  experimental: {
    turbopackMemoryEviction: false, // default es 'auto'
  },
};

React Compiler en Rust: menos tiempo hasta la primera página

16.3 incorpora una versión experimental del React Compiler escrita en Rust y ejecutada dentro de Turbopack. Las cifras que acompañan al anuncio son un 34 % menos en frío y un 46 % menos en caliente hasta que la página está lista.

Se activa con dos flags:

// next.config.ts
const nextConfig = {
  reactCompiler: true,
  experimental: {
    turbopackRustReactCompiler: true,
  },
};

Ahora la advertencia importante: React Compiler sigue siendo experimental. No es una bala de plata y no debería entrar en producción sin medir. La ganancia además asume que has salido de Babel; si mantienes Babel para otros transforms, el beneficio es menor. Si tu proyecto ya está limpio de Babel, es la mejora más interesante de la versión después de la memoria.

Cache Components e Instant Navigation

cacheComponents y partialPrefetching son la apuesta de Next.js por una navegación con sensación de SPA sin renunciar al modelo de servidor. La combinación permite que los enlaces precarguen solo lo necesario y que la transición ocurra sin esperas perceptibles.

const nextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
};

El modelo se apoya en la directiva 'use cache' para marcar qué partes del árbol se pueden cachear y durante cuánto tiempo. Es un cambio mental más que un flag: obliga a pensar en la granularidad de la caché y en la invalidación.

Dos matices. Primero, es opt-in en 16.3. Segundo, su comportamiento será el valor por defecto en una futura versión major, así que migrar ahora reduce trabajo futuro. Si tienes una aplicación grande con datos en tiempo real, empieza por una sección acotada y mide antes de extenderlo.

Otras mejoras que vienen incluidas

No todo es memoria. 16.3 añade varias piezas que se agradecen en el día a día:

• TypeScript 7 en next build: el type-check pasa a usar el compilador nativo, con la mejora de velocidad que eso implica. Se adopta instalando la dependencia (pnpm add -D typescript@^7).
• SSR con streams nativos de Node.js: hasta un 22 % más de requests bajo carga, sin cambios en tu código.
• import.meta.glob: compatibilidad con la API de Vite para importar ficheros por patrón, con HMR incluido.
• Root params: acceso a parámetros de layout raíz sin prop-drilling.

Un ejemplo de import.meta.glob:

// app/blog/page.tsx
import matter from 'gray-matter';

export default function Page() {
  // .md necesita un loader registrado en next.config.js
  const posts = import.meta.glob('./posts/*.md', { eager: true });
  return (
    <ul>
      {Object.entries(posts).map(([path, mod]) => {
        const { data } = matter(mod.default);
        return <li key={path}>{data.title}</li>;
      })}
    </ul>
  );
}

Y root params, que evita pasar el idioma por toda la jerarquía de componentes:

// app/[lang]/posts/[slug]/page.tsx
import { lang } from 'next/root-params';

export default async function PostPage(props: PageProps<'/[lang]/posts/[slug]'>) {
  const { slug } = await props.params;
  const language = await lang();
  return <article><p>{language}</p><p>{slug}</p></article>;
}

Lo que puede arruinar la ganancia

Hay cuatro trampas que he visto en entornos reales y que conviene revisar antes de dar por hecho el 90 %:

1. La caché de build vive en .next/cache. Si tu pipeline arranca contenedores desde una capa limpia y no preserva ese directorio, no habrá ganancia. Monta un volumen o cachea el directorio entre ejecuciones. Si no puedes, desactiva turbopackFileSystemCacheForBuild para no pagar el coste de escribir una caché que nadie va a leer.
2. turbopackMemoryEviction solo actúa en next dev. No esperes que reduzca la memoria de next build ni la del proceso en producción.
3. turbopackGc requiere la caché de sistema de ficheros. Sin ella, la opción no tiene efecto.
4. React Compiler en Rust asume que has salido de Babel. Si sigues usándolo para otros transforms, mide antes de atribuirle la mejora.

A esto se suma un quinto punto más conceptual: Cache Components cambia el modelo de datos. No es un flag que se pone y se olvida; requiere revisar qué se cachea, durante cuánto tiempo y cómo se invalida.

Qué significa para este sitio

Este blog sigue en Next.js 15, así que la migración a 16.3 es el siguiente paso natural. El interés no está solo en la memoria del portátil: la caché de build por defecto y TypeScript 7 en el type-check reducen el tiempo de CI, que es donde más se nota en un proyecto pequeño.

Si estás en una situación parecida, el orden que recomiendo es: primero actualizar y medir sin tocar configuración; después activar React Compiler en una rama y comparar; y dejar Cache Components para una migración aparte, con su propia revisión. Si vienes del modelo de componentes de servidor, el artículo sobre cómo usar React Server Components en Next.js 15 te da el contexto que Cache Components asume.

Conclusión

Next.js 16.3 no vende una gran novedad, sino algo más aburrido y más valioso: que el entorno de desarrollo deje de ser el proceso más hambriento de tu máquina. Pasar de 21,5 GB a 2 GB no es una optimización marginal; es la diferencia entre poder trabajar y reiniciar el editor cada dos horas.

La buena noticia es que la mayor parte de la mejora es gratuita: el desalojo de memoria y las dos cachés en disco vienen activados. La parte que requiere criterio es la experimental —React Compiler en Rust, Cache Components— y ahí conviene medir antes de confiar. Como siempre en rendimiento, la cifra del anuncio es el punto de partida, no tu resultado.

Artículos relacionados

• Cómo usar React Server Components en Next.js 15 — La base del modelo que Cache Components amplía
• Server Actions en Next.js 15: guía práctica — Mutaciones sin API routes y su relación con la caché

Artículo escrito por Roberto Serrano — Desarrollador web, automatizaciones e IA en Tarragona, España.