Hace tres años estaba en una llamada con un cliente en Toronto, viendo una compilación de Next.js avanzar lentamente en 94 segundos mientras ambos fingíamos estar bien con eso. Webpack. Ocho mil módulos. Un monorepo con componentes UI compartidos que nadie había auditado desde 2021. El cliente preguntó si podíamos "hacerlo más rápido". Presupuesté dos días de trabajo. Tomó cuatro. E incluso así lo redujimos a 61 segundos, lo que se sintió como ganar una carrera que nadie quería correr.
Turbopack cambió esa historia. Mayormente. Pero aquí en 2026, sigo viendo desarrolladores asumir que cambiar a Turbopack es una meta final en lugar de un punto de partida. Activan la opción, reducen 40% el tiempo de inicio del servidor de desarrollo, y lo dan por terminado. Los cuellos de botella reales simplemente se movieron a un lugar más silencioso.
Así que déjame mostrarte por dónde va realmente el tiempo de compilación cuando ejecutas Turbopack en un codebase de producción real. No una aplicación de tareas. No la plantilla de ejemplo de Next.js. Un sitio real con más de 200 rutas, integración con CMS, y un cliente que nota cada segundo.
La brecha entre modo desarrollo y compilaciones de producción
Aquí está lo que la mayoría de gente se pierde: las mayores victorias de Turbopack están en el servidor de desarrollo. Compilación incremental, caché a nivel de módulo, todo impulsado por Rust. En modo desarrollo, es genuinamente transformador. Cronometré un inicio en frío en un proyecto de cliente de Seahawk que pasó de 28 segundos bajo webpack a menos de 4 con Turbopack. Eso no es un error de redondeo.
Pero next build es un animal diferente. A partir de principios de 2026, el soporte de compilación de producción de Turbopack es estable pero no reescribe todo el pipeline. El análisis estático, la optimización de páginas y el compilador SWC siguen haciendo mucho trabajo junto al bundler de Turbopack. No estás obteniendo un 10x uniforme en la salida de producción.
Esto importa porque los desarrolladores miden la cosa equivocada. Ven next dev arrancar y concluyen que la compilación es rápida. Luego CI toma 3 minutos y se encogen de hombros.
Qué hace realmente la arquitectura de Turbopack
Turbopack opera en un modelo de computación impulsado por demanda. Compila solo lo que se solicita, cachea a nivel de módulo e invalida de forma precisa en lugar de amplia. Por eso el escrito sobre arquitectura del equipo de Vercel habla sobre "memoización a nivel de función". No es copia de marketing. Es el mecanismo real detrás de por qué tocar un componente no fuerza un re-bundle completo.
La implicación: tus ganancias más rápidas ocurren donde la invalidación era previamente demasiado amplia. Archivos de utilidad compartidos, grandes exportaciones barrel, re-exportaciones profundamente anidadas. Esos son los lugares donde Webpack te estaba castigando silenciosamente.
Por dónde desaparece realmente el tiempo en 2026
Audité cuatro codebases el trimestre pasado usando NEXT_TURBOPACK_TRACING=1. Sí, esa variable de entorno existe y sí, escupe un archivo de traza que puedes cargar en el panel de rendimiento de Chrome. Altamente recomendado antes de asumir que algo en particular es el culpable.
Aquí está lo que encontré, clasificado aproximadamente por qué tan a menudo aparecen:
- Explosiones de archivos barrel. Un único
index.tsre-exportando 60 componentes de un sistema de diseño tira cada uno de esos módulos al grafo incluso si usas dos. Turbopack maneja esto mejor que Webpack pero no hace que el problema desaparezca. La solución es importaciones granulares. Siempre. - Verificación de tipos no separada de la compilación. Ejecutar
tsc --noEmitdentro del mismo pipeline de compilación que Turbopack está procesando está duplicando tu tiempo real. Sepáralos. La verificación de tipos de TypeScript y la compilación de Turbopack deberían ser trabajos paralelos en CI, no pasos secuenciales. - IDs de módulo inestables en paquetes de terceros. Algunos paquetes npm siguen incluyendo CommonJS con requires dinámicos. Turbopack tiene que recurrir a rutas de análisis más lentas para estos. Me topé con esto el mes pasado con una versión antigua de una librería de generación de PDF. La actualicé, ahorré 8 segundos.
- Optimización de imágenes en el tiempo de compilación. Si estás pre-generando miles de variantes de imagen con
next/imagey una exportación estática, eso es síncrono y consume CPU. No es Turbopack. Pero aparece en el rastreo de compilación y la gente culpa al empaquetador. - Cargas grandes de datos en `getStaticProps`. Obtener 4MB de datos del CMS por página durante la compilación, en 300 páginas, es un problema de red y análisis. De nuevo, no es Turbopack. Pero está dentro del mismo tiempo de compilación de 180 segundos y se culpa colectivamente.
La verdad incómoda es que Turbopack aceleró la fase de empaquetamiento tanto que todo a su alrededor ahora se ve lento en comparación. Es como mejorar tu cubo de basura de la cocina para que se abra automáticamente y luego darte cuenta de que la caminata al contenedor afuera es el verdadero inconveniente.
El Problema de los Barrel Files Se Merece Su Propia Sección
No puedo estresarlo lo suficiente. Los barrel files son la herida de compilación más común que me inflige a sí misma en todas las agencias.
Un cliente vino a nosotros a fines de 2025 con una biblioteca de componentes que tenía esta estructura:
`` components/ index.ts (exports 140 named components) ``
Cada página importando incluso un botón jalaba el gráfico completo de 140 componentes. Con Webpack, tree-shaking ayudaba parcialmente en el tiempo de salida. Con Turbopack, el gráfico de módulos todavía tenía que ser recorrido y entendido antes de que nada pudiera ser podado. El servidor de desarrollo no era lento per se, pero los inicios en frío eran dolorosos.
Reestructuramos a importaciones específicas de ruta:
`` import { Button } from '@company/ui/button' import { Modal } from '@company/ui/modal' ``
El inicio en frío del dev bajó de 11 segundos a menos de 3. La compilación de producción bajó 22 segundos. Nadie tocó la configuración de Turbopack. La solución fue simplemente... no ser perezoso con las importaciones.
Hay una buena regla de eslint-plugin-import para detectar estos: import/no-barrel-files. Agrégala a tu configuración de lint y trata las violaciones como deuda de compilación.
Almacenamiento en Caché en CI: Probablemente Estés Dejando 40 Segundos Sobre la Mesa
El almacenamiento en caché local de Turbopack es excelente. El almacenamiento en caché de CI es un problema separado y la mayoría de los equipos lo configuran una vez y nunca lo revisan.
El caché de Turbopack vive en .next/cache/turbopack por defecto. Si tu pipeline de CI (GitHub Actions, CircleCI, lo que sea) no persiste ese directorio entre ejecuciones, estás haciendo una compilación completamente en frío cada vez. En una base de código de cualquier tamaño razonable, eso son 30 a 60 segundos de puro desperdicio por ejecución.
Así es como se ve una clave de caché adecuada para una configuración de Next.js + Turbopack en GitHub Actions:
- Clave de caché: hash de
package-lock.json+ hash denext.config.js+ hash detsconfig.json - Ruta de caché:
.next/cache - Claves de restauración: volver al caché anterior en la misma rama, luego main
Eso es todo. La mayoría de los equipos solo hacen hash de package-lock.json. Pero si tu next.config.js cambia la configuración de Turbopack (características experimentales, alias de módulos, cargadores personalizados), quieres que se invalide. He visto bugs donde un caché obsoleto estaba sirviendo resoluciones de módulos incorrectas después de un cambio de configuración. Desagradable de depurar a las 11pm.
Seahawk tenía un proyecto fintech donde simplemente arreglar la estructura de la clave de caché redujo la compilación de CI promedio de 4 minutos 20 segundos a 2 minutos 50 segundos. Mismo código. Mismo hardware. Solo invalidación de caché más inteligente.
Cargadores Personalizados y Por Qué Están Matando Tus Ganancias
Turbopack soporta cargadores personalizados, pero hay un costo. Cada cargador personalizado te saca del camino rápido nativo de Turbopack y te pone en una capa de compatibilidad. El equipo de Vercel es bastante honesto sobre esto en la documentación de configuración de Next.js Turbopack.
Veo esto más a menudo con:
- Cargadores SVG (personas convirtiendo SVGs a componentes React en tiempo de compilación)
- MDX con cadenas pesadas de plugins remark/rehype
- CSS Modules con configs PostCSS personalizadas que incluyen plugins raramente utilizados
Para SVGs específicamente, el movimiento en 2026 es precompilar tu librería de iconos a componentes React como un paso de compilación separado, no en el tiempo de compilación de Next.js. SVGR es excelente para esto como script independiente. Ejecútalo cuando cambien tus design tokens, commitea la salida, y deja que Turbopack los trate como archivos .tsx normales.
MDX es más complicado. Si ejecutas 40 plugins de remark, lo vas a sentir. Audita cuáles realmente necesitas. He visto bases de código ejecutando remark-gfm, remark-smartypants, un plugin personalizado de notas al pie, y dos más, donde solo dos de esos producían diferencias visibles en la salida. Elimina los no utilizados.
El Impuesto de Resolución de Módulos del que Nadie Habla
Alias de rutas. Todos los usan. @/components, @/lib, ~/utils. Son convenientes. También son un pequeño impuesto que se compone.
Turbopack resuelve alias en cada encuentro de importación. En una base de código grande con 4.000 importaciones y 12 alias configurados, eso son 48.000 operaciones de resolución por compilación. No es catastrófico. Pero tampoco es gratis.
La solución no es eliminar alias. Es ser preciso con ellos. Evita patrones de alias comodín donde una ruta específica funcionará. Y mantén tus rutas tsconfig.json sincronizadas con tu config resolveAlias de next.config.js. La divergencia entre estos dos hace que Turbopack haga trabajo redundante de resolución. He visto ahorros de 4-5 segundos solo limpiando esto.
Lo Que Turbopack 2026 Todavía No Hace
Mira, me gusta Turbopack. Lo usamos en la mayoría de proyectos nuevos de Seahawk. Pero la honestidad importa.
- El análisis de bundle no es tan maduro como el ecosistema de Webpack.
@next/bundle-analyzerfunciona pero la visualización es menos granular que lo que obtendrías dewebpack-bundle-analyzer. Esto está mejorando pero aún no está ahí. - El ecosistema de plugins es más pequeño. Si tu stack depende de plugins de Webpack altamente personalizados (algunos setups empresariales heredados lo hacen), la migración sigue siendo un proyecto real, no una tarde.
- El rendimiento en Windows históricamente ha quedado atrás de macOS y Linux. Esto está mejorando con cada release de Next.js, pero si tu equipo es pesado en Windows, benchmarkea antes de comprometerte.
Ninguno de estos son obstáculos. Pero son consideraciones reales si estás evaluando si migrar un proyecto existente versus comenzar desde cero.
Cómo Trazar Realmente Tu Compilación
Deja de adivinar. Ejecuta esto:
- Establece
NEXT_TURBOPACK_TRACING=1en tu entorno - Ejecuta
next build(onext devsi estás haciendo profiling del startup de dev) - Abre
.next/traceen Perfetto UI o enchrome://tracingde Chrome - Filtra por duración. Cualquier cosa mayor a 2 segundos en un módulo individual vale la pena investigar.
Este es el mismo enfoque que uso antes de cualquier compromiso de optimización de compilación. El trace te dice dónde va el tiempo. Todo lo demás es adivinar disfrazado de experiencia.
---
FAQ
¿Es Turbopack lo suficientemente estable para compilaciones de producción en 2026?
Sí, el soporte de compilación de producción llegó como estable a finales de 2024 y ha madurado significativamente a través de 2025. Para la mayoría de proyectos Next.js que comienzan desde cero, optaría por Turbopack sin dudarlo. Para proyectos heredados con personalización pesada de Webpack, haz un spike primero y mide.
¿Turbopack reemplaza SWC?
No. SWC es el transpilador de TypeScript y JSX. Turbopack es el empaquetador. Trabajan juntos. Turbopack usa SWC internamente para la transformación. No tienes que elegir entre ellos.
¿Por qué mi servidor de desarrollo Turbopack es rápido pero la compilación en CI sigue siendo lenta?
Casi seguro que es uno de estos: type-checking ejecutándose en serie con el empaquetado, sin caché de CI configurado para .next/cache, u optimización de imágenes dominando la fase de generación estática. Ejecuta el trace. Te mostrará cuál es.
¿Debería migrar un proyecto existente de Webpack a Turbopack ahora mismo?
Si es un proyecto greenfield o con poca personalización, sí. Si tienes 15 plugins de Webpack personalizados y una cadena de loaders compleja, presupuesta un sprint de migración adecuado. No lo hagas como una ocurrencia un viernes por la tarde. (Lo digo por experiencia personal. No preguntes sobre el viernes.)
¿Turbopack funciona con monorepos de Nx o Turborepo?
Sí, y bastante bien además. El caché de Turborepo se apila muy bien sobre el caché interno de Turbopack, y ambas herramientas comparten linaje del mismo equipo. La combinación es genuinamente buena para monorepos grandes donde solo un subconjunto de paquetes cambia por PR.
---
Las herramientas de compilación son aburridas hasta que tu factura de CI es de $800 al mes y tu equipo de desarrollo se queja de cold starts en la standup. Turbopack movió el cuello de botella, lo cual es progreso. Pero no eliminó la necesidad de pensar claramente sobre dónde va el tiempo. Trace primero. Optimiza segundo. Y por el amor de todo, arregla tus barrel files.