Si tu proyecto usa Next.js 14 o 15 y no miraste qué pasó en los últimos meses, hay bastante que procesar. Next.js 16 salió en octubre de 2025 y trajo cambios de fondo en el sistema de bundling, el compilador de React y el modelo de caché. El 16.3 llegó a stable el 3 de agosto de 2026 con un rediseño completo del sistema de navegación. Ambas versiones tienen breaking changes y funcionalidades nuevas que vale entender antes de actualizar en producción.

Este post recorre todo lo que cambió, qué está disponible por defecto, qué requiere activación manual y cuándo conviene esperar.

Turbopack es el default desde Next.js 16

Lo más significativo de la versión 16 no fue ninguna feature nueva sino la salida de Webpack. Turbopack, el bundler escrito en Rust que Vercel venía desarrollando desde 2022, pasó a ser el default estable para desarrollo y producción.

No requiere configuración. Actualizás, corrés next dev y ya estás usando Turbopack. Los números que reportan proyectos reales son considerables: builds de producción que tardaban 24.5 segundos bajaron a 5.7 segundos. Fast Refresh es hasta 10 veces más rápido. Algunos proyectos en sesiones largas de desarrollo llegaban a usar 21.5 GB de memoria con versiones anteriores; Next.js 16.3 redujo el uso de memoria del servidor de desarrollo hasta un 90%.

Si tenés una configuración personalizada de Webpack, todavía podés usarla con el flag --webpack:

next dev --webpack
next build --webpack

Eso te da tiempo para migrar sin bloquear el proyecto. Pero conviene hacerlo, ya que Webpack no va a recibir mejoras en versiones futuras de Next.js y el soporte es de mantenimiento.

React Compiler, qué hace y cuándo importa

Next.js 16 incluyó soporte estable para el React Compiler. Lo que hace el compilador es analizar el árbol de componentes y agregar memoización automática donde detecta que un valor o componente no necesita recalcularse. En práctica, elimina la mayoría de los useMemo, useCallback y memo manuales.

Lo que no hace es arreglar código mal escrito. Si un componente tiene side effects que deberían estar en un useEffect pero están sueltos en el render, el compilador no lo compensa. Y si tu app ya tiene muy buena disciplina de memoización manual, la diferencia perceptible puede ser mínima.

Para proyectos nuevos tiene sentido activarlo desde el inicio. Para proyectos existentes, lo más conservador es activarlo en un entorno de staging, medir el impacto y migrar.

Breaking changes en Next.js 16

Hay tres cambios que pueden romper código existente y conviene revisar antes de actualizar.

Los params y searchParams en layouts, pages y metadata ahora son Promises. El código que asumía acceso sincrónico a esos valores va a fallar. La migración es agregar await antes de accederlos o usar el codemod oficial que lo hace automáticamente.

next/image cambió sus defaults: decoding ahora es async por defecto y fetchPriority es auto. Imágenes que dependían de los comportamientos anteriores pueden necesitar ajuste explícito de esos atributos.

Los fetch requests en Server Components que no pasaban una cache policy ahora por defecto tienen cache: 'no-store'. Datos que antes se cacheaban silenciosamente ahora se piden en cada request. Si notás un aumento de latencia después de actualizar, ese cambio es probablemente la causa.

Para la migración, Vercel publicó un codemod:

npx @next/codemod@canary upgrade latest

Cubre la mayoría de los cambios automáticos pero no todos. La guía de upgrade oficial tiene el detalle de lo que el codemod no maneja.

Instant Navigations y Partial Prefetching

Next.js 16.3 llegó a stable el 3 de agosto de 2026. El cambio más relevante es Instant Navigations, que resuelve una diferencia histórica entre Next.js y las SPAs: la percepción de velocidad en navegaciones del lado del cliente.

En Next.js 14 y 15, cuando un usuario hacía click en un link, el browser mandaba una request al servidor, esperaba la respuesta y renderizaba. El tiempo de espera siempre fue visible, especialmente en conexiones lentas. Las SPAs clásicas evitaban eso mostrando contenido inmediato porque todo estaba en el cliente, pero pagaban el costo en carga inicial y SEO.

