Tu pipeline de CI termina un build de Next.js y empuja a Vercel. Cuatro minutos después, tu deploy en preview se publica. Has aceptado este ritmo porque Webpack siempre ha sido lento a escala — hasta que Turbopack se convirtió en el bundler predeterminado en Next.js 16. Migramos tres apps de clientes desde Next.js 15 en marzo de 2025, persiguiendo esos tiempos de build menores a un minuto que prometían las notas de lanzamiento. Dos deploys se rompieron inmediatamente. Una integración de Sentry dejó de reportar. Un plugin de Webpack personalizado en el que habíamos confiado durante dos años no tenía equivalente en Turbopack. Pero las apps que sobrevivieron? Los tiempos de build bajaron de 3m 52s a 51 segundos, y un bundle particularmente complejo se encogió en 18%. Aquí está cada cambio que documentamos, los deltas de rendimiento que medimos, y la secuencia de migración que nos permitió hacer ship sin rollback.

Esto no es un resumen de las notas de lanzamiento. Esto es lo que realmente sucedió cuando ejecutamos next build con Turbopack en codebases reales con complejidad real.

Tabla de Contenidos

Next.js 16 Turbopack Production Builds: Qué Cambió y Cómo Migramos

Por Qué Next.js 16 Es Importante

Next.js 16 no es solo un bump de versión. Representa el cambio más significativo a la infraestructura de build desde que el framework se movió de pages al App Router. La feature titular es obvia: Turbopack reemplaza webpack como el bundler predeterminado para builds de desarrollo y producción.

Pero hay más. Next.js 16 también incluye:

  • React 19 como versión mínima soportada — sin más compatibilidad con React 18
  • Madurez mejorada en streaming y prerendering parcial
  • Nuevos defaults de caching que realmente tienen sentido (aprendieron del backlash de caching de Next.js 15)
  • APIs de request asincrónicas totalmente reforzadas — cookies(), headers(), y params ahora son async sin soporte legacy sincrónico
  • Requerimiento mínimo de Node.js 20 — el soporte para Node 18 se ha eliminado

Para agencias como la nuestra haciendo desarrollo Next.js, este es el tipo de lanzamiento que toca todo. No puedes simplemente bumpar un número de versión y llamarlo un día.

Qué Realmente Cambió con Turbopack en Producción

Vayamos al grano. Durante Next.js 14 y 15, Turbopack estaba disponible para next dev con la bandera --turbo. Los builds de producción aún usaban webpack. Next.js 15.3 introdujo una bandera experimental --turbopack para next build, y cuando 16 salió, se convirtió en el predeterminado.

Aquí está lo que es fundamentalmente diferente sobre cómo Turbopack maneja builds de producción en comparación con webpack:

Arquitectura de Compilación Incremental

Webpack procesa tu gráfico de dependencias completo en cada build. Turbopack usa un sistema de caching a nivel de función construido sobre el motor Turbo (escrito en Rust). En la práctica, esto significa que los builds subsecuentes solo recompilan lo que realmente cambió. Tu primer build podría no ser dramáticamente más rápido, pero tu segundo, tercero, y décimo builds lo serán.

Mejoras en Tree Shaking

El tree shaking de Turbopack opera a un nivel más granular que el de webpack. Notamos que nuestros bundles de cliente eran 8-15% más pequeños en promedio en nuestros tres proyectos sin cambios de código. Las mayores ganancias vinieron del manejo de archivos barrel — Turbopack es genuinamente mejor eliminando re-exportes no utilizados de archivos de índice.

Resolución de Módulos

Turbopack resuelve módulos diferente. Es más rápido, pero también es más estricto. Si tenías rutas de importación descuidadas que webpack estaba resolviendo silenciosamente (como extensiones de archivo faltantes en ciertos casos extremos, o rutas insensibles a mayúsculas en macOS que se rompen en Linux), Turbopack las atrapará. Esto causó aproximadamente el 30% de nuestros problemas de migración.

Estrategia de Code Splitting

El algoritmo de chunk splitting es nuevo. Turbopack crea más chunks, más pequeños por defecto. Esto generalmente mejora el rendimiento de carga para navegadores modernos con HTTP/2, pero puede aumentar el número total de requests. Vimos que los conteos de chunks aumentaban en aproximadamente 40% mientras que el tamaño total del bundle disminuía.

