A medida que más empresas adoptan iniciativas digitales, estas deben trabajar duro no solo para encontrar una audiencia para su sitio web, sino también para mantener a los usuarios comprometidos e interesados. Sin embargo, competir por clics se ha vuelto cada vez más desafiante, ya que deja poco espacio para un mal desempeño en velocidad y SEO, además de que refuerza la importancia que tienen las redes sociales para atraer tráfico y obtener conversiones.
Por esta razón, herramientas como la generación de sitios estáticos (static site generation, SSG) y la renderización del lado del servidor (server-side rendering, SSR) han ganado (o en el caso de la SSR, recuperado) popularidad como una forma de optimizar el rendimiento, el SEO, la difusión en redes sociales y otros factores claves para el negocio.
Saber sobre SSR y SSG, y cuándo usarlas, puede ayudar a los negocios digitales a analizar todas las opciones posibles para mejorar la experiencia de usuario y aumentar los resultados. Este artículo explicará los conceptos básicos sobre la SSR y la SSG, sus ventajas y desventajas, así como los diversos factores que las empresas deben considerar al determinar cómo renderizar sus páginas web.
¿Qué son la SSR y la SSG?
La SSR y la SSG son opciones de renderización para generar HTML antes de que este sea suministrado al navegador del cliente, lo que permite a los usuarios ver la página web más rápido de lo que lo harían durante una renderización del lado del cliente (client-side rendering, CSR), donde los usuarios ven solo una página en blanco mientras esperan que el navegador compile y renderice el JavaScript. Además de definir dónde se renderiza el contenido, la SSR y la SSG se diferencian de la CSR en el cuándo, el cómo y el tipo de contenido que es renderizado.
- Con SSR, un cliente solicita contenido, el HTML dinámico es renderizado previamente en el servidor y la página es suministrada al navegador del cliente.
- Con SSG, el HTML estático es renderizado en el momento de la construcción a partir de plantillas y contenido proporcionado por el desarrollador, luego se entrega a pedido del cliente.
- Con CSR, el cliente solicita contenido y el servidor devuelve una página HTML en blanco al navegador del cliente, que compila y ejecuta JavaScript y hace las llamadas a la API.
Aunque la CSR ha sido el método de renderización usado más frecuentemente desde la introducción de los marcos de JavaScript, el incremento de páginas web complejas con bastante uso de contenido dinámico extraído de numerosas API ha generado tiempos de carga cada vez más largos. Esto frustra a los usuarios que esperan un desempeño cada vez mejor. Además, la CSR puede afectar negativamente los rankings de los motores de búsquedas y la difusión en redes sociales, dos riesgos que muchos negocios no pueden permitirse tomar, ya que se enfrentan a una dura competencia por el engagement de los usuarios, medido por las páginas vistas.
¿Cómo la renderización impacta los resultados de los sitios web?
Gestión del tráfico
Tomar la decisión correcta entre SSR, SSG y CSR puede jugar un papel importante en uno de los factores determinantes del tráfico orgánico: los rankings de SEO. De acuerdo con los datos citados en un artículo del blog de Forbes en 2017 se aseguraba que la primera página de resultados de los motores de búsqueda puede atraer hasta 92 % del tráfico web y solo 15 % de los usuarios hará clic en un anuncio o intentará completar una búsqueda diferente si no están satisfechos con los resultados de la primera página.
Los algoritmos que determinan los rankings de SEO no solo toman en cuenta la calidad y la relevancia del contenido, sino también factores como la velocidad, la seguridad, la facilidad de uso en móviles y, lo más importante, la capacidad de rastreo. Si los bots no pueden rastrearlo, no pueden indexarlo y eso significa que tu sitio web no aparecerá en los resultados de búsqueda.
Desafortunadamente, la capacidad de rastreo puede ser difícil de lograr con la CSR. Como Google Developres explica en Rendering on the Web “los rastreadores (crawlers) pueden entender JavaScript, pero a menudo existen limitaciones que vale la pena conocer en la forma en que se ejecutan. La renderización en el lado del cliente puede funcionar, pero a menudo no sin pruebas adicionales y trabajo previo”.
Además, la CSR no genera vistas previas precisas de los enlaces, un problema real para sitios web que dependen de compartir su contenido en redes sociales para generar tráfico. Cuando se comparten enlaces en las redes sociales, debe aparecer una vista previa con una imagen y el título para atraer a los usuarios al sitio. Estas vistas previas son generadas por los rastreadores de sitios de las redes sociales que escanean HTML en busca de metatags que describen cómo debería mostrarse esa vista previa.
Sin embargo, con la renderización del lado del cliente, se enviará un archivo HTML en blanco desde el servidor, lo que resultará en una vista genérica (que es la misma para todas las páginas del sitio web) o ninguna vista previa. Esto hace que el enlace sea menos atractivo para los usuarios.
Interacción del usuario
Debido a las altas expectativas que tienen los usuarios hoy en día, incluso pequeñas variaciones en la velocidad de la página pueden tener un gran impacto en su interacción. El reporte Milliseconds Make Millions, publicado por Deloitte en 2020, encontró que una mejora de 0,1 segundos en la velocidad móvil produjo un aumento en las conversiones, en el tamaño de los pedidos en múltiples industrias y una disminución en las tasas de rebote. También aseguró que los sitios web lentos hicieron que más del 40 % de los usuarios del e-commerce fueran menos propensos a realizar una compra y que 30 % no quisieran regresar al sitio web.
Mientras la necesidad por velocidad es obvia para la mayoría de los dueños de sitios web, lo que compone la velocidad de una página es un poco más complicado. Elementos como el tipo de dispositivo, la ubicación del usuario, la conexión de Internet y las condiciones de la red juegan un papel en la velocidad que el usuario experimenta, así que las métricas pueden variar significativamente entre un usuario y otro, en especial cuando la renderización es hecha en el lado del cliente.
Además, la velocidad puede ser dividida en varias categorías que reflejan no solo qué tan rápido pueden ver el contenido los usuarios, sino también el contenido que pueden ver, cómo pueden interactuar y el tiempo que los procesos en el servidor tardan en iniciar. Estas métricas incluyen:
- TTFB (Time to First Byte): es el tiempo que va desde que se hace la solicitud a una página hasta que el primer byte es cargado por un servidor u otro recurso de red;
- FP (First Paint): es el tiempo que tarda cualquier píxel en cargarse en la pantalla del usuario después de hacer una solicitud a una página web;
- FCP (First Contentful Paint): es el tiempo que se necesita para que cualquier elemento de la página solicitada cargue en la pantalla del usuario, y
- TTI (Time To Interactive): es el tiempo desde que una página comienza a cargarse hasta que puede reaccionar de manera confiable a la interacción del usuario.
Aunque la renderización en el lado del cliente tiene un TTFB rápido, FCP y TTI pueden tomar un largo tiempo. Este es un problema que se agrava en los sitios web con mucho contenido dinámico o llamadas a las API y en usuarios con una mala conexión a Internet. Como resultado, las experiencias móviles se verán afectadas y los usuarios impacientes pueden irse a navegar fuera de la página web antes de interactuar o incluso antes de ver el contenido solicitado.
¿Cuáles son las ventajas y desventajas de la SSR y la SSG?
Aunque la CSR proporciona un TTFB rápido y una gran flexibilidad para las aplicaciones web, los sitios que dependen del SEO, la difusión en redes sociales y los usuarios móviles para el tráfico podrían querer considerar un método de renderización diferente. Definir entre SSR o SSG cuál es mejor para tu sitio web depende en gran medida de los requisitos específicos propios del sitio. Como ocurre con todas las tecnologías web, ambos métodos tienen ventajas y desventajas.
SSR
Aunque la SSR es un método de renderización más antiguo que la CSR, recientemente ha recuperado su popularidad. Además de ser mejor para SEO y redes sociales, la SSR aprovecha la conexión confiable de Internet del servidor para renderizar la mayor parte del contenido del sitio web, lo que resulta en un FCP más rápido, especialmente para los usuarios con una mala conectividad. El contenido de sitios renderizados en servidores también está tan actualizado como es posible. Esto convierte a la SSR en una gran opción tanto para sitios web dinámicos como sitios que se actualizan durante las sesiones de usuario, como los portales de noticias.
La desventaja de la SSR es que la renderización en el servidor puede ser costosa e implica un uso intensivo de recursos. El HTML dinámico no puede ser almacenado en caché por CDN estáticas, lo que significa viajes más largos desde y hacia el servidor y un TTFB más lento. Los tiempos de segunda carga (o el tiempo de carga de una nueva página en el mismo sitio web) son también más lentos, ya que el servidor debe recuperar y compilar el PHP, así como suministrar el HTML de cada nueva página.
Una nueva técnica, la renderización universal, evita este problema al combinar renderización del lado del cliente y en el lado del servidor, pero requiere que sea renderizado el JavaScript en el navegador después de que el HTML es suministrado. Esto significa que los usuarios con una mala conectividad pueden experimentar una larga espera entre que el contenido es visible y cuando está interactivo.
Ventajas de las SSR:
- Amigable con las redes sociales
- Amigable con el SEO
- FCP y FP rápidos
- Contenido actualizado
Desventajas de la SSR:
- TTFB lento
- Workloads intensivas en servidores
- No se puede almacenar en caché con CDN tradicionales
- La navegación por un sitio web es lenta sin la renderización universal
- El TTI es más largo que el FTP con renderizado universal
SSG
La generación de sitios estáticos es otra alternativa a la CSR que puede parecer un regreso a los métodos de desarrollo más antiguos, pero algunas mejoras recientes han hecho que las SSG se conviertan en una opción cada vez más popular. Si bien la actualización de sitios generados de forma estática alguna vez fue una tarea engorrosa, la automatización ha aliviado significativamente esta carga de mantenimiento. Nuevas herramientas como NextJS y GatsbyJS permiten a los desarrolladores agregar a los sitios más funcionalidades para los clientes, además la amplia variedad de SSG que existe actualmente es compatible con diferentes lenguajes y marcos de programación.
De igual manera, hacer la generación en el momento de la construcción produce tiempos de carga increíblemente rápidos, lo que hace que las SSG sean una alternativa ideal para mantenerse al día con las expectativas de alto rendimiento que tienen los usuarios en la actualidad. Por último, las SSG no dependen de bases de datos, lo que mejora su seguridad y les permite permanecer completamente en las CDN para lograr una escalabilidad masiva durante los picos de desempeño.
Aunque la SSG tiene claras ventajas, la renderización en el momento de la construcción presenta algunos problemas. Esta no es una buena opción para los sitios web personalizados, ya que el contenido es generado antes que los usuarios lo soliciten. Dependiendo de cómo un sitio web almacena en caché y purga el contenido, es posible que no siempre esté actualizado. Finalmente, se deben generar archivos HTML individuales para cada URL en un sitio con cada construcción del sitio, por lo que un sitio web con miles de páginas tendrá velocidades de construcción muy lentas, lo que hace que la SSG sea una opción poco práctica.
Ventajas de la SSG:
- Tiempos de carga más rápidos
- Segura
- Amigable con las redes sociales
- Amigable con el SEO
- Amigable con dispositivos móviles
- Escalabilidad
Desventajas de la SSG:
- Problemática para los sitios web con muchas páginas
- No permite la personalización
- El contenido puede estar obsoleto
SSR y SSG con Azion
Los cambios en los hábitos de los usuarios y en las técnicas de desarrollo han renovado el interés por la SSR y la SSG como alternativas para la renderización del lado del cliente. Si bien la decisión siempre dependerá del balance entre las ventajas y desventajas de cada método, la Plataforma de Edge de Azion puede minimizar los inconvenientes que presentan ambos.
Los desarrolladores pueden reducir las workloads (cargas de trabajo) de la SSR que hacen un uso intensivo del servidor con Edge Functions de Azion, que permite a las páginas hacer una renderización previa en el edge node más cercano antes de enviarlas al cliente que las solicita. El poder de Edge Cache de Azion es un multiplicador de fuerza cuando se trata de suministrar contenido de manera rápida a través de caché dinámico para obtener tiempos de carga más veloces. Además, nuestro modelo de computación serverless también reduce costos al ejecutar los workloads solo cuando es solicitado y con una facturación de acuerdo al uso.
Los clientes de Azion que usan SSG no solo disfrutan de los beneficios en desempeño y costos de almacenar en caché su contenido en el edge, sino también de poder usar una variedad de opciones para caching y purga de contenido a fin de asegurarse de que está lo más actualizado posible.
