Chunking de Turbopack en Next.js 16.3: cómo ajustar el dilema entre la primera carga y la navegación

El 3 de septiembre de 2026, el equipo de Next.js publicó exactamente cómo decide Turbopack qué JavaScript va en cada chunk — y estrenó los primeros controles que te permiten cambiar esa decisión por sitio. El chunking es el proceso de dividir el código de tu aplicación en los archivos que descarga el navegador. Hay dos objetivos que se pelean entre sí: quieres la menor cantidad posible de peticiones y quieres enviar la menor cantidad posible de código. Pocos chunks grandes ganan en la primera carga pero se vuelven a descargar en la navegación; muchos chunks pequeños reutilizan más caché pero suman overhead de peticiones. En Next.js 16.3, opciones experimentales como firstPageLoadPriority, priorityRoutes, clusters y generateComponentChunks te permiten inclinar esa balanza según cómo se mueve tu audiencia. Este artículo explica el dilema con los números del benchmark oficial y te da un marco de decisión para ajustarlo — el mismo que usamos cuando auditamos aplicaciones Next.js en producción.

La paradoja del chunking: menos peticiones o menos código

Abre la pestaña de red de casi cualquier sitio Next.js y verás una pila de archivos con nombres como 36wnellv-yn9q.js. Eso es la salida de Turbopack. Lo interesante es cómo decide armarlos, porque los extremos están mal en ambos sentidos.

Si metes todos tus módulos en un solo chunk, cada página carga 1.09 MB de JavaScript aunque no use casi nada. La primera carga tras una visita es un cache hit y la navegación es rápida — pero cada primera carga siguiente pesa más a medida que el sitio crece. Si le das a cada módulo su propio chunk, nada se envía de más y el código compartido se descarga una sola vez, pero una app grande se convierte en cientos de peticiones diminutas, cada una con su overhead de red, y la compresión funciona peor con muchos archivos pequeños porque los patrones repetidos viven en archivos separados.

La respuesta de Turbopack es fusionar chunks pequeños en otros más grandes, y solo fusionar los que pertenecen al mismo chunk group — el conjunto de chunks que carga una ruta. Fusionar dentro de un grupo no añade nada que la página no fuera a descargar igualmente, así que es seguro en una visita simple. El problema es la navegación: cuando un visitante pasa de una página que necesita el chunk A a una que necesita A y B, el archivo fusionado A+B obliga al navegador a volver a descargar A. En una sesión que empieza en la home y termina en una página legal, el visitante descarga A dos veces. La fusión solo paga a través de una navegación cuando ambas páginas necesitan ambos chunks.

El equipo midió las tres estrategias en nextjs.org, repitiendo la misma serie de cargas y contando peticiones y JavaScript transferido:

Los valores por defecto reducen las peticiones a menos de la mitad frente a no fusionar y además envían menos código en total. La fusión máxima deja la primera carga más liviana pero envía alrededor de un 10% más de código en toda la sesión. En otras palabras: la respuesta correcta depende de si tus usuarios ven una página y se van, o navegan varias. Y esa es justo la suposición que las nuevas opciones te dejan cambiar.

Qué hay de nuevo en Next.js 16.3

Turbopack fusiona en tiempo de build, antes de que alguien visite, así que no puede reaccionar a lo que el navegador ya tiene en caché, y tiene que adivinar cómo se mueve la gente por el sitio — la estimación por defecto es que dos tercios de las sesiones son de una sola página. El post del 3 de septiembre y su documentación añaden cuatro cosas, todas experimentales bajo next.config.js:

1. Fetch de chunks más inteligente con generateComponentChunks. Al activarlo, Turbopack emite los chunks de componentes sin fusionar junto a los fusionados, y registra qué módulos ya están cargados. En tiempo de petición, el runtime elige lo más barato: el chunk fusionado o solo las piezas que faltan. El problema de "descargar A dos veces" desaparece en las navegaciones suaves — obtienes los beneficios de la fusión sin su costo en navegación.

2. Chunking basado en analítica con firstPageLoadPriority, priorityRoutes y clusters. firstPageLoadPriority (0 a 1, por defecto 0.67) desplaza el peso entre sesiones de una página y de varias; el equipo sugiere partir de tu tasa de rebote. priorityRoutes es una lista de rutas cuya velocidad de carga importa más, que se fusionan con más agresividad. clusters agrupa rutas que se visitan juntas como arreglos de expresiones regulares, de modo que Turbopack fusiona mejor los chunks solapados dentro del clúster.