SWC Es Ahora Obligatorio

Si aún estabas aferrándote a cualquier configuración de Babel, se ha ido. Turbopack usa exclusivamente SWC para transformación. Esto ya era la dirección hacia la que las cosas iban, pero Next.js 16 elimina cualquier fallback a Babel completamente.

Benchmarks de Rendimiento de Build

Aquí están números reales de nuestros tres proyectos de migración. Estos no son benchmarks sintéticos — son de aplicaciones de cliente reales ejecutándose en nuestro pipeline de CI en GitHub Actions (Ubuntu, 4 vCPU, runners con 16GB RAM).

Métrica Proyecto A (E-commerce) Proyecto B (Dashboard SaaS) Proyecto C (Sitio de Contenido)
Páginas/Rutas 847 124 2,340
build webpack (Next 15) 4m 32s 1m 48s 6m 15s
build Turbopack (Next 16, frío) 3m 10s 1m 22s 4m 44s
build Turbopack (Next 16, cache cálido) 1m 05s 28s 1m 52s
cambio de tamaño de bundle -12% -8% -14%
JS First Load (homepage) -18KB -7KB -22KB
pico de memoria de build 3.8GB → 2.9GB 1.6GB → 1.2GB 4.2GB → 3.1GB

Los números de cache cálido son la verdadera historia. Una vez que Turbopack ha construido tu proyecto una vez, los builds incrementales son dramáticamente más rápidos. Para nuestro Proyecto C pesado en contenido (que usa un CMS headless con miles de páginas generadas estáticamente), ir de 6+ minutos a menos de 2 minutos en builds cacheados fue significativo. Eso es dinero real ahorrado en minutos de CI.

Las mejoras en el uso de memoria también fueron significativas. El Proyecto A ocasionalmente estaba alcanzando errores OOM en runners de CI más pequeños con webpack. Ese problema desapareció con Turbopack.

Next.js 16 Turbopack Production Builds: Qué Cambió y Cómo Migramos - arquitectura

Cambios Disruptivos Que Necesitas Conocer

Aquí está una lista corriente de todo lo que realmente se rompió durante nuestras migraciones. La guía de actualización de Next.js 16 cubre algunos de estos, pero algunos nos tomaron por sorpresa.

1. Configuración de Webpack Personalizada

Este es el grande. Si tienes una clave webpack en tu next.config.js, ya no funciona. Turbopack tiene su propia API de configuración bajo turbopack en la configuración de Next.js. No todo tiene un mapeo 1:1.

// next.config.js — ANTES (Next.js 15 con webpack)
module.exports = {
  webpack: (config) => {
    config.module.rules.push({
      test: /\.svg$/,
      use: ['@svgr/webpack'],
    });
    return config;
  },
};

// next.config.js — DESPUÉS (Next.js 16 con Turbopack)
module.exports = {
  turbopack: {
    rules: {
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
    },
  },
};

2. APIs de Request Sincrónicas Removidas

Next.js 15 deprecó el acceso sincrónico a cookies(), headers(), params, y searchParams. Next.js 16 los elimina completamente. Si ignoraste esas advertencias de deprecación, vas a tener un mal momento.

// ANTES — esto se cuelga en Next.js 16
export default function Page({ params }) {
  const { slug } = params;
  return <div>{slug}</div>;
}

// DESPUÉS
export default async function Page({ params }) {
  const { slug } = await params;
  return <div>{slug}</div>;
}

Esto parece trivial pero tocó más de 200 componentes en nuestros proyectos. Escribimos un codemod para manejar la mayoría (más sobre eso abajo).

3. React 18 Ya No Es Soportado

Next.js 16 requiere React 19. Si tienes dependencias fijadas a React 18, necesitan actualización. La mayoría de librerías bien mantenidas tenían soporte de React 19 a mediados de 2025, pero encontramos un par de rezagados.

4. Node.js 18 Descontinuado

El mínimo es Node.js 20. Actualiza tus imágenes Docker, configs de CI, y archivos .nvmrc.

5. Cambios en next/image

La prop onLoadingComplete se elimina completamente (fue deprecada desde Next.js 14). Usa onLoad en su lugar. El pipeline de optimización de imagen también usa una nueva librería subyacente, lo que significa que tus imágenes optimizadas cacheadas se regenerarán en el primer request.

