Qué es y cómo funciona
SSG (Static Site Generation, generación de sitios estáticos) mueve el trabajo de montar la página del momento de la visita al momento de la construcción. Durante el build, el framework recorre las rutas, lee los datos de donde estén (archivos, una API, un CMS) y escribe un archivo HTML por página. Esos archivos se suben a un servidor o una CDN y se entregan tal cual.
Como no hay que ejecutar código por cada visita, la respuesta es muy rápida y predecible, y el servidor tiene poco que hacer. También reduce la superficie de ataque: no hay base de datos ni lógica de aplicación expuesta en la página pública.
El precio es que el HTML refleja el contenido tal y como estaba en el último build. Si cambias un texto en el CMS, la web pública no se entera hasta que se vuelva a construir, salvo que combines SSG con regeneración incremental (ISR) o con un aviso automático que lance un nuevo despliegue.
Por qué importa
Para páginas que no dependen de quién las mira, SSG suele ser la opción más sensata: webs corporativas, páginas de servicios, documentación y blogs. Rinde bien en las métricas de carga, aguanta picos de tráfico sin esfuerzo y abarata el alojamiento, porque servir archivos es mucho más barato que ejecutar código.
Su límite aparece con el volumen y la frescura. Un sitio con decenas de miles de páginas puede tardar mucho en construirse, y cada pequeño cambio obligaría a repetirlo entero. Si además el contenido cambia varias veces al día, hace falta otra estrategia o una combinación de varias. Elegirlo bien al empezar evita rehacer la arquitectura cuando el proyecto crece.
Un ejemplo
Una consultora tiene una web con unas 40 páginas: servicios, equipo, casos de uso y un blog que publica un artículo a la semana. Con SSG, todo se genera en cada despliegue y se sirve desde una CDN. Cuando alguien publica un artículo, el CMS avisa para que se lance un nuevo build y la página nueva queda online en cuestión de minutos, sin ningún servidor ejecutando código por cada visita.
Errores y confusiones frecuentes
- Esperar que un cambio en el CMS se vea al instante. Con SSG puro hace falta un nuevo build o un mecanismo de revalidación.
- Usarlo para contenido personalizado por usuario. El HTML estático es igual para todos; la personalización se tiene que resolver aparte, en el cliente o con otra técnica.
- Ignorar el tiempo de build. En sitios grandes puede hacerse largo y conviene generar solo lo esencial y dejar el resto para después.