SSR con frameworks reactivos.

Cuando trabajamos en una aplicación web es importante tener en cuenta si queremos que nuestro contenido se posicione de manera eficaz en los diferentes buscadores existentes. Huelga mencionar la importancia que el SEO puede tener en una aplicación web. La indexación de nuestro contenido será un punto a tener muy en cuenta para decidir cómo y con qué tecnología haremos que nuestro contenido se renderice.

En este post nos vamos a centrar en el server-side rendering (SSR), ya que comúnmente trabajamos con frameworks reactivos y gran parte del contenido suele ser dinámico, lo que propicia que el renderizado en el servidor sea una opción acertada.

¿Qué es el renderizado de una web?

El renderizado es el proceso mediante el cual se transforma el código HTML (que forma el DOM), CSS (los estilos) y JS (la lógica) en una representación visual del mismo con la que los usuarios puedan interactuar. Cómo y cuándo hacer esta transformación dependerá de la tecnología de renderizado que estemos utilizando.

¿Qué tipos de renderizado existen?

Hay que tener en cuenta que hasta la aparición de los frameworks JS o librerías como jQuery el renderizado siempre se realizaba en el servidor. Debido a esto la mayoría de bots de indexación o spiders no indexan el contenido de los sitios con CSR, ya que no ejecutan JS y no pueden ver el resultado final del contenido.

En la actualidad existen varios tipos de renderizado, aunque los más comunes son el Renderizado en el Lado del Servidor (Server-Side Rendering (SSR)), el Renderizado en el Lado del Cliente (Client-Side Rendering (CSR)) y el Renderizado Estático (Static Rendering o (SR)).

Veamos una pequeña explicación de cómo funcionan los renderizados SCR y SR. Más adelante veremos el SSR de manera más extensa.

Client-Side Rendering (CSR)

Cuando se renderiza en el lado del cliente, el navegador del cliente descarga el código HTML de la página. En esta primera carga podría venir la información o simplemente un HTML vacío. Luego, el navegador descarga y ejecuta scripts JavaScript que se encargan de crear y renderizar dinámicamente el contenido en el lado del cliente. Es el renderizado común en las SPA (Single Page Applications).

Static Rendering

Se genera HTML estático durante la fase de construcción o compilación del sitio web y luego se almacena en el servidor web. El HTML se sirve directamente al navegador del usuario sin necesidad de procesamiento adicional en el servidor o en el lado del cliente.

Antes de la aparición de lenguajes server side (como PHP, Python, Ruby) esta era la forma habitual de servir el contenido.

Server-Side Rendering (SSR)

Como el nombre explica el primer renderizado, en este caso, se efectúa en el lado del servidor.

Veamos cómo funciona.

Un usuario accede a la URL de nuestra aplicación web y el navegador en uso envía una solicitud a nuestro servidor web.
El servidor recibe la solicitud y la procesa. Genera código HTML dinámico en función de las posibles reglas de negocio que afecten a la web, por ejemplo consultando una base de datos y procesando dicha información.
El HTML generado se envía como respuesta al cliente (navegador) y lo muestra (renderiza).
(Opcional) La hidratación (funcionalidades y eventos interactivos), en caso de ser necesaria, se efectuaría en la parte del cliente.

Qué ventajas tiene el SSR

Permite indexar contenido dinámico (SEO).
Permite que la web cargue contenido visible de inmediato en el navegador por lo que mejora la experiencia de usuario.
Mejora la accesibilidad ya que mejora la experiencia en navegadores con soporte limitado para JavaScript.
Mejora el rendimiento en dispositivos con pocos recursos ya que parte del contenido se procesa en el servidor.

SSR en frameworks reactivos

Por describirlo brevemente, un framework reactivo es aquel que se actualiza cuando hay un cambio sin tener que recargar toda la página que estemos visitando.

Sus bondades son muchas y están más que aceptadas, pero los frameworks reactivos, por ejemplo Vue y React (que realmente es una librería) por si solos no permiten indexar el contenido dinámico. Al no indexar ese contenido los buscadores no lo tendrán en cuenta y huelga decir la importancia que el SEO puede llegar a tener en ciertas webs.

Podemos implementar el SSR mediante librerías o bien utilizando un framework que nos proporcione esta funcionalidad. Dos ejemplos de frameworks recomendados serían para estos casos:

Nuxt.js – Basado en VUE

Next.js – Basado en React

¿Cuándo utilizar SSR?

Si trabajamos en un proyecto con alguna de las tecnologías anteriormente citadas (VUE/React), lo cual es algo bastante común puesto que las virtudes que nos proporcionan son más que sabidas y están muy adoptadas por la comunidad, va a ser indispensable renderizar en la parte del servidor siempre que queramos que nuestro contenido dinámico se posicione.

Si el SEO no es un requisito y la carga inicial no es un problema, no tenemos por qué meter SSR con calzador. Como dijimos anteriormente, debemos aplicar la tecnología correcta en cada momento.

Conclusión

Tenemos que ser conscientes de que no siempre las necesidades de nuestras webs se pueden definir de manera binaria. Puede que nos encontremos con un entorno mixto en el cual una parte del contenido se tenga en cuenta para el SEO y haya otro contenido que no necesitemos posicionar. Por ejemplo, un marketplace donde queremos que nuestros productos se tengan en cuenta para el SEO pero en el que el carrito de compra de los usuarios queda fuera de ese scope. En este caso bien podríamos tener un único proyecto con contenido que renderizase en el servidor y otro que no lo hiciese, o incluso tener 2 proyector diferentes, uno enfocado al SEO y otro a las necesidades de los usuarios.

En definitiva, cómo renderice nuestra aplicación es una decisión importante que dependerá de las características y necesidades de cada proyecto. Cuando una de estas necesidades es el posicionamiento SEO, el renderizado en el servidor será una opción muy a tener en cuenta y casi indispensable si trabajamos con una tecnología reactiva.