¿Qué es Static Site Generation (SSG)?

¿Qué es la generación de sitios estáticos (SSG)?

La generación de sitios estáticos (SSG, por Static Site Generation) es un enfoque de renderizado en el que un paso de compilación convierte tu contenido y tus plantillas en archivos HTML por adelantado. Esos archivos se suben a un hosting o CDN y se sirven tal cual, de modo que no se ejecuta código ni consulta a base de datos cuando alguien pide una página. Es una de las varias estrategias de renderizado web.

Cómo funciona el SSG

1. El contenido vive en archivos fuente o en un CMS. Markdown, JSON, YAML o la API de un CMS headless.
2. Una herramienta de compilación combina contenido, plantillas y datos. Escribe un archivo HTML por URL, además de CSS, JavaScript e imágenes.
3. El resultado se despliega. Los archivos van a un almacenamiento de objetos o a un hosting estático, normalmente detrás de un CDN.
4. Cada petición es una lectura de archivo. El edge devuelve el archivo ya generado, así que el tiempo hasta el primer byte depende sobre todo de la distancia de red.

Frameworks como Astro, Hugo, Eleventy, Jekyll, Next.js y Nuxt pueden generar salida estática. Según su documentación de islas, Astro renderiza los componentes a HTML y CSS y solo envía JavaScript de las partes que marcas como interactivas. En Next.js, con output: 'export', next build escribe una carpeta estática con HTML, CSS y JavaScript.

Cuándo el SSG es la opción correcta

• Sitios de marketing, blogs y documentación: el contenido cambia según un calendario editorial, no por visitante.
• Páginas de aterrizaje que deben ser rápidas: el HTML generado de antemano y servido desde un CDN es el camino más corto al primer byte.
• Catálogos o listados con precio o stock consultados desde el cliente: la estructura es estática y una pequeña petición a una API rellena los datos en vivo.
• Sitios que necesitan un hosting simple y barato: un hosting estático no tiene servidor de aplicaciones que parchear ni escalar.

Dónde se queda corto el SSG

• Contenido por usuario. Un panel con sesión no se puede generar de antemano para cada usuario. Usa renderizado en el servidor u obtén los datos en el navegador.
• Datos en vivo. Marcadores o niveles de stock que cambian cada pocos segundos necesitan SSR o una petición desde el cliente.
• Sitios muy grandes que cambian rápido. Reconstruir miles de páginas con cada edición se vuelve lento. La regeneración estática incremental reconstruye solo las páginas que cambiaron.
• Funciones de servidor. La exportación estática no tiene lógica en tiempo de petición. Next.js indica que cookies, redirecciones, reescrituras, cabeceras, server actions e ISR no se admiten con output: 'export', así que se resuelven en el hosting o el CDN.

Ejemplo: un sitio de documentación

Una documentación tiene 400 páginas en Markdown. La compilación las convierte en 400 archivos HTML, un trabajo de CI los sube al almacenamiento y el CDN los cachea en todo el mundo. Cuando una redactora corrige una errata, la canalización recompila y vuelve a desplegar, y se purga la caché del CDN de las rutas modificadas. La búsqueda funciona con un índice generado de antemano en el navegador o con una API de búsqueda alojada.

Errores comunes

• Olvidar invalidar la caché del CDN tras desplegar, de modo que los visitantes siguen viendo la página antigua.
• Llamar durante la compilación a una API de terceros lenta y sin tiempo límite, de forma que una sola caída rompe toda la compilación.
• Dar por hecho que estático es seguro por defecto: el hosting, los formularios y cualquier API siguen necesitando protección.
• Cargar paquetes grandes de JavaScript en una página estática y perder la ventaja de velocidad.
• Fijar en el código datos que deberían consultarse en el momento, como los precios.

SSG, pruebas de rendimiento y monitorización

Las páginas estáticas eliminan casi toda la variabilidad del backend, así que lo que conviene vigilar es la tasa de aciertos de caché del CDN, el tiempo hasta el primer byte desde distintas regiones y el peso de lo que se envía. Sigue la velocidad de página y las Core Web Vitals tras cada despliegue con LoadFocus Page Speed Monitoring, que ejecuta auditorías Lighthouse programadas desde 25 regiones en la nube. El artículo consejos de velocidad de página (en inglés) cubre el trabajo de frontend que sigue importando en un sitio estático.

Si un sitio estático llama a APIs para búsqueda, formularios o datos en vivo, la carga se nota en esos endpoints. Haz una prueba de carga contra ellos antes de un pico de tráfico.

Preguntas frecuentes: generación de sitios estáticos

¿Qué diferencia hay entre SSG y SSR?

El momento. SSG genera el HTML una vez, antes de que llegue ningún visitante. SSR lo genera en el servidor en cada petición. SSG es más barato y rápido de servir; SSR puede mostrar datos por petición o en tiempo real.

¿Un sitio estático es un sitio sin JavaScript?

No. Un sitio estático puede ejecutar JavaScript en el navegador para menús, búsqueda o widgets. Estático significa que el HTML está generado de antemano, no que la página no sea interactiva.

¿Es bueno el SSG para el SEO?

Sí. Los rastreadores reciben el HTML completo de inmediato y las páginas rápidas ayudan con las Core Web Vitals. Eso sí, el SSG por sí solo no posiciona una página: siguen decidiendo la calidad del contenido y los enlaces.

¿Cómo actualizo el contenido de un sitio estático?

Cambia la fuente, ejecuta la compilación y despliega los archivos nuevos. La mayoría de los hostings y sistemas de CI lo hacen solos en cada commit o cuando tu CMS publica. En sitios muy grandes, la regeneración incremental reconstruye solo lo que cambió.

¿Puede un sitio estático tener formularios, búsqueda o inicio de sesión?

Sí, llamando a APIs desde el navegador o usando servicios alojados para formularios y búsqueda. La página sigue siendo estática y la parte dinámica se ejecuta en otro sitio.