Apps

Patrones de renderización para apps web

Maurício Bruno da Silva

• 9 min read
Patrones de renderización para apps web

Con el crecimiento exponencial de las aplicaciones web y la búsqueda continua de experiencias de usuario cada vez más dinámicas e interactivas, han surgido varias técnicas y estrategias de renderizado para optimizar el rendimiento y la eficiencia de las aplicaciones. Como resultado, los desarrolladores enfrentan desafíos sobre cuál elegir, en medio del revuelo por las nuevas herramientas y tecnologías.

Por eso, en este artículo exploraremos estos diferentes patrones de renderizado, sus principios fundamentales y los beneficios que ofrece cada uno. Analizaremos los matices de cada enfoque y discutiremos escenarios de uso apropiados para cada uno, lo que le permitirá tomar decisiones informadas al desarrollar sus aplicaciones web.


¿Qué son patrones de renderización?

Antes de empezar a enumerar y explicar los diferentes patrones, es importante que entiendas bien de qué estamos hablando. Los patrones de renderización, similares a los patrones de diseño, son formas comunes en que se diseñan las aplicaciones web para ser construidas, cargadas y mostradas. Se refieren a preguntas como: “¿Cómo y dónde se debe presentar el contenido? ¿Debería representarse en el servidor web, en el borde (edge) o directamente en el cliente? ¿Se debe procesar todo de una vez, parcial o progresivamente?”

Elegir el patrón correcto puede generar cargas más rápidas e incluso menores costos de procesamiento. Habiendo entendido esto, enumeremos ahora los patrones de representación comunes.


Renderización estática

Implica generar HTML en el momento de crear o compilar la aplicación web y entregar este HTML renderizado a los clientes. Por lo tanto, el contenido se renderiza previamente y el servidor web simplemente envía el HTML final al navegador.

Este modelo es eficiente en cuanto a rendimiento porque los navegadores pueden cargar y mostrar contenido inmediatamente. Es un patrón simple y podemos decir que este fue el primer tipo de renderizado web, pero eso no significa que esté desactualizado. Veamos los pros y los contras de este modelo de renderizado:

Pros

  • Carga rápida: El HTML prerenderizado se envía directamente a los clientes, lo que reduce los tiempos de carga.
  • Fácilmente "cacheable": Debido a que el contenido es estático, se puede almacenar en caché fácilmente en servidores perimetrales (edge servers) o CDN (Content Delivery Networks).

Contras

  • Dificultad para actualizar datos: Debido a que el contenido está renderizado previamente, para actualizar los datos es necesario reconstruir y volver a enviar el HTML.

¿Cuándo utilizarla?

La renderización estática es ideal para aplicaciones con contenido estático o que no requieren actualizaciones frecuentes. Si tiene un sitio web informativo, un blog, un portafolio o una pequeña tienda en línea, el renderizado estático puede ser la mejor opción. Porque, como se mencionó anteriormente, este patrón tiene un rendimiento eficiente y se puede almacenar en caché fácilmente.

Herramientas

Hay varias herramientas disponibles que facilitan la creación y desarrollo de sitios web estáticos. Estas herramientas suelen proporcionar funciones avanzadas para compilar, administrar e implementar sitios web estáticos de manera eficiente. Algunas de las herramientas populares son: Jekyll, Hugo, Gatsby, 11ty, Gridsome y Pelican.

Renderización del lado del servidor (SSR)

La renderización del lado del servidor (SSR - Server-Side Rendering) implica generar el HTML en el servidor web antes de enviarlo al cliente. En este patrón, el servidor es responsable de representar el contenido y enviar la página completa al navegador.

Esto permite que las aplicaciones tengan datos dinámicos, mientras el cliente recibe una página lista para ser mostrada. Veamos un ejemplo de SSR aquí, usando el framework Rails:

<h1>Listing Books</h1>

<table>
  <thead>
    <tr>
      <th>Title</th>
      <th>Content</th>
      <th colspan="3"></th>
    </tr>
  </thead>

  <tbody>
    <% @books.each do |book| %>
      <tr>
        <td><%= book.title %></td>
        <td><%= book.content %></td>
        <td><%= link_to "Show", book %></td>
        <td><%= link_to "Edit", edit_book_path(book) %></td>
        <td><%= link_to "Destroy", book, data: { turbo_method: :delete, turbo_confirm: "Are you sure?" } %></td>
      </tr>
    <% end %>
  </tbody>
</table>

<br>

<%= link_to "New book", new_book_path %>

Este es un diseño de página, donde, en un escenario típico, el servidor procesa los libros para cada solicitud y devuelve una lista con todos ellos.

