¿Qué es Static Site Generation (SSG)?

¿Qué es Static Site Generation (SSG)?

Static Site Generation (SSG) es la práctica de pre-renderizar todas las páginas de un sitio web a archivos HTML planos en build time, luego servir esos archivos directamente desde una CDN sin queries de base de datos en runtime ni renderizado del lado servidor. El resultado: las cargas de página completan en decenas de milisegundos porque el servidor (el edge de la CDN) simplemente entrega un archivo HTML terminado. No corre lógica de backend por petición. Sin conexión a base de datos. Sin motor de templates. Solo bytes en → bytes fuera.

SSG es una de tres estrategias principales de renderizado para páginas web. Las otras son SSR (Server-Side Rendering — HTML generado por petición en el servidor) y CSR (Client-Side Rendering — shell HTML vacío con JavaScript que fetcha y renderiza datos en el navegador). SSG está en el extremo rápido-barato-seguro del espectro: las cargas de página son insuperablemente rápidas, los costes de hosting tienden a cero y la superficie de ataque es mínima porque no hay lógica de servidor en runtime que explotar.

Cómo funciona SSG

El build step:

1. El contenido fuente vive en archivos. Markdown, YAML, JSON o un CMS headless. Diseñadores/escritores editan contenido en un formato amigable.
2. Una herramienta de build lee contenido + plantillas + datos. Next.js, Astro, Hugo, Jekyll, Gatsby, 11ty, Nuxt — todos compiten en este espacio. La herramienta de build mezcla plantillas con datos para producir HTML.
3. Las páginas se renderizan a archivos HTML. Un archivo HTML por URL. /blog/post-1.html, /products/widget-x.html, etc.
4. El output sube a S3 / CDN. CloudFront, Cloudflare, Netlify, Vercel — la CDN sirve los archivos pre-construidos.

El serve step (por petición):

1. El navegador pide /blog/post-1.
2. El edge de CDN sirve post-1.html. Cacheado en el edge más cercano, 50 KB transferidos, 10-50 ms total.
3. La página es interactiva inmediatamente. Sin esperar round-trips de backend. JavaScript hidrata si se necesita interactividad.

Cuándo SSG es la elección correcta

• Sitios de marketing y blogs. Las actualizaciones de contenido son infrecuentes (a lo sumo diarias). Build-una-vez-servir-barato encaja con el patrón de acceso.
• Sitios de documentación. Stripe Docs, Tailwind Docs, la documentación de Stack Overflow son todas SSG. La búsqueda puede usar una API separada; la documentación misma está pre-renderizada.
• Catálogos de productos e-commerce (mayormente). Las páginas de producto se renderizan una vez por build. Los datos en tiempo real (inventario, precios) cargan vía llamadas API separadas. Los grandes sitios e-commerce usan este patrón híbrido.
• Páginas landing SaaS. El sitio de marketing es SSG; la app detrás del login es otra cosa (SSR o CSR).
• Sitios que priorizan Core Web Vitals. SSG produce el LCP y TTFB más rápidos posibles. El SEO impulsado por CrUX favorece esto.

Dónde SSG se queda corto

• Contenido que cambia por usuario. Un dashboard logueado con datos específicos del usuario no puede ser SSG (sin fetching dinámico del lado cliente). Las páginas de marketing PUEDEN; el dashboard NO PUEDE.
• Contenido en tiempo real (precios de acciones, marcadores en vivo). SSG requeriría rebuilds cada pocos segundos. Usa SSR o WebSockets del lado cliente en su lugar.
• Sitios muy grandes con actualizaciones frecuentes. Un sitio con 1 millón de páginas donde 10K cambian diariamente es difícil de hacer como SSG puro — los rebuilds completos tardan demasiado. Incremental Static Regeneration (ISR — término de Next.js) lo aborda reconstruyendo páginas on-demand dentro de un SLA.
• Funcionalidad de búsqueda. Los sitios estáticos no pueden ejecutar búsqueda del lado servidor; necesitarás o una API de búsqueda de terceros (Algolia, Typesense) o búsqueda fuzzy del lado cliente sobre un índice pre-construido.
• Formularios y mutaciones. SSG no puede aceptar envíos de formularios directamente. Combina con un endpoint API separado de manejo de formularios o usa un servicio como Formspree.

Los grandes frameworks SSG (panorama 2026)

