Renderizado en Cliente vs. Servidor: Diferencias y Funciones

Cuando una aplicación genera su contenido directamente en el navegador del usuario, toda la responsabilidad del procesamiento recae sobre el dispositivo del visitante. Entender dónde ocurre ese proceso de renderizado —si en el cliente o en el servidor— es fundamental para tomar decisiones de arquitectura que impacten el rendimiento y la experiencia de usuario.

¿Cómo funciona el client side rendering?

El client side rendering (CSR) es el modelo en el que el navegador se encarga de construir el HTML visible a partir de JavaScript. El flujo es el siguiente [0:42]:

• El navegador (browser) se conecta al servidor mediante HTTP.
• El servidor responde con un archivo index.html, que es una página prácticamente vacía en cuanto a contenido dinámico.
• El navegador inicia el Critical Rendering Path, un proceso que ya conocemos para interpretar y pintar el HTML recibido.
• Durante la lectura del HTML, el navegador detecta que necesita un archivo llamado bundle.js [2:28].
• Solicita ese archivo al servidor, lo descarga, lo parsea y lo ejecuta.
• Una vez ejecutado, JavaScript se conecta a las APIs necesarias, obtiene la información y la convierte en HTML visible.

Este último paso es la esencia del CSR: todo el contenido principal se genera dentro del navegador del usuario [3:13]. El problema es que nada se muestra hasta que el JavaScript ha sido completamente descargado y ejecutado. En el ejemplo práctico, los carousel items de anime no aparecen hasta que se cumple esa condición [0:16].

¿Qué cambia con el server side rendering?

El server side rendering (SSR) consiste en tomar ese bloque de renderizado que antes ocurría en el cliente y moverlo al servidor [3:32]. El flujo se transforma así [3:46]:

• El navegador hace la solicitud HTTP al servidor.
• Antes de responder con el index.html, el servidor ejecuta JavaScript internamente.
• Ese JavaScript se conecta a las APIs, obtiene los datos y renderiza el HTML en el servidor.
• El HTML resultante se incluye directamente dentro del index.html que se envía al navegador [4:28].

La diferencia es notable: cuando el navegador recibe el archivo, el Critical Rendering Path trabaja principalmente con HTML ya resuelto, porque el contenido dinámico viene pre-construido desde el servidor [4:38].

¿Se sigue enviando JavaScript al navegador?

Sí. En SSR también se envía un archivo bundle.js, pero su propósito cambia [4:52]. En lugar de generar todo el contenido desde cero, este JavaScript se encarga de agregar interactividad: que los botones respondan a clics, que se abran modales o que se ejecuten animaciones. La mayoría del contenido visible ya está resuelto en el HTML.

¿Por qué se menciona Node en este contexto?

Históricamente, el renderizado en el servidor se hacía con tecnologías como PHP, Python o Ruby. Lo relativamente nuevo es realizarlo con Node.js [4:15], lo que permite usar el mismo lenguaje (JavaScript) tanto en el cliente como en el servidor. Esto no significa que sea la única opción; cualquier tecnología de backend puede implementar SSR.

¿Cuáles son las diferencias clave entre CSR y SSR?

• CSR: el servidor envía un HTML vacío y un archivo JavaScript pesado. El navegador construye el contenido tras descargar y ejecutar ese JS.
• SSR: el servidor genera el HTML con el contenido ya incluido. El navegador recibe una página lista para mostrar y solo necesita JS adicional para la interactividad.
• En CSR, la carga de procesamiento está en el dispositivo del usuario.
• En SSR, esa carga se traslada al servidor, lo que suele mejorar el tiempo de primera visualización.

El proceso de handshaking y la resolución de DNS ocurren en ambos casos como parte del protocolo HTTP [1:22], pero la gran diferencia está en qué tan completo llega el HTML al navegador.

Ahora que la diferencia entre ambos modelos está clara de forma visual, el siguiente paso es ver cómo se implementa el server side rendering directamente en código. Si tienes dudas sobre cuándo conviene usar uno u otro enfoque, comparte tu experiencia en los comentarios.