Next.js 16 en profundidad: qué cambia y cómo migrar tu proyecto

Next.js 16 es la versión mayor del framework de React publicada en octubre de 2025. Cierra la historia de Turbopack, introduce un nuevo modelo declarativo de caché, alinea el stack con React 19 y endurece las APIs asíncronas que en Next 15 solo emitían warnings. Si gestionas un proyecto en Next.js, esta guía te sirve como referencia para entender qué ha cambiado, por qué, y cómo migrar desde la versión anterior sin sustos.

En Think! Madrid ya migramos este mismo sitio a Next.js 16 poco después de su publicación. Los pasos que vas a leer están probados en producción, no son teoría.

Novedades principales de Next.js 16

1. Turbopack estable para producción

Turbopack deja de ser opcional para desarrollo y pasa a ser el bundler por defecto también en next build. El compilador en Rust reemplaza definitivamente a webpack para la mayoría de proyectos, con builds entre 2× y 5× más rápidos en proyectos medianos. Sigue habiendo un fallback de webpack para quien use plugins no portados.

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  }
}

Ya no hace falta el flag --turbo. Si quieres forzar webpack por compatibilidad, puedes hacerlo vía next.config.ts con experimental.turbo: false, pero es raro que lo necesites.

2. Cache Components: caché declarativa

El cambio más importante conceptualmente. Next.js 16 introduce la directiva "use cache", que sigue el mismo patrón que "use client" o "use server". Puedes marcar un archivo, una función o un componente como cacheado:

"use cache";

export async function getProducts(category: string) {
  const res = await fetch(`https://api.ejemplo.com/products?c=${category}`);
  return res.json();
}

Con esto, todas las llamadas a getProducts con los mismos argumentos se sirven desde caché. Sustituye al patrón antiguo de pasar { next: { revalidate } } a fetch, que sigue funcionando pero ya no es el camino recomendado para nuevo código.

Para invalidar por tag, ahora se usa cacheTag:

import { unstable_cacheTag as cacheTag } from "next/cache";

export async function getProducts(category: string) {
  "use cache";
  cacheTag(`products-${category}`);
  const res = await fetch(`https://api.ejemplo.com/products?c=${category}`);
  return res.json();
}

3. APIs asíncronas endurecidas

Las APIs de request (params, searchParams, cookies(), headers(), draftMode()) ya eran asíncronas en Next 15, pero accederlas de forma síncrona solo emitía un warning. En Next 16 es un error. Si no aplicaste el codemod, ahora es obligatorio:

// ❌ Next 15 (warning) — Next 16 (error)
export default function Post({ params }) {
  const { slug } = params;
  return <Article slug={slug} />;
}

