El pre-rendering en Angular, también llamado static site generation, te permite construir páginas en tiempo de build en lugar de renderizarlas en cada petición. Si trabajas con Angular y buscas optimizar rendimiento, esta estrategia te ahorra recursos del servidor en rutas que casi nunca cambian.

Cómo funciona el pre-rendering frente al server-side rendering

La diferencia clave está en cuándo se construye el HTML. En server-side rendering, cada vez que entras a una URL como /about o /product/:slug, el request viaja al servidor, este se conecta con las APIs, arma el HTML y lo devuelve ya construido. Es rápido porque el cliente no carga con ese trabajo.

En cambio, con static site generation la página no se construye ni en el servidor en caliente ni en el cliente. Se genera una sola vez en tiempo de build, cuando ejecutas ng build [00:55]. Piénsalo como tomarle un screenshot a la página: queda ahí guardada hasta que vuelvas a construir la aplicación.

¿Qué es el pre-rendering en Angular? Es una técnica que genera el HTML de ciertas rutas en tiempo de build, no en cada request. El resultado es un archivo estático que se sirve sin pasar por renderizado dinámico.

Cuál es la única falencia del pre-rendering

Esas rutas no se actualizan en tiempo real. Si cambias el contenido, necesitas empujar un commit y ejecutar otro ng build para que el nuevo screenshot reemplace al anterior. Es el costo de la velocidad estática.

Cuándo conviene usar static site generation

Esta técnica brilla en partes de la aplicación que no cambian con frecuencia o que ni siquiera consumen una API. Algunos casos típicos:

• Páginas informativas como about, términos o contacto.
• Blogs, donde el contenido se publica una vez y rara vez se edita.
• Landings de marketing con información estática.

Para un blog, por ejemplo, basta con publicar el artículo y dejarlo servido como archivo estático. Las partes interactivas, como comentarios, pueden seguir funcionando del lado del cliente sin afectar el contenido pre-renderizado.

¿Cuándo no debo usar pre-rendering? Cuando los datos cambian en tiempo real, como precios, stock o descripciones de productos. Ahí conviene server-side rendering para reflejar cualquier ajuste sin redeploy.

Cómo habilitar pre-rendering en angular.json

Primero, recuerda que el pre-rendering se apoya en server-side rendering, así que debes tenerlo activo. Dentro de angular.json, en la sección architect > build, encontrarás la opción prerender que por defecto está en true [05:10]. Eso significa que Angular intenta pre-renderizar todas las páginas automáticamente, lo cual normalmente no es lo que quieres.

Cómo controlar qué rutas se pre-renderizan

La configuración recomendada usa dos propiedades dentro del objeto prerender:

• discoverRoutes en false: evita que Angular auto descubra rutas desde tu routing.
• routesFile apuntando a un archivo, por convención routes.txt.

Ese archivo routes.txt se crea al mismo nivel del angular.json y contiene las rutas que quieres pre-renderizar, una por línea. Por ejemplo:

txt /about /blog/*

El asterisco actúa como comodín para pre-renderizar todas las rutas hijas de un path, útil para blogs completos.

Qué pasa al ejecutar ng build con pre-rendering

Cuando corres ng build, Angular genera un index.html por cada ruta listada. Si revisas la carpeta browser del output, encontrarás algo como about/index.html con todo el HTML ya armado, incluyendo componentes interactivos como contadores o reproductores MP3 [09:30]. La interactividad se hidrata después en el cliente, pero el HTML inicial ya viene servido.

Para probar el resultado en un entorno productivo, Angular genera un archivo server.mjs que levanta un servidor Express sobre Node. Ese es el archivo que despliegas si vas a correr la aplicación en una instancia de DigitalOcean, AWS u otro proveedor con runtime de Node.

Qué ocurre con rutas dinámicas como productos

Puedes pre-renderizar una ruta específica de producto agregándola al routes.txt, por ejemplo /product/abc-123. Angular creará una carpeta con ese slug y un index.html congelado en el estado que tenía el producto al momento del build [12:40].

Pero ojo: si el precio o la descripción cambian en la base de datos, ese screenshot no se entera. Por eso, para catálogos con datos volátiles, es mejor mantener server-side rendering y reservar el pre-rendering para contenido estable.

Qué hacer si no quieres pre-renderizar nada

Es perfectamente válido dejar el archivo routes.txt vacío o desactivar la opción. Toda la aplicación pasaría a renderizarse del lado del servidor en cada request, sin complicaciones adicionales. La elección depende de tu estrategia de contenido y tu arquitectura.

Un detalle importante para el deployment: al activar server-side rendering ya no estás sirviendo solo HTML, JavaScript y CSS estáticos. Necesitas un proveedor que ejecute JavaScript en un servidor con Node o un runtime compatible, lo que cambia tus opciones de hosting respecto a una SPA tradicional.

¿Vas a usar pre-rendering en tu próximo proyecto Angular o prefieres mantener todo en server-side rendering? Cuéntame en los comentarios qué tipo de rutas tienes en mente.