¿Qué es el Server Side Rendering del que todos hablan? ¿En qué consiste el renderizado del lado del servidor? Bueno, para comenzar, definamos qué es SSR: El documento HTML de una página web, es renderizado -generado- en el servidor y es enviado en respuesta al cliente (navegador). ✅ En otras palabras: el servidor es el encargado de generar el HTML de una página web. Esto es diferente a lo que actualmente hacen las Single Page Web Apps (Aplicaciones web de página única), que crean su propio árbol de componentes en el cliente ayudándose de una copia virtual del DOM. ⚛️

Pero, para entender mejor, vamos a visualizar:

Seguro conoces este diagrama: ¡es nuestro viejo amigo! request/response ¿En qué momento lo cambiamos por SPAs? 🤦🏻‍♀️

Trabajar con fetch únicamente, sin aprovechar el ciclo request/response, es re-hacer a mano mucho de lo que el navegador ya administra por nosotros. 😰

El SSR genera todo el contenido en HTML para ser enviado como respuesta a la primera petición GET del cliente.

Entre muchas otras ventajas, existe la de incluir contenido proveniente de una base de datos o API. el servidor puede incluir esta información en el HTML sin necesidad de JavaScript, y puede estar lista desde el primer render. ✅

Lo que ya no hacemos

En una SPA (Single Page App): el servidor solo responde al cliente una vez, la primera vez, pues entregar tu SPA. Digamos que entrega un app React por ejemplo, esta, al llegar al navegador, comienza a trabajar; muestra muchos spinners y ****muta el sitio web consiguiendo datos con múltiples peticiones fetch**, incluso, solo para dibujar la home page. 🏋🏻‍♀️

Esto tiene beneficios para el UX: solo si el usuario sigue navegando dentro del sitio (pues todo es muy rápido después). El primer render es el más lento de todos, pues se descarga el app por completo, se enciende (esto le toma tiempo) y después, hace más peticiones al servidor para conseguir más datos. Sin embargo existen estadísticas que indican que el pimer render es el más importante y que perdemos una gran cantidad de usuarios solo porque la primer carga es pésima en una SPA. Sin mencionar que la experiencia del desarrollador al mantener una SPA y administrar un estado global en el cliente, puede ser muy tediosa. 🥲

Lo que preferimos

Con el SSR (Server Side Rendering) cada petición llega al servidor, en vez de ser interceptada y simulada, como hace una SPA. La primer petición GET es recibida por el servidor que genera la página HTML e incluye contenido de tu base de datos. Respondiendo con un documento HTML “pre-renderizado” permitiendo que el usuario perciba la carga como instantánea y pueda inmediatamente leer el documento, sin hacerlo esperar por más datos. En los frameworks más modernos podemos encontrar la capacidad de combinar este “primer server render” (casi instantáneo) con las habilidades de una SPA y comenzar a simular el ruteo después de esa primer petición y consumir el resto de las páginas con fetch.

A esto se le conoce con muchos nombres, en el mundo de React podría ser hidratación y Astro las llama islas, Remix es excelente en esto gracias a react-router. ✅ 🏝️ 💿

Afortunadamente, esta generación/renderizado es lo que nuestro servidor sabe hacer mejor y no le es difícil ejecutar su tarea a tiempo. Es un servidor web, nació para esto. 😎

👀 ¡Ojo! Otra ventaja importantes para preferir SSR es: que se puede hacer uso de la CACHE tanto de la Fetch API, como de la del navegador. Puedes almacenar las respuestas a peticiones similares y así no procesar nada, solo devolver el archivo generado previamente para otra petición. Y también tenemos capacidades SPA desde SSR hoy en día. 🤖

Lo más destacado

