¿Qué es SSG?

Introducción

A los desarrolladores nos encantan las siglas. Seguro que alguna vez has oído hablar de SPA, SSR, SSG, JAMstack… y te has preguntado:

¿De qué demonios están hablando?
¿Esto me afecta si solo quiero hacer una web?

Hoy vamos a centrarnos en una de esas siglas: SSG.
Veremos qué es, para qué sirve, qué problemas resuelve (y cuáles no), y cómo puede ayudarte a crear sitios más rápidos, seguros y fáciles de mantener.

TL;DR

SSG significa Static Site Generation (Generación de Sitios Estáticos).

¿La idea? En lugar de generar una página web cada vez que alguien la visita, el sitio se preconstruye en el momento del build. Es decir mientras haces un build del sitio, usas componentes modernos, accedes a datos de APIs o HCMS, generas todas la combinaciones posibles de páginas, y como resultado obtienes archivos estáticos listos para desplegar: HTML, CSS y JS.

Ventajas:
✅ Carga ultra rápida
✅ SEO perfecto
✅ Seguridad y mantenimiento más simples
✅ Fácil de desplegar y escalar

Un ejemplo para entenderlo

Imagina que te encargan una web corporativa. Requisitos:

• Que aparezca bien posicionada en buscadores.
• Que consuma pocos recursos.
• Que cargue rápido.
• Que sea fácil de mantener.
• Que personas no técnicas puedan actualizar contenidos (noticias, eventos...).

Veamos las posibles soluciones.

Opción 1: PHP clásico

Una opción válida sería usar PHP, como se ha hecho durante años. Miles de sitios siguen funcionando con PHP sin problemas.

Igual que decimos PHP, podría ser ASP .net MVC, u otras tecnologías, que son multi-page application (es decir aplicaciones en las que cada vez que el usuario navega a otra página, el servidor genera un HTML nuevo).

¿Cómo funciona una página de PHP clásico?

• Tu tienes un fichero con una mezcla de código:
  • HTML para la estructura y JavaScript para interacciones en cliente (código que se ejecutará en el navegador).
  • PHP para código que se ejecuta en el servidor, si las páginas son dinámicas (por ejemplo, para mostrar artículos de un blog, leo de base de datos y voy generando el HTML)¡, este PHP se mezcla con el HTML.
• Cuando alguien visita una página, el servidor ejecuta el código PHP, genera el HTML y lo envía al navegador.

Veamos esto en un diagrama:

Aquí hemos simplificado el diagrama, además de HTML, se puede servir CSS y JS, pero lo importante es que el HTML se genera en el servidor.

¿Qué quiere decir esto? Que cada vez que alguien visita una página, hay que ejecutar el código PHP en el servidor, generar el HTML y enviarlo al navegador, eso sí, en el HTML que enviamos está todo el contenido.

En este contexto, aparecen algunas limitaciones:

• Necesitas un servidor con PHP y cierta configuración → eso añade mantenimiento e incrementa la superficie de ataque.
• Cada página se genera en tiempo real en cada visita → consume CPU y memoria constantemente (existen mecanismos de caché para paliar parcialmente esto).
• El tiempo de carga depende de lo que tarde el servidor en montar la página y enviarla.

Sigue siendo útil en muchos casos, pero si lo que quieres es velocidad, simplicidad y menor mantenimiento, hay alternativas más modernas.

Opción 2: SPA (Single Page Application)

“¿Y si usamos React, Vue o Angular?”

Si NO usamos un meta-framework como Next.js o Nuxt, estaremos trabajando en modo Client Side Rendering (CSR). Es decir: el servidor solo entrega una página básica, y todo el contenido se construye en el navegador mediante JavaScript.

¿Cómo funciona esto?

• El servidor envía un HTML básico con un script en JavaScript.

• No hay ningún código que se ejecuta en el servidor.

• Ese HTML/JS no tiene contenido (o apenas contenido), ya se generará en el navegador, por ejemplo en cuanto se carga la página, conecta con una API rest, carga los datos y los convierte en HTML dinámicamente para mostrarlo.

Ventajas:

• Se sirve como archivos estáticos.
• Es fácil de desplegar y escalar.
• Buena experiencia una vez que la app se ha cargado.

Inconvenientes:

• El primer impacto visual es más lento, ya que el contenido se monta después de que llegue el JS.

• SEO limitado: los buscadores no siempre indexan correctamente contenido generado por JS (aunque han mejorado).

¿SEO eso que es? SEO (Search Engine Optimization) es el proceso de mejorar una web para que aparezca entre los primeros resultados en buscadores como Google. Estos buscadores leen principalmente el HTML que entrega el servidor, y si usas una SPA, ese HTML suele estar casi vacío, lo que dificulta que tu sitio se posicione bien.

Ideal para aplicaciones con muchas interacciones (dashboards, apps internas...).
Pero para una web informativa o corporativa, se queda corto en SEO y rendimiento inicial.

Opción 3: SSR (Server Side Rendering)