Nuestro Proceso de Migración Paso a Paso

Aquí está el proceso real que seguimos. Hicimos el Proyecto B (el más pequeño) primero como una prueba, luego abordamos A y C.

Paso 1: Auditar Dependencias

Antes de tocar Next.js, auditamos cada dependencia para compatibilidad con React 19 y Node.js 20. Usamos un script simple:

npx npm-check-updates --target latest --filter '/react|next/'

También verificamos manualmente nuestros paquetes más críticos: nuestro SDK de CMS headless, librería de autenticación, y librería de componentes de UI.

Paso 2: Actualizar Node.js

Actualizamos nuestro .nvmrc a 20.18.0 (LTS más reciente en ese momento), actualizamos Dockerfiles, y verificamos runners de CI. Simple pero fácil de olvidar.

Paso 3: Actualizar React Primero

npm install react@19 react-dom@19 @types/react@19 @types/react-dom@19

Ejecutamos la suite de pruebas completa aquí antes de proceder. React 19 tiene sus propios cambios disruptivos (removió la necesidad de forwardRef, ref ahora es una prop regular, el hook use() es estable). Solucionamos esos problemas en aislamiento para no estar debuggeando problemas de React y Next.js simultáneamente.

Paso 4: Ejecutar el Codemod de Next.js

Next.js proporciona un codemod de actualización que maneja muchos de los cambios mecánicos:

npx @next/codemod@latest upgrade

Esto manejó aproximadamente el 70% de las migraciones de API async automáticamente. No es perfecto — tuvo dificultades con algunos de nuestros patrones de server component más complejos — pero nos ahorró horas.

Paso 5: Actualizar Next.js

npm install next@16

Paso 6: Migrar next.config.js

Este fue el paso más que consumió tiempo para el Proyecto A, que tenía una personalización de webpack significativa. Cubriré las traducciones específicas en la siguiente sección.

Paso 7: Arreglar Errores de Build Iterativamente

Ejecutamos next build y resolvimos errores uno por uno. Los mensajes de error de Turbopack son realmente mejores que los de webpack en la mayoría de casos — más específicos, con rutas de archivo más claras y sugerencias.

Paso 8: Testing de Regresión Visual

Usamos Playwright para tests E2E y ejecutamos nuestra suite de regresión visual para atrapar cualquier diferencia de renderizado. Encontramos dos problemas: una diferencia en el ordenamiento de CSS (Turbopack procesa importaciones de CSS en un orden ligeramente diferente que webpack) y un import dinámico que no se estaba dividiendo en código correctamente.

Paso 9: Validación de Rendimiento

Comparamos puntuaciones de Lighthouse y Core Web Vitals antes y después. Cada proyecto mejoró o se mantuvo neutral. Sin regresiones.

Traducciones de Configuración Webpack

Esta sección es para equipos con configuración de webpack personalizada. Aquí está cómo se traducen patrones comunes a Turbopack.

Loaders Personalizados

// Equivalente de Turbopack para loaders personalizados
module.exports = {
  turbopack: {
    rules: {
      '*.md': {
        loaders: ['raw-loader'],
        as: '*.js',
      },
      '*.graphql': {
        loaders: ['graphql-tag/loader'],
        as: '*.js',
      },
    },
  },
};

Module Aliases

// Resolve aliases funcionan similarmente
module.exports = {
  turbopack: {
    resolveAlias: {
      'old-package': 'new-package',
      // También puedes apuntar a archivos locales
      '@legacy/utils': './src/utils/legacy.ts',
    },
  },
};

Lo Que No Se Traduce

Algunos plugins de webpack simplemente no tienen equivalentes en Turbopack aún:

  • webpack.DefinePlugin — Usa env en next.config.js o variables de entorno directamente
  • BundleAnalyzerPlugin — El paquete @next/bundle-analyzer funciona con Turbopack a partir de v16, pero el formato de salida cambió
  • Custom chunk splitting via splitChunks — Turbopack maneja esto automáticamente y no expone el mismo nivel de control. Honestamente, los defaults son suficientemente buenos para la mayoría de proyectos.
  • webpack.IgnorePlugin — Usa resolveAlias para apuntar imports a módulos vacíos

