Next.js 16.3 y Turbopack: build y memoria dev, la verdad

Next.js 16.3 con Turbopack cambia dos cosas reales para una app en producción: acelera la compilación incremental en desarrollo mediante una caché a nivel de función (no de módulo, como hacía Webpack), y estabiliza `next build --turbopack` como alternativa de producción. Lo que no cambia automáticamente es la memoria RAM que consume tu servidor en producción: esa memoria depende de tu código y tu runtime, no del bundler que empaquetó los archivos.

Turbopack no es una versión más rápida de Webpack: es un motor de compilación distinto, escrito en Rust, construido sobre lo que Vercel llama Turbo Engine, un sistema de computación incremental que memoriza el resultado de cada función de compilación (parseo, resolución de módulos, transformación) y solo recalcula lo que cambió. Webpack, en cambio, razona en términos de grafo de módulos: cuando cambias un archivo, recompone el subárbol de dependencias afectado, pero la granularidad es el fichero completo, no la operación interna. Esa diferencia de diseño explica por qué el Fast Refresh de Turbopack se nota especialmente en proyectos grandes, con cientos de rutas y componentes compartidos, y por qué en proyectos pequeños la diferencia es casi imperceptible. Next.js 15 estabilizó Turbopack para `next dev` en octubre de 2024; la serie 16.x empuja esa misma arquitectura hacia el build de producción, hasta ahora dominio exclusivo de Webpack. No es un simple flag nuevo: es un cambio de motor que toca resolución de alias, loaders, y cómo se invalida caché entre commits.

El mecanismo que nadie explica: caché a nivel de función

La pieza que casi ningún artículo cuenta es que la caché de Turbopack vive a nivel de función individual dentro del propio compilador, no a nivel de archivo de salida. Cuando guardas un cambio, Turbopack no pregunta '¿qué módulos dependen de este archivo?' sino '¿qué funciones de compilación tenían este archivo como input?', y solo re-ejecuta esas funciones concretas, reutilizando el resto del árbol de cómputo tal cual estaba. Esto tiene una consecuencia práctica que sí importa en producción: si cambias una dependencia en el lockfile, buena parte de ese árbol de funciones memorizadas deja de ser válido de golpe, y el siguiente build se comporta como si partiera de cero, sin el beneficio incremental que ves en el día a día. Los equipos que actualizan dependencias con frecuencia en su pipeline de CI notan esto rápido: la promesa de build incremental rápido se cumple entre commits normales, pero no sobrevive a un `npm update` grande. Vale la pena diseñar la estrategia de caché de CI sabiendo esto, en lugar de asumir que el build siempre será igual de rápido.

Durante Next.js 13 y 14, Turbopack era una opción experimental limitada al servidor de desarrollo; usarlo en build de producción no era una opción soportada. Next.js 15, en octubre de 2024, marcó `next dev --turbopack` como estable, y desde entonces cada versión menor ha ido cerrando la brecha de compatibilidad con el ecosistema de plugins y loaders de Webpack. La serie 16.x continúa ese camino con `next build --turbopack` madurando hacia estable, pero "madurando" es la palabra clave: no todos los proyectos con configuración de Webpack personalizada migran sin fricción, y el propio equipo de Next.js sigue documentando incompatibilidades caso por caso en cada release. Antes de activarlo en el pipeline de producción de un cliente, lo probamos primero en un build de staging con el `next.config.js` real, no con un proyecto de ejemplo limpio, porque ahí es donde aparecen los loaders y plugins que realmente rompen algo.

Aquí está el malentendido más caro que vemos repetirse: equipos que migran a Turbopack esperando que su servidor de producción consuma menos memoria, y se llevan una sorpresa cuando el uso de RAM en el contenedor no baja ni un megabyte. Turbopack ataca la memoria y velocidad del proceso del compilador —el proceso de Node que corre mientras desarrollas o mientras haces `next build`—, no la memoria del servidor Next.js que sirve tráfico real una vez desplegado. El bundle final que sirve tu aplicación en producción sigue siendo, en esencia, el mismo tipo de código JavaScript ejecutándose en el mismo runtime Node o Edge; el bundler que lo generó no cambia cuánta memoria retiene tu store de estado, tus conexiones de base de datos o tus imports pesados en tiempo de ejecución. La mejora real de memoria ocurre durante el desarrollo: en proyectos grandes con Webpack era habitual ver el proceso `next dev` crecer en memoria residente a medida que se acumulaban recompilaciones en una sesión larga, obligando a reiniciar el servidor cada cierto tiempo. La caché persistente de Turbopack en disco reduce esa acumulación porque no todo vive en la memoria del proceso Node mientras dura la sesión.

• Sí cambia: tiempo de arranque de `next dev` y del Fast Refresh en proyectos grandes
• Sí cambia: memoria residente del proceso de desarrollo en sesiones largas, gracias a la caché persistente en disco
• Sí cambia: tiempo de build en CI si tu pipeline reutiliza caché entre commits (no entre cambios de dependencias)
• No cambia: la memoria RAM del servidor Next.js sirviendo tráfico en producción
• No cambia: el tamaño del bundle de forma automática — sigue dependiendo de tu código y tus imports
• No cambia: el comportamiento en runtime — Turbopack compila, no reescribe tu lógica de negocio

Dónde sí notarás menos memoria

No siempre recomendamos migrar ya, y lo decimos aunque suene contraintuitivo viniendo de una consultora que vive de proyectos de desarrollo. Si tu proyecto es pequeño o mediano, sin configuración de Webpack personalizada compleja, y tu pipeline de CI ya es razonablemente rápido, el salto a Turbopack en build de producción probablemente te ahorre minutos que no estabas perdiendo dinero por perder. Donde sí vemos retorno claro es en monorepos grandes con decenas de apps o paquetes compartidos, equipos donde el tiempo de espera del Fast Refresh se ha convertido en una queja recurrente en retrospectivas, o pipelines de CI donde el build es el cuello de botella documentado del despliegue. Migrar sin haber corrido antes un build de staging completo, con las mismas dependencias y el mismo `next.config.js` de producción, es la forma más común de descubrir tarde una incompatibilidad de loader que bloquea un despliegue. La regla que aplicamos internamente es simple: si no puedes nombrar qué problema concreto te resuelve Turbopack en tu caso, probablemente no es la prioridad de esta semana.

• Ejecutar `next build --turbopack` en una rama de staging con el `next.config.js` real de producción, no una config limpia de ejemplo
• Auditar si existe función `webpack()` personalizada en el config y migrar sus reglas a `turbopack.rules` / `turbopack.resolveAlias`
• Revisar loaders y plugins de terceros (SVGR, CSS-in-JS, transformaciones custom) uno a uno contra la compatibilidad de Turbopack
• Medir el tiempo de build actual en CI como línea base antes de migrar, para comparar con datos reales y no con expectativas
• Probar el build en un entorno con las mismas dependencias que producción, incluyendo un lockfile actualizado, para validar el caso de invalidación de caché
• No asumir que la memoria del servidor de producción bajará: monitorizarla igual que antes tras el despliegue