// ✅ Next 16
export default async function Post({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  return <Article slug={slug} />;
}

4. React 19 como mínimo

Next.js 16 exige React 19. Esto abre acceso a Actions, el hook use() para promesas y contextos dentro de componentes, el nuevo useOptimistic y mejoras internas en Server Components. Si vienes de React 18, revisa la nota de release de React 19 antes de migrar.

5. Middleware con runtime de Node.js

Hasta ahora Middleware solo podía ejecutarse en Edge Runtime, con limitaciones de APIs Node. Next.js 16 permite optar por Node.js runtime también en middleware, lo que habilita uso de librerías pesadas (bcrypt, ORMs, SDKs de AWS) que antes requerían mover lógica a Route Handlers.

import type { NextRequest } from "next/server";

export const config = {
  runtime: "nodejs", // antes solo "edge" era posible
  matcher: ["/admin/:path*"],
};

export function middleware(req: NextRequest) {
  // lógica con acceso completo a APIs de Node
}

6. next/image: DPR y sizes mejorados

El componente Image ahora genera automáticamente srcsets más finos para pantallas de alta densidad (DPR 2× y 3×) sin necesidad de configurarlo manualmente. También hay mejoras en el placeholder blur y en la detección de imágenes remotas.

Breaking changes que debes conocer

Resumen de lo que se rompe al pasar de Next 15 a Next 16. No todo es drama — con el codemod oficial la mayor parte se resuelve automáticamente.

Migración paso a paso desde Next.js 15

Paso 1 — Prepara el entorno

Antes de tocar nada, asegúrate de que tu CI y tu máquina local tienen Node 20.9 o superior. Comprueba:

node -v
# v20.9.0 o superior

Haz un commit limpio del estado actual, crea una rama chore/nextjs-16 y arranca desde ahí. Si usas Vercel, confirma que el proyecto tiene Node 20 o 22 seleccionado en Project Settings → General.

Paso 2 — Ejecuta el codemod oficial

Next.js mantiene un CLI de codemods que aplica la mayoría de transformaciones automáticamente:

npx @next/codemod@canary upgrade latest

El codemod hace, entre otras cosas:

• Actualiza next, react y react-dom a las versiones correctas.
• Convierte accesos síncronos a params/searchParams en async + await.
• Renombra cookies()/headers() a sus versiones asíncronas.
• Migra images.domains a remotePatterns.
• Limpia flags experimental que ya son default.

Paso 3 — Revisa las dependencias

Después del codemod, revisa el package.json. Algunas librerías comunes que suelen requerir actualización manual:

npx npm-check-updates -u
npm install

# Librerías a vigilar:
# - next-auth / auth.js
# - drizzle-orm / prisma
# - next-intl
# - tailwindcss (v4 si aún estabas en v3)
# - framer-motion

Si alguna librería no tiene versión compatible con React 19, revisa su repositorio para ver si hay RC o alpha. Si no, valora reemplazarla o bloquear la migración hasta que publiquen.

Paso 4 — Limpia next.config.ts

Algunas opciones que antes eran experimental ya son default. Ejemplo real:

// Antes (Next 15)
const nextConfig = {
  experimental: {
    serverActions: true,
    ppr: true,
  },
  images: {
    domains: ["images.ejemplo.com"],
  },
};

// Después (Next 16)
const nextConfig = {
  experimental: {
    // serverActions ya es default
    ppr: true, // sigue experimental pero maduro
  },
  images: {
    remotePatterns: [
      { protocol: "https", hostname: "images.ejemplo.com" },
    ],
  },
};

Paso 5 — Adopta Cache Components (opcional pero recomendado)

No tienes que migrar toda la caché el primer día. El patrón antiguo (fetch con next.revalidate) sigue funcionando. Pero para funciones nuevas o hotspots que revalidas con frecuencia, usa "use cache". Es más legible, testeable y quita la magia del wrapper de fetch:

import { unstable_cacheTag as cacheTag } from "next/cache";

export async function getPostBySlug(slug: string) {
  "use cache";
  cacheTag(`post-${slug}`);
  const res = await fetch(`${process.env.API_URL}/posts/${slug}`);
  if (!res.ok) return null;
  return res.json();
}

Y cuando publiques un post nuevo, invalidas con:

import { revalidateTag } from "next/cache";

revalidateTag(`post-${slug}`);

Paso 6 — Prueba build, lint y types

npm run lint
npx tsc --noEmit
npm run build

Si npm run build pasa y las rutas se generan como esperas, la parte dura está hecha. Si hay errores, la mayoría serán tipos en rutas dinámicas por el cambio a Promise en params.

Paso 7 — Smoke test de rutas críticas

Antes de mergear a main, despliega a un entorno de preview y prueba:

• Home y rutas estáticas principales.
• Rutas dinámicas con params ([slug], [id]).
• Formularios con Server Actions.
• Autenticación completa (login, logout, rutas protegidas).
• Upload de archivos si tu app los tiene.
• Revalidación de caché: publica algo y comprueba que revalidateTag / revalidatePath funcionan.

Checklist final de migración

• ☐ Node 20.9+ en local y CI
• ☐ npx @next/codemod@canary upgrade latest ejecutado
• ☐ React 19 instalado y sin warnings en consola
• ☐ Todas las params y searchParams awaiteadas
• ☐ cookies() y headers() awaiteadas
• ☐ images.domains migrado a remotePatterns
• ☐ Flags experimental obsoletos eliminados
• ☐ Build de producción en verde con Turbopack
• ☐ Lint y typecheck en verde
• ☐ Smoke test manual en preview
• ☐ Core Web Vitals verificados post-deploy

Errores comunes durante la migración

"Route used params.X — params should be awaited"

Falta convertir el componente a async y hacer await params. Si lo recibes en un componente hijo sin tipos correctos, asegúrate de tipar la prop como Promise<{ ... }>.

"Expected React 19, found 18.x"

Alguna dependencia está pinando React 18 en tu árbol de dependencias. Ejecuta npm ls react para encontrar el culpable y actualiza o fuerza la resolución con overrides en package.json.

Turbopack falla en el build de producción

Lo más común: un plugin webpack del proyecto que Turbopack aún no soporta. Opciones: migrar el plugin a equivalente Turbopack, eliminarlo si no es esencial, o volver a webpack con experimental.turbo: false mientras decides.

"use cache" no está disponible

Requiere activar experimental.dynamicIO en next.config.ts. Y el archivo o función donde la uses debe ser async.

¿Cuándo tiene sentido migrar?

No todo proyecto debe saltar el mismo día del release. Guía rápida:

• Proyecto nuevo: empieza directamente en Next 16.
• Proyecto en Next 15 con App Router: migra en la siguiente ventana de release (1-2 semanas de trabajo).
• Proyecto en Next 14 o anterior: salta primero a 15 con el codemod de esa versión, estabiliza, y después a 16. No intentes dos saltos a la vez.
• Proyecto en Pages Router: valora si la migración a App Router tiene sentido al mismo tiempo. Muchas veces conviene hacerlo por pasos, primero Next 16 con Pages Router, después migrar rutas.

Conclusión

Next.js 16 es una release que consolida más que revoluciona: estabiliza Turbopack, endurece las APIs asíncronas y da a la caché un modelo declarativo más limpio. Para equipos que ya estaban en Next 15 al día, la migración es cuestión de horas. Para proyectos más antiguos, conviene hacerla por fases. En cualquier caso, cada versión que saltas sin actualizar encarece la siguiente, así que el coste de esperar compone.

Si quieres profundizar en el lado SEO del framework, tenemos la Guía SEO para Next.js con metadata API, sitemap, schemas y Core Web Vitals. Y si estás evaluando si Next es la tecnología adecuada para tu próximo proyecto, echa un vistazo a Next.js vs WordPress o escríbenos a /contacto y lo vemos juntos.