Renderizado en Cliente vs. Servidor: Diferencias y Funciones

Contenido del curso

Entendiendo el rendimiento

Antes de optimizar...

Crítical Rendering Path

CSS

WebFonts

14
Optimización de WebFonts para Mejorar el Rendimiento Web
15:30 min

Imágenes, Iconos y SVG

Aplicaciones JavaScript

Caché

Performance Budget

Conclusiones

38
Optimización del Critical Render Path en Aplicaciones Web
02:04 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:008:44

Renderizado en Cliente vs. Servidor: Diferencias y Funciones

Curso de Optimización Web

Clase 28 de 38

Clase 28 / 38

Recursos

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.

Entendiendo el rendimiento

Optimización Avanzada de Páginas Web con Técnicas Prácticas

Optimización de Sitios Web para Mejorar Conversión y Experiencia Usuario

Optimización del Rendimiento Web: Modelo RAIL de Google

Antes de optimizar...

Medición del Rendimiento Web con Chrome DevTools y Lighthouse

Métricas de Experiencia de Usuario: LCP, FID y CLS

Instalación y Configuración de Proyecto Web con Git y Webpack

Crítical Rendering Path

Entendiendo el Critical Rendering Path en Navegadores Web

Optimización de JavaScript para mejorar rendimiento web

Priorización de recursos CSS para mejorar rendimiento web

Optimización de Carga de Recursos con Preload, Prefetch y Preconnect

Optimización de Animaciones CSS para Mejorar el Renderizado

CSS

Optimización de Animaciones CSS para Mejorar Rendimiento

Optimización de CSS: Reducir Complejidad y Mejorar Rendimiento

WebFonts

Optimización de WebFonts para Mejorar el Rendimiento Web

Imágenes, Iconos y SVG

Optimización de Imágenes para Web: Formatos y Herramientas Efectivas

Optimización de Imágenes para Web: Uso de Tamaños y Formatos Adecuados

Comparación entre WebFonts y SVG: Ventajas y Desventajas

Lazy Loading de Imágenes: Técnicas y Estrategias Efectivas

Carga Adaptativa de Imágenes con Gatsby y Web API

Aplicaciones JavaScript

Optimización de JavaScript para Producción Web

Análisis y Optimización de Bundles con Webpack

Optimización de Bundles en Proyectos Web con Webpack

Code Splitting con Webpack: Optimización de Bundles en Proyectos Web

Lazy Loading de Videos con JavaScript y Modales

Event Propagation y Filtrado de Eventos en JavaScript

Integración de Librerías en Proyectos JavaScript

Optimización de Carga de Modales con Lazy Loading en Webpack

Renderizado en Cliente vs. Servidor: Diferencias y Funciones

Implementación de Server Side Rendering en NodeJS

Optimización de Sitios con Static Site Generation

Caché

Funcionamiento de Caché y Redes de Distribución de Contenido (CDN)

Configuración y despliegue de sitios web con Netlify y Github Actions

Automatización de despliegues con Github Actions y Cron en Netlify

Implementación de Caché con Service Workers en JavaScript

Performance Budget

Auditoría de Performance Web con Github Actions y Lighthouse

Creación de Pull Request y Auditorías con Github Actions

Monitoreo de Métricas en Sitios Web en Producción

Conclusiones

Optimización del Critical Render Path en Aplicaciones Web

Renderizado en Cliente vs. Servidor: Diferencias y Funciones