Elegir entre server-side rendering y single-page application define cómo se carga, navega y siente tu aplicación web. Esta decisión de arquitectura frontend impacta velocidad, experiencia de usuario y la forma en que React Router se configura en tu proyecto.

Si estás aprendiendo React o diseñando el flujo de navegación de una app, entender estos dos enfoques te abre los ojos a por qué algunas páginas cargan rapidísimo al inicio y otras navegan sin recargar nunca. Aquí te explico cómo funciona cada uno, sus ventajas, sus costos y cómo se combinan.

¿Qué es el server-side rendering y cómo funciona?

El server-side rendering (SSR) parte de una idea simple: el backend es la madre de todo. Cada vez que haces una solicitud, el backend la recibe y decide qué responder.

En el flujo SSR, el backend te devuelve un documento HTML ya con el contenido insertado. Si entras al blog de Platzi, el servidor arma el HTML con título, imágenes y texto, y tu navegador solo lo renderiza [01:30].

¿Qué es el server-side rendering? Es la estrategia donde el backend genera un HTML completo con datos ya insertados y se lo envía al navegador en cada solicitud. El cliente solo lo muestra.

¿Qué pasa cuando el usuario navega en SSR?

La navegación usa etiquetas a (anchors, links) que disparan el comportamiento normal del navegador: una nueva petición al backend [02:00]. El servidor recibe esa nueva ruta (/about, /blog, lo que sea), genera otro HTML desde cero y lo envía.

Eso significa que cada cambio de ruta es una nueva carga completa. El navegador procesa todo otra vez desde el inicio.

¿Qué es una single-page application y por qué es distinta?

Una single-page application (SPA) usa una sola página HTML para toda la app. El backend te entrega un HTML prácticamente vacío: un div con id="root" y un script enlazado a un archivo JavaScript [03:30].

Ese JavaScript se encarga de todo lo demás. Manipula el DOM, hace consultas a APIs REST, recibe JSON y muestra la información a los usuarios. La comunicación es bidireccional, no un monólogo del backend.

En una SPA, los botones y enlaces ya no usan etiquetas a tradicionales. Cada interacción se escucha con event listeners en JavaScript, se traduce en una consulta a una API y la respuesta se inserta en el DOM sin recargar la página.

¿Qué es client-side rendering y client-side routing?

El client-side rendering es la técnica de renderizar el contenido desde el navegador con JavaScript. El client-side routing es manejar la navegación entre rutas también desde el cliente, sin pedirle al backend un HTML nuevo cada vez [05:00].

¿Qué diferencia hay entre client-side rendering y server-side rendering? En CSR el navegador construye y actualiza el contenido con JavaScript usando un solo HTML. En SSR el backend genera un HTML nuevo por cada ruta solicitada.

Una SPA usa ambas estrategias: un solo HTML, todo el render y la navegación ocurren en el cliente.

¿Cuáles son las ventajas y desventajas de cada estrategia?

Cada enfoque brilla en momentos distintos, así que la decisión depende del tipo de aplicación que estés construyendo.

Ventajas y costos del server-side rendering

• Primera carga muy rápida, porque el HTML llega listo desde el backend [06:30].
• Mejor para SEO, ya que los buscadores reciben contenido renderizado.
• Navegación más lenta, porque cada cambio de ruta requiere una nueva consulta y un nuevo render del backend.
• Tiempo muerto entre páginas: si el internet falla, la app puede quedarse en blanco.

Ventajas y costos del client-side rendering

• Primera carga más lenta, porque el HTML inicial está vacío y JavaScript debe pedir los datos [07:30].
• Navegación muy rápida entre rutas, ya que solo se piden JSON, no HTML completos.
• Control sobre los estados de carga: puedes mostrar un loading skeleton mientras llega la información.
• Resiliencia offline: con JavaScript puedes detectar si se cae el internet y avisar al usuario sin que la app se rompa.

¿Qué es progressive server-side rendering y por qué importa?

La fusión entre ambos mundos se llama progressive server-side rendering. La idea es que el backend genere ese primer HTML completo para una primera carga rápida, y luego la aplicación se transforme en una SPA para la navegación posterior [09:30].

Para lograrlo, React aplica un proceso llamado hidratación: toma el HTML inicial y lo conecta con el JavaScript que controlará la app desde ese momento. Una vez hidratado, cada interacción se maneja con consultas a APIs y manipulación del DOM, no con nuevas cargas del servidor.

Es la mejor estrategia que existe hoy, pero también la más compleja. La hidratación exige que el HTML del servidor coincida con el que JavaScript renderizaría en el cliente. Herramientas como los React Server Components ayudan a optimizar este proceso.

¿Por qué importa esto al usar React Router?

React Router se configura distinto según la estrategia. Si trabajas con una SPA, usarás client-side routing puro. Si tu proyecto usa SSR o progressive SSR, la navegación necesita otro tipo de configuración.

Saber qué estrategia usa tu app es el primer paso para elegir bien las herramientas y evitar comportamientos raros en producción.

Cuéntame en los comentarios qué estrategia usa tu Doomachine: ¿server-side rendering, single-page application con client-side routing, o crees que deberías migrar a otra si empiezas a agregarle rutas?