ARQUITECTURA

SSG

Generación estática: todas las páginas se construyen una vez al compilar y el servidor solo entrega ficheros HTML ya hechos, sin calcular nada.

Nivel · intermedio4 min de lecturaActualizado 23 ago 2026
También conocido como: Static Site Generation, Generación de sitio estático

Definición

SSG (Static Site Generation) consiste en generar todas las páginas de una web durante la compilación, antes de que nadie las pida. El resultado es una carpeta de ficheros HTML, CSS, JavaScript e imágenes que el servidor se limita a entregar.

No hay base de datos consultándose en cada visita, ni código ejecutándose por petición. El trabajo se hizo una vez.

Suena antiguo —al fin y al cabo así era la web en 1995— y es la arquitectura más recomendable hoy para todo lo que sea contenido. Los generadores modernos permiten escribir con componentes, leer de un CMS o de ficheros Markdown, y producir HTML plano al final.

Por qué gana cuando encaja

  • Velocidad. No hay nada que calcular. Un fichero se sirve en milisegundos, y encima se puede poner en una CDN cerca del visitante.
  • Coste. Un alojamiento compartido de unos euros al mes aguanta lo que a un servidor dinámico le costaría mucho más.
  • Seguridad. Sin código ejecutándose por petición y sin base de datos expuesta, la superficie de ataque se reduce muchísimo. No hay inyección SQL posible si no hay consultas.
  • Fiabilidad. Un pico de tráfico que tumbaría una aplicación dinámica, en estático apenas se nota.
  • SEO. El HTML llega completo desde el primer byte. Es el mejor escenario posible para un buscador.

Ejemplo práctico

Esta web es SSG de principio a fin, y da la medida de lo que permite.

Al compilar, un script lee los 101 ficheros Markdown del diccionario y genera 107 páginas HTML completas: una por término, una por categoría, más las páginas fijas. Genera además el sitemap, las imágenes para compartir en redes de cada término y el índice del buscador.

Ese proceso tarda unos segundos. Lo que se sube al hosting es una carpeta de ficheros. El servidor no tiene PHP ni base de datos ni nada corriendo: solo entrega ficheros.

El resultado medible: cada página pesa entre 570 KB y 1 MB y responde en décimas de segundo, en un alojamiento compartido de los baratos.

Y hay una consecuencia que no es obvia y que me gusta especialmente: como no hay servidor procesando nada, el buscador del diccionario también funciona sin servidor. El índice se descarga con la página y la búsqueda se resuelve en el navegador del visitante. Cero coste por consulta, y lo que la gente escribe no llega a mí.

Los límites, y cómo se rodean

El contenido personalizado. No puedes pregenerar una página que dice "Hola, Antonio" para cada usuario. Solución: la parte pública en estático y la privada en servidor. Es el reparto que uso entre esta web y el portal de clientes de IMDICA.

El contenido que cambia a cada minuto. Un stock en vivo no puede estar en un HTML compilado esta mañana. Solución: pedir ese dato concreto por API desde el navegador, dejando el resto de la página estática.

Los tiempos de compilación. Con cien páginas, segundos. Con cincuenta mil, la compilación empieza a doler. Solución: generación incremental —regenerar solo lo que cambió— o generar bajo demanda la primera vez que alguien pide una página.

Publicar exige compilar. No basta con guardar en un panel: hay que reconstruir y desplegar. Se automatiza con CI/CD, pero es un paso más.

Errores comunes

  • Olvidar que el despliegue no borra. Si subes por encima sin limpiar, los ficheros de compilaciones antiguas se quedan ahí para siempre. Yo me encontré con un panel privado publicado meses después de haberlo quitado del código, precisamente por esto.
  • Pregenerar demasiado. Generar cien mil páginas que nadie visita alarga la compilación sin beneficio.
  • Meter datos que caducan. Precios o plazos escritos en el HTML compilado envejecen sin que nadie se entere.
  • No versionar los assets. Sin un identificador en el nombre del fichero, el navegador sirve la versión antigua de la caché.

Cuándo usarlo

en webs corporativas, blogs, documentación, portfolios, landings y catálogos que no cambian cada minuto. Que es la mayoría de lo que se encarga.

No cuando cada usuario ve algo distinto, cuando el contenido cambia en tiempo real, o cuando publicar tiene que ser inmediato sin proceso de compilación.

Mi regla, después de tener las dos cosas en producción: empieza por estático y pásate a dinámico solo cuando tengas un motivo concreto. El camino contrario, de dinámico a estático, es mucho más caro.

Referencias

Tagsprogramacionarquitecturarendimientoweb
Escrito por
Antonio Echeverría

Dirijo IMDICA, una empresa de suministro industrial, desde 2007. Escribo estas definiciones desde el lado de quien las usa para decidir, no desde el de quien las estudia.

Si necesitas que alguien construya esto de verdad y no solo lo explique, eso es lo que hago en AE Works.