Por qué usar renderizado del lado del servidor

Server-Side Rendering (SSR) ejecuta su aplicación Angular en el servidor para generar HTML completamente renderizado en cada solicitud. El navegador recibe inmediatamente un marcado con contenido significativo, en lugar de una estructura vacía.

Una aplicación renderizada completamente en el cliente (CSR) envía un index.html casi vacío junto con JavaScript. Los usuarios y los rastreadores ven una página en blanco hasta que el bundle se descarga, se analiza y se ejecuta. SSR soluciona ese retraso del primer renderizado.

Muchos rastreadores y bots que generan vistas previas de enlaces leen el HTML inicial. Con SSR, el título, las etiquetas meta y el contenido de la página están presentes en la respuesta, lo que mejora la indexación y las vistas previas enriquecidas en redes sociales.

Como el servidor envía HTML renderizado, el navegador muestra el contenido antes. Esto mejora el First Contentful Paint (FCP) y la velocidad percibida, especialmente en redes o dispositivos lentos.

SSR puede mejorar el Largest Contentful Paint (LCP) al entregar el contenido principal en el HTML inicial, en lugar de hacerlo después de ejecutar JavaScript. Unos buenos indicadores benefician tanto a la experiencia de usuario como al posicionamiento en buscadores.

Cuando alguien comparte un enlace, las plataformas solicitan la URL y leen las etiquetas meta de Open Graph y Twitter del HTML. SSR garantiza que esas etiquetas reflejen la página real y produzcan tarjetas precisas.

Después de entregar el HTML, la misma aplicación se inicia en el cliente y asume el control de la interactividad. Este proceso se denomina hidratación; Angular moderno reutiliza el HTML del servidor en lugar de volver a renderizarlo.

SSR añade costes y complejidad en el servidor: un entorno de ejecución de Node, consideraciones sobre código exclusivo del servidor o del navegador y renderizado en el momento de la solicitud. Evalúe estos aspectos frente a las mejoras de SEO y rendimiento que necesita su aplicación.

Las páginas públicas con mucho contenido y sensibles al SEO (marketing, blogs y catálogos de comercio electrónico) son las que más se benefician. Los paneles internos protegidos por inicio de sesión suelen obtener pocas ventajas de SSR.

Para rutas principalmente estáticas, el prerenderizado (SSG) genera el HTML durante la compilación y ofrece ventajas similares a SSR sin necesidad de un servidor activo. Angular admite SSR y prerenderizado en paralelo.

Angular moderno incluye SSR de primera mano mediante @angular/ssr, junto con el application builder, la hidratación completa del DOM y modos de renderizado por ruta. Esto hace que SSR sea mucho más sencillo que las configuraciones antiguas de Angular Universal.

Aprendió por qué SSR es importante: el HTML real en la primera solicitud mejora el SEO, las vistas previas en redes sociales, FCP y LCP. Añade costes en el servidor, resulta adecuado para páginas públicas con mucho contenido, complementa el prerenderizado y Angular moderno lo integra como funcionalidad principal mediante @angular/ssr.