Next.js 16: Turbopack estable y 400% más rápido

Next.js 16 es la primera release mayor en la que Vercel se anima a hacer algo que veníamos esperando hace tres años: declarar Turbopack estable y volverlo el bundler default para next dev y next build. La promesa concreta — 400% más rápido en arranque de dev, 2-5x en builds, Hot Module Replacement casi instantáneo en proyectos grandes — se cumple en la mayoría de los casos. Pero no en todos, y este post es para que entiendas qué migrar hoy, qué dejar para Next.js 16.2+, y qué cambios silenciosos en el modelo de cache te pueden romper producción sin avisar.

La release de Next.js 16 llegó en febrero de 2026; 16.2 en marzo trajo otro 400% de mejora en next dev y 200 fixes de Turbopack; 16.1 (enero) había estabilizado Cache Components. Sumado al React Compiler 1.0 que cubrimos en otro post, el resultado es un Next.js radicalmente distinto al 14/15 que mucha gente todavía corre en producción. Si tu equipo aún no migró, esta es la guía para decidir cuándo hacerlo y qué romper en el camino.

Lo que cambia (de verdad) en Next.js 16

Cinco cambios estructurales, en orden de impacto sobre proyectos reales.

1. Turbopack default para dev y build

Antes había que pasar --turbopack explícitamente y aguantar el aviso “Turbopack is in beta”. En Next.js 16 corrés next dev y next build y Turbopack se activa solo. Webpack sigue disponible vía next dev --webpack por un período de transición — pensalo como una salida de emergencia, no como configuración a largo plazo.

Los números reales medidos en proyectos de producción (Catch Metrics):

El número que más impacta el día a día no es el build sino el HMR: pasar de 1.4 s a 180 ms vuelve la edición prácticamente sin lag. Después de una semana de usar Turbopack estable, volver a Webpack se siente como programar en otro siglo.

2. Cache Components y la directiva "use cache"

Acá está el cambio que más va a confundir a equipos migrando. Next.js 16 introduce Cache Components, un modelo nuevo de caching que reemplaza la combinación caótica de revalidate, cache: 'force-cache', unstable_cache y los headers manuales que veníamos arrastrando desde Next.js 13.

La idea base: todo es dinámico por default; lo que querés cachear lo marcás con "use cache". Ejemplo:

"use cache"

import { db } from "@/lib/db"

export async function getProductosDestacados() {
  const productos = await db.producto.findMany({
    where: { destacado: true },
    take: 20,
  })
  return productos
}

Esa función ahora cachea su resultado automáticamente. Podés controlar el comportamiento con tags y revalidación:

"use cache"

import { cacheTag, cacheLife } from "next/cache"

export async function getProducto(id: string) {
  cacheTag(`producto-${id}`)
  cacheLife("hours")
  return await db.producto.findUnique({ where: { id } })
}

cacheTag te permite invalidar selectivamente con revalidateTag() desde un Server Action; cacheLife define la frescura. Mucho más limpio que pelearse con next: { revalidate: 3600, tags: ['producto'] } dentro de cada fetch.

El asterisco importante: "use cache" cambia las semánticas de tu app. Si migrás un proyecto que dependía de revalidación automática por ruta (el viejo revalidate = 60 exportado de la página), Next.js 16 no la corre por default. Hay que marcar explícitamente lo cacheable. Esto va a romper apps que asumían “todo se cachea por una hora salvo que diga lo contrario”.

3. React Compiler 1.0 activo por default

El React Compiler 1.0 está integrado en Next.js 16. No tenés que instalarlo aparte ni configurarlo: viene activo. El efecto práctico es que podés borrar el 90% de tus useMemo y useCallback sin pérdida de performance — el compilador los inyecta solo donde hacen falta.

Esto no es un cambio funcional sino un cambio de hábitos de código. La migración recomendada: dejá los hooks viejos donde están (no rompen nada) y, en código nuevo, escribí sin memoizar. Cuando hagas refactors, sacá los memos legacy. En 6-12 meses tu codebase queda mucho más legible.

4. proxy.ts reemplaza a middleware.ts

Next.js 16 introduce proxy.ts para clarificar el límite de red — la idea es separar lo que es “transformación de request antes de routing” (proxy) de lo que era “middleware” (un nombre demasiado vago que se usaba para todo). El renombre no es solo cosmético: el modelo de ejecución cambió.

Migración mínima:

// proxy.ts
import { NextResponse } from "next/server"
import type { NextRequest } from "next/server"

export function proxy(request: NextRequest) {
  const isAuthed = request.cookies.get("session")
  if (!isAuthed && request.nextUrl.pathname.startsWith("/dashboard")) {
    return NextResponse.redirect(new URL("/login", request.url))
  }
  return NextResponse.next()
}

export const config = {
  matcher: ["/dashboard/:path*"],
}

Es básicamente lo mismo que middleware.ts con la función renombrada de middleware a proxy. Para proyectos existentes, Next.js 16 acepta ambos archivos durante una ventana de deprecación que va a cerrar en Next.js 17 (estimado primer trimestre 2027).