Instant Navigations combina dos cosas. Cache Components permite cachear partes del layout en el cliente. Partial Prefetching genera un único shell reutilizable por ruta y lo cachea una sola vez. Si tenés 20 links apuntando a /productos/[id], el browser prefetchea un solo shell genérico, no 20 prefetch requests individuales. Cuando el usuario hace click, el shell aparece de inmediato mientras el contenido dinámico llega desde el servidor.

El resultado práctico: navegaciones que se sienten como las de una SPA sin renunciar a Server Components ni al modelo server-first.

Las dos features son opt-in por ahora. Para activarlas:

// next.config.ts
import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
};
 
export default nextConfig;

Están planificadas como defaults en una versión major futura. Activarlas ahora no es un dead end, es adopción anticipada de algo que va a ser estándar.

Dentro de las rutas, tenés tres modos posibles:

// Stream: el shell aparece inmediato, el contenido llega después
export default async function Page() {
  return <Suspense fallback={<Shell />}><Content /></Suspense>
}
 
// Cache: el contenido se cachea en el cliente
async function DatosProducto({ id }: { id: string }) {
  'use cache'
  // ...
}
 
// Block: desactivar Instant Navigations para esta ruta específica
export const instant = false

Para rutas completamente estáticas prerenderizadas con SSG, Instant Navigations no aporta diferencia perceptible. El beneficio es mayor en rutas dinámicas con datos que varían por request.

Turbopack y memoria en 16.3

Además de Instant Navigations, el 16.3 trajo mejoras específicas a Turbopack. El uso de memoria del servidor de desarrollo bajó hasta un 90% en proyectos grandes. Algunos setups que llegaban a 21.5 GB en sesiones largas ahora corren en una fracción de eso.

También se agregó caché en sistema de archivos para builds. Builds posteriores al primero reutilizan trabajo previo. En proyectos grandes eso se nota en el tiempo de build incremental.

MCP y agentes en Next.js 16.3

Una adición menos mencionada en la cobertura habitual es el endpoint MCP. Next.js 16.3 expone /_next/mcp en el servidor de desarrollo, lo que permite que agentes de código se conecten al dev server y consulten el estado de compilación de rutas específicas sin tener que correr un next build completo.

El compilador de rutas tiene una herramienta llamada compile_route que responde si una ruta específica compila correctamente. Para flujos de desarrollo asistidos por IA, eso reduce significativamente el tiempo de validación.

El equipo de Next.js también distribuyó cuatro agent skills de primera parte: uno que adopta Cache Components, uno que optimiza rutas después de la adopción, uno que adopta Partial Prefetching, y un skill de dev-loop que conecta el agente al servidor en ejecución vía ese endpoint MCP.

Qué conviene activar ahora y qué esperar

Para un proyecto nuevo, activar Turbopack y React Compiler desde el inicio tiene sentido. Son estables y los beneficios son inmediatos.

Para Instant Navigations y Partial Prefetching, la decisión depende del perfil de la aplicación. Rutas dinámicas con muchos links entre páginas son el caso ideal. Rutas completamente estáticas no van a notar diferencia. Conviene activarlos en un ambiente de staging, medir con herramientas como Lighthouse o Web Vitals, y migrar a producción con los datos en mano.

Los breaking changes de async params y los cambios de defaults en next/image y fetch requieren revisión independientemente del resto. El codemod cubre la mayoría pero no todo.

Si usás Azure Static Web Apps para desplegar tu aplicación Next.js, la documentación oficial cubre tanto el modo estático como el híbrido con Server Components. La migración de versión no requiere cambios en la configuración de infraestructura para la mayoría de los proyectos:

👉 https://learn.microsoft.com/azure/static-web-apps/nextjs?wt.mc_id=studentamb_510930

Información basada en las release notes oficiales de Next.js 16, 16.2 y 16.3 al 16 de agosto de 2026. Next.js puede actualizar comportamientos entre versiones menores. Revisá el changelog oficial en nextjs.org/blog antes de actualizar proyectos en producción.