3. Tree-shaking para CommonJS. experimental.turbopackCjsTreeShaking elimina imports y exports sin usar en módulos CJS, que antes llegaban al cliente porque solo se analizaba ESM. Será el valor por defecto en una versión futura.

4. Un runtime compartido y más liviano. experimental.turbopackSharedRuntime reemplaza los runtimes por página con un solo chunk compartido, ahorrando una petición bloqueante y unos 10 KB de JavaScript en cada navegación posterior a la primera. Por separado, el runtime por defecto ya no envía código WebAssembly ni Web Worker salvo que realmente uses esos módulos.

Si prefieres ajustar los umbrales de tamaño en vez del comportamiento, la documentación expone minChunkSize (por defecto 50,000 bytes de código sin comprimir), maxChunkCountPerGroup (40), maxMergeChunkSize (200,000) y minComponentChunkSize (20,000). Ojo: son bytes de código sin comprimir ni minificar — más o menos 5 veces lo que realmente viaja por la red.

Un marco de decisión para tu sitio

Aquí es donde la mayoría de artículos se detienen y empieza el trabajo real. Los valores por defecto están afinados para un sitio de contenido típico, así que "no toques nada" es una recomendación válida para muchos proyectos — pero no para todos. Este es el marco que usamos:

La regla de fondo: sube firstPageLoadPriority cuando te importe la primera pantalla, bájalo cuando te importe el recorrido. Una landing de campaña con 60% de rebote quiere el primer render más rápido posible. Un dashboard SaaS donde el usuario hace clic por 15 vistas en una sesión quiere reutilizar caché en cada transición — ahí es donde generateComponentChunks y el runtime compartido se pagan solos.

Dónde hemos sentido el costo de la navegación en producción

Este dilema no es teórico para nosotros. En las apps Next.js que auditamos, el dolor casi nunca aparece en la landing — aparece en el Interaction to Next Paint (INP) durante la navegación, que es justo la métrica que controla la decisión de chunking. En proyectos tipo portal, los peores picos están en las transiciones entre módulos, donde el navegador se queda esperando JavaScript que en realidad ya tenía, solo que partido en archivos que no pudo reutilizar. Ese es el escenario exacto para el que nació generateComponentChunks, y también es la razón por la que ahora tratamos la configuración de chunking como una decisión por proyecto y no como un default global. Nuestro flujo de depuración de INP en sitios interactivos trata las transiciones como ciudadanos de primera clase: medir, reproducir, y cambiar una sola cosa a la vez.

También conviene recordar por qué movimos mintec.co de Next.js a Astro en Cloudflare Pages — los números de la migración mostraron 94% menos JavaScript en páginas de contenido, y nuestros benchmarks reales comparando ambos frameworks confirman que en sitios de contenido, enviar casi nada de JS de cliente le gana a afinar cómo lo envías. Pero para experiencias de verdad tipo aplicación — portales autenticados, e-commerce interactivo, herramientas internas — Next.js sigue siendo la decisión correcta, y el chunking es ahora la palanca que tiras en vez de cambiar de framework. Nuestra lectura: estos controles hacen a Next.js más competitivo justo en el territorio donde su estrategia de bundle por defecto solía doler.

Cómo medir antes de cambiar nada

Las opciones son experimentales, así que pruébalas en una rama y mide con datos reales:

1. Saca tu tasa de rebote real y la proporción de sesiones multipágina de tu analítica. Ese es tu punto de partida para firstPageLoadPriority, no una corazonada.
2. Mide los dos lados del dilema: LCP de campo (primera carga) e INP de campo (navegación) en CrUX o una herramienta de laboratorio. En páginas con mucho media o dashboards, nuestro enfoque de presupuesto de rendimiento te da los umbrales a los que apuntar.
3. Cambia una opción a la vez y repite el mismo camino de navegación. Los números de nextjs.org de arriba son un sanity check, no tu objetivo — tu grafo de módulos y tu tráfico son distintos.
4. Vigila el total transferido en una sesión completa, no solo la primera página. La fusión máxima se ve espectacular en la primera pantalla y te cuesta después, exactamente como muestra la tabla.

Los controles de chunking no van a arreglar un sitio que envía un heap de terceros de 400 KB o que se bloquea con un hero enorme — esos son problemas aparte (y conversaciones de otro nivel de optimización). Pero cierran una brecha real: por primera vez puedes decirle al bundler cómo navega tu audiencia, en vez de aceptar una suposición global. Es un cambio de config pequeño con un retorno real en Core Web Vitals — y es de las palancas que conviene tirar antes de plantearse una migración de framework.