5. DevTools MCP integration

Next.js 16 expone su DevTools como un MCP server (ver nuestro post sobre WebMCP para entender el protocolo). En la práctica esto significa que podés conectar Claude Code, Cursor o cualquier IDE-IA al runtime de tu app Next.js y hacerle preguntas como “qué rutas tienen el cold start más lento” o “qué cache key se invalidó después de mi último deploy”. Es debugging conversacional sobre el estado real de la app.

Para activarlo, en next.config.ts:

import type { NextConfig } from "next"

const config: NextConfig = {
  experimental: {
    devtoolsMCP: true,
  },
}

export default config

Después, en Claude Code o Cursor, configurás el MCP server apuntando a http://localhost:3000/_next/devtools/mcp y tenés a tu agente conectado al runtime. Es una de esas features que parecen menores hasta que las usás y entendés cuánto tiempo ahorran en debugging.

La trampa silenciosa: bundle size puede crecer

Mucha gente migró a Turbopack viendo solo los benchmarks de velocidad y se llevó una sorpresa fea en producción: el shared client chunk del App Router creció ~211 kB en algunos proyectos (de 180 kB a 391 kB), con un First Load JS mediano 72% más alto. La causa documentada es que Turbopack todavía no hace el mismo nivel de code splitting agresivo que Webpack maduro hacía en App Router.

Antes de declarar la migración exitosa, medí estos tres números con tu propia app:

# antes (Next.js 15 con Webpack)
next build --webpack
# anotar "First Load JS shared by all" y los pesos por ruta

# después (Next.js 16 con Turbopack default)
next build
# comparar

Si ves crecimiento de más de 100 kB en el shared chunk, no migres todavía a producción. Esperá Next.js 16.3 o 16.4, donde Vercel anunció optimizaciones de chunking específicas para corregir esto. Mientras tanto, podés usar Turbopack solo en next dev (es seguro y siempre conviene) y mantener Webpack para next build:

next build --webpack

Esto es la recomendación oficial para apps grandes en producción durante el segundo trimestre de 2026.

Plan de migración recomendado

Para un equipo que está en Next.js 15.x hoy y quiere llegar a 16.x sin romper nada:

Semana 1: Turbopack en dev

pnpm dlx @next/upgrade
# o
npm install next@16 react@19 react-dom@19

Probá next dev un par de días. Si no aparecen errores raros (algunos plugins de Webpack viejos no funcionan, sobre todo bundlers de SVG custom), seguís.

Semana 2: Renombrar middleware.ts a proxy.ts

Renombrá el archivo, cambiá export function middleware por export function proxy. Probá. Si tu middleware hacía cosas raras con NextRequest.geo o request.ip, fijate que esas APIs cambiaron levemente — la versión nueva está documentada.

Semana 3: Migrar a Cache Components selectivamente

No conviertas toda la app de golpe. Empezá por las rutas que más fetcheaban con force-cache o revalidate. Marcalas con "use cache", agregales cacheTag y cacheLife. Verificá que el comportamiento sea el esperado.

Semana 4: React Compiler en código nuevo

No toques el código viejo. En features nuevas, no escribas useMemo/useCallback salvo casos donde el compilador no pueda inferir (cierres complejos, dependencias circulares). Confiá en el compilador y medí.

Semana 5+: Validar production build

Cuando todo el dev se sienta estable, hacé un deploy a staging con next build (Turbopack default). Medí Core Web Vitals, bundle sizes, error rates. Si todo OK, vas a producción. Si ves regresión en LCP o CLS por el bundle más grande, fallback a next build --webpack hasta que la versión 16.3+ corrija el chunking.

Casos donde no conviene migrar a Next.js 16 todavía

Tres situaciones donde lo más sensato es quedarse en 15.x:

1. App con Webpack plugins custom que el equipo escribió internamente. Turbopack no soporta el ecosistema de plugins de Webpack; vas a tener que reescribir todo. Si esos plugins son críticos, el costo de migración no compensa.
2. App grande (>500 rutas) cerca de límites de Vercel. El crecimiento de bundle size del App Router con Turbopack te puede empujar fuera del free tier de Vercel o aumentar la factura de manera significativa. Medí antes.
3. Equipo sin capacidad de testing extensivo. Cache Components es un cambio semántico, no solo sintáctico. Si tu equipo no tiene tests de integración cubriendo flujos críticos, migrar a 16 puede meter bugs sutiles de stale data en producción.

Para todos los demás casos, la migración a Next.js 16 mejora la calidad de vida del equipo y la performance del usuario. Hacela con cuidado pero hacela.

Comparativa rápida con Vite + React Router

Pregunta justa que aparece cada vez que Next sube versión: ¿no es mejor Vite con React Router? Honestamente, en 2026:

Para apps nuevas que no necesiten SSR profundo, Vite 7 con React Router 7 es competitivo y a veces más simple. Para apps que sí necesitan SSR/RSC, edge runtime y la integración nativa con Vercel, Next.js 16 sigue siendo la opción default. No hay un ganador universal.

Tabla resumen