• Next.js (React). Híbrido SSG/SSR. El framework basado en React más popular. Nativo de Vercel pero funciona en otros sitios. Pesado pero feature-completo.
• Astro. Agnóstico de componentes (React, Vue, Svelte todos en un proyecto). Envía cero JavaScript por defecto — excelentes Core Web Vitals out of the box.
• Hugo (Go). Binario compilado, builds increíblemente rápidos (1000+ páginas por segundo). Capacidades dinámicas limitadas pero velocidad de build inigualable.
• 11ty (Eleventy, Node). Minimal, flexible. Popular para sitios simples que no necesitan un framework JavaScript en el cliente.
• Gatsby (React). Maduro, rico en plugins. Mayormente superado por Next.js pero aún mantenido.
• Nuxt (Vue). La respuesta de Vue a Next.js. Híbrido SSG/SSR.
• Jekyll (Ruby). El SSG original. Impulsa GitHub Pages por defecto. Envejeciendo pero aún funciona.

SSG y Core Web Vitals

SSG produce las mejores métricas CWV del mercado:

• LCP: HTML pre-renderizado + CSS crítico inline típicamente da LCP sub-1.5s desde cualquier región con cobertura CDN.
• FCP: Sub-1s en la mayoría de casos. El HTML llega en el primer paquete.
• CLS: Mismas restricciones que cualquier otra estrategia de renderizado — depende del markup, no del enfoque de build. SSG no hace CLS malo ni bueno.
• INP: Si el sitio es mayormente estático (sin JavaScript pesado), INP es excelente. Si el sitio usa hidratación pesada del lado cliente, INP puede ser igual a un sitio CSR.
• TTFB: Mejor en su clase. HTML cacheado en CDN sirve en milisegundos, bien por debajo de 200 ms incluso desde regiones distantes.

FAQ: Static Site Generation

¿Cuál es la diferencia entre SSG y SSR?

Timing de generación de HTML. SSG genera todas las páginas en build time; SSR genera cada página por petición en el servidor. SSG es más rápido (sin trabajo por petición) pero stale (contenido fijado en el momento del build). SSR es más fresco (datos en vivo) pero más lento por petición.

¿Pueden los sitios SSG ser dinámicos?

Sí — el HTML estático puede incluir JavaScript que fetcha datos dinámicos después de la carga de página. El contenido base está pre-renderizado (bueno para SEO), y las features dinámicas (conteo de carrito, personalización) cargan después. Este es el patrón dominante para e-commerce moderno.

¿Qué pasa con SSG con millones de páginas?

Los tiempos de build se vuelven un problema. Soluciones: Incremental Static Regeneration (Next.js) construye páginas en la primera petición y cachea; builds distribuidos a través de workers CI (Vercel, Netlify); o aceptar que algunas páginas vivan como SSR mientras las populares se quedan SSG.

¿Es SSG siempre más rápido que SSR?

Para primer byte y carga total de página, casi siempre sí. Para frescura de datos, no — SSR puede mostrar datos actualizados hace segundos, SSG muestra datos del último build. La respuesta correcta depende de tu caso de uso.

¿Funciona SSG con personalización?

Sí, vía carga de datos del lado cliente. El HTML compartido es SSG; los elementos específicos del usuario (su nombre, su carrito, sus recomendaciones) cargan vía JavaScript después de la carga de página. Mismo patrón que las páginas de checkout de Stripe, Notion docs, etc.

¿Cuál es el truco con SSG?

Los tiempos de build escalan linealmente con el tamaño de contenido. Los sitios con 100K+ páginas necesitan estrategias de build cuidadosas. Las actualizaciones de contenido requieren un deploy (o ISR). Y las features dinámicas (formularios, búsqueda, comentarios) necesitan infraestructura separada.

Cómo LoadFocus mide el rendimiento SSG

LoadFocus ejecuta tests de velocidad basados en Lighthouse desde más de 25 regiones, capturando TTFB, LCP, INP y CLS. Los sitios SSG típicamente muestran en el decil superior de scores CWV — pero deberías verificar entre regiones porque la cobertura CDN varía. Las pruebas de carga con JMeter/k6 también confirman que tu CDN maneja bien el tráfico spike — SSG con una CDN fuerte es uno de los pocos stacks que maneja spikes de tráfico 10x con elegancia.