Cada clic en tu sitio web pone en marcha un proceso. Cuando un visitante solicita una página específica, el servidor de tu sitio web responde entregando algo que el navegador puede mostrar: típicamente un HTML estático con su correspondiente doctype, que define la estructura de la página (la apariencia, experiencia e interfaz de usuario).
Hay dos lugares donde puede ocurrir la renderización de contenido: del lado del cliente o del lado del servidor. En la renderización del lado del cliente, el ordenador del usuario recibe un archivo HTML mínimo, y el navegador del cliente (como Google Chrome o Safari) hace la mayor parte del trabajo, ejecutando JavaScript para construir y mostrar la página.
En el renderizado del lado del servidor, la página se ensambla completamente en el servidor antes de enviarse al navegador, por lo que el usuario recibe una página completa y lista para mostrar. Este artículo se centrará en lo último: renderizar contenido del lado del servidor.
¿Qué es el renderizado del lado del servidor?
El renderizado del lado del servidor (SSR, por sus siglas en inglés) es un proceso donde un servidor web recopila todos los datos necesarios, el diseño y los elementos de interfaz de usuario de una página web, luego los ensambla en un archivo HTML completo antes de enviarlo al navegador web del usuario.
El resultado es una página completamente renderizada que está lista para mostrar. Este enfoque conduce a tiempos de carga rápidos con páginas optimizadas para SEO que benefician tanto a los visitantes como a los rastreadores de los buscadores.
Por ejemplo, imagina que administras una web de noticias. Cuando un usuario hace clic en un enlace para leer un artículo, un framework de renderizado del lado del servidor obtiene datos de una base de datos o una API, recopila rápidamente el contenido HTML ya renderizado (incluyendo diseño y elementos de interfaz de usuario como titulares, firmas, fecha de publicación, artículos relacionados, menús de navegación y espacios publicitarios), y lo entrega al navegador del usuario.
El navegador entonces muestra la página completamente renderizada. Después, el navegador puede "hidratar" la página con contenido más dinámico, como cargar comentarios o votos positivos, usando JavaScript para hacer la página interactiva.
SSR es particularmente útil para sitios que dependen mucho del tráfico de búsqueda orgánica (ya que las páginas pre-renderizadas son más fáciles de rastrear para los motores de búsqueda) y dependen de velocidades de carga rápidas para mantener a los usuarios comprometidos; esto incluye páginas de productos de comercio electrónico.
Y no es que SSR y la renderización del lado del cliente (CSR) sean incompatibles: a menudo, ambos se usan para propósitos específicos. Por ejemplo, una tienda de comercio electrónico podría usar SSR para páginas de productos pero usar CSR para el proceso de pago.
Beneficios del renderizado del lado del servidor
- Primeras cargas más rápidas
- Mejora el rendimiento SEO
- Mejora la accesibilidad
- Ideal para el contenido dinámico
- Reduce la carga de JavaScript
Aquí verás más formas con las que el renderizado del lado del servidor puede mejorar el rendimiento de tu sitio web:
Primeras cargas más rápidas
Con el renderizado del lado del servidor, el servidor web hace el trabajo pesado y entrega inmediatamente una página HTML completamente renderizada al navegador del usuario. Los usuarios no tienen que esperar a que JavaScript se descargue y renderice (como lo harían con la renderización del lado del cliente) antes de ver el contenido que desean.
Esta experiencia, también conocida como "first paint", puede ser vital para mantener a los usuarios en la página que solicitaron, lo que puede ayudarlos a sentir más confianza hacia tu web y tu marca.
Esto es aún más importante para usuarios con dispositivos más lentos o redes móviles, donde una página CSR puede verse en blanco durante varios segundos.
Mejora el rendimiento SEO
La visibilidad en motores de búsqueda es esencial para dirigir tráfico a tu sitio, y el renderizado del lado del servidor puede mejorar significativamente cómo se posiciona tu sitio. Los motores de búsqueda como Google indexan tu contenido leyendo tu HTML con sus bots.
Eso significa que una página SSR ya está en el formato ideal para que Google la lea e incluye elementos como encabezados, enlaces, texto alternativo de imágenes y metadatos, todo lo cual Google usa para clasificar sitios web.
Puedes facilitar que Google rastree tus páginas con el renderizado del lado del cliente, pero puede requerir muchas soluciones alternativas adicionales y herramientas de terceros potencialmente costosas.
Mejora la accesibilidad
El renderizado del lado del servidor facilita las cosas para personas que usan lectores de pantalla u otras tecnologías de asistencia. Dado que la carga inicial de la página incluye el contenido HTML completo (en lugar de una plantilla en blanco que depende de JavaScript para cargar), las herramientas de asistencia pueden acceder e interpretar inmediatamente la información.
Aún mejor, si algunos de tus usuarios tienen JavaScript deshabilitado (o usan navegadores más antiguos sin capacidades modernas de JavaScript), aún verán una página funcional.
Tener un sitio web más accesible también significa que podrás cumplir con estándares de accesibilidad como WCAG, particularmente importante si estás en un campo regulado como educación, gobierno o atención médica.
Ideal para el contenido dinámico
Si tu página web tiene mucho contenido que cambia frecuentemente, como un blog o una web de noticias, el SSR es ideal. Puedes combinar datos en tiempo real a través de APIs con la entrega rápida que ofrece el SSR. Esto te da la sensación fresca de la renderización del lado del cliente mientras ofrece mejoras de velocidad y SEO a través del HTML renderizado en el servidor.
El navegador de tu usuario no tendrá que hacer todo el trabajo de extraer datos después de la carga de la página, por lo que parecerá más rápido y resultará más accesible para los motores de búsqueda.
Reduce la carga de JavaScript
Mientras que la renderización del lado del cliente depende de muchos paquetes de JavaScript, estos pueden ralentizar a los usuarios móviles y aquellos con dispositivos más antiguos. SSR hace todo el trabajo pesado antes del navegador, por lo que JavaScript no se necesita por adelantado.
Esto también beneficia a usuarios en áreas con velocidades de red más lentas o dispositivos más limitados, ayudándote a alcanzar una audiencia más amplia y global.
Desventajas del renderizado del lado del servidor
- Mayor tiempo hasta el primer byte (TTFB)
- Infraestructura y despliegue más complejos
- Mayor carga del servidor
Las desventajas del renderizado del lado del servidor incluyen:
Mayor tiempo hasta el primer byte (TTFB)
El renderizado del lado del servidor depende del servidor web para obtener todos los datos necesarios y renderizar una página web HTML completa antes de poder entregarla al usuario. Esto significa que podría haber un retraso notable entre el momento en que el navegador solicita la página y cuando finalmente comienza a recibir ese contenido.
Esto se llama tiempo hasta el primer byte. Sin estrategias de caché, esta latencia puede ocurrir en cada carga de página, especialmente para sitios con necesidades de obtención de datos más complicadas, llevando a cuellos de botella del servidor.
Infraestructura y despliegue más complejos
Para usar un renderizado del lado del servidor, necesitarás un entorno de servidor en vivo que pueda renderizar páginas sobre la marcha. Esto requiere más infraestructura y posiblemente soporte de DevOps.
A diferencia de los sitios estáticos, que sirven HTML pre-construido con requisitos mínimos de base de datos o API, los sitios SSR necesitan un motor de renderizado como Node.js y un alojamiento que soporte funciones de servidor, como Vercel, Netlify Edge o Render.
Gestionar el tiempo de actividad del servidor, escalar para mayor tráfico y manejar problemas como arranques en frío puede añadir complejidad y puede requerir un equipo de desarrolladores dedicado.
Mayor carga del servidor
El renderizado del lado del servidor requiere muchos recursos de CPU de tu servidor web, ya que renderiza páginas cada vez que un usuario solicita una. A medida que tu sitio obtiene más tráfico, necesitará más y más recursos de cómputo.
Esto puede llevar a costes de alojamiento más altos, posibles caídas del servidor debido al tráfico pesado y tiempos de carga más lentos cuando el servidor está saturado.
Cómo implementar el renderizado del lado del servidor
El renderizado del lado del servidor tiene lugar completamente en tu servidor web. Cuando un usuario escribe una URL o hace clic en un enlace, el navegador envía una solicitud al servidor.
El servidor recopila los datos necesarios (extrayendo de fuentes externas o bases de datos internas) y carga todos los elementos de interfaz requeridos, como logotipos, menús de navegación y otros componentes de diseño.
El servidor recopila todo esto en una página HTML completa y la envía de vuelta al navegador del usuario. La página resultante está completamente renderizada y es legible inmediatamente; no se requiere carga de JavaScript (como en la renderización del lado del cliente).
Si eres un emprendedor que busca implementar un renderizado del lado del servidor en tu sitio web, hay algunos pasos que necesitarás tomar.
Selecciona un framework SSR
Primero, necesitarás elegir las herramientas de desarrollador correctas, o frameworks de renderización del lado del servidor.
Por ejemplo, Shopify Hydrogen es un framework basado en React que ofrece SSR, CSR y otras opciones. Next.js es otro framework SSR bastante bien documentado y ampliamente adoptado, pero SvelteKit, Nuxt.js y Astro también se usan frecuentemente.
Configura tu stack de desarrollo
Este es el conjunto de herramientas, frameworks, lenguajes de programación y servicios que usarás para construir y ejecutar una aplicación web con un renderizado del lado del servidor.
Esto puede incluir frameworks de front-end para manejar la interfaz de usuario y un renderizado del lado del servidor, junto con JavaScript del lado del cliente, y el lenguaje de programación (típicamente JavaScript o TypeScript).
También necesitarás un editor de código (como VS Code), una plataforma de alojamiento con soporte SSR integrado como Vercel o Netlify, y un CMS, si estás sirviendo tu propio contenido a la web. Ejemplos de CMS incluyen Sanity, Contentful, o el CMS de código abierto Strapi.
Contrata a un diseñador
Configurar un SSR puede ser complejo. Tal vez te convenga contratar a un desarrollador web profesional con experiencia en frameworks del lado del servidor. Un profesional experimentado puede ayudarte a elegir las tecnologías adecuadas y optimizar el rendimiento, así como diseñar, construir y configurar el sistema back-end para tu sitio.
Considera contactar a freelancers a través de Upwork, Toptal y Gun.io. También puedes contratar una agencia enfocada en Jamstack que se especialice en diseño de sitios web trabajando con JavaScript del lado del servidor, APIs y Markup, o agencias que trabajen con CMS headless (esto desacopla el back end de contenido del front end del sitio web).
Preguntas frecuentes sobre el renderizado del lado del servidor
¿Me conviene tener un renderizado del lado del servidor, o es suficiente del lado del cliente?
Depende del tipo de web que estés construyendo. Si quieres que cargue rápidamente, tener buen rendimiento en optimización de motores de búsqueda o servir contenido dinámico, SSR es una gran solución. Ejemplos de sitios que se benefician del renderizado del lado del servidor incluyen: tiendas con páginas de productos que quieres posicionar en Google, blogs o sitios de revistas, sitios de marketing donde una primera impresión fuerte es importante, y páginas con contenido actualizado frecuentemente. Para propietarios de tiendas Shopify, usar el framework de comercio headless de Shopify, Hydrogen, permite un enfoque híbrido que usa SSR y CSR.
¿Cuál es la principal desventaja del renderizado del lado del servidor?
En última instancia, el renderizado del lado del servidor agrega complejidad a tu infraestructura de servidor web. Necesitarás un servidor potente para generar páginas dinámicamente sobre la marcha, lo que puede significar tiempos de respuesta algo más largos. Los sitios con renderizado del lado del servidor pueden fallar bajo alto tráfico, por lo que necesitarás planificar más en torno al caché y la escalabilidad.
¿Qué sistema es mejor, el SSR o el CSR?
Ambas estrategias para renderizar páginas web tienen ventajas y desventajas, y la que elijas se basará en las necesidades del sitio que quieres crear. Usa un renderizado del lado del servidor cuando quieras enfocarte en SEO, habilitar tiempos de carga rápidos para conversiones rápidas, o servir páginas ricas en contenido rápidamente, o si tu web presenta datos que cambian frecuentemente, como un blog, una web de comercio electrónico o una página de reseñas. Usa renderización del lado del cliente cuando estés construyendo una aplicación web y no un web de contenido, cuando SEO sea menos preocupante (como un panel de usuario), y quieras un sitio con una arquitectura más simple y una configuración más rápida para desarrolladores.
