¿Qué es Static Site Generation (SSG)?

Static Site Generation prerrenderiza cada página como HTML plano en el momento de la build, antes de cualquier solicitud del usuario. Los archivos resultantes se suben a almacenamiento de objetos o a una content-delivery-network-cdn y se sirven como respuestas cacheables y deterministas. En comercio, SSG funciona mejor con contenido que cambia en escalas de tiempo editoriales y no transaccionales.

Definición

Durante el paso de build, el framework recorre un conjunto de rutas, obtiene datos de APIs de comercio, del content-management-system-cms y de los catálogos de producto, y escribe un documento HTML autocontenido más un bundle de hidratación por página. Herramientas como Next.js getStaticProps, Astro, Nuxt nuxt generate, Gatsby y Hugo son implementaciones típicas de SSG. Las páginas se sirven desde cachés de edge con un TTFB de decenas de milisegundos y coste de renderizado cero. SSG es una piedra angular del jamstack y se combina de forma natural con una content-delivery-network-cdn para la distribución global.

Por qué importa

SSG elimina por completo el coste de renderizado en tiempo de ejecución, lo que se traduce en un TTFB predecible, un escalado horizontal sencillo y facturas de hosting más bajas. Para las Core Web Vitals es la estrategia de renderizado más benigna, porque el LCP depende principalmente de la entrega de activos. Es la opción adecuada para páginas de marketing, entradas de glosario, historias de marca, landing pages de SEO y contenido de categoría perenne. SSG también reduce la superficie de seguridad, porque no hay un runtime activo por solicitud. La contrapartida es la actualidad: cualquier cambio en el catálogo requiere una nueva build, lo que limita el uso de SSG en PDP sensibles al inventario.

Casos de uso

Los equipos de composable-commerce suelen aplicar SSG a su red de landing pages, blog, centros de ayuda y páginas de categoría de bajo tráfico en Astro, Next.js o Nuxt, y luego las despliegan mediante Vercel, Netlify o Cloudflare Pages. Los webhooks de un CMS headless activan builds incrementales cuando los editores publican, de modo que el TTFB se mantiene casi en cero mientras el contenido permanece actualizado. Para las PDP, los equipos o bien pasan a ISR para una revalidación más granular, o combinan shells de SSG con peticiones del lado del cliente para stock y precios. SSG también es la opción por defecto en las arquitecturas de referencia jamstack que combinan Hygraph, Sanity o Contentful con un frontend estático.

Relacionado

Explora Composable Headless Frontend · Performance and Core Web Vitals.