Algo que está volviendo al desarrollo web, es la generación de contenido y sitios enteros SIN JS. No es que JS sea malo, es que abusamos de él, poniendo a trabajar demasiados recursos del navegador y haciendo esperar mucho a nuestros usuarios para colocar interacciones innecesarias. Los sitios web sin JS están pensados para trabajar solo con contenido (texto) y ofrecer una experiencia más cómoda, ligera y extremadamente rápida. ⚡️ Una vez que nuestro usuario tiene un documento que puede leer, podemos pasar a la carga del JS, no antes. Podemos “enchular” (pimpear) con un poquito de JS, nomás una pizca, como la sal. 🧂 Pero después de que tenemos un documento HTML pre-rederizado en el servidor.

Aquí también existen optimizaciones muy espectaculares, como el streaming. Con el HTML streaming, puedes mostrar un documento HTML cachito por cachito conforme el servidor los va entregando, logrando con esto una sensación superior a la instantánea. 🤯

👀 React quiere explotar el streaming en su versión 19 enviando cachitos de componentes. 🧩

La mayor ventaja: la optimización SEO

Sí, el SEO definitivamente. ✅

El SSR, es la mejor manera de manipular las etiquetas <meta> de tu sitio web, desde el servidor. Con un control total sobre lo que se muestra, incluso de forma dinámica, colocando en nuestras etiquetas la información correcta desde el primer rénder, lo que beneficia la indexación en Google y la previsualización correcta en redes sociales. 🎩

👀 React v19 ya contará con la habilidad de agregar etiquetas <meta> en una SPA. 🤯 Enterate aquí.

SSR con Next.js

El framework Next.js soporta SSR, puedes pre-renderiza las páginas en el servidor en cada petición (Request). Este framework nos provee de una función llamada:getServerSideProps()

// ...
export async function getServerSideProps(context){
	return { props:{} }
}

El objeto context, contiene llaves con los objetos Request y Response, params, queryStrings, etc. Aquí podemos conseguir datos desde la DB y colocarlos como props en nuestros componentes React. ✅

SSR con Remix.run

El framework Remix soporta SSR entre otros. Remix va a conseguir los datos con su función loader y los pondrá a disposición del componente React gracias a un hook llamado useLoaderData, así, el desarrollador front end no sufre cambios en su forma típica de trabajar con React. ✅

Esta, es ya la forma estandarizada para trabajar incluso con react-router-dom, pues Remix proviene de los mismos creadores del router más consentido de la comunidad React, con más de 10 millones de descargas a la semana. 🤓

export async function loader({request, params}){
	return tuDB.users.findOne({_id:params.id});
}
//...
export default function Component(){
	const user = useLoaderData();
return <h2>¡Hola 👋 {user.displayName}!</h2>
}

Depende de qué te guste más, a mí me gusta la simplicidad, por eso me voy con Remix. 💿 😉

Pero Next.js es más popular. 💅🏼

Componentes React para servidor

Un componente de React puede ser renderizado de forma isomórfica, y esa es la razón de que estos frameworks puedan ofrecer SSR. Es decir, un componente React puede ser generado tanto en el navegador como en el servidor, a esto se le conoce como JavaScript Universal. ✅

Vamos a ilustrar el Universal JS usando las herramientas que React nos ofrece para trabajar con SSR y devolver un Server Component con express.js:

app.get('/', (req,res)=>{
	const stringifiedAppComponent = ReactDOMServer.renderToString(<App />);
})

Si lo anterior se combina con la herramienta: ReactDOM.hydrate(<App/>, root), es posible construir tu propio SSR con React sin usar un framework (excepto express o Hono claro).

¡Pues ya está! Yo creo que esto funciona bien como introducción. 👏🏼

Es momento de que investigues por tu cuenta, un buen lugar para leer sobre el SRR pero en un mundo paralelo al de React, es en esta documentación (inglés). 🤓

Espero hayas aprendido algo nuevo hoy.

No olvides que puedes aprender más en mi curso.

Abrazo. Bliss. 🤓

Enlaces relacionados (links)

React 19 ya está aquí

Remix te interesa

Digital Ocean tutorial