CSR vs SSR: cómo el servidor pinta primero

Curso de Server Side Render o SSR con React.js

Contenido del curso

No sé dónde empezar

Fundamentos de SSR

Crea tu primer app con SSR

Bonus

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:005:55

CSR vs SSR: cómo el servidor pinta primero

Curso de Server Side Render o SSR con React.js

Clase 4 de 17

Clase 4 / 17

Recursos

Si trabajas con aplicaciones web modernas y te importa el SEO, la velocidad inicial de carga y la seguridad del cliente, entender el server side rendering (SSR) frente al client side rendering (CSR) te va a ahorrar muchos dolores de cabeza. Aquí te explico cómo funciona cada uno, qué pasa paso a paso en el navegador y cuándo conviene elegir SSR sobre una single page application.

¿Qué problema resuelve el server side rendering?

Las single page applications tienen una alta dependencia de JavaScript. Eso significa que el árbol de elementos del DOM no se genera hasta que el JavaScript se ejecuta en el navegador, lo que arrastra dos consecuencias incómodas: problemas de SEO y problemas de performance. Y conforme la app crece, el bundle se vuelve más pesado.

El server side rendering aparece para reducir ese golpe inicial. En lugar de esperar a que tu navegador descargue y ejecute todo el JavaScript, el servidor manda una primera fotografía del HTML, una especie de template en formato string, y mientras tanto descarga en paralelo el CSS y el JavaScript que tu aplicación necesita.

¿Qué es el server side rendering? Es una técnica de renderizado donde el servidor envía un HTML inicial ya construido al cliente. El navegador muestra contenido casi de inmediato, mientras descarga el JavaScript en paralelo para activar la interactividad.

¿Cómo funciona el client side rendering paso a paso?

El flujo del client side rendering es el que usan las SPAs de toda la vida y se ejecuta así:

El cliente solicita la página al servidor.
El servidor responde con un primer archivo HTML prácticamente vacío.
La aplicación pide el index.js, que es el entry point o punto de entrada.
Una vez descargado, el navegador ejecuta el index.js y arranca React.
React genera el árbol del DOM y por fin puedes interactuar con la app.

Lo crítico aquí: durante las primeras tres fases solo ves una pantalla en blanco o una pantalla de carga. No hay nada pintado hasta que React se ejecuta [00:50].

¿Cómo cambia el flujo con server side rendering?

El recorrido del server side rendering se ve distinto:

El cliente pide al servidor la respuesta inicial.
El servidor responde directamente con un string HTML ya armado.
El navegador empieza a dibujar elementos casi de inmediato.
Mientras eso ocurre, se descarga el index.js en paralelo.
Se ejecuta React y la aplicación queda totalmente interactiva.

La diferencia clave es visual y perceptiva: en SSR solo el primer paso muestra una pestaña en blanco, después ya hay elementos del DOM en pantalla. La interactividad llega al final, pero el usuario nunca siente que la página está "muerta" [02:30].

¿Cuándo debes usar server side rendering en tu aplicación?

No es una decisión automática, depende del proyecto. Te recomiendo SSR cuando se cumplen estas condiciones:

Tienes una aplicación con múltiples rutas y el SEO es prioridad, porque los buscadores reciben HTML listo para indexar.
Necesitas un performance alto en el primer pintado, ya que la respuesta inicial muestra el HTML mucho más rápido.
Quieres aumentar la seguridad del lado del cliente, porque reduces la dependencia de JavaScript ejecutándose en el navegador.

¿Qué es el entry point en una SPA? Es el archivo JavaScript principal, normalmente index.js, que el navegador descarga y ejecuta para arrancar el framework, generar el DOM y habilitar la interactividad.

¿Qué conceptos clave deberías dominar?

Para moverte con soltura entre estos dos mundos, vale la pena tener claros varios términos que aparecen en el flujo:

Single page application (SPA): aplicación que carga una sola página y reemplaza el contenido con JavaScript [00:05].
Client side rendering: el navegador hace todo el trabajo de renderizado tras descargar el JavaScript [00:30].
Server side rendering: el servidor envía HTML pre renderizado en la respuesta inicial [00:55].
DOM: el árbol de elementos que el navegador construye para representar la página.
Respuesta inicial: el primer HTML que el servidor entrega al cliente, distinto en CSR y SSR.
Entry point: el archivo JavaScript que dispara la ejecución del framework, como React.

La idea central es simple: cuanto antes vea contenido tu usuario, mejor experiencia y mejor SEO. SSR adelanta ese momento porque convierte al servidor en el primer pintor de la página, mientras el navegador termina de cargar lo demás.

¿Ya tienes claro en qué proyecto aplicarías server side rendering primero? Cuéntame en los comentarios qué problema de tu app actual crees que se resolvería con esta técnica.

Fundamentos de SSR

Por qué React necesita server-side rendering

Problemas reales de las SPAs con JavaScript

Creación y Funcionamiento de una SPA con Create React App

CSR vs SSR: cómo el servidor pinta primero

Ventajas y desventajas del server-side rendering

Crea tu primer app con SSR

Proyecto Helix Eye: de CSR a SSR

Webpack para servidor Node con TypeScript

Servidor Express con TypeScript desde cero

Función template HTML dinámica en TypeScript

renderToString y StaticRouter en el servidor

Hidratación de React con hydrateRoot en SSR

Prefetching de API en el servidor con Axios

Inyectando initialProps del servidor a React

Cómo inyectar estilos de SSR sin flickering

Bonus

Hot Module Replacement con Webpack y Express

Tu motor SSR vs Next.js en práctica

Helix Eye como proyecto de portafolio

CSR vs SSR: cómo el servidor pinta primero

Progreso del curso

Fundamentos de SSR

Crea tu primer app con SSR

Bonus

Recursos

Recursos