Next.js 15 (App Router + RSC)
Mi veredicto
Elección por defecto para frontends headless con mucha aplicación. RSC estable tras 18 meses en producción.
Brief de profesional
Por qué lo adoptamos
Publicamos cuatro app shells de cliente sobre Next.js 15 entre noviembre de 2025 y abril de 2026. El TTFB de una ruta de panel personalizado servida por streaming con RSC y PPR (Partial Prerendering, RFC vercel/next.js#54647 de Sebastian Markbåge y Andrew Clark): el shell renderiza a 240 ms mientras el slot personalizado llega por streaming en menos de 800 ms. La misma vista en la anterior app pages router del cliente era un muro de 1,6 s de TTFB esperando a un único getServerSideProps. Los tiempos de build pasaron de 9 min a 6 min una vez que Turbopack se estabilizó en next build (15.2). El bundle del panel de comerciante cayó de 410 KB gzipped a 230 KB tras aplicar RSC y 'use client' selectivo.
Cuándo lo usamos
Encargos con forma de aplicación: paneles autenticados, checkout multipaso, portales B2B con UI por roles, listados de comercio personalizados que necesitan slots en streaming en la zona visible sin scroll. Las superficies editoriales van a Astro 5. El streaming de RSC perjudica cuando los payloads son pequeños, cuando un upstream lento anula la ventaja, o cuando el equipo pone 'use client' a nivel de layout.
Ruta de migración
Desde Next.js 14 pages router la migración es un proyecto real, no un cambio de flag. El codemod de Lee Robinson (@next/codemod app-dir) resuelve la estructura de ficheros, pero no puede razonar sobre la forma del data fetching; el trabajo restante es partir los componentes en capas de servidor y de cliente, e identificar qué contextos viven por debajo de una frontera 'use client'. Calcula dos semanas de ingeniería para una app de 40 rutas, tres si hay carrito o contexto de autenticación compartidos. Desde Remix v2 el salto es más duro de lo esperado: loaders y actions son un modelo mental distinto de RSC más server actions. Lo que no se transfiere: los stores de Redux solo de cliente, getInitialProps y la mayor parte del middleware de pages router.
Dos cicatrices de producción
Primera, la combinación de streaming RSC, Tailwind v4 y el edge runtime rompió la generación dinámica de clases en un portal B2B en febrero de 2026. El scanner JIT de Tailwind se ejecuta antes de que rendericen los server components, así que las clases interpoladas dentro de payloads RSC son invisibles. Arreglo: declarar las permutaciones por adelantado en safelist, dentro de tailwind.config.mjs. Segunda, las server actions con el adaptador OpenNext para Cloudflare se invocaron dos veces durante un reintento de checkout: un usuario pulsó Pagar dos veces en 800 ms y cobramos la tarjeta dos veces. El arreglo llegó en OpenNext 3.4 (PR #492 de sst/opennext); añadimos una cookie con clave de idempotencia para que las builds antiguas del adaptador tampoco hagan nada.
Qué estamos vigilando
El GA de Partial Prerendering en Next.js 15.5 nos permite dejar de mantener dos estrategias de render en la misma ruta (vercel/next.js#54647). El useOptimistic de React 19.1 junto a resultados tipados de server actions simplifica la ruta de actualización del carrito. También seguimos la API after() para trabajo posterior a la respuesta y el avance de OpenNext hacia la paridad de ISR en Workers (milestone 4.0 de sst/opennext).
Añadido: 2026-04-26 · Última revisión: 2026-04-26