Con el Server Side Rendering, el contenido se genera en el servidor y se entrega ya montado al navegador.

Esto mejora:

• El tiempo de primera carga.
• El SEO (los buscadores ven el contenido directamente).

Además, frameworks como Next.js permiten mezclar SSR con CSR. También existen avances como:

• Hydration: HTML pre-renderizado que luego se conecta con la lógica JS.
• Server Components: partes de la UI se generan en servidor, otras en cliente.

¿Cómo funciona esto?

• Si se realiza la primera petición (da igual la página que sea), el servidor ejecuta el código, genera el HTML y lo envía al navegador, incluyendo todo el contenido e información adicional para después conectar la aplicación JS (implementada en React, Vue, etc.) con el HTML generado.

• Si se realiza una petición posterior (navegar a otra página), el servidor puede enviar solo los datos necesarios, y el navegador ya tiene la estructura HTML inicial (es decir aquí pasa a modo SPA).

De esta manera un crawler puede ver el contenido directamente en el HTML (un crawler no suele ejecutar el JavaScript, si no que parsea el HTML y va buscando enlaces y para él todo son primeras peticiones), y el usuario ve la página completa desde el primer momento.

Esto es una mezcla de multipage application y single page application.

Ventajas:

• SEO efectivo.
• Mejor rendimiento que una SPA pura.
• Permite contenido dinámico con más control.

Inconvenientes:

• Necesita infraestructura con lógica de servidor.
• Hay que gestionar escalabilidad, cachés, seguridad y actualizaciones.
• El coste operativo es mayor.

Muy útil cuando el contenido cambia constantemente. Para una web informativa o con pocas actualizaciones, puede ser excesivo.

Opción 4: HTML puro

“¿Y si escribimos directamente HTML y CSS a mano?”

¡Claro! Es la forma más directa de tener una web estática.

¿Cómo funciona esto?

• Creas archivos HTML y CSS manualmente.
• Los subes a un servidor o CDN.
• Cada vez que alguien visita una página, el servidor envía el HTML tal cual (con todo el contenido estático), no hay ningún procesamiento adicional en el servidor.

Ventajas:

• Rendimiento excelente: se sirve como un rayo desde cualquier servidor o CDN.
• Escala perfectamente en visitas: puedes recibir miles o millones sin problema.

Pero...

• Mantener el contenido es un dolor. Si necesitas cambiar un texto, tienes que editar archivos manualmente.
• No hay reutilización: si tienes un mismo pie de página en 10 archivos, tienes que modificarlo en los 10.
• No hay componentes, ni estructura clara. Es fácil que el proyecto se vuelva inmanejable a medida que crece.

Escala en visitas, pero no escala en mantenimiento. Se vuelve inviable en proyectos medianos o grandes.

SSG al rescate 🦸‍♂️

Aquí es donde entra Static Site Generation.

Con SSG puedes:

• Usar componentes y lógica moderna.
• Acceder a datos desde HCMS, APIs, bases de datos...
• Generar páginas una vez en el build.
• Desplegar un sitio estático, optimizado y listo para servir desde cualquier parte.

¿Cómo funciona esto?

• En el momento del build, el framework lee los datos (de un HCMS, API, etc.), genera el HTML de cada página y lo guarda como archivos estáticos, es decir sólo se lanza esto una vez, no cada vez que alguien visita la página.
• Luego, cuando alguien visita el sitio, el servidor simplemente entrega esos archivos HTML ya generados
• No hay lógica de servidor en tiempo de ejecución, todo está precalculado.
• ¿Y si quiero introducir cambios? Simplemente vuelves a hacer un build y subes los nuevos archivos.

Nota: en el diagrama hemos puesto Astro, pero esto es aplicable a cualquier framework que soporte SSG, como Next.js, Nuxt, Gatsby, Angular etc.

¿Qué te ofrece SSG?

✅ Velocidad: los archivos ya están generados, se sirven al instante.
✅ SEO impecable: el contenido está presente en el HTML.
✅ Seguridad: no hay lógica en servidor, menos superficie de ataque.
✅ Simplicidad en despliegue: puedes usar Netlify, Vercel, GitHub Pages, un FTP o lo que prefieras.
✅ Mantenibilidad: usas componentes, layouts y herramientas modernas.
✅ Escalabilidad: al ser estático, no te preocupas por picos de tráfico.
✅ Edición de contenido: puedes conectar un Headless CMS para que cualquier persona actualice el contenido sin tocar el código.

Hablemos de rendimiento

Vamos a sacar una gráfica a alto nivel comparando el rendimiento de las diferentes opciones:

Nota: Esta gráfica es conceptual, cada proyecto, con su carga de tráfico etc puede tener un redimiento diferente, pero nos puede ayudar a entender las diferencias.

Terminos:

• TTFB (Time To First Byte): tiempo que tarda el servidor en responder a la petición inicial.
• FCP (First Contentful Paint): tiempo que tarda en aparecer el primer contenido visual.

A tener en cuenta:

• En PHP hay una carga fuerte en servidor, si la web tiene mucho tráfico, el servidor puede saturarse (todo el trabajo va en el TTFB).

• En SPA, el TTFB es bajo, pero el FCP puede ser alto porque, tienes que ejecutar un montón de codigo JS para montar el contenido y además traerte los datos desde por ejemplo una API Rest.

• En SSR, el TTFB lo hemos puesto un poco más bajo que en PHP porque los frameworks modernos suelen venir preparados con sistemas de caché (aunque en PHP se pueden añadir), pero el FCP puede ser más alto que en SSR porque hay que ejecutar el JS para hidratar la página.

• En SSG, el TTFB es muy bajo porque el HTML ya está generado y se sirve directamente, lo que también permite un FCP muy rápido, pero ojo es un pelín más alto que en HTML puro porque en algunos casos (depende del framework y opción que elijamos), puede tener algó de código o markup adicional de boilerplate.

• En HTML puro, el TTFB es el más bajo posible porque se sirve un archivo estático, y el FCP es muy rápido porque no hay JS que ejecutar para rendirizar el HTML.

Es decir con SSG tenemos un rendimiento muy cercano al de HTML puro, pero con la ventaja de poder usar componentes, lógica moderna y un Headless CMS para gestionar el contenido.

¿Y si...?

💡 ¿Y si necesito actualizar el contenido?

Usa un Headless CMS. Son gestores de contenido sin “capa visual” que sirven los datos mediante API.

Ejemplo: Content Island, que permite crear y editar contenido sin necesidad de tener conocimientos en programación, y luego consumirlo desde tu web generada con SSG.

Cuando alguien edita algo, puedes configurar un webhook que dispare automáticamente un nuevo build y despliegue el sitio actualizado. Este proceso está totalmente automatizado.

💡 ¿Y si necesito contenido dinámico?

SSG no es un callejón sin salida.

Los Frameworks modernos permiten:

• Insertar islas interactivas (componentes dinámicos dentro de páginas estáticas).

• Trabajar en modo híbrido, y usar SSG donde haga falta y SSR sólo en las páginas que lo necesitan.

• Usar técnicas como Incremental Static Regeneration (ISR): aquí sigues trabajando exactamente igual que el SSG (en build generamos todos los HTML) pero para cuando cambien tus datos, en lugar de hacer un nuevo build + despliegue, el framework irá mostrando HTML con los datos antiguos y por debajo hace petición a la API si la cache ha caducado. En cuanto vea que tiene datos nuevos, genera el nuevo HTML y lo sustituye. Para que el usuario vea los datos nuevos, necesita descargarse el nuevo HTML si o si, es decir, le saldría para la proxima vez que visite la web o haciendo un F5 .

¿Qué es ISR? ISR (Incremental Static Regeneration) es una técnica que combina lo mejor del contenido estático y dinámico. Permite generar páginas estáticas al momento de la primera visita o en segundo plano, sin tener que reconstruir todo el sitio cada vez.

Puedes tener lo mejor de cada enfoque si lo necesitas.

¿Cuándo NO usar SSG?

SSG no es una solución mágica para todo.

Evítalo si:

• Necesitas actualizaciones en tiempo real (p. ej., cotizaciones en vivo, chats).

• Tus datos cambian constantemente y el coste de regenerar el sitio entero es demasiado alto.

• Requieres mucha lógica en tiempo de ejecución.

En esos casos, SPA, SSR o módo híbrido pueden ser más adecuados.

Un buen ejemplo sería un panel de control en tiempo real, como el seguimiento de pedidos o la gestión de flotas. En este tipo de aplicaciones, los datos cambian constantemente, regenerar las páginas sería costoso e ineficiente, y además la lógica de negocio suele ser compleja y requiere mucha interacción por parte del usuario.

Conclusión

SSG es una técnica potente y moderna que te permite crear sitios rápidos, seguros, fáciles de desplegar y mantener, y con un SEO excelente.

Ideal para:

• Webs corporativas
• Blogs
• Portfolios
• Documentación
• Landing pages

Si usas un Headless CMS, puedes olvidarte del mantenimiento manual de contenido. Todo encaja como un guante.

Otro tipos de casos, dependen muchos, por ejemplo, un catálogo de un portal de comercio electrónico, si hay pocos productos y no cambian con frecuencia, SSG o una aproximación híbrida puede ser buena opción, pero si no se dan estas condiciones, no es la opción correcta.

Como puedes ver, hay casos donde SSG es claramente la mejor opción, otros donde dependerá de las necesidades específicas del proyecto, y algunos donde simplemente no aplica. Es ahí cuando tiene sentido hablar de SSG, SSR, SPA, y otras soluciones. No existe una bala de plata: hay que elegir la herramienta adecuada para cada problema.

Próximamente...

En los siguientes posts te contaré:

• Qué es JAMstack y cómo se relaciona con SSG.
• Cómo funciona un Headless CMS por dentro.
• Por qué Astro es uno de los mejores frameworks para SSG.
• Cómo montar un flujo de trabajo completo para publicar contenido sin tocar código.