Quando Usar SSG: Static Site Generation Guia
Quando geração estática é superior a SSR ou CSR.
Por que isso é importante
Quando Usar SSG: Static Site Generation Guia. SSG entrega performance máxima: HTML pré-renderizado em CDN, load <100ms. Mas limitação é rigidez - conteúdo atualiza só em rebuild. Sites dinâmicos sofrem, sites de conteúdo brilham. Quando SIM usar SSG Conteúdo muda raramente (horas/dias)
Quando SIM usar SSG
Conteúdo muda raramente (horas/dias)
Blog, documentação, landing pages, portfolios. Você publica conteúdo novo e faz rebuild. Entre rebuilds, HTML estático serve de CDN. Performance imbatível.
SEO é prioridade máxima
HTML completo pré-renderizado. Crawlers Google indexam perfeito. Nenhum JS necessário pra conteúdo aparecer. SSG é SEO no hard mode.
Você quer custo zero de infra
CDN hosting (Netlify, Vercel, Cloudflare Pages) é grátis pra static sites. Sem servidor, sem banco. Budget apertado? SSG economiza.
Performance é requisito crítico
Sites de marketing onde cada 100ms importa. SSG elimina server processing. HTML já pronto no edge. Fastest possible.
Conteúdo vem de CMS headless
Contentful, Sanity, Strapi como source. Build puxa dados do CMS, gera HTML estático. Editores usam CMS, devs não tocam código.
Quando NÃO usar SSG
Conteúdo atualiza frequentemente (minutos)
Feed de notícias, dashboard ao vivo, dados real-time. Rebuild a cada minuto é inviável. SSR ou CSR são melhores.
Personalização por usuário
Recomendações personalizadas, dashboards customizados. SSG gera mesmo HTML pra todos. Personalização exige JS no cliente ou servidor.
Site tem milhares de páginas dinâmicas
E-commerce com 100K produtos, rede social com milhões de perfis. Build time explode. SSR on-demand é mais viável.
Você precisa de dados de formulários
SSG puro não tem backend. Formulários exigem API separada. Se app é form-heavy, SSR com API routes é mais direto.
Frameworks SSG Populares
Next.js Static Export
Familiar pra quem já usa Next. Export estático mantém React. Limitação: sem API routes, sem ISR.
Astro
Zero JS por padrão. Usa componentes de qualquer framework (React, Vue, Svelte). Performance máxima. Ideal pra sites de conteúdo.
Gatsby
Veterano de SSG. GraphQL data layer. Plugins pra tudo. Meio pesado mas poderoso pra sites complexos.
Hugo/Jekyll
Geradores tradicionais em Go/Ruby. Ultrarapidos. Sem JS framework. Ideal pra blogs simples e docs.
Framework de Decisão
Checklist pra usar SSG
- Conteúdo atualiza em horas/dias, não minutos?
- Site tem menos de 10K páginas?
- SEO é prioridade e conteúdo é público?
- Você quer hosting grátis ou barato?
- Performance <100ms load é requisito?
- Não precisa de personalização por usuário?
5+ sim: SSG é ideal. 3-4: considere ISR como meio-termo. 0-2: SSR ou CSR são melhores.
SSG + CSR Hybrid
Você pode ter SSG pro conteúdo estático e hidratar com dados dinâmicos via fetch no cliente. Skeleton estático carrega instantâneo, dados atualizam depois. Best of both.
Perguntas frequentes
Quando SIM usar SSG
Blog, documentação, landing pages, portfolios. Você publica conteúdo novo e faz rebuild. Entre rebuilds, HTML estático serve de CDN. Performance imbatível. HTML completo pré-renderizado. Crawlers Google indexam perfeito. Nenhum JS necessário pra conteúdo aparecer. SSG é SEO no hard mode. CDN hosting (Netlify, Vercel, Cloudflare Pages) é grátis pra static sites. Sem servidor, sem banco. Budget apertado? SSG economiza.
Quando NÃO usar SSG
Feed de notícias, dashboard ao vivo, dados real-time. Rebuild a cada minuto é inviável. SSR ou CSR são melhores. Recomendações personalizadas, dashboards customizados. SSG gera mesmo HTML pra todos. Personalização exige JS no cliente ou servidor. E-commerce com 100K produtos, rede social com milhões de perfis. Build time explode. SSR on-demand é mais viável.