Pros

  • Datos dinámicos en el servidor: El servidor puede procesar los datos e incluirlos en el HTML antes de enviarlos al cliente, permitiendo que los datos se actualicen con cada solicitud.
  • Mejor SEO (Search Engine Optimization): Los motores de búsqueda pueden rastrear e indexar el contenido renderizado del lado del servidor más fácilmente que el contenido renderizado del lado del cliente.

Contras

  • Carga inicial más lenta: Debido a que el servidor necesita procesar el HTML antes de enviarlo, el tiempo de respuesta inicial puede ser más lento en comparación con la representación del lado del cliente.
  • Mayor carga en el servidor: El servidor necesita realizar la representación para cada solicitud, lo que puede requerir más recursos del servidor en comparación con la representación del lado del cliente.

¿Cuándo utilizarla?

La renderización del lado del servidor es una buena opción para aplicaciones que requieren datos dinámicos y tienen una gran necesidad de SEO. Es adecuada para aplicaciones que tienen contenido actualizado con frecuencia y necesitan proporcionar información consistente a los motores de búsqueda. Además, es una buena opción cuando el tiempo de carga inicial no es un factor crítico.

Herramientas

Existen herramientas para (probablemente) todos los lenguajes comúnmente utilizados en el desarrollo web, como Next.js, Remix, Nuxt.js, Angular Universal (todos basados ​​en JavaScript), Django (Python), Rails (Ruby), Laravel (PHP), etc. Estas herramientas facilitan la implementación de la representación del lado del servidor en sus aplicaciones.

Renderización del Lado del Cliente (CSR)

La Renderización del Lado del Cliente (CSR - Client-Side Rendering) implica enviar un archivo HTML básico al cliente, junto con el código JavaScript necesario para representar y actualizar el contenido en el navegador.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/icon.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>CSR</title>
  </head>
  <body>
    <div id="app"></div>
    <script type="module" src="/src/main.js"></script>
  </body>
</html>

Este es el archivo raíz típico en aplicaciones web renderizadas del lado del cliente. Solo un div, que será el contenedor de toda la aplicación que se creará mediante JavaScript en el navegador.

En este modelo, el cliente es responsable de renderizar y manipular el DOM (Document Object Model). Se hizo popular como método para crear aplicaciones de una sola página (SPAs).

Pros

  • Experiencia suave después de la carga: Una vez cargada la aplicación, las interacciones del usuario son rápidas y receptivas a medida que se produce la renderización en el cliente.
  • No hay carga de trabajo en el servidor: El servidor envía solo los archivos iniciales y el procesamiento posterior se realiza en el cliente.

Contras

  • La carga inicial lleva mucho tiempo: El cliente debe descargar todo el código JavaScript necesario para representar la aplicación antes de poder mostrarla, lo que puede resultar en tiempos de carga más prolongados.
  • Dificultades con SEO: Los motores de búsqueda tienen dificultades para rastrear e indexar las aplicaciones renderizadas del lado del cliente, lo que puede afectar la capacidad de descubrimiento y la clasificación en los resultados de búsqueda.


¿Cuándo utilizarla?

  • Cuando no hay necesidad de optimizar para los motores de búsqueda (por ejemplo, aplicaciones internas o paneles de administración).
  • Aplicaciones que requieren interacciones y actualizaciones frecuentes de datos.
  • Aplicaciones que cargan datos bajo demanda mientras el usuario navega.

Herramientas

Hay varias herramientas disponibles para facilitar el desarrollo de aplicaciones que utilizan la RSE. Algunos de los más populares son React, Vue.js y Angular. Todas estas herramientas proporcionan una manera sencilla de crear componentes y administrar el estado de la aplicación.

Renderización estática incremental

La renderización estática incremental es una variación de la (renderización) estática en la que el contenido se genera según demanda a medida que el usuario interactúa con la aplicación. En lugar de renderizar previamente todas las páginas, solo se renderizan las partes relevantes según sea necesario.

Pros

  • Carga más rápida: El renderizado ocurre solo cuando es necesario, evitando la carga de contenido innecesario.
  • Mejor experiencia del usuario: Responder rápidamente a las interacciones del usuario crea una experiencia más fluida y receptiva.

Contras

  • Complejidad adicional: La implementación de la representación estática incremental puede requerir una lógica más sofisticada para determinar qué partes del contenido deben representarse en tiempo real.

¿Cuándo utilizarla?

La renderización estática incremental es ideal para aplicaciones que tienen un gran volumen de contenido, pero donde solo partes específicas son relevantes en determinados momentos. Esto se ve comúnmente en fuentes de noticias, redes sociales o aplicaciones de comercio electrónico, donde el contenido se actualiza continuamente y mostrar toda la información a la vez puede ser innecesario y perjudicial para el rendimiento.

