La importancia del renderizado del lado del servidor portada

La importancia del renderizado del lado del servidor

Compártelo

La mayoría de nuestras páginas en elFaroStudio utilizan el renderizado del lado del servidor (en adelante SSR), con sólo unas pocas excepciones.

Utilizamos el renderizado del lado del servidor por dos razones

  • Beneficio de rendimiento para nuestros clientes
  • Rendimiento SEO consistente

Debido a las ventajas del SSR, cuando transformamos nuestro proyecto en React y Nodejs, por ejemplo, dedicamos mucho tiempo y esfuerzo en optimizar el rendimiento del SSR. Una de nuestras métricas clave para medir el rendimiento es la representación «por encima del pliegue».

Esta entrada del blog se centra en el beneficio del rendimiento de usar SSR.

El beneficio teórico del rendimiento

He aquí un diagrama cronológico muy sencillo (súper sencillo) para mostrar la diferencia entre la SSR y la CSR (Renderizado del lado del Cliente).

La importancia del renderizado del lado del servidor captura 1
La importancia del renderizado del lado del servidor captura 2

La principal diferencia es que para el SSR la respuesta de tu servidor al navegador es el HTML de tu página que está listo para ser renderizado, mientras que para CSR el navegador obtiene un documento bastante vacío con enlaces a tu javascript. Esto significa que el navegador empezará a renderizar el HTML desde tu servidor sin tener que esperar a que se descargue y ejecute todo el javascript.

En ambos casos, React tendrá que descargarse y pasar por el mismo proceso de construir un dom virtual y adjuntar eventos para que la página sea interactiva, pero en el caso de la RSE, el usuario puede empezar a ver la página mientras todo eso ocurre. Para el mundo de la RSE, tienes que esperar a que ocurra todo lo anterior y luego hacer que el dom virtual se traslade al dom del navegador para que la página sea visible.

Otra ventaja: el parpadeo de la página en blanco que se produce con la RSE tampoco se produce realmente con la SSR, aunque la mayoría de la gente lo evita haciendo que se envíe una imagen de carga en la respuesta del servidor, que se elimina cuando todo termina de cargarse.

Ahora bien, hay algunas advertencias:

  • Aunque la página se renderiza antes y el cliente puede ver la página antes, no puede interactuar realmente con ella hasta que los elementos reactivos termines de ejecutarse. Si el cliente es realmente rápido y haces clic en un botón, la acción no se ejecutará hasta que React termine de ejecutarse;
  • El TTFB (Time To First Byte) de SSR es más lento que el de CSR, porque tu servidor tendrá que dedicar tiempo a crear el HTML de tu página en lugar de limitarse a enviar una respuesta relativamente vacía;
  • El rendimiento SSR de tu servidor es significativamente menor que el rendimiento CSR. En el caso de React en particular, el impacto en el rendimiento es extremadamente grande. ReactDOMServer.renderToString es una llamada sincrónica ligada a la CPU, que mantiene el bucle de eventos, lo que significa que el servidor no podrá procesar ninguna otra solicitud hasta que ReactDOMServer.renderToString finalice. Digamos que tardas 500ms en SSR tu página, eso significa que puedes hacer como máximo 2 peticiones por segundo. GRAN CONSIDERACIÓN

Caso de uso real

A continuación se muestran aplicaciones de producción de algún proyecto de elFaroStudio renderizadas con SSR frente a CSR.

La importancia del renderizado del lado del servidor captura 3

Comparamos tres de nuestras aplicaciones (inicio, categoría y búsqueda) en SSR frente a CSR. Estas son las capturas de pantalla de la red Chrome de las páginas que se están renderizando. Notarás que SSR se renderiza más rápido, y que al usar CSR aparece la página blanca en blanco mientras se carga.

La mayoría de las aplicaciones que utilizan CSR obviamente sustituirán la página blanca en blanco por un icono de carga, pero como utilizamos SSR para nuestras operaciones normales, cuando se fuerza el modo CSR, las páginas están en blanco. Ten en cuenta que se trata de capturas puntuales, con nuestras máquinas, a una hora determinada del día con la actual versión de producción, por lo que el rendimiento individual puede variar, pero ésta debería ser la tendencia general que se observa en las aplicaciones.

La importancia del renderizado del lado del servidor captura 4

Aquí está la primera respuesta del servidor para las páginas de inicio, categoría y búsqueda. Yo ignoraría la barra verde, porque es más relativa en comparación con el resto del gráfico de la red. Las dos cosas sobre las que quiero llamar la atención son el tamaño del documento y el TTFB. Dado que el servidor responde con el HTML de la página, te darás cuenta de que el tamaño del documento para el SSR es siempre mayor. Otro punto del que se ha hablado antes, la respuesta de la RSC es más rápida (excepto en la página de inicio por alguna razón en esta prueba).

Sin embargo, no puedo dejar de recalcar que estas capturas son variables en función de la aplicación, la latencia, el servidor, la ubicación y un montón de otras variables, por lo que no deben tomarse como un hecho científico, sino más bien como una tendencia general.

Conclusión

Cuando realizamos pruebas A/B sobre el SSR frente a la CSR, la tendencia anterior es la que observamos, y nuestras cifras mostraron un mejor compromiso del cliente con la renderización temprana. Por estas razones, nuestros proyectos está muy centrados en el SSR.

Si estás intereado en este tema, puede que también te interese: Node.js vs. Python: ¿qué backend utilizar?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *