¿Dónde se renderiza tu app?
Una app de React produce HTML, pero dónde y cuándo se genera ese HTML cambia mucho el rendimiento y el SEO. Hay tres estrategias clásicas.
CSR — Client-Side Rendering
El servidor envía un HTML casi vacío y un bundle de JavaScript. El navegador descarga, ejecuta React y entonces pinta la interfaz. Es lo que hace una SPA tradicional (p. ej. con Vite o Create React App).
- ✅ Sencillo; tras la primera carga, la navegación es muy fluida.
- ❌ Primera pintura lenta (hay que esperar al JS) y mal SEO: los buscadores reciben una página vacía al principio.
SSR — Server-Side Rendering
El servidor ejecuta React en cada petición y devuelve el HTML ya pintado. El navegador lo muestra de inmediato y, después, React "lo despierta" (proceso llamado hidratación) para hacerlo interactivo.
- ✅ HTML completo desde el primer momento → mejor SEO y primera pintura rápida.
- ❌ Más carga en el servidor (renderiza en cada visita).
SSG — Static Site Generation
El HTML se genera una sola vez al compilar (build time) y se sirve como archivos estáticos desde una CDN. Ideal para contenido que cambia poco (blogs, documentación, landing pages).
- ✅ Rapidísimo y barato (archivos estáticos, cacheables).
- ❌ No sirve para contenido muy dinámico o personalizado por usuario.
Resumen: CSR renderiza en el navegador; SSR en el servidor por petición; SSG en el momento de compilar. La mayoría de frameworks modernos permiten mezclar las tres según la página.
React Server Components (RSC)
Los Server Components son una evolución más reciente: componentes que se ejecutan solo en el servidor y nunca envían su JavaScript al navegador. El servidor renderiza su salida y la manda lista; el cliente recibe menos JS.
- Pueden acceder directamente a la base de datos, leer archivos o usar secretos, porque corren en el servidor.
- No pueden usar estado ni efectos (
useState,useEffect) ni manejadores de eventos: eso es cosa del cliente.
Cuando una parte sí necesita interactividad (un botón con estado, un input),
se marca como Client Component con la directiva "use client" al
principio del archivo:
"use client";
import { useState } from "react";
export function Contador() {
const [n, setN] = useState(0);
return <button onClick={() => setN(n + 1)}>Pulsado {n}</button>;
}
Idea clave: por defecto, en este modelo los componentes son de servidor (cero JS al cliente). Añades
"use client"solo en las "islas" que de verdad necesitan interactividad. Así envías menos JavaScript.
Next.js y el App Router
Next.js es el framework de React más usado para SSR/SSG y Server Components.
Su App Router (la carpeta app/) trata cada componente como de servidor por
defecto y usa "use client" para las islas interactivas. Además, te deja
elegir por página entre renderizado estático (SSG) y dinámico (SSR).
// app/page.tsx → Server Component por defecto
export default async function Pagina() {
const datos = await obtenerDatos(); // se ejecuta en el servidor
return <Lista datos={datos} />;
}
¿Por qué importa?
- Rendimiento: el usuario ve contenido antes (HTML del servidor) y descarga menos JavaScript (Server Components) → la página es utilizable cuanto antes.
- SEO: los buscadores y las redes sociales reciben HTML real con el contenido, no una página vacía a la espera de JavaScript.
No necesitas SSR para todo. Una app interna sin SEO puede vivir bien con CSR. Lo profesional es elegir la estrategia por página según sus necesidades.