Herramientas

Suele ser un método compatible con frameworks como Next.js, Nuxt y SvelteKit. Estas herramientas cuentan con características y técnicas que permiten el renderizado selectivo de componentes o secciones, facilitando la implementación de este patrón.

Renderización del lado del servidor en tiempo real

Esta técnica, conocida como streaming server-side rendering, implica la generación dinámica y la entrega de contenido renderizado por el servidor directamente a los clientes, lo que permite a los usuarios ver el contenido que se muestra antes de que se complete todo el procesamiento.

Este método es particularmente útil en sitios web o aplicaciones que requieren páginas con muchos elementos complejos, como gráficos o tablas, ya que la representación del lado del servidor puede manejar estas tareas de manera más eficiente que la representación del lado del cliente.

Pros

  • Carga rápida del contenido inicial: El servidor envía inmediatamente contenido renderizado a los clientes, lo que reduce el tiempo de respuesta percibido por el usuario.
  • Experiencia del usuario mejorada: Los usuarios pueden interactuar con el contenido mientras se realiza un procesamiento adicional en el servidor, lo que da como resultado una experiencia con mayor capacidad de respuesta.

Contras

  • Mayor carga en el servidor: La renderización en tiempo real requiere recursos informáticos adicionales en el servidor, especialmente en escenarios con un gran volumen de usuarios simultáneos.
  • Complejidad adicional en la implementación: La renderización en tiempo real requiere una infraestructura adecuada para manejar la entrega de contenido dinámico y la comunicación en tiempo real con los clientes.


¿Cuándo utilizarla?

La representación en tiempo real del lado del servidor es adecuada para aplicaciones en las que se requiere algún procesamiento en el servidor, pero es deseable proporcionar a los usuarios una vista previa inmediata del contenido, incluso antes de que se complete todo el procesamiento. Algunos ejemplos podrían ser: resultados de búsqueda o páginas de listado.

Herramientas

Existen varias tecnologías y frameworks que se pueden utilizar para implementar la representación del lado del servidor en tiempo real, como Node.js con marcos como Express.js y Socket.io. Estas herramientas proporcionan funciones para facilitar la comunicación en tiempo real entre el servidor y los clientes, permitiendo una experiencia interactiva en tiempo real.

Arquitectura en islas

Es un método que tiene como objetivo reducir la cantidad de JavaScript enviado a través de "islas" de interactividad que se pueden entregar de forma independiente sobre HTML estático.

Las regiones estáticas de la página constan de HTML puro y no interactivo, y las regiones dinámicas están compuestas de HTML y scripts que permiten la interactividad.

Fuente: https://jasonformat.com/islands-architecture/

Pros

  • Reducción del volumen de JavaScript: Al separar las partes estáticas y dinámicas de la aplicación, es posible enviar solo lo necesario a las islas de interactividad, reduciendo el tamaño total del archivo JavaScript.
  • Mejor desempeño: Al evitar la necesidad de cargar y ejecutar todo JavaScript en cada interacción, la arquitectura de isla puede dar como resultado un rendimiento más rápido y con mayor capacidad de respuesta.

Contras

  • Complejidad de implementación: La arquitectura de isla introduce una capa adicional de complejidad en la estructura de la aplicación, lo que requiere una buena comprensión de la separación entre partes estáticas y dinámicas, así como el proceso de hidratación de los componentes.
  • Escalabilidad: La arquitectura no es adecuada para páginas altamente interactivas, como aplicaciones de redes sociales, que probablemente requerirían miles de islas.

¿Cuándo utilizarla?

La arquitectura de isla es más adecuada para aplicaciones en las que se pueden identificar claramente partes de la página que son estáticas y no interactivas, así como áreas que requieren interactividad dinámica. Es especialmente útil en escenarios donde es necesario optimizar el tamaño de JavaScript, como en aplicaciones móviles o en redes con ancho de banda limitado.

Herramientas

Algunos frameworks actuales soportan la arquitectura en islas. Los más notables son Marko y Astro.


Conclusión

Como puedes ver, existen varios patrones de renderización disponibles para los desarrolladores de aplicaciones web. Cada uno de estos patrones tiene sus propios beneficios y consideraciones a tener en cuenta al decidir cuál usar en un proyecto, así que ¡aprovecha este conocimiento!

¡Hasta luego!

💡
Las opiniones y comentarios emitidos en este artículo son propiedad única de su autor y no necesariamente representan el punto de vista de Listopro.

Listopro Community da la bienvenida a todas las razas, etnias, nacionalidades, credos, géneros, orientaciones, puntos de vista e ideologías, siempre y cuando promuevan la diversidad, la equidad, la inclusión y el crecimiento profesional de los profesionales en tecnología.