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
Render no cliente é ótimo para experiência; render no servidor é essencial para descoberta. Combine os dois e ganhe os dois mundos.