Frontend
Quando Usar SSG: Static Site Generation Guia
Quando geração estática é superior a SSR ou CSR.
CrazyStack
Carregando
Quando geração estática é superior a SSR ou CSR.
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)
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.
Sites de marketing onde cada 100ms importa. SSG elimina server processing. HTML já pronto no edge. Fastest possible.
Contentful, Sanity, Strapi como source. Build puxa dados do CMS, gera HTML estático. Editores usam CMS, devs não tocam código.
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.
SSG puro não tem backend. Formulários exigem API separada. Se app é form-heavy, SSR com API routes é mais direto.
Familiar pra quem já usa Next. Export estático mantém React. Limitação: sem API routes, sem ISR.
Zero JS por padrão. Usa componentes de qualquer framework (React, Vue, Svelte). Performance máxima. Ideal pra sites de conteúdo.
Veterano de SSG. GraphQL data layer. Plugins pra tudo. Meio pesado mas poderoso pra sites complexos.
Geradores tradicionais em Go/Ruby. Ultrarapidos. Sem JS framework. Ideal pra blogs simples e docs.