Renderizado del lado del servidor con React

Publicado: 2021-05-27

Un poco sobre reaccionar

React es una biblioteca JavaScript de frontend de código abierto, creada y mantenida por la comunidad de desarrolladores de Facebook. Se utiliza para crear interfaces de usuario o componentes de interfaz de usuario.

Sin embargo, esta definición puede no ser completamente comprensible para los novatos. Tenemos la publicación de blog perfecta que lo guía a través de una breve explicación de React, hasta una descripción técnica muy detallada, que puede encontrar aquí.

El viaje de una página web | Del servidor a su navegador

Para comprender qué es la representación del lado del servidor, primero es importante obtener una descripción general de cómo aparece una página web en su pantalla, que se explica en el siguiente diagrama:

ssr-with-react-webpage-server-to-browser
  1. Cada vez que ingresa la URL de un sitio web o hace clic en un enlace al sitio web, su navegador envía una solicitud de algunos archivos al servidor apropiado, identificado por la URL.
  2. El servidor envía algunos archivos, como los archivos HTML y JavaScript, entre otros, a su navegador.
  3. Su navegador descarga y 'renderiza' o procesa estos archivos y puede ver e interactuar con la página web que solicitó.

Esta es una gran simplificación del viaje de una página web, pero es un prefacio lo suficientemente bueno para explicar los diferentes pasos secundarios y las diferentes formas (incluida la representación del lado del servidor) para realizar esta tarea.

Recorrido de una página web de representación del lado del cliente 'normal'

Profundizando en el proceso mencionado en la sección anterior, tenemos una técnica conocida como Client Side Rendering o CSR, que se utiliza desde hace mucho tiempo para mostrar un sitio web en las pantallas de los usuarios. Esto se explica en el siguiente diagrama:

ssr-with-react-csr-webpage-rendering
  1. Al escribir la URL de un sitio web o hacer clic en un enlace al sitio web, su navegador envía una solicitud de algunos archivos al servidor apropiado, identificado por la URL.
  2. El servidor envía el archivo HTML que contiene las referencias a otros activos, como archivos de imagen, archivos CSS y archivos JavaScript.
  3. El navegador vuelve a enviar una solicitud al servidor y descarga todos los archivos, incluidos los archivos CSS y JavaScript a los que se hace referencia en el archivo HTML.
    1. Esto puede ser un factor que contribuye a aumentar el tiempo de carga de un sitio web si los usuarios tienen una conexión deficiente y el archivo JavaScript es de gran tamaño.
  4. Una vez que el navegador descarga estos archivos, el navegador ejecuta el marco o la biblioteca (por ejemplo, React) y analiza los archivos JavaScript, que son responsables de hacer que la página web sea interactiva.
    1. Desde la perspectiva de la optimización de la velocidad, este punto depende de la máquina del cliente y si el cliente es un hardware de baja potencia, esto puede llevar mucho tiempo.
    2. El usuario sigue viendo la pantalla de carga cuando se están realizando estos pasos
  5. La página web finalmente se carga por completo y el usuario puede ver e interactuar con la página web.

Como queda claro con los pasos mencionados anteriormente, desde la perspectiva del usuario, solo puede ver e interactuar con el sitio web en el paso final, después de que la máquina cliente haya descargado y procesado todos los archivos necesarios.

Esto puede llevar una gran cantidad de tiempo, ya que depende del rendimiento de la máquina cliente para ejecutar el marco y analizar los archivos JavaScript.

El viaje de la página web de representación del lado del servidor

Explicándolo en una sola línea, Server Side Rendering o SSR es el proceso de tomar un sitio web de JavaScript del lado del cliente y renderizarlo en HTML y CSS estáticos en el servidor en lugar del cliente, como fue el caso en CSR.

A continuación se menciona una representación pictórica del viaje que realiza una página web con Server Side Rendering, con React:

ssr-with-react-ssr-webpage-rendering-with-react
  1. Al escribir la URL de un sitio web o hacer clic en un enlace al sitio web, su navegador envía una solicitud de algunos archivos al servidor apropiado, identificado por la URL.
  2. El servidor, en lugar de simplemente enviar archivos HTML estándar como en CSR, convierte la aplicación en una cadena usando la función renderToString importada de react-dom/server
    1. Luego se inyecta en el archivo index.html y se envía al navegador.
    2. Aquí es donde radica el quid de SSR, funcionalmente hablando, ya que es donde el servidor muestra la página y no la máquina cliente.
  3. El navegador representa este archivo HTML, lo que da como resultado que la vista se complete en el navegador.
    1. Sin embargo, esto aún no es interactivo, pero el usuario puede ver la vista final de la página web.
  4. El navegador vuelve a enviar una solicitud al servidor y descarga todos los archivos a los que se hace referencia en el archivo HTML, incluidos los archivos JavaScript.
  5. Una vez que se descargan todos los scripts, el componente React se representa nuevamente en el cliente. Sin embargo, esta vez, hidrata la vista existente en lugar de sobrescribirla.
    1. 'Hidratar' una vista significa que adjunta cualquier controlador de eventos a los elementos DOM (Modelo de objeto del documento) renderizados, pero mantiene intactos los elementos DOM renderizados. De esta manera, el estado de los elementos DOM se conserva y no se restablece la vista.
  6. La página web finalmente está completamente cargada y el usuario ahora puede interactuar con la página que pudo ver desde el paso 3.

