¿Por qué renderizado del lado del servidor (SSR)?

Hay algunas buenas razones para usar SSR:

Haz tu aplicación más rápida: Si su aplicación tiene una gran cantidad de contenido estático que es siempre el mismo (no específico del usuario), tiene sentido tener ese contenido construido en el lado del servidor y devuelto a todos los usuarios porque el servidor puede (y lo hará) almacenar en caché ese contenido, lo que evita la reconstrucción de ese HTML una y otra vez.
Optimización para motores de búsqueda (SEO): Google se ha vuelto bueno con la indexación de contenido generado por Javascript. Sin embargo, a veces, una página pre-renderizada puede cargar más rápido y por lo tanto ser favorecida por los dioses SEO.
Mejor rendimiento: SSR da como resultado mejores puntuaciones de Lighthouse para la primera pintura de contenido (FCP), la pintura de contenido más grande (LCP), así como el desplazamiento de diseño acumulativo (CLS) porque el contenido de la página y su diseño están ahí desde el principio y permanecen estables. Esto es importante porque algunos dispositivos (smartphones antiguos) pueden tener problemas con las páginas web cuando su contenido se mueve mientras se carga.

¿Cómo se hace el renderizado del lado del servidor?

Con Angular 17, se ha vuelto super fácil. Si creas un nuevo proyecto, simplemente ejecuta:

ng new --ssr

Si desea añadir SSR a un proyecto existente, sólo tiene que ejecutar lo siguiente:

ng add @angular/ssr

Y ya está. Hay una pega: Una vez que usas Angular para SSR, necesitas un servidor Node.js para ejecutar tu código Angular del lado del servidor.

En otras palabras, el código del lado del servidor se genera para usted, pero usted necesita un servidor capaz de ejecutarlo, que es diferente de una aplicación Angular regular.

Aquí están los archivos adicionales que contienen el código del servidor:

¿Qué pasa cuando usamos renderizado del lado del servidor?

Cuando usamos renderizado del lado del servidor, Angular pre-renderiza nuestras «páginas» en el lado del servidor. Podemos verlo desde el navegador, donde en lugar de recibir el casi vacío index. html con el que probablemente estés familiarizado:

<!doctype html>
<html lang="en">
<head>
  ...
</head>
<body>
  <app-root></app-root>
</body>
</html>

e puede ver todo el HTML que se descarga desde el principio en las herramientas de desarrollo del navegador, antes de que se descargue ningún Javascript:

Esto se debe a que la aplicación del lado del servidor ha ejecutado cualquier solicitud de HttpClient, ha almacenado en caché esos datos y los ha enviado al navegador junto con el HTML de la página. Angular puede reutilizar esos datos en el lado del cliente, lo que significa que las peticiones HTTP para obtener datos de una API no tienen que ejecutarse dos veces.

En el lado del cliente, una vez que el HTML pre-renderizado se descarga, Angular se encarga de actualizar el DOM a través de la hidratación.

En lugar de reconstruir toda la aplicación en el navegador (como ocurría en el pasado), la hidratación permite a Angular reutilizar la estructura DOM generada por el servidor para una transición fluida a nuestro código Javascript. Todo es automático; no necesitamos hacer nada.

La hidratación está habilitada por defecto en los nuevos proyectos Angular SSR:

export const appConfig: ApplicationConfig = {
  providers: [
     provideRouter(routes), 
     provideClientHydration()
  t]
};

¿Hay que tener en cuenta algunas advertencias?

Sí, hay algunas. Los objetos globales específicos del navegador, como la ventana, el documento, el navegador o la ubicación, así como las propiedades específicas de HTMLElement, no están disponibles en el lado del servidor, ya que allí no hay navegador.

Si necesitas usarlos, tienes que llamar a ese código en los nuevos métodos del ciclo de vida afterRender y afterNextRender como se ilustra aquí:

export class MyComponent {

  @ViewChild('content') contentRef: ElementRef;

  constructor() {

    afterNextRender(() => {
      // Safe to check `scrollHeight` because this will only run 
      // in the browser, not the server.
      console.log(this.contentRef.nativeElement.scrollHeight);
    });
  }

}

¿Qué pasa si no quiero o no puedo usar un servidor Node.js?

Aquí tienes buenas noticias: puedes usar esas mismas características para pre-renderizar la aplicación en el servidor en tiempo de compilación, y luego usar esas páginas pre-renderizadas como una aplicación Angular completa del lado del cliente, ¡que no necesita un servidor Node.js!

Para ello, debes construir tu aplicación Angular SSR con ng build, creando automáticamente archivos HTML pre-renderizados para todas tus rutas.

Por ejemplo, con una configuración de enrutamiento de:

export const routes: Routes = [
  {path: "fun", component: FunComponent},
  {path: "hello", component: HelloComponent}
];

Con SSR, el comando Angular ng build crea la siguiente estructura de archivos en la carpeta dist :

Páginas HTML prerrenderizadas

Como puede ver, se han creado archivos index. html para mis dos componentes enrutados y el AppComponent principal. Tenemos tres archivos HTML diferentes, uno para cada componente.

Podemos desplegar esos archivos estáticos en nuestro servidor HTTP y disfrutar de los beneficios del pre-renderizado, también conocido como generación de sitios estáticos (SSG) a un coste mínimo ya que no tenemos que cambiar nuestra infraestructura de servidor.
Como puede ver, se han creado archivos index. html para mis dos componentes enrutados y el AppComponent principal. Tenemos tres archivos HTML diferentes, uno para cada componente.

¿No es genial?

Fuente