Manejo de Paquetes de Terceros

Unos pocos paquetes causaron problemas durante la migración:

@sentry/nextjs — Necesitaba v9+ para compatibilidad con Turbopack. Las versiones anteriores estaban conectadas a internales de webpack. La actualización fue directa pero requirió cambios de config.

next-intl — Funcionó bien después de actualizar a la última versión. El plugin API se adaptó de forma limpia.

@vanilla-extract/next-plugin — Este fue nuestro dolor de cabeza más grande en el Proyecto B. El plugin de webpack de Vanilla Extract no tenía un equivalente en Turbopack hasta su release 2.0. Tuvimos que esperar a ese o considerar alternativas. Esperamos.

Paquetes de archivos barrel — Cualquier paquete que exporte cientos de componentes desde un archivo de índice único (mirándote a ti, librerías de íconos) ahora se tree-shaking mucho más agresivamente. Esto es algo bueno, pero vimos un caso donde un ícono dinámicamente referenciado no estaba siendo incluido. Cambiamos de lookups de íconos basados en strings a imports directos, que es mejor práctica de todas formas.

Consideraciones de CSS y Tailwind

Si estás usando Tailwind CSS (y la mayoría de nuestros proyectos lo hacen), la migración es mayormente sin dolor. Tailwind v4 funciona genial con Turbopack. Pero hay algunas cosas a tener en cuenta:

Ordenamiento de Importaciones de CSS

Turbopack procesa importaciones de CSS en un orden determinista pero diferente al de webpack. Si estás confiando en el orden de importación para especificidad (y no deberías estarlo, pero seamos honestos — todos terminamos allá a veces), podrías ver diferencias visuales. Tuvimos un proyecto donde un reset global estaba siendo anulado por un módulo CSS de componente porque el orden de importación se invirtió.

La solución fue el uso explícito de @layer en nuestro CSS, que deberíamos haber estado haciendo todo el tiempo.

CSS Modules

Los CSS Modules funcionan idénticamente. Sin cambios necesarios. Los nombres de clase generados se ven diferentes (más cortos, realmente), pero eso es cosmético a menos que estés haciendo algo raro como apuntar nombres de clase generados en tests.

PostCSS

Los archivos de config de PostCSS aún se respetan. Tu postcss.config.js continúa funcionando. Sin cambios necesarios aquí.

Actualizaciones de Deployment y Pipeline de CI

Nuestros objetivos de deployment son principalmente Vercel y AWS (vía SST/OpenNext). Aquí está lo que cambió:

Vercel: Detectó automáticamente Next.js 16 y usó Turbopack. La integración de build cache funciona fuera de la caja. Nuestros tiempos de build en Vercel bajaron incluso más dramáticamente que en CI local porque Vercel tiene integración profunda con la capa de caching de Turbopack. El Proyecto C pasó de ~8 minutos a ~2.5 minutos en Vercel.

AWS/OpenNext: Requirió actualizar a OpenNext 4.x, que agregó soporte de output de Turbopack. El formato de salida cambió ligeramente — la estructura del directorio .next se reorganizó — entonces cualquier script post-build que referenciara rutas de archivo específicas necesitaba actualización.

Docker builds: Si estás construyendo Next.js en Docker, actualiza tu imagen base a Node 20+ y sé consciente de que el directorio de cache de Turbopack (.next/cache/turbopack) debe ser incluido en tu estrategia de caching de capas Docker. Agregamos una capa específica de COPY para esto.

# Optimizar caching de capas Docker para Turbopack
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
# Mount de cache para Turbopack
RUN --mount=type=cache,target=/app/.next/cache \
    npm run build

Cuándo NO Deberías Migrar Aún

No quiero pintar esto como todo rosas. Hay razones legítimas para mantenerse en Next.js 15 por ahora:

  • Dependencia de plugin webpack pesado: Si tu build se basa en 3+ plugins de webpack personalizados que no tienen equivalentes en Turbopack, el costo de migración podría no valer la pena aún.
  • Monorepo con configuración compartida de webpack: Si estás compartiendo config de webpack en Next.js y proyectos que no son Next.js en un monorepo, dividir esa config es trabajo adicional.
  • Requerimientos de estabilidad: Next.js 16.0 es estable, pero 16.1 y 16.2 arreglaron bugs reales. Yo esperaría al menos 16.2+ antes de migrar algo en lo que no puedas tolerar downtime.
  • Dependencias legacy atascadas en React 18: Si una dependencia crítica no ha añadido soporte de React 19, estás bloqueado sin importar qué.

