Estudio
Next.js 16 para una web corporativa
Qué cambia Next.js 16 en una web corporativa con Next.js: Cache Components, Turbopack por defecto, proxy.ts y qué planificar antes de actualizar o empezar.
- Publicado
- min de lectura
- 7 min de lectura
- Por
- Redacción de Kyvrel

Next.js 16 salió en octubre de 2025 y hace más fácil mantener rápida una web corporativa con Next.js. La caché ahora es explícita, Turbopack es el bundler por defecto y el middleware pasó a llamarse proxy.ts. En la práctica: páginas estáticas con pequeñas partes en vivo, compilaciones más rápidas y menos sorpresas de caché. Esto es lo que cambió y lo que implica para quien gestiona la web.
Construimos webs de marketing con Next.js, así que lo contamos desde el lado del desarrollo. Nos centramos en los cambios que afectan al equipo de contenido, al rendimiento y al presupuesto, no en cada línea del changelog.
Qué cambia Next.js 16 en una web corporativa con Next.js
Las notas de la versión 16 de Next.js recogen muchos cambios. Para una web de marketing importan sobre todo cinco:
- Cache Components. Un modelo nuevo en el que marcas lo que se puede cachear con la directiva
"use cache". Todo lo demás es dinámico. - Turbopack por defecto. El bundler escrito en Rust es ahora el predeterminado en proyectos nuevos, tanto en desarrollo como en producción.
proxy.tssustituye amiddleware.ts. La capa de peticiones recibe un nombre más claro y se ejecuta en el runtime de Node.js.- Invalidación de caché más clara.
revalidateTagrecibe un perfil de caché, y el nuevoupdateTagcubre los casos en los que una Server Action debe ver al instante lo que acaba de escribir. - React 19.2. Con la nueva versión de React llegan View Transitions y el componente
Activity.
También hay cambios incompatibles: Node.js 20.9 es la versión mínima, desaparece el acceso síncrono a params y cookies, y se eliminó el comando next lint.

