A medida que más empresas adoptan iniciativas digitales, los negocios deben trabajar arduamente no solo para encontrar una audiencia para su sitio, sino también para mantener a los usuarios interesados y comprometidos. Sin embargo, competir por clics se está volviendo cada vez más desafiante, dejando poco espacio para un mal desempeño en velocidad y SEO, y aumentando la importancia de las redes sociales para dirigir tráfico y obtener conversiones. Es por eso que herramientas como la generación de sitios estáticos (SSG) y el renderizado del lado del servidor (SSR) están ganando (o en el caso de SSR, recuperando) popularidad como una forma de optimizar el desempeño, SEO, compartir en redes sociales y otros impulsores de negocio.
Aprender sobre SSR y SSG y cuándo usarlos puede ayudar a los negocios digitales a evaluar todas las opciones posibles para mejorar la experiencia del usuario y aumentar sus resultados. Esta publicación explicará los conceptos básicos de SSR y SSG, sus pros y contras, y los diversos factores que las empresas deben considerar al determinar cómo renderizar páginas web.
¿Qué son SSR y SSG?
SSR y SSG son opciones de renderizado para generar HTML antes de que se entregue al navegador del cliente, permitiendo a los usuarios ver la página más rápidamente que durante el renderizado del lado del cliente, donde los usuarios ven solo una página en blanco mientras esperan a que el navegador compile y renderice JavaScript. Además de dónde se renderiza el contenido, SSR y SSG difieren de CSR en cuándo, cómo y qué tipo de contenido se renderiza.
- En SSR, un cliente solicita contenido, el HTML dinámico se pre-renderiza en el servidor y la página se entrega al navegador del cliente.
- En SSG, el HTML estático se renderiza durante el tiempo de compilación a partir de templates y contenido proporcionado por el desarrollador, y luego se entrega cuando el cliente lo solicita.
- En 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 realiza llamadas a la API.
Aunque CSR ha sido el método de renderizado más utilizado desde la introducción de los frameworks de JavaScript, las páginas web cada vez más complejas con un uso intensivo de contenido dinámico extraído de numerosas API han resultado en tiempos de carga cada vez más largos, frustrando a los usuarios con expectativas de desempeño cada vez más altas. Además, CSR puede impactar negativamente en los rankings de motores de búsqueda y en compartir en redes sociales—dos riesgos que muchas empresas no pueden permitirse correr mientras enfrentan una dura competencia por la participación del usuario medida en visitas a páginas.
¿Cómo impacta el renderizado en los resultados de los sitios web?
Dirigiendo tráfico
Tomar la decisión correcta entre SSR, SSG y CSR puede jugar un papel importante en uno de los mayores determinantes del tráfico orgánico: los rankings de SEO. Las estadísticas citadas en una publicación de blog de Forbes de 2017 blog post indicaron que la primera página de resultados de motores de búsqueda puede capturar hasta el 92% del tráfico web, y solo el 15% de los usuarios harán clic en un anuncio o intentarán 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 toman en cuenta no solo la calidad y relevancia del contenido, sino factores como velocidad, seguridad, adaptabilidad móvil y, lo más importante, la capacidad de rastreo. Si los bots no pueden rastrear tu sitio, no pueden indexarlo, y eso significa que tu sitio no aparecerá en los resultados de búsqueda.
Desafortunadamente, la capacidad de rastreo puede ser difícil de lograr con CSR. Como explica Google Developers en “Rendering on the Web”, “Los rastreadores pueden entender JavaScript, pero a menudo hay limitaciones que vale la pena conocer en la forma en que renderizan. El renderizado del lado del cliente puede funcionar, pero a menudo no sin pruebas y trabajo adicionales”. Además, CSR no genera vistas previas de enlaces precisas, un problema real para sitios que dependen de compartir en redes sociales para dirigir tráfico. Cuando los enlaces se comparten en redes sociales, debería aparecer una vista previa con una imagen y un título para atraer a los usuarios al sitio. Estas vistas previas son generadas por rastreadores de sitios de redes sociales que escanean HTML en busca de meta tags que describan cómo debería verse la vista previa. Sin embargo, con el renderizado del lado del cliente, se enviará un archivo HTML en blanco desde el servidor, lo que resultará en una vista previa genérica que es la misma para cada página del sitio o en ninguna vista previa, haciendo que el enlace sea menos atractivo para los lectores.
Interacción del usuario
Dadas las altas expectativas de los usuarios actuales, incluso pequeñas diferencias en la velocidad de la página pueden tener un gran impacto en la interacción del usuario. El informe de Deloitte de 2020 Milliseconds Make Millions encontró que una mejora de 0.1s en la velocidad móvil produjo mejoras en las conversiones, tasas de rebote, participación del cliente y tamaño de pedido en múltiples sectores. Además, indicó que los sitios lentos hicieron que más del 40% de los usuarios de e-commerce fueran menos propensos a realizar una compra, y más del 30% menos propensos a regresar al sitio.
Si bien la necesidad de velocidad es obvia para la mayoría de los propietarios de sitios, lo que constituye la velocidad de la página es un poco más complicado. El tipo de dispositivo, la ubicación del usuario, la conexión a Internet y las condiciones de la red juegan un papel en la velocidad experimentada por el usuario, lo que resulta en métricas que pueden variar significativamente de un usuario a otro, especialmente cuando el renderizado se realiza del lado del cliente. Además, la velocidad puede dividirse en múltiples subcategorías que reflejan no solo la rapidez con la que los usuarios pueden ver el contenido, sino el tipo de contenido que pueden ver, si pueden interactuar con él y el tiempo que tardan los procesos del lado del servidor en iniciarse. Estas métricas incluyen:
- TTFB, o Tiempo hasta el Primer Byte: el tiempo entre solicitar una página y el primer byte cargado por un servidor u otro recurso de red.
- FP, o Primera Pintura: el tiempo que toma para que cualquier píxel se cargue en la pantalla de un usuario después de solicitar una página web.
- FCP, o Primera Pintura de Contenido: el tiempo que toma para que cualquier elemento del contenido solicitado de la página se cargue en la pantalla de un usuario.
- TTI, o Tiempo Hasta Interactivo: el tiempo desde que una página comienza a cargarse hasta que puede reaccionar de manera confiable a la entrada del usuario.
Aunque el renderizado del lado del cliente tiene un TTFB rápido, FCP y TTI pueden tardar mucho tiempo, un problema que se agrava para sitios con mucho contenido dinámico o llamadas a API, y usuarios con una mala conexión a Internet. Como resultado, las experiencias móviles sufrirán y los usuarios impacientes pueden navegar lejos de la página web antes de interactuar o incluso ver el contenido que solicitaron.
¿Cuáles son los pros y contras de SSR y SSG?
Aunque CSR proporciona un TTFB rápido y gran flexibilidad para aplicaciones web, los sitios que dependen de SEO, compartir en redes sociales y usuarios móviles para el tráfico pueden querer considerar un método de renderizado diferente. Si SSR o SSG es mejor para tu sitio depende en gran medida de los requisitos específicos del sitio. Como con cualquier tecnología web, hay pros y contras para ambos métodos.
SSR
Aunque SSR es un método de renderizado más antiguo que CSR, recientemente ha ganado renovada popularidad. Además de ser mejor para SEO y redes sociales, SSR aprovecha la conexión a Internet confiable del servidor para renderizar la mayor parte del contenido del sitio, lo que resulta en un FCP más rápido, especialmente para usuarios con mala conectividad. El contenido en sitios renderizados por servidor también está tan actualizado como sea posible, lo que hace que SSR sea excelente tanto para sitios dinámicos como para sitios que se actualizan durante las sesiones de usuario, como sitios de noticias.
La desventaja de SSR es que el renderizado en el servidor puede ser costoso y consumir muchos recursos. El HTML dinámico no puede ser almacenado en caché por CDN estáticos, lo que resulta en viajes más largos hacia y desde el servidor y un TTFB más lento. Los tiempos de segunda carga, o el tiempo que toma cargar una nueva página en el mismo sitio web, también son más lentos, ya que el servidor tiene que recuperar y compilar PHP y entregar HTML para cada nueva página. Una nueva técnica, el renderizado universal, evita este problema con una combinación de renderizado del lado del servidor y del cliente, pero requiere que JavaScript se renderice en el navegador después de que se entrega el HTML, lo que significa que los usuarios con mala conectividad pueden experimentar una larga espera entre cuando el contenido es visible y cuando es interactivo.
Pros de SSR:
- Amigable para redes sociales.
- Amigable para SEO.
- FCP y FP rápidos.
- Contenido actualizado.
Contras de SSR:
- TTFB lento
- Cargas de trabajo intensivas para el servidor.
- No puede ser almacenado en caché por CDN tradicionales.
- Navegar por un sitio es lento sin renderizado universal.
- TTI es más largo que FTP con renderizado universal.
SSG
La generación de sitios estáticos es otra alternativa a CSR que puede parecer un retorno a métodos de desarrollo más antiguos, pero las mejoras recientes en los SSG los están convirtiendo en una opción cada vez más popular. Mientras que actualizar sitios generados estáticamente solía ser una tarea engorrosa, la automatización ha aliviado significativamente esta carga de mantenimiento. Nuevas herramientas como NextJS y GatsbyJS permiten a los desarrolladores agregar más funcionalidad rica en cliente a los sitios, y la amplia variedad de SSG actuales soporta muchos lenguajes y frameworks diferentes. Y generar en tiempo de compilación produce tiempos de carga increíblemente rápidos, haciendo que los SSG sean ideales para mantenerse al día con las altas expectativas de desempeño de los usuarios actuales. Finalmente, los SSG no dependen de bases de datos, mejorando su seguridad y permitiéndoles vivir completamente en CDN para una escalabilidad masiva durante picos de desempeño.
Aunque hay claras ventajas para SSG, renderizar en tiempo de compilación presenta algunos problemas. No es una buena elección para sitios personalizados, ya que el contenido se genera antes de que los usuarios lo soliciten. Dependiendo de cómo un sitio almacene en caché y purgue el contenido, puede que no siempre esté actualizado. Finalmente, los archivos HTML individuales deben generarse para cada URL en un sitio con cada compilación del sitio, por lo que un sitio con miles de páginas tendrá velocidades de compilación muy lentas, haciendo que SSG sea una elección poco práctica.
Pros de SSG:
- Tiempos de carga rápidos.
- Seguro.
- Amigable para redes sociales.
- Amigable para SEO.
- Amigable para móviles.
- Escalabilidad.
Contras de SSG:
- Problemático para sitios con muchas páginas.
- Sin personalización.
- El contenido puede estar desactualizado.
Entendiendo SSR y SSG en Edge Computing
Los cambios en el comportamiento del usuario y las técnicas de desarrollo han renovado el interés en el Renderizado del Lado del Servidor (SSR) y la Generación de Sitios Estáticos (SSG) como alternativas al renderizado del lado del cliente. Cada enfoque viene con compensaciones, pero aprovechar la edge computing puede ayudar a mitigar algunos de los desafíos asociados con SSR y SSG.
Para SSR, las cargas de trabajo intensivas del servidor pueden reducirse utilizando edge functions para pre-renderizar páginas en el nodo edge más cercano antes de entregarlas al cliente solicitante. Este enfoque mejora los tiempos de respuesta y reduce la carga en los servidores de origen. Además, las capacidades de Edge Cache permiten el caching dinámico, permitiendo que el contenido frecuentemente accedido se entregue de manera más eficiente, lo que lleva a tiempos de carga más rápidos.
Con SSG, el caching de contenido estático en el edge mejora tanto el desempeño como la escalabilidad. Al almacenar páginas pre-generadas más cerca de los usuarios, se reduce la latencia y se mejoran las velocidades de entrega. Las opciones flexibles de caching y purga aseguran que el contenido permanezca actualizado mientras se mantienen los beneficios de la distribución en el edge.
Integrar estas técnicas en un entorno de edge computing permite a los desarrolladores optimizar las estrategias de renderizado para velocidad, eficiencia y costo-efectividad, adaptándose a las demandas modernas de desempeño web.