Métodos de Renderizado: CSR, SSR, SSG e Hidratación

Los frameworks modernos de frontend ofrecen varias estrategias para entregar contenido al navegador. Elegir la correcta puede afectar drásticamente el rendimiento, el SEO y la experiencia del usuario. Este artículo cubre los cuatro métodos de renderizado más importantes — CSR, SSR, SSG e Hidratación — con un diagrama para cada uno.

Client-Side Rendering (CSR)

En CSR el navegador descarga una carcasa HTML mínima y un bundle de JavaScript. El JS se ejecuta en el navegador, obtiene los datos y construye la página completa en el cliente.

Frameworks: React (CRA / Vite SPA), Vue (Vite SPA), Angular

Cómo funciona el CSR paso a paso

El navegador solicita la página → el servidor devuelve un archivo HTML casi vacío
El navegador descarga el bundle de JavaScript
El JS se ejecuta en el navegador y construye el DOM
Se obtienen datos de las APIs y se renderiza la interfaz

⚠️ La página está completamente en blanco hasta que el bundle de JS se ha descargado y ejecutado. Esto perjudica tanto el rendimiento percibido como los crawlers de SEO que no ejecutan JS.

Ventajas y desventajas

✅ Ventajas	❌ Desventajas
Interacciones ricas, tipo aplicación	Carga inicial lenta (pantalla en blanco)
Baja carga en el servidor	SEO deficiente por defecto
Despliegue sencillo (hosting estático)	Bundles de JS grandes
Navegación rápida tras la primera carga	Requiere JS habilitado

Ideal para: Dashboards, paneles de administración, apps detrás de un login, herramientas en tiempo real.

Server-Side Rendering (SSR)

Con SSR el servidor genera el HTML completo en cada solicitud. El navegador recibe una página completa y legible de inmediato. Después el JavaScript se ejecuta para hacer la página interactiva.

Frameworks: Next.js (getServerSideProps), Nuxt.js, SvelteKit, Remix

sequenceDiagram participant B as 🌐 Navegador participant S as 🖥️ Servidor participant D as 🗄️ Base de datos / API B->>S: GET /pagina S->>D: Consulta de datos D-->>S: Respuesta con datos Note over S: Renderiza el HTML completo en el servidor S-->>B: Página HTML completa ✅ Note over B: Contenido visible de inmediato (FCP rápido) B->>S: GET /bundle.js S-->>B: Bundle JS Note over B: Hidratación — la página se vuelve interactiva ✅

Cómo funciona el SSR paso a paso

El navegador envía una solicitud para una página
El servidor obtiene datos de la base de datos o API
El servidor renderiza el HTML completo y lo envía al navegador
El navegador muestra el HTML de inmediato (First Contentful Paint rápido)
El navegador descarga el JS e hidrata la página para agregar interactividad

⚠️ Todo este ciclo se ejecuta en cada solicitud. El servidor debe estar disponible, ser rápido y escalar horizontalmente.

Ventajas y desventajas

✅ Ventajas	❌ Desventajas
Excelente SEO	Mayor carga en el servidor por solicitud
Pintura inicial rápida (contenido visible)	Infraestructura más compleja
Datos dinámicos y siempre frescos	Retrasos de arranque en frío (serverless)
Funciona sin JS	Más lento que servir archivos estáticos

Ideal para: Páginas de productos en e-commerce, artículos de noticias, páginas que necesitan datos frescos en cada visita.

Static Site Generation (SSG)

SSG pre-renderiza todas las páginas en tiempo de compilación. El resultado es un conjunto de archivos HTML estáticos desplegados en una CDN. No se necesita servidor en tiempo de solicitud.

Frameworks: Next.js (getStaticProps), Gatsby, Astro, Hugo, Eleventy

flowchart TD subgraph Build["🔨 Tiempo de Compilación — se ejecuta una vez"] C["📁 Contenido\nMD / JSON / CMS"] --> BT["⚙️ Herramienta de Build\nNext.js / Gatsby"] BT --> H["📄 Archivos HTML Estáticos"] H --> D["🚀 Despliegue a CDN\nVercel / Netlify / S3"] end subgraph Runtime["🌍 Tiempo de Solicitud — instantáneo"] Browser["🌐 Navegador"] -->|"GET /pagina"| Edge["☁️ Nodo CDN Edge\ncaché global"] Edge -->|"HTML pre-construido ⚡"| Browser end D --> Edge

Cómo funciona el SSG paso a paso

En tiempo de compilación, el framework obtiene todos los datos y renderiza cada página a HTML
Los archivos HTML se suben a una CDN
En tiempo de solicitud, el navegador obtiene el HTML pre-construido del nodo CDN más cercano — sin ejecución en el servidor

⚠️ Los datos pueden quedar desactualizados entre compilaciones. Se requiere un nuevo despliegue para cambios de contenido, a menos que se use ISR (Incremental Static Regeneration).

