El modelo mental de los Server Components
Cuando React Server Components (RSC) aparecieron en el ecosistema, la comunidad se dividió. Algunos vieron la evolución natural del SSR, otros vieron complejidad innecesaria. Después de un año completo usando RSC en producción con Next.js, puedo decir con confianza: es el cambio más significativo en arquitectura frontend desde la llegada de los hooks.
El modelo mental es simple pero poderoso: los componentes del servidor se ejecutan solo en el servidor, nunca envían JavaScript al cliente, y pueden acceder directamente a bases de datos, APIs y el sistema de archivos. Los componentes del cliente manejan la interactividad.
Patrones que funcionan en producción
Después de múltiples proyectos, estos son los patrones que he encontrado más efectivos:
- Data fetching en el servidor: Cada página hace sus queries directamente en el componente, sin useEffect ni estado de loading. El resultado es una UX instantánea.
- Client boundaries explícitos: Solo los componentes que necesitan useState, useEffect o event handlers llevan
'use client'. El resto es servidor por defecto. - Streaming con Suspense: Las partes pesadas de la página se envuelven en Suspense boundaries, permitiendo que el contenido principal se muestre inmediatamente mientras las secciones secundarias cargan en streaming.
El impacto real en Core Web Vitals
Los números no mienten. En proyectos donde migramos de un SPA tradicional a RSC:
- LCP (Largest Contentful Paint): reducción del 45% promedio
- TTI (Time to Interactive): reducción del 60%
- JavaScript enviado al cliente: reducción del 30-50%
Estos no son números de laboratorio — son métricas reales de producción medidas con Real User Monitoring. La reducción de JavaScript es particularmente impactante en dispositivos móviles y conexiones lentas.
Errores comunes a evitar
El error más frecuente es marcar demasiados componentes como 'use client' por inercia. Cada vez que agregas esa directiva, estás enviando más JavaScript al navegador. La pregunta correcta siempre es: ¿este componente NECESITA interactividad del lado del cliente?
Otro error común es no aprovechar el streaming. Si tu página tiene una sección que requiere una query lenta, envuélvela en Suspense y deja que Next.js haga streaming del resto mientras esa sección se resuelve.
Lo que viene en 2026
Con Next.js 15, las mejoras en caché parcial, Server Actions más robustos y mejor integración con edge computing prometen llevar este paradigma aún más lejos. El futuro del web no es más JavaScript — es el JavaScript correcto, ejecutado en el lugar correcto.