Antes de profundizar sobre el punto clave de este post, me gustaría aclarar cómo funciona el mundo de servicios web de una manera muy resumida. Una forma sencilla de explicarlo es pensar en una aplicación web como una conversación entre tres actores:
- Cliente (navegador) → donde el usuario interactúa.
- Servidor → donde vive la lógica de negocio y los datos.
- Base de datos o servicios externos → donde está la información.
Los Server Components son componentes de React que se ejecutan exclusivamente en el servidor. Esto significa que al cliente (página web, aplicación móvil, etc) le añaden JavaScript que descargar ni otros elementos, tampoco pueden usar funcionalidades propias de React, como hooks (useState o useEffect).
A cambio, tienen acceso directo a recursos del servidor: bases de datos, sistema de ficheros, variables de entorno o APIs internas, sin necesidad de crear un endpoint intermedio.
Entonces.. ¿Qué es lo que el navegador recibe? El resultado renderizado: HTML y una descripción serializada del árbol de componentes que React sabe cómo hidratar de forma eficiente.
Durante años, el debate en el ecosistema React ha girado en torno a hooks, estado global o la mejor forma de gestionar los efectos. Los React Server Components (RSC) han llegado para replantear sobre quién debe ejecutar las distintas partes del código.
Este enfoque tiene varias ventajas, especialmente para aplicaciones muy atractivas, pero también presenta algunos inconvenientes:
- Más JavaScript que descargar y ejecutar.
- Mayor tiempo hasta que el usuario ve contenido útil.
- Necesidad de crear y mantener endpoints intermedios para acceder a los datos.
- Duplicación de lógica entre cliente y servidor.
- Peor rendimiento en dispositivos menos potentes.
Los React Server Components intentan solucionar estos problemas permitiendo que ciertas partes de la aplicación se ejecuten directamente en el servidor. En lugar de enviar al navegador el código necesario para obtener y procesar los datos, el servidor realiza ese trabajo y envía únicamente el resultado.
En este post te lo explico desde la experiencia real, de forma que puedas saber las diferencias y cuándo usar un RSC para tu propósito.
¿En qué se diferencian de los Server Side Rendering clásico?
El SSR tradicional renderiza toda la página en el servidor y envía HTML al cliente, pero luego hidrata toda la aplicación con JavaScript. El resultado: mucho JS en el cliente, tiempos de hidratación elevados y una experiencia que puede ser lenta en dispositivos con poca potencia.
Los Server Components van un paso más allá: sólo los componentes marcados como «use client» se hidratan. El resto permanece en el servidor de forma permanente. Esto no es Server Side Rendering (SSR) mejorado, es un modelo de ejecución distinto.
Arquitectura resultante
Con Server Components, una aplicación React moderna tiende a organizarse así:
- Server Components: lógica de datos, layouts, contenido estático
- Client Components: interactividad, estado, efectos, acceso al navegador
Ambos pueden coexistir en el mismo árbol, con Client Components renderizando dentro de Server Components.
Cuándo usar Server Components
Acceso directo a datos
Si un componente necesita hacer una consulta a base de datos, llamar a una API interna o leer un fichero de configuración, un Server Component es la opción natural. No necesitas crear un endpoint REST solo para alimentar ese componente.
// app/products/page.jsx (Server Component por defecto en Next.js App Router)
import { db } from '@/lib/db';
export default async function ProductsPage() {
const products = await db.products.findMany();
return <ProductList products={products} />;
}
Sin “useEffect”, sin fetch desde el cliente, sin estado de carga. El componente es asíncrono y los datos llegan directos.
Contenido que no necesita interactividad
Páginas de blog, fichas de producto, dashboards de solo lectura, documentación… Si el usuario no necesita interactuar con ese bloque de IU, no hay razón para enviarlo como JavaScript.
Reducir el bundle del cliente
Librerías pesadas como parsers de Markdown, date formatters o clientes de CMS pueden importarse en un Server Component sin que el usuario descargue ni una sola línea de ese código. En aplicaciones grandes, la diferencia en el Time to Interactive puede ser notable.
Cuándo evitar los Server Components
Cuando necesitas estado o interactividad
Cualquier componente que use useState, useReducer, useEffect o event handlers (onClick, onChange…) debe ser un Client Component. Intentar usar estos hooks en un Server Component lanzará un error en tiempo de ejecución.
'use client'; // necesario
import { useState } from 'react';
export function Counter() {
const [count, setCount] = useState(0);
return <button onClick={() => setCount(count + 1)}>{count}</button>;
}
Cuando trabajas con APIs del navegador
En las aplicaciones de cliente, desarrolladas con React u otras librerías o frameworks, se pueden usar la navegación nativa como: window, localStorage, navigator, canvas, Web APIs en general: nada de esto existe en el servidor. Si tu componente depende de estas APIs, es un Client Component sin discusión.
Cuando la lógica cambia en tiempo real
Actualizaciones en tiempo real, suscripciones a websockets, polling… requieren estar en el cliente. Un Server Component se ejecuta una vez en el servidor durante la request y no puede «escuchar» eventos posteriores.
Cuando el contexto de React es necesario
Los providers de contexto (React.createContext) solo funcionan en Client Components. Si necesitas compartir estado global con Context API, tendrás que envolver tu árbol en un Client Component, aunque los hijos puedan seguir siendo Server Components.
Errores comunes al empezar con Server Components
- Marcar todo como «use client» por defecto. Es el error más habitual. Si añades «use client» a todos tus componentes «para evitar problemas», pierdes todos los beneficios de los Server Components.
- Pasar funciones como props desde Server a Client Components. Las funciones no son serializables, por lo que no pueden pasarse directamente entre la frontera server/client. Hay que usar Server Actions o rediseñar la arquitectura.
- Asumir que los Server Components reemplazan la caché. Los Server Components ejecutan código en cada request. Por lo que una base de datos rápida en caso de refrescar la caché es esencial.
¿Dónde merece adoptarlos?
Si trabajas con Next.js, los Server Components son el comportamiento por defecto y vale la pena entenderlos bien en lugar de evitarlos. La curva de aprendizaje existe, pero es mucho más clara y limpia que otros frameworks: cada componente vive donde tiene sentido que viva.
Si trabajas en una SPA pura sin framework con soporte explícito para RSC, todavía no es el momento. Los Server Components requieren infraestructura específica y no se pueden usar con Vite o Create React App.
La clave está en no tratarlos como una solución universal, sino como una herramienta más dentro de la arquitectura. Usados donde corresponde, reducen la complejidad, mejoran el rendimiento y simplifican el acceso a datos. Usados donde no corresponde, añaden fricción sin ningún beneficio real.
Conclusión
Los React Server Components representan un cambio real en cómo pensamos la arquitectura de aplicaciones React, no solo una optimización. La división entre lo que pertenece al servidor y lo que pertenece al cliente obliga a tomar decisiones más conscientes sobre dónde vive cada pieza de lógica.
¿Quieres seguir aprendiendo todo sobre desarrollo de software? ¡Síguenos en redes sociales y en nuestro canal de YouTube!