Cache Components: páginas estáticas con partes en vivo
Las versiones anteriores del App Router cacheaban mucho de forma implícita. Los equipos se encontraban a menudo con una página desactualizada, o dinámica cuando la esperaban estática, y tenían que leer la documentación con lupa para entender por qué. Next.js 16 le da la vuelta. Con cacheComponents activado, tú decides qué se cachea, a nivel de función o de componente.
Para una web de marketing, el patrón es sencillo. El contenido del CMS se cachea y se etiqueta. Cuando alguien publica, un webhook invalida la etiqueta.
import { cacheLife, cacheTag } from "next/cache";
export async function getPricingPlans() {
"use cache";
cacheLife("hours");
cacheTag("pricing");
const res = await fetch("https://cms.example.com/api/plans");
return res.json();
}Un route handler que recibe el webhook del CMS llama a revalidateTag("pricing", "max") y el siguiente visitante ya ve el contenido nuevo. Las piezas que dependen de cada petición, como un aviso por región o el estado de sesión, quedan tras un límite de Suspense y llegan después de la estructura estática.
Por qué le importa al negocio: la estructura de la página se sirve desde el edge en milisegundos y el equipo editorial ve sus cambios publicados sin recompilar todo. Eso ayuda al Largest Contentful Paint, del que hablamos en Core Web Vitals para webs de marketing.
Turbopack por defecto, y por qué lo nota también marketing
Turbopack ya era estable en desarrollo desde Next.js 15. En la 16 también es el predeterminado para las compilaciones de producción. El equipo de Next.js habla de compilaciones de producción entre 2 y 5 veces más rápidas y de un Fast Refresh hasta 10 veces más rápido.
La velocidad de compilación parece un asunto de desarrolladores. En una web con mucho contenido, también llega a marketing. Compilaciones más rápidas significan previsualizaciones antes, correcciones más ágiles el día del lanzamiento y menos coste de CI. Si algún webhook aún dispara una recompilación completa, la espera se acorta.
Los proyectos con configuración propia de webpack pueden seguir con webpack de momento mediante una opción. Lo tratamos como un paso temporal y planificamos el cambio durante la actualización.
proxy.ts y otros cambios de nombre
middleware.ts queda obsoleto en favor de proxy.ts. La función interna pasa de llamarse middleware a proxy. El comportamiento es parecido al que conoces: redirecciones, reescrituras, detección de idioma y cambios de cabeceras antes de que la petición llegue a la página.
import { NextResponse, type NextRequest } from "next/server";
export function proxy(request: NextRequest) {
if (request.nextUrl.pathname === "/old-pricing") {
return NextResponse.redirect(new URL("/pricing", request.url), 308);
}
return NextResponse.next();
}El nombre nuevo describe mejor lo que hace esta capa. Es buen momento para revisar qué ejecuta tu middleware en cada petición, porque cada milisegundo ahí va delante de cada visita.
Otros cambios que merecen una línea en tu plan de actualización:
- Imágenes. Cambiaron los valores por defecto de
next/image, con un tiempo mínimo de caché más largo y una lista de calidades más corta. Revisa tu configuración de imágenes. - Rutas. La deduplicación de layouts y el prefetch incremental reducen los datos que descarga una página cuando el visitante pasa el cursor por muchos enlaces. Los menús grandes son los que más ganan.
- React Compiler. El soporte es estable pero opcional. Reduce la memoización manual. Actívalo cuando la actualización esté asentada, no durante.
¿Es Next.js 16 la opción adecuada para tu web?
Para muchas webs de marketing, sí. Next.js encaja si quieres un diseño a medida sin los límites de una plantilla, buen rendimiento, varios idiomas y un CMS headless que edita tu equipo. También si la web comparte componentes con un producto hecho en React.
No es la única buena opción. Una web pequeña que cambia poco puede funcionar bien en un constructor alojado. Un equipo con mucha experiencia en WordPress y muchos plugins quizá prefiera quedarse. Nuestra comparación entre WordPress y Next.js, enlazada al final de este artículo, pone los pros y contras lado a lado.
Si vienes de un constructor visual, el camino de migración es el mismo que antes, y nuestra guía para migrar de Webflow a Next.js sigue vigente. La versión 16 simplemente facilita cachear bien el resultado.

Actualizar desde Next.js 15: qué planificar
Para una web de marketing típica en Next.js 15 con App Router, actualizar es un proyecto acotado. Nuestro orden habitual:
- Revisa el entorno. Node.js 20.9 o superior en CI y en el hosting.
- Ejecuta el codemod.
npx @next/codemod@canary upgrade latestresuelve casi todos los cambios de nombre y de API asíncronas. - Pasa el middleware a proxy. Renombra el archivo y la función y prueba cada redirección y regla de idioma.
- Revisa la caché. Decide qué datos se cachean, define perfiles y etiquetas y conecta los webhooks del CMS a
revalidateTag. - Prueba imágenes y rutas. Compara las imágenes renderizadas y revisa cada página en un despliegue de pruebas.
- Mide. Compara tiempos de compilación y Core Web Vitals antes y después.
Las webs que siguen en Pages Router, o en Next.js 13 o 14, necesitan más tiempo. Las valoramos tras una breve auditoría de código, para que la estimación parta de tu código.
Planifica tu web corporativa con Next.js
Construimos nuestras webs corporativas con Next.js. Una página web corporativa empieza en 8500 $ por 8 plantillas de página y suele llevar 4-5 semanas. Incluye un CMS headless que edita tu equipo y 2 rondas de revisión. Una web con 10 plantillas sale por 9400 $. El desarrollo cubre el renderizado estático y la configuración de caché descrita arriba.
Si todavía estás eligiendo plataforma, empieza por nuestra comparación WordPress vs Next.js. Si ya la elegiste, envíanos tu lista de páginas e idiomas y te responderemos en un máximo de 4 horas laborables, de lunes a viernes, hora de Kyiv.