Tu App Router No es una Versión Mejorada del Pages Router. Es Otro Framework
Si abriste la documentación de Next.js 16 y pensaste "vale, es el mismo React con routing mejorado", *llevas dos años de retraso mental y no lo sabes. *
El App Router + Server Components no es la versión 14 de Next.js. Es un framework nuevo que se llama igual que el antiguo para confundirte.
Los que lo tratan como una actualización de archivo — cambiar pages por app, renombrar getServerSideProps por async function — acaban con:
- 80kB de JavaScript en el "Hola Mundo"
- Bugs de serialización que no existían en el Pages Router
- Un middleware que no puede leer el body de un POST
- Y una dependencia tácita de Vercel para que todo esto funcione sin montar infraestructura paralela
*El 70% de los equipos que migren a Next.js 16 va a perder dos semanas en bugs que el Pages Router ni siquiera permitía. *
Vamos a ver las 3 features que sí importan, por qué rompen tu mentalidad actual, y cómo migrar sin perder esas dos semanas.
---
1. Partial Prerendering (PPR): El Rendimiento que Viene con una Factura Oculta
PPR es, con diferencia, la feature más potente de Next.js 16. Y la más peligrosa.
¿Qué hace PPR exactamente?
Permite que una misma página tenga partes estáticas (shell renderizado en build time) y partes dinámicas (contenido que se genera por petición). Todo dentro del mismo componente tree.
❌ Antes (Pages Router): Elegías una estrategia por página — SSG, SSR o ISR. Toda la página compartía el mismo modelo de renderizado.
✅ Con PPR (App Router): Cada componente puede tener su propia estrategia. El header es estático. El contenido del artículo es dinámico. El footer es ISR. Todo en la misma ruta.
El problema no es PPR. El problema es que PPR te obliga a diseñar el server/client boundary desde el minuto cero.
El 90% de los que activen PPR se van a encontrar con esto:
El footer parece inocente. Pero si Footer usa 'use client' para cualquier hook, y Header le pasa props desde un Server Component, *acabas de crear un bug de serialización que no verás hasta producción. *
La regla que nadie sigue:
Todo lo que cruce de un Server Component a un Client Component debe ser serializable. Sin funciones. Sin React elements. Sin referencias circulares.
PPR no es gratuito. Es una herramienta de precisión. Si la usas con mentalidad de Pages Router, te revienta en la cara.
---
2. Async Request APIs: El Cambio que Rompe Middlewares y Server Actions
Next.js 16 introduce las Async Request APIs. Suena a cambio menor. *Es el cambio más grande de esta versión para cualquiera que tenga middlewares o Server Actions en producción. *
¿Qué cambia exactamente?
Objetos como cookies(), headers(), params y searchParams pasan de ser síncronos a asíncronos.
❌ Antes (Next.js 15 y anteriores):
✅ En Next.js 16:
¿Por qué es un problema real?
Porque el 90% de los middlewares y Server Actions que encontré en migraciones reales usan cookies() o headers() sin await. Next.js 16 no te va a dar un error en build time. *Te va a dar un fallo intermitente en producción que atribuirás a cualquier otra cosa. *
La solución rápida:
*Este cambio solo va a romper middlewares y Server Actions que escribiste hace 6 meses y ya olvidaste que existen. *
---
3. El App Router se Come el Pages Router — y Tu Código Legacy se Queda Fuera
Next.js 16 no solo añade features. Empieza a eliminar el Pages Router de forma activa.
No es un rumor. La documentación oficial de Next.js 16 marca el Pages Router como "heredado". Las nuevas features — PPR, Server Actions con formularios nativos, streaming optimizado — solo existen en el App Router.
Esto significa que:
- `getServerSideProps` y `getStaticProps` desaparecen como concepto. Ya no son funciones especiales. Son
asynccomponents que hacen fetch directamente. - `_app.tsx` y `_document.tsx` no tienen equivalente directo en App Router.
layout.tsxytemplate.tsxson otra cosa. - El mental model cambia por completo. Ya no piensas en "rutas que responden a peticiones HTTP". Piensas en "árboles de componentes que se renderizan en el servidor".
El anti-patrón más común que veo:
Esto es un Pages Router disfrazado. Has puesto `'use client'` en el layout, lo que significa que todo el árbol de componentes debajo se ejecuta en el cliente. Adiós SSR. Adiós streaming. Adiós rendimiento.
✅ El patrón correcto:
*Pon `'use client'` lo más abajo posible en el árbol. No en el layout. No en las páginas. Solo en los botones, inputs, y elementos que necesitan interactividad. *
---
El Marco de 3 Pasos para Migrar a Next.js 16 Sin Perder Dos Semanas
No voy a decirte que no migres. Te voy a decir cómo hacerlo sin que te sangren los dedos.
Paso 1: Mapa de flujo de datos antes de tocar un archivo
Coge un papel o un Excalidraw. Dibuja tu aplicación como un árbol de componentes. Marca:
- Verde: Componentes que solo muestran contenido (estáticos, servidor)
- Rojo: Componentes que necesitan
useState,useEffect,onClick, o APIs del navegador - Amarillo: Componentes que hacen fetch de datos
La frontera server/client debe seguir este mapa, no la estructura de carpetas.
Paso 2: `'use client'` en las hojas, no en las ramas
Regla de oro: Si un componente no usa hooks, event handlers, o browser APIs, NO necesita 'use client'.
Cada 'use client' que pones demasiado arriba en el árbol convierte decenas de Server Components en JavaScript que el cliente tiene que descargar, parsear y ejecutar.
Paso 3: Adopta el patrón de fetch directo en Server Components
❌ No hagas esto:
✅ Haz esto:
Cero loading state. Cero JavaScript para el fetch. Cero waterfall de peticiones.
---
La Realidad: Next.js 16 es Mejor. Pero Solo si lo Aprendes Desde Cero
No puedes migrar a Next.js 16 con mentalidad de Next.js 12. *No es un upgrade. Es un re-entrenamiento mental. *
Las 3 features que importan — PPR, Async Request APIs, y el App Router nativo — te dan un rendimiento y una arquitectura que el Pages Router ni soñaba. Pero el precio es que tienes que olvidar lo que sabías.
Mi consejo: no migres archivo por archivo. Migra página por página. Empieza por una ruta nueva. Aprende el patrón. Luego migra las rutas complejas una a una.
Y sobre todo: no pongas `'use client'` en el layout. Por favor.
---
Resumen: Lo que te Llevas
- PPR es potente, pero la frontera server/client se define desde el diseño, no desde la sintaxis. Sin un mapa de flujo de datos, PPR te va a generar bugs de serialización difíciles de debuggear.
- Async Request APIs rompen middlewares y Server Actions existentes.
cookies()yheaders()ahora requierenawait. Si no lo añades antes de migrar, te vas a encontrar fallos intermitentes en producción. - El App Router no es un Pages Router con esteroides. Es un framework diferente. Los que lo traten como una simple actualización de archivos perderán semanas en bugs que el Pages Router no permitía.
Next.js 16 es, objetivamente, mejor que cualquier versión anterior. Pero *solo es mejor si estás dispuesto a aprenderlo como si fuera la primera vez. *
Artículos relacionados
- Next.js 16: Las Features que el 90% de Developers Todavía No Entienden
- Next.js 16 New Features: Las 5 Que Multiplican tu Velocidad de Deploy (y las 3 Trampas que Nadie Cuenta)
- Next.js 16 New Features: Las 3 que Multiplican Tu Velocidad (y las Otras Que Son Humo)
- Next.js 16 New Features: Las 3 que Ponen Tu Proyecto en Riesgo (y Cómo Sortearlas)
- Next.js se Ha Vuelto Peligrosamente Sobrediseñado: El App Router Te Cuesta Más de lo que Aporta
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
