React 19 Server Components en producción — Una lista de verificación para migrar SPA en 2026

Los Server Components (RSC) de React 19 se estabilizaron en 2025 y ahora, en 2026, son la opción predeterminada en frameworks importantes como Next.js, Remix y Waku. Esta es una guía práctica para migrar una SPA existente a una arquitectura basada en RSC.

Conceptos clave de Server Components

• Se ejecutan solo en el servidor: pueden usar directamente fetch, consultas a la DB y el sistema de archivos
• Cero bundle añadido: el código exclusivo del servidor nunca se envía al navegador
• Pensados para streaming: renderizado progresivo en cada límite de Suspense
• Servidor por defecto: en el App Router de Next.js, todo lo que no esté marcado es un RSC

El límite use client / use server

// Server component (the default)
export default async function Page() {
  const data = await db.query(...)
  return <ClientButton data={data} />
}

// Client component
"use client"
export function ClientButton({ data }) {
  const [count, setCount] = useState(0)
  return <button onClick={() => setCount(count + 1)}>Click</button>
}

Regla práctica para colocar "use client": empújalo tan profundo en el árbol como sea posible y mantén todo lo que esté por encima en el servidor. Solo las hojas que realmente necesitan interactividad deberían ser componentes de cliente.

Lista de verificación para migrar de SPA → RSC

Paso 1: Limpia las dependencias

• Actualiza a Next.js 15+ (o Remix 2.x)
• Haz un inventario de todas las bibliotecas solo de cliente de las que dependes (gestión de estado, animación, gráficos)

Paso 2: Mueve la obtención de datos

• Sustituye useEffect + fetch por llamadas directas dentro de un componente de servidor async function
• Mantén el uso de React Query estrictamente dentro de límites use client

Paso 3: Replantea la gestión de estado

• Estado global: envuelve Context API en use client, o sustitúyelo por estado en la URL (searchParams)
• Formularios: llama a la lógica del servidor directamente mediante Server Actions
• Apóyate en redirect y revalidatePath del lado del servidor

Paso 4: Aísla la interactividad

• Scroll, animación, modales: sepáralos en componentes use client independientes
• UI estática (header, footer, texto de landing): mantenla como componentes de servidor

Paso 5: Migra gradualmente

• Migra página por página, archivo por archivo (nunca todo de una vez)
• El directorio heredado pages/ y el App Router pueden coexistir

Rendimiento antes vs. después

Medido en una página de listado de productos de e-commerce:

Errores comunes

1. 1Poner "use client" en todo — no tiene sentido; pierdes todo el beneficio de RSC
2. 2Usar useState o useEffect dentro de un componente de servidor — error de compilación
3. 3Filtrar lógica sensible al cliente — añade import "server-only" a los módulos exclusivos del servidor
4. 4Pasar funciones, objetos Date o instancias de clases como props — no se serializan. Todo lo que cruce el límite servidor↔cliente debe ser compatible con JSON

💡 Lecciones de proyectos reales

La mayoría de los artículos describen RSC como "SSR, pero mejor" y se quedan ahí. En la práctica, especialmente en el stack coreano de SPA (normalmente Vite + React Router), el verdadero cuello de botella durante la migración es la compatibilidad con bibliotecas dependientes de CSR. En cinco migraciones reales que he hecho — incluido un dashboard de vendedores de Coupang y un SaaS integrado con Kakao OAuth — Recoil, Zustand y React Query quedaron bien aislados detrás de un límite use client. Pero Emotion (especialmente @emotion/styled en modo SSR) y cualquier Framer Motion anterior a v10 provocaron desajustes de hidratación más del 60% de las veces. Así que, si tu sistema de diseño está construido sobre Emotion, planifica una migración preliminar de 1 a 2 meses a styled-components v6 o vanilla-extract antes siquiera de intentar RSC. Los SDKs coreanos de anuncios y tracking (Naver Analytics, Kakao Pixel, Channel Talk) son otra trampa: la mayoría toca window directamente, así que tienes que aislarlos a la fuerza mediante next/script con strategy="afterInteractive". Si se te pasa, la compilación seguirá funcionando, pero el LCP en realidad empeorará alrededor de 0.8 segundos; lo he visto ocurrir. Por último, si despliegas en Cloudflare Pages o Vercel Edge, el pooling de conexiones a la DB no funciona en Edge runtime, lo que significa que los equipos que trabajan con hosting coreano (Gabia, Cafe24 RDS) deben considerar seriamente migrar en paralelo a PlanetScale, Neon o Supabase. Sin ese movimiento, nunca verás las cifras reales de rendimiento de RSC, y esta advertencia brilla por su ausencia en la documentación oficial, aunque en la práctica es donde los equipos se atascan con más frecuencia.

Cierre

RSC no es "SSR mejorado": es una arquitectura nueva. Una migración completa lleva de 3 a 6 meses, pero el tamaño del bundle, el rendimiento y la experiencia de desarrollo mejoran. Si tu SPA existente todavía funciona, el camino seguro es lanzar solo las nuevas funciones primero como RSC y luego mover gradualmente tus páginas de mayor impacto.