SSR: render no servidor

Frameworks como Next.js, Remix e Nuxt geram o HTML no servidor a cada requisição. É a solução mais robusta para conteúdo dinâmico (e-commerce, dashboards públicos, blogs com comentários). Custo: infraestrutura e complexidade maiores.

Prerender: estático na hora do build

Ferramentas como react-snap ou Vite SSG geram HTML estático no build para cada rota conhecida. Ideal para sites institucionais e blogs sem conteúdo personalizado. Bots veem HTML completo; usuários recebem hydration depois.

Hydration sem SSR: cuidado

  • Apenas para apps onde SEO não é prioridade
  • Como SaaS internos ou painéis logados
  • Crawlers de IA não confiam em JS render
  • Evite para qualquer página pública que deva ranquear

Como escolher

Se o conteúdo muda por usuário ou em tempo real, use SSR. Se as rotas são conhecidas no build e mudam raramente, prerender é mais barato e rápido. Apps puramente logados podem ficar em CSR sem prejuízo.

Perguntas frequentes

Vite tem SSR?

Sim, via vite-plugin-ssr ou Vike. Mais simples que Next em projetos pequenos.

Google indexa SPA puro?

Indexa, mas com atraso e falhas frequentes. Não recomendado.

Prerender funciona com rotas dinâmicas?

Sim, desde que você liste os slugs no build.

GPTBot executa JavaScript?

Não de forma confiável. HTML inicial precisa ter o conteúdo.

Posso migrar de CSR para SSR aos poucos?

Sim, rota por rota. Next App Router e Remix facilitam isso.

Conclusão

Renderização no cliente pode sustentar interações ricas, enquanto SSR ou pré-renderização disponibilizam conteúdo principal no HTML inicial. A escolha depende de atualização, personalização, cache e custo operacional. Sites modernos podem combinar estratégias por rota, desde que validem o resultado publicado para pessoas e crawlers em vez de assumir descoberta automática.