Por lo tanto, uno de los mayores cambios visuales desde la perspectiva del usuario es que la página web se vuelve 'visible' bastante rápido, ya que la representación de HTML no requiere muchos recursos, hablando desde la perspectiva del navegador.

Esto no hace que la página se cargue inherentemente más rápido que una aplicación que no sea SSR, pero les brinda a los usuarios la vista de la página web a medida que los archivos JavaScript se descargan y analizan en segundo plano, después de lo cual la página web se vuelve interactiva. Esto significa que el TTI, es decir, el tiempo de interacción (este es el tiempo que tarda la página web en ser completamente interactiva desde que el usuario solicita la página web) es un poco más que el tiempo que tarda la página web en ser visible. en el navegador.

Por lo tanto, en un escenario de SSR, para acelerar el primer tiempo de procesamiento, su HTML y CSS deben ser significativos para los usuarios, y JavaScript puede ser la mejora para HTML y CSS, ya que su carga es diferida.

Un concepto erróneo común sobre el funcionamiento de SSR con React es que después de cada cambio, como cuando un usuario solicita datos nuevos, el servidor vuelve a completar todos los pasos y envía el archivo HTML con una nueva interfaz de usuario al navegador, pero este no es el caso. . Solo se realiza una actualización parcial de la página. Aunque el renderizado lo realiza el servidor, la salida finalizada se inserta en el DOM 'hidratándolo', como se explicó anteriormente.

ssr-con-reaccionar-pros-contras-de-ssr

Representación del lado del servidor | Cuándo y cuándo no usar

  • Si necesita un SEO sólido, opte por SSR, ya que es más fácil de rastrear para los motores de búsqueda.
  • Para los sitios web que se centran en el contenido y no en la interacción, como blogs, sitios web de noticias, sitios web estáticos y sitios web con mucho texto, SSR puede ser una gran ayuda, ya que cargará el quid de su sitio web, es decir, el contenido increíblemente rápido.
  • Se necesita tiempo y esfuerzo por parte del servidor para procesar y generar los archivos que se enviarán al navegador. Entonces, si tiene un servidor y un presupuesto de operaciones bajo, es mejor que no implemente SSR, ya que se enviarán muchas solicitudes a su servidor.
    • Sin embargo, con proveedores como Firebase, podemos generar contenido de forma dinámica con funciones en la nube y el servidor puede almacenarlo en caché de CDN.
    • Lo que esto haría es que la próxima vez que el usuario lo solicite, el servidor no volverá a generar los archivos. Más bien, solo se sirve desde un borde CDN local, lo que mejora los tiempos de carga desde el punto de vista del usuario y al mismo tiempo usa menos recursos del servidor.

¿Cómo es React Good para SSR?

React es una excelente opción para implementar SSR porque incorpora el concepto de un DOM virtual (Document Object Model).

Esto permite a los desarrolladores crear una versión virtual de la aplicación React y tenerla en el propio servidor.

Esto hace que sea más fácil representarlo en un HTML usando la función renderToString como se mencionó anteriormente, enviarlo al navegador para que el navegador pueda procesarlo con bastante rapidez y crear una versión virtual en la máquina cliente.

Entonces, al observar el hecho de que esta versión virtual coincide con el HTML que enviamos desde el servidor, React no lo volverá a procesar, lo que reduce el tiempo de interacción (TTI), lo que resulta en una página web de carga "más rápida".

SSR, ¡Todo el día, todos los días!

Desearíamos que hubiera una solución única para todo, pero eso está lejos de ser el caso, especialmente con las nuevas tecnologías. Aunque SSR tiene muchos beneficios, hay algunos casos, como se discutió anteriormente, para los cuales SSR podría no ser una buena opción; sitios altamente interactivos estando a la vanguardia de la misma.

Ahí es donde entran Creole Studios. Contamos con una variedad de expertos en tecnología, siempre al tanto de casi todas las nuevas tecnologías que aparecen en el techverse. Comprenderemos las necesidades de su negocio y le brindaremos soluciones personalizadas, ya sea una aplicación SSR o CSR, y tenga la seguridad de que no tendrá que preocuparse por nada mientras hacemos el trabajo pesado por usted. ¡Contáctanos y lleva tus ideas de tu cabeza a una aplicación!