CSR vs. SSR: ¿Dónde Debería Renderizarse tu Web?
El peso de la decisión: ¿Cliente o Servidor?
Hace algunos años, el modelo tradicional de las aplicaciones multipágina (MPA) era predecible: el usuario pedía una página, el servidor armaba el HTML y lo enviaba listo para mostrar. Pero con el auge de las bibliotecas y frameworks de JavaScript (como Angular, React o Vue) y las Single Page Applications (SPA), le pasamos gran parte de la responsabilidad de renderizado al navegador.
En el CSR, el navegador recibe las piezas (JavaScript) y debe hacer el esfuerzo de armar la interfaz en tiempo real.
Hoy, al definir la arquitectura de un proyecto, nos enfrentamos a una decisión fundamental que suele reducirse a dos grandes enfoques: CSR (Client-Side Rendering) y SSR (Server-Side Rendering). Entender los matices de cada uno es clave para optimizar la experiencia de usuario y nuestras métricas.
CSR: El navegador hace el trabajo pesado
En un enfoque de Client-Side Rendering puro, el servidor entrega un shell (caparazón) de HTML con un marcado mínimo —por lo general, un simple <div id="root"></div>— junto con los recursos estáticos necesarios.
En esta arquitectura, el navegador debe obtener y ejecutar el código JavaScript antes de poder generar y mostrar la interfaz que depende de él.
El impacto: Si enviamos un bundle (paquete de código) demasiado grande, o si el usuario navega desde un dispositivo modesto o una red lenta, podemos experimentar un retraso perceptible que empeora métricas como el FCP (First Contentful Paint) o el INP (Interaction to Next Paint). Esto no significa que haya una pantalla en blanco inevitable; podemos mitigarlo usando técnicas como code-splitting (dividir el código) o mostrando un estado de carga inicial.
A nivel SEO, aunque los rastreadores modernos como Googlebot pueden ejecutar JavaScript y procesar páginas CSR, depender exclusivamente del cliente introduce ciertas condiciones. Si los recursos se bloquean o la ejecución demora demasiado, parte del contenido podría no indexarse correctamente.
Sin embargo, el CSR brilla en la interacción continua: al delegar el enrutamiento al cliente, evitamos recargas completas de la página. Las transiciones entre vistas suelen actualizarse pidiendo solo datos o payloads parciales (como JSON) a una API, logrando una sensación de mayor fluidez.
SSR: El regreso al servidor y la "Hidratación"
El Server-Side Rendering moderno consiste en generar el HTML en el servidor y enviarlo al navegador. Esto puede hacerse procesando datos bajo demanda en cada petición, reutilizando respuestas desde una caché, o incluso transmitiendo el documento por partes (Streaming).
En el SSR, el servidor hace el trabajo pesado y entrega la interfaz ya procesada y lista para mostrarse.
Al recibir un documento con el contenido ya estructurado, el navegador puede pintarlo en pantalla mucho antes, favoreciendo un FCP temprano. Esto facilita el trabajo de los rastreadores web (incluso aquellos que no procesan JavaScript) y reduce los riesgos de indexación, aunque generar el HTML en el servidor en tiempo real puede aumentar el TTFB (Time to First Byte) inicial si no aplicamos estrategias de caché.
Pero acá entra un concepto técnico crucial: la Hidratación. Ese HTML inicial es, al principio, estático. En segundo plano, el navegador debe ejecutar el JavaScript de la aplicación para reconciliar el estado con ese árbol HTML y adjuntar los event listeners (como los clics en los botones) para que la página se vuelva interactiva. Hoy en día, arquitecturas avanzadas permiten incluso hacer "hidratación parcial" para ejecutar código solo en los componentes que realmente lo necesitan.
Eligiendo la arquitectura correcta
No hay una opción superior a la otra, sino herramientas distintas que deben evaluarse según las métricas de visibilidad, latencia y costos:
- CSR suele priorizarse para aplicaciones web complejas, paneles de administración autenticados o herramientas internas (como un CRM). En estos escenarios, la indexación pública no es prioridad y buscamos aprovechar al máximo el enrutamiento del lado del cliente.
- SSR (o enfoques como Static Site Generation) es una excelente opción cuando el contenido público es dinámico y la visibilidad orgánica es vital. Blogs, e-commerces y portales de noticias se benefician de entregar HTML renderizado para facilitar el rastreo y mejorar la percepción inicial de carga.
Medir la experiencia real de nuestros usuarios y conocer a fondo cómo renderiza nuestra aplicación nos permite evitar sobrecargar al servidor cuando no hace falta, o saturar el dispositivo del usuario de forma innecesaria.
