CSR, SSR, SSG, ISR: cómo elegir el paradigma de renderizado adecuado

Los marcos web modernos ofrecen muchas opciones sobre cómo entregar un sitio o una aplicación del servidor al cliente. Puede generar HTML en cualquier lado o renderizarlo previamente para una distribución de alta velocidad a través de una red de entrega de contenido.

Decidir cómo estructurar un sitio o una aplicación depende de algunos factores diferentes. Debe saber cómo accederán los visitantes a su sitio o aplicación. Debe comprender si la velocidad de carga es más importante en la carga inicial o en la navegación posterior. Considere también la frecuencia con la que actualizará el sitio.

Tenga en cuenta todos estos factores para sopesar los pros y los contras de cada paradigma de renderizado.

Representación de sitios web en más de un sentido

La representación de un sitio web se refiere al proceso mediante el cual se muestra un sitio web en un navegador web. Hay muchas formas diferentes de abordar el proceso de convertir datos sin procesar a HTML formateado en la pantalla de un usuario.

Cada método tiene sus pros y sus contras, y conocer las ventajas y desventajas de cada uno puede ayudarlo a elegir el adecuado para su sitio.

CSR: el navegador se hace cargo

CSR significa Representación del lado del cliente. Cuando representa una aplicación o un sitio del lado del cliente, el servidor pasa poco o nada de HTML, excepto una pequeña parte del código repetitivo. Luego, la página solicita los datos que necesita del servidor, después del evento de carga de la página, a través de solicitudes AJAX.

Cuando una aplicación o página muestra el lado del cliente, el servidor pasa un script al cliente que generará el HTML en el navegador del cliente. Esto permite aplicaciones de una sola página que no actualizan el navegador cuando interactúas con ellas.

Las aplicaciones de CSR a menudo se cargan rápidamente en la navegación, pero pueden tardar en cargarse inicialmente. La velocidad dependerá en gran medida del marco que elija para hacer el renderizado y cuántas bibliotecas y complementos adicionales use. Mayoría marcos de JavaScript modernos y populares incluir una opción para la RSE.

Las aplicaciones y las páginas renderizadas completamente del lado del cliente sufren la incapacidad de navegar directamente a una página determinada usando una URL. Cuando una aplicación renderizada del lado del cliente se inicia por primera vez, independientemente de la URL ingresada, navegará al mismo punto de inicio.

SSR: renderizado en un servidor central

SSR significa representación del lado del servidor. Esta es una forma mucho más tradicional de representación de páginas web en la que los sitios generan HTML basado en plantillas y envían una combinación de HTML, hojas de estilo y secuencias de comandos al cliente. La mayoría de los frameworks web backend más populares caer en esta categoría.

Las aplicaciones y sitios renderizados del lado del servidor tienden a tener cargas iniciales más rápidas, pero cada navegación sucesiva requerirá una actualización completa. Esto significa que no solo tardarán más, sino que los desarrolladores que trabajen con SSR deberán tener en cuenta la gestión de sesiones.

La mayor ventaja de los sitios y aplicaciones generados por SSR es la consistencia de la ruta de navegación. Un usuario que ingrese a una ruta determinada será llevado directamente a la página solicitada. Algunos marcos administran las redirecciones de usuarios de una página a otra dentro de la aplicación, pero es posible que los usuarios no puedan acceder a la página que desean inicialmente.

Muchos marcos modernos ofrecen soluciones combinadas que comienzan por servir una página renderizada por el servidor al cliente. Una vez que la página se ha cargado, ocurre un evento conocido como hidratación en el que los eventos del script del lado del cliente se adjuntan a los controles de la página. De aquí en adelante, el cliente maneja cualquier navegación.

Una dinámica combinada ofrece a los usuarios la posibilidad de ir directamente a cualquier página de una aplicación, sin dejar de recibir la velocidad y la fluidez de una aplicación de una sola página. Next.js ofrece múltiples paradigmas de renderizado, al igual que Nuxt.js y Sveltekit.

SSG: representación minimizada

SSG, o generación de sitios estáticos, evita la necesidad de generar HTML en el lado del cliente o del servidor. En cambio, los sitios y las aplicaciones de estilo SSG precompilan cada página que podrían necesitar y envían los resultados a una CDN para una entrega rápida.

Este es un método extremadamente efectivo para servir páginas web extremadamente rápido. Los resultados normalmente se compilan en paquetes simples que contienen todo el HTML y las hojas de estilo necesarias para una página individual. Estos paquetes se mantienen lo más compactos posible para garantizar que el usuario los reciba lo más rápido posible.

Los sitios SSG tienden a ofrecer velocidades de carga excepcionalmente rápidas, a pesar de que requieren una actualización para cada navegación. Sin embargo, la principal desventaja de un sitio estático es la falta de flexibilidad. Los sistemas altamente dinámicos, como las aplicaciones de redes sociales o las plataformas complejas de comercio electrónico, requerirán muchos más cambios de los que un SSG puede manejar fácilmente.

Muchos sitios estáticos también requerirán una mayor cantidad de gastos generales para modificarlos, ya que cada nuevo cambio deberá compilarse de forma independiente. Esto hace que el renderizado estilo SSG sea una mala elección para sitios que cambian rápidamente, como una tienda digital con un inventario que cambia rápidamente o aplicaciones de redes sociales.

ISR: un poco de todo

Fácilmente el tipo de renderizado más complejo, pero también el más beneficioso, ISR significa Regeneración Estática Incremental. ISR combina la velocidad y la escalabilidad de los sitios generados estáticamente con la reactividad de las aplicaciones de estilo SSR y CSR.

Cuando se solicita cualquier página en una página o aplicación de estilo ISR, el servidor primero verificará si hay una versión en caché de la página que no haya vencido. Si lo hay, el servidor servirá inmediatamente la página almacenada en caché.

Si no existe una versión en caché de la página, o ha pasado suficiente tiempo desde su generación, el servidor generará una nueva versión. Esta nueva versión se pasará al cliente y se almacenará en caché para uso futuro.

Este tipo de renderizado es más complejo de configurar, pero automatiza la mayoría de los problemas que normalmente experimentan los sitios SSG. Esto permite que las aplicaciones ofrezcan tanto la velocidad como la confiabilidad de una aplicación generada estáticamente, al tiempo que eliminan los gastos generales adicionales.

Varios marcos modernos ya ofrecen la opción de renderizado de estilo ISR. Muchos más tienen soporte para generación incremental en desarrollo. La mayoría de los marcos principales pronto admitirán la representación ISR si aún no lo hacen.

¿Qué tipo de renderizado es el mejor?

Hay varias formas de renderizar un sitio web o una aplicación. Cada uno de estos cuatro tipos de representación tiene múltiples variaciones. Ningún tipo de representación es ideal para todos los proyectos, y el tipo que elija dependerá de lo que sea más importante en su sitio o aplicación.

Al elegir un paradigma de renderizado para su proyecto, es importante tener en cuenta la velocidad, cómo usará su audiencia su proyecto y con qué frecuencia cambiará el sitio. Estos serán los principios principales que lo ayudarán a decidir la mejor manera de estructurar su sitio o aplicación.