Para equipos haciendo desarrollo de headless CMS, la migración es generalmente más suave porque los sitios impulsados por CMS tienden a tener configuraciones de build más simples.

FAQ

¿Es Turbopack lo suficientemente estable para producción en Next.js 16?

Sí. Turbopack ha estado en desarrollo durante más de tres años, fue ampliamente probado en modo dev en millones de proyectos Next.js, y pasó por una beta extendida en builds de producción durante Next.js 15.3-15.5. Hemos estado ejecutándolo en producción desde el lanzamiento de 16.0 en múltiples sitios de cliente sin problemas relacionados con bundler. Dicho esto, si estás en 16.0 específicamente, actualiza a 16.2+ donde se resolvieron varios bugs de caso extremo.

¿Puedo aún usar webpack con Next.js 16?

No como el bundler principal. Turbopack es el único bundler soportado en Next.js 16. Si absolutamente necesitas webpack, necesitarás mantenerte en Next.js 15, que recibirá parches de seguridad hasta principios de 2026. Vercel ha sido claro que el soporte de webpack en Next.js está hecho.

¿Cuánto más rápido es Turbopack en comparación a webpack para builds de producción?

En builds fríos (sin cache), vimos mejoras de 20-30%. En builds cálidos/cacheados, la mejora salta a 50-70%. Los números exactos dependen fuertemente del tamaño del proyecto, número de rutas, y la cantidad de generación estática que sucede. El uso de memoria también bajó 20-30% consistentemente en nuestros proyectos.

¿Necesito reescribir mi next.config.js para Turbopack?

Si tienes configuración custom de webpack en tu next.config.js, sí — esos bloques necesitan ser traducidos al formato de configuración turbopack. Si solo estás usando opciones estándar de configuración de Next.js (imágenes, redirects, rewrites, variables de env), todas funcionan exactamente igual. El esfuerzo de migración es proporcional a cuánta configuración webpack personalizada tengas.

¿Funcionará mi pipeline de CI/CD existente con Next.js 16?

Mayormente sí. Las cosas principales a actualizar son: versión de Node.js (mínimo 20), cualquier script que referencie archivos de salida específicos de webpack, y cualquier estrategia de caching que apunte a .next/cache/webpack. Querrás cachear .next/cache/turbopack en su lugar. Si estás desplegando a Vercel, todo se maneja automáticamente.

¿Turbopack soporta todas las mismas features que webpack en Next.js?

Para features específicas de Next.js, sí — App Router, Pages Router, rutas API, middleware, ISR, SSG, SSR todos funcionan. Para configuración personalizada de webpack, hay aproximadamente 90% de paridad de features. Las brechas restantes son principalmente alrededor de plugins de webpack de nicho y estrategias de chunk splitting altamente personalizadas. Chequea los docs de compatibilidad de Turbopack para tu caso de uso específico.

¿Debería migrar a Next.js 16 o considerar alternativas como Astro?

Depende de tu caso de uso. Si estás construyendo aplicaciones altamente interactivas con gestión de estado compleja, Next.js 16 es una opción fuerte y las mejoras de Turbopack hacen el DX significativamente mejor. Si estás construyendo sitios pesados en contenido con interactividad mínima, Astro sigue siendo una excelente alternativa con su modelo de hidratación parcial. Hemos estado construyendo con ambos y eligiendo basado en requerimientos del proyecto. Si no estás seguro, contáctanos y podemos ayudarte a evaluar.

¿Cuál es el tiempo mínimo necesario para migrar una app mediana de Next.js 15 a 16?

Para una aplicación mediana típica (50-200 rutas, dependencias estándar, configuración webpack mínima), presupuesta 2-4 días de tiempo de desarrollador. Eso incluye actualizaciones de dependencia, migraciones de API async, testing, y verificación de deployment. Si tienes configuración de webpack extensiva o dependencias legacy, podría tomar una semana o más. Nuestro equipo en Social Animal ofrece servicios de migración si prefieres no quemar el sprint de tu equipo en trabajo de infraestructura.