Server Side Rendering (SSR) | Fazt.dev

Cuando hablamos de Frameworks de desarrollo Web Modernos, mucho se escucha el termino Server Side Rendering. Así que la pregunta que muchos pueden tener es, ¿Qué es el Server Side Rendering y porque se ha mencionado tanto en estos ultimos años en el Frontend?

¿Qué es el Server Side Rendering?

Server side Rendering, abreviado SSR, y traducido al español como Renderizado del lado de Servidor, como su nombre indica es un metodo de como convertir archivos en el backend para enviarle informacion preparada al navegador cuando este hace una peticion, todo esto con el objetivo de mejorar 2 cosas:

El SEO (Search Engine optimization) de una aplicación web.
Aumentar la velocidad de carga inicial de tu aplicación, es decir la primera vez que tu sitio es visitado.

Y no se debe confundir con el concepto de Static Site Generation que lo hace esto es crear archivos en el backend antes del despliegue a producción, y un servidor envia estos archivos que no cambian (Archivos estaticos), esto lo puedes ver más a fondo el en articulo ¿Qué son los Static site Generators?

Para poder entender SSR, primero debemos tener en claro como se crean aplicaciones web hoy en día (esto se explica mejor en el video MPA vs SPA).

Actualmente una forma de crear webs, es teniendo proyectos de Backend y Frontend por separados, en el backend puedes usar Frameworks como Express, Django, Laravel, Spring, Ruby on Rails y muchos otros.

Mientras que en el frontend se usa comunmente frameworks de Javascript como React, Vue, Angular, Svelte o incluso Javascript puro (Javascript Vanilla).

Para comunicarlos puedes creas APIs (REST APIs, GraphQL) en el backend que respondan datos en formato JSON.

Esto funciona así:

Un navegador visita por primer vez tu sitio web, ejemplo faztweb.com
tu Servidor sirve archivos en formato HTML, CSS y Javascript (que fueron creados por algun framework de Javascript), esta primera peticion lo que hace es cargar el esqueleto de tu aplicación web, lo que significa que ya no sera necesario pedirlo nuevamente en proximas interacciones del usuario
Una vez cargado estos archivos se haran peticiones HTTP al servidor por tan solo datos que por lo general estan en formate JSON.

Es decir bajo este metodo la primera peticion carga la interfaz de usuario y las siguientes peticiones solo datos.

Ahora en el frontend como cada cambio de URL no solicita ninguna página nueva, sino que es creada en el navegador, a este metodo se llama Client Side Rendering (CSR).

Y tiene ventajas en cuanto a:

Mejorar la experiencia de usuario, porque el usuario ya no espera una página nueva en cada interacción y los datos al llegar simplemente en formato JSON son más rapidos y no pesan tanto como enviar interfaces de HTML.
El Frontend y backend se pueden desarrollar en proyectos paralelos, con lenguajes de programacion distintos y sin que interfieran entre si
La misma API de Backend puede ser usada luego en otras aplicaciones cliente, como aplicaciones moviles, aplicaciones de escritorio o CLI (Common Line Interfaces).

Esto en la práctica significa que Javascript es el lenguaje principal para crear interfaces. De hecho si has usado frameworks de Frontend quizas has visto un archivo HTML como este:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Example Website</title>
</head>
<body>
  <div id="root"></div>

  <script src="https://scriptDeTuFramework.com/bundle.min.js"type="text/javascript"></script>
  <script src="location/of/app.js"type="text/javascript"></script>

</body>
</html>

Practicamente tenemos un archivo HTML en blanco y 2 scripts de Javascript. Uno para poder cargar el código del framework y otro para cargar nuestro código desarrollado en el framework.

Deventajas de SPA

Y este enfoque tambien tiene sus desventajas, por ejemplo:

Los crawlers de los buscadores tienen más complicado entender cual es el contenido de la página que se esta cargando, Es decir el poder extraer parrafos, enlaces, titulos, y demas. esto es porque las SPA por lo general carecen de:

Metadatos
URLs Unicas
Analiticas
Indexacion

y aunque an mejorando con los años, esto no esta enteramente solucionado.

Tambien son muchos más vulnerables a ataques de Cross-Site Scripting (XSS), es decir usuarios maliciosos pueden inyectar scripts en tu web

Y aunque no es comun, aquellos que tengan desabilitado la ejecucion de Javascript en sus navegadores no podran ver tu sitio.

Entonces como una forma de solucionar esto podemos hacer Pre-Rendering o Server Side Rendering de una SPA. Esto quiere decir que a pesar que la pagina puede estar usando Javascript para generar la interfaz, la carga inicial de la pagina será generada en el servidor, lo que significa que el navegador recibira un HTML con código y no uno vacio.

Esto soluciona problemas como:

Es facil de Indexar, al poder extraer el contenido como los parrafos y enlaces
Cada pagina puede tener una URL unica y SEO amigables
Y la primer carga es más rapida, al venir generada la interfaz desde el backend

Frameworks de Server Side Rendering

Ahora, Como SSR es un concepto y no una tecnología este puede ser implementado en cualquier framework de Frontend, aunque algunos lo ponen más facil que otros, por ejemplo estos son algunos Frameworks modernos que usan SSR:

Ahora algo a tomar en cuenta con todos estos frameworks, es que son frameworks de Javascript, la razon de esto es porque como muchos usan Nodejs como herramienta de desarrollo, tambien lo estan implementando como servidor para Server Side Rendering Generalmente unido a un framework llamado express, al usarse el mismo lenguaje en el backend y frontend.

Y aunque tambien es posible implementar SSR en frameworks de backend de otros lenguajes como Laravel o Django, por ejemplo, es mucho más complicado al no usarse paquetes de javascript y no haber mucha información en comparación.

Pero facilmente puedes usar estos frameworks de backend en cualquier lenguaje, y en lugar de tu framework de Frontend y unirlo a las APIs de Backend que ya hallas desarrollado, de esta forma tendras un Stack muy versatil (CSR, SSR, y SSG). Aunque te llevara un poco más de tiempo dominar todos estos conceptos si eres un desarrollador FullStack.

Por cierto Muchos de estos frameworks, estan basados encima de Frameworks ya exitententes, es por esto que tambien son referidos como Meta Frameworks.

Conlusión

En resumen, si en tu aplicación web tienes contenido que no cambia mucho, y requieres que la carga inicial sea muy rapida, y que sea indexable por buscadores (SEO), pudes implementar Server Side Rendering en esas páginas. Por ejemplo las articulos de un sitio como un blog, la pagina de productos de un ecommerce, o sitio de noticias, y asi.

Por otro lado si tienes contenido que es altamente ineractivo (usando Javascript), y el SEO no es importante, es mejor usar CSR. Por ejemplo un panel administrador o el feed de una red social, una aplicación de Streaming y así.

En la práctica con los frameworks que te he mostrado anterioremente, es bastante facil escoger de hecho entre SSR y CSR, casi todos estos frameworks te permiten decidir en que paginas quieres usar uno u otro.

Y Si eres un desarrollador iniciante no lo pienses mucho y crea tus aplicaciones frontend usando solo tu framework de Javascript y un backend como siempre lo has hecho, eventualmente cuando domines las bases de tu framework puedes empezar a estudiar más a fondo SSR.

Ya que el usar SSR no es un proceso tan sencillo en la práctica, hay muchos modulos que no soportan SSR, asi que es más trabajo implementarlos tu mismo, y requiere que el desarrollador conozca varios coneptos del backend y frontend a la vez.