Ventajas y desventajas

✅ Ventajas	❌ Desventajas
Extremadamente rápido (archivos desde CDN)	Los datos pueden quedar desactualizados
Excelente SEO	Se requiere recompilar para cambios de contenido
Altamente escalable (sin servidor)	Tiempos de build largos en sitios grandes
Muy seguro	No apto para páginas personalizadas por usuario

Ideal para: Blogs, sitios de documentación, páginas de marketing, portfolios.

Hidratación

La hidratación es el proceso que hace interactiva una página renderizada en el servidor o generada estáticamente. El navegador recibe el HTML completo (pintura rápida), luego se carga el JS y se "conecta" al DOM existente — adjuntando event listeners y estado sin volver a renderizar.

flowchart TD A["① HTML del Servidor\n📄 HTML completo enviado\nVisible ✅\nNo Interactivo ❌"] B["② Bundle JS Cargando\n⬇️ Descargando...\nVisible ✅\nNo Interactivo ❌"] C["③ Hidratando\n💧 Adjuntando eventos\nVisible ✅\nParcial ⚠️"] D["④ Interactivo\n✅ El framework controla el DOM\nVisible ✅\nInteractivo ✅"] A -->|El navegador recibe| B B -->|JS se ejecuta| C C -->|Completo| D style A fill:#f1f5f9,stroke:#94a3b8,color:#334155 style B fill:#dbeafe,stroke:#3b82f6,color:#1e40af style C fill:#fef9c3,stroke:#eab308,color:#713f12 style D fill:#dcfce7,stroke:#22c55e,color:#166534

El problema de la Hidratación

La hidratación introduce el concepto de Time To Interactive (TTI): la página parece lista pero no es clicable hasta que el JS termina de hidratarse. En redes lentas o bundles de JS grandes, esta brecha frustra a los usuarios.

FCP ─────────────────────────────────► TTI
(página visible)                      (página usable)
     │◄─── JS descarga + hidrata ────►│

Soluciones modernas

Hidratación Parcial — solo hidratar componentes interactivos (Astro Islands)
Hidratación Progresiva — hidratar a medida que los componentes entran en el viewport
Resumability — saltar la hidratación completamente serializando el estado (Qwik)

Comparación de todos los métodos

quadrantChart title Velocidad vs SEO — Dónde se sitúa cada método x-axis "Carga inicial lenta" --> "Carga inicial rápida" y-axis "SEO deficiente" --> "SEO excelente" quadrant-1 Ideal quadrant-2 Bueno para contenido quadrant-3 Uso limitado quadrant-4 Orientado a apps CSR: [0.40, 0.15] SSR: [0.58, 0.88] SSG: [0.92, 0.92] Hybrid SSR+SSG: [0.75, 0.88]

	CSR	SSR	SSG	Híbrido (SSR+SSG)
Velocidad de carga inicial	🔴 Lenta	🟡 Media	🟢 Rápida	🟢 Rápida
SEO	🔴 Deficiente	🟢 Excelente	🟢 Excelente	🟢 Excelente
Frescura de datos	🟢 Tiempo real	🟢 Por solicitud	🔴 Tiempo de build	🟡 Configurable
Coste de servidor	🟢 Bajo	🔴 Alto	🟢 Ninguno	🟡 Medio
Escalabilidad	🟡 Media	🔴 Más difícil	🟢 Excelente	🟢 Buena
Interactividad	🟢 Rica	🟡 Tras hidratación	🟡 Tras hidratación	🟡 Tras hidratación
Complejidad	🟢 Simple	🟡 Media	🟢 Simple	🔴 Compleja

Cuándo usar cada método

Usa CSR cuando:

Construyes apps con autenticación (dashboards, paneles de administración)
Los datos cambian frecuentemente y el SEO no importa
Necesitas interacciones complejas del lado del cliente

Usa SSR cuando:

Las páginas necesitan datos frescos en cada solicitud
El SEO es crítico y el contenido cambia frecuentemente
Construyes plataformas de e-commerce o redes sociales

Usa SSG cuando:

El contenido no cambia frecuentemente (blogs, docs, portfolios)
Quieres máxima velocidad y coste de servidor cero
Las páginas son iguales para todos los usuarios

Usa Híbrido (SSG + SSR + ISR) cuando:

Algunas páginas son estáticas y otras dinámicas
Necesitas reconstrucciones incrementales (ISR) para mantener las páginas estáticas actualizadas
Quieres control del método de renderizado por página

El consenso moderno: La mayoría de las apps en producción se benefician de un enfoque híbrido. Frameworks como Next.js, Nuxt.js y SvelteKit permiten elegir la estrategia de renderizado por página, de forma que puedes generar estáticamente tus páginas de marketing mientras renderizas en servidor tus listados de productos y en cliente tu dashboard.