¿Qué es Server Side Rendering?

Client Side Rendering (CSR)
Es lo habitual, el navegador descarga la aplicación y una vez procesada se presenta. Lo cual puede tomar algún tiempo en suceder y aburrir al usuario.
     
Server Side Rendering (SSR)
Es un proceso similar, pero entre los datos que envía el servidor hay un pre renderizado de la aplicación en un String el cual se interpreta como HTML para ofrecerle una preview al usuario.

Las ventajas de SSR son:

• Hace que la primera carga sea mas rapida.
• Mejora el SEO.
• Look and Feel --> No pasa de una pantalla en blanco a de repente toda la aplicación, sino que con un primer renderizado se va gradualmente haciendo interactiva.

Ventajas del SSR

• Primera carga más rápida
• Mejor SEO
• Look & Feel
• Mejor UX

Tener estos conceptos claros es súper clave, y más con las nuevas features que están por lanzar en React y las que ya lanzaron en NextJS.
👇

• CSR (Client Side Rendering): Es la forma normal de usar React, hacemos un bundle de JS con nuestros componentes (React, ReactDOM) hacemos render y listo, todo funciona en el navegador, todo el HTML se genera ahí mismo.
• SSR (Server Side Rendering): Es tomar estos mismos componentes de React y hacer render en el servidor al recibir una petición, este render genera un string de HTML que se envía al navegador para que lo muestre, después se carga el JS y se hace CSR como siempre.
• SSG (Server Side Generation): Es hacer lo que hace SSR pero al momento de hacer el build de la app en vez de que cada petición, esto es bueno para evitar montar un servidor, pero es posible solo si el contenido es público y más o menos estático (ej. blog, e-commerce, landings).
• ISR (Incremental Static Regeneration): Es hacer SSG, pero manteniendo un servidor corriendo que pueda, cada tanto, hacer SSR, esto permite tener el performance de SSG con la capacidad de actualización de SSR, que con SSG requeriría un nuevo build (usualmente asociado a un deploy).

👉 Fuente

Con SSR tendremos mejor experiencia de usuario, velocidad y mejor SEO.

Entonces a grandes rasgos, hacer SSR nos permite hacer tareas en paralelo, que en este caso es hidratar el cliente con HTML en lo que se descarga el bundle de nuestra aplicación ¿cierto?

Ventajas del SSR

• Primera carga más rápida ⇒ Debido a que se envía un prerenderizado antes, tiene que enviar menos información para completar la pagina
• Mejor SEO ⇒ Gracias a que ya hay información previa cargada. Los buscadores utilizan esta información para indexarlos en sus resultados
• Look & Feel ⇒ Como ya hay datos precargados, la pagina se siente mas rápida al momento de cambiar entre pantallas.

Tengo una duda con respecto a el Server Side Rendering.

Cuando utilizarlo con Express o hacer SSR con Next.js / Nest / Nuxt…?

Client Side Rendering CSR

El Server-side rendering (o renderizado en la parte servidor) se basa en la posibilidad de poder renderizar el HTML de nuestros componentes en cadenas de texto en la parte servidor, vez de la parte cliente.

VENTAJAS

La carga es mucho más rapida

Mejor seo

Look & Feel

✌

CSR (Client Side Rendering - Renderizado desde el lado del cliente)
SSR (Server Side Rendering - Renderizado desde el lado del servidor)
Beneficios de implementar SSR:

• Primera carga más rápida.
• Mejor SEO.
• Look & feel

Las ventajas de SSR son:

• Hace que la primera carga sea mas rapida.
• Mejora el SEO.
• Look and Feel --> No pasa de una pantalla en blanco a de repente toda la aplicación, sino que con un primer renderizado se va gradualmente haciendo interactiva.

Simplemente magico para el SEO

Hola Devs:
Aqui tienen un pequena lectura para conocer algo mas sobre SSR: Click Aqui

ahora entiendo porque hay mejor SEO con ssr

Client Side Rendering

Server Side Rendering

SSR para mejorar el SEO

Viajerx, vengo del futuro. Si esta es tu primera vez viendo este contenido te recomiendo que veas este video, hagas todos los cursos que el plantea en ese video, y después vuelvas. Ya vas a ver como lo vas a aprovechar.

Entonces sucede algo conocido como el pre renderizado de la aplicación, este es una respuesta rápida de lo que es tu aplicación, su funcionalidad es que sea un mensaje rápido del servidor al cliente por eso este mensaje se convierte en un String (un escrito, cómo el que lees ahora, solo que de código que entiende la computadora ) por la cual se interpreta como HTML (el esqueleto de tu aplicación) para ofrecerle una preview al usuario (para que no te quedes viendo una página en blanco, sino como un tráiler de lo que será la aplicación).

Según lo que se explica solamente el primer contenido es el que se renderiza del lado del servidor, y no es como las vistas desde el servidor como en los casos de usar vistas en express con pugjs o en php con Laravel (blade), symfony(twig), java (jsp)… etc.,
esta es una gran solución para mejorar la persepcion del usuario frente a la carga de la pagina, excelente contenido

CSR -> usa recursos del dispositivo = lento
SSR -> el servidor pre-carga = ligero/ rapido

Que es el no SSR?

Proceso habitual cuando es un servicio frontend, el navegador hace la petición del archivo comprimido de nuestro JS, lo ejecuta, y a partir de esto corre con lo ya pedido. Usa una sola descarga que puede ser pesada.

Que es el si SSR

El servidor envía una respuesta y se envía un pre-renderizado de la aplicación, con esto un preview del sitio.

En paralelo descarga el build del proyecto para setearlo.
Esto pa que

• Carga inicial más rápida
• Mejora el SEO, porque la maquetación llega más rápido
• Mejora la experiencia de usuario

les dejo mi github
https://github.com/ruben-xe