"SSR, SSG e CSR: qual estratégia de renderização escolher"
Renderização no servidor, geração estática ou no cliente? Entenda os trade-offs de SSR, SSG e CSR, mais ISR e streaming, para tomar a decisão certa de SEO, performance e custo.
Onde o HTML da sua página é gerado — no servidor, no momento do build ou no navegador do usuário — é uma das decisões de arquitetura mais consequentes que você toma. Ela afeta velocidade, custo de infraestrutura, frescor dos dados e, crucialmente, se o Google consegue indexar seu conteúdo. Este guia explica SSR, SSG e CSR com clareza, mostrando os trade-offs de cada um, as abordagens híbridas que dominam os frameworks modernos e como escolher com confiança para o seu caso.
O problema: de onde vem o HTML?
Toda página web acaba virando HTML que o navegador exibe. A pergunta é onde e quando esse HTML é montado. Existem três respostas principais, e cada uma move o trabalho de renderização para um lugar diferente da linha do tempo:
- CSR: o navegador monta o HTML em tempo de execução, com JavaScript.
- SSR: o servidor monta o HTML a cada requisição.
- SSG: o HTML é montado uma vez, no build, antes de qualquer visita.
Essa escolha conversa diretamente com o SEO técnico, porque define o que o robô do Google enxerga quando chega à página. Mas o impacto vai além do SEO: ele define quanto você gasta em servidores, quão rápido o usuário vê algo na tela e até quão difícil é manter o sistema. Antes de escolher, vale entender cada modelo isoladamente para depois compará-los lado a lado.
Uma forma útil de pensar é imaginar uma "linha do tempo da renderização" com três marcos: o build (quando você publica o site), a requisição (quando alguém pede a página) e o runtime no cliente (quando o navegador executa o JavaScript). Cada estratégia coloca o trabalho pesado em um desses três marcos. Quem entende isso para de decorar nomes e passa a raciocinar sobre trade-offs.
CSR: Client-Side Rendering
No CSR, o servidor envia um HTML praticamente vazio mais um bundle JavaScript. O navegador então baixa, executa o JS e monta a interface. É o modelo das Single Page Applications tradicionais com React, Vue ou Angular sem framework de servidor.
<!-- O que o servidor envia no CSR -->
<body>
<div id="root"></div>
<script src="/app.bundle.js"></script>
</body>O fluxo, do ponto de vista do usuário, é o seguinte: ele recebe uma casca vazia, vê uma tela em branco (ou um spinner), o navegador baixa o JavaScript, executa a aplicação, faz as chamadas de API necessárias e só então pinta o conteúdo. Esse encadeamento de etapas em série é a raiz tanto das forças quanto das fraquezas do modelo.
Vantagens:
- Navegação interna fluida, sem recarregar a página.
- Servidor simples — entrega arquivos estáticos, podendo morar inteiramente em uma CDN.
- Ótimo para apps autenticados e dashboards, onde SEO não importa.
- Separação clara entre back-end (API) e front-end, facilitando equipes independentes.
Desvantagens:
- O primeiro carregamento é mais lento (precisa baixar e executar JS).
- Risco de SEO: o bot pode ver uma página vazia antes de o JS rodar.
- Pior LCP, afetando os Core Web Vitals.
- Vulnerável a falhas de rede no meio do caminho: se o bundle não carrega, a página não aparece.
O CSR não é "errado". Ele é a escolha certa quando a página fica atrás de um login, quando o SEO é irrelevante e quando a interatividade rica domina a experiência — pense em um editor de planilhas, um painel de analytics ou um cliente de e-mail. Nesses casos, pagar o custo de um primeiro carregamento mais lento em troca de navegação instantânea depois faz todo sentido.
SSR: Server-Side Rendering
No SSR, o servidor executa o código da aplicação e gera o HTML completo a cada requisição, enviando uma página já preenchida. No navegador, o JavaScript então "hidrata" esse HTML, tornando-o interativo.
// Exemplo conceitual de SSR (Next.js)
export async function getServerSideProps(context) {
const dados = await buscarDados();
return { props: { dados } }; // renderizado no servidor a cada request
}Vantagens:
- Conteúdo no HTML inicial — ótimo para SEO e para o primeiro paint.
- Dados sempre frescos (gerados na hora).
- Ideal para conteúdo personalizado ou que muda constantemente.
- O usuário vê conteúdo útil rapidamente, mesmo antes da hidratação.
Desvantagens:
- Maior carga e custo no servidor (renderiza a cada visita).
- TTFB (time to first byte) pode subir se a geração for pesada.
- Necessita de cache para escalar.
- Complexidade operacional: você precisa de um runtime rodando, não só de arquivos estáticos.
O que é hidratação, exatamente?
A hidratação é um conceito central no SSR e merece atenção. O servidor manda HTML pronto, mas esse HTML é "morto": botões não respondem a cliques, formulários não validam. O navegador então baixa o mesmo código de componente que rodou no servidor e o "anexa" ao HTML existente, religando os event listeners e o estado da aplicação. Esse processo é a hidratação.
O problema é que a hidratação tem um custo: o navegador precisa baixar e executar JavaScript proporcional ao tamanho da página. Em páginas pesadas, existe um intervalo desconfortável em que o usuário vê o conteúdo mas não consegue interagir com ele — o famoso "uncanny valley" da hidratação. É justamente por isso que técnicas como hidratação parcial e ilhas (que veremos adiante) ganharam força.
Cache: o segredo para o SSR escalar
Renderizar a cada requisição parece caro, e é — se você fizer isso literalmente. Na prática, SSR sério vive de cache. Você pode cachear a página inteira por alguns segundos, cachear fragmentos que mudam pouco, ou usar Cache-Control com stale-while-revalidate para servir uma versão antiga enquanto gera a nova em segundo plano. Sem uma estratégia de cache, um pico de tráfego derruba o servidor de renderização.
SSG: Static Site Generation
No SSG, todas as páginas são geradas no momento do build e servidas como arquivos estáticos. Quando o usuário visita, recebe HTML pronto, sem nenhuma renderização sob demanda.
// Exemplo conceitual de SSG (Next.js)
export async function getStaticProps() {
const dados = await buscarDados();
return { props: { dados } }; // gerado uma vez, no build
}Vantagens:
- Velocidade máxima — só servir arquivos prontos, idealmente via CDN.
- Excelente para SEO e Core Web Vitals.
- Custo e superfície de ataque mínimos.
- Confiabilidade altíssima: arquivos estáticos quase nunca "caem".
Desvantagens:
- Conteúdo "congelado" no build — não serve para dados em tempo real.
- Builds podem ficar lentos em sites com milhares de páginas.
- Requer rebuild (ou ISR) para atualizar conteúdo.
- Personalização por usuário não é possível diretamente (mas pode ser hidratada no cliente).
O SSG é imbatível para blogs, documentação e sites institucionais. Combinado a um bom sitemap XML, garante indexação rápida e completa. Como cada página é um arquivo pronto na borda da rede, a latência percebida é mínima em qualquer lugar do mundo — a CDN entrega o arquivo do ponto de presença mais próximo do usuário.
Vale notar que SSG não significa "sem JavaScript". Você ainda pode ter componentes interativos: o HTML chega estático e rápido, e o JS hidrata as partes dinâmicas depois. É a base das arquiteturas que combinam estático com ilhas de interatividade.
Estratégias híbridas e modernas
Na prática, os frameworks modernos não obrigam você a escolher um único modelo para o site inteiro. As abordagens híbridas combinam o melhor de cada um:
- ISR (Incremental Static Regeneration): páginas estáticas que se regeneram em segundo plano após um intervalo, unindo a velocidade do SSG ao frescor do SSR.
- Streaming SSR / React Server Components: envia partes do HTML conforme ficam prontas, melhorando o tempo até o primeiro byte útil.
- Hidratação parcial / Islands: hidrata apenas os componentes interativos, deixando o resto como HTML estático e leve.
Essas técnicas se apoiam em recursos do protocolo, como a multiplexação introduzida no HTTP/2 (Belshe, Peon e Thomson, 2015), que permite enviar muitos recursos em paralelo sobre uma única conexão — algo que potencializa o streaming de HTML.
ISR em detalhe
O ISR é a resposta para a maior fraqueza do SSG: conteúdo congelado. Em vez de regerar o site inteiro toda vez que um post muda, você define um intervalo de revalidação. A primeira visita após esse intervalo dispara, em segundo plano, a regeneração daquela página específica. O usuário que disparou ainda recebe a versão antiga (rápida); os próximos recebem a nova.
// ISR no Next.js: a página revalida a cada 60 segundos
export async function getStaticProps() {
const dados = await buscarDados();
return {
props: { dados },
revalidate: 60, // regenera no máximo uma vez por minuto
};
}Na prática, o ISR entrega 99% da velocidade do SSG com frescor "quase em tempo real". É a escolha padrão para catálogos de produtos, portais de notícias e qualquer conteúdo que muda de hora em hora, mas não a cada segundo.
Streaming e ilhas
O streaming SSR muda o jogo do TTFB: em vez de esperar a página inteira ficar pronta no servidor para então enviá-la, o servidor manda o <head> e o esqueleto imediatamente, e vai "empurrando" o resto do HTML conforme os dados chegam. Componentes lentos (como uma seção que depende de uma API externa) não bloqueiam o restante da página.
A arquitetura de ilhas, por sua vez, parte de uma página majoritariamente estática e marca apenas alguns componentes como interativos — as "ilhas". Só essas ilhas baixam e executam JavaScript. O resultado é uma página que carrega quase tão leve quanto SSG puro, mas com pontos de interatividade onde realmente importa. Frameworks como Astro popularizaram essa ideia.
SEO: o que o Google realmente vê
O Google rende JavaScript, mas o faz numa segunda passada e com orçamento limitado. Isso cria um risco concreto no CSR: na primeira visita do crawler, o conteúdo pode não estar lá.
Para o Google, a ordem de preferência em termos de robustez de indexação costuma ser:
- SSG — HTML completo, estático, rápido.
- SSR — HTML completo gerado por requisição.
- CSR — depende da renderização de JS, mais arriscado.
Entender como funciona o Google — crawling, renderização e indexação — deixa claro por que entregar conteúdo no HTML inicial é a aposta mais segura. Dados estruturados também devem estar no HTML servidor para garantir rich snippets.
Por que o CSR é arriscado para SEO
O processo de indexação do Google tem duas filas: a primeira lê o HTML cru imediatamente; a segunda, que executa JavaScript, pode demorar dias ou semanas e tem orçamento finito. Em um site CSR, a primeira fila vê uma <div id="root"> vazia. Se o conteúdo é importante, você está apostando que a segunda fila vai chegar logo e renderizar tudo corretamente — uma aposta que nem sempre se paga, especialmente em sites grandes onde o orçamento de renderização é disputado.
Outros motores de busca e ferramentas (Bing, redes sociais que geram previews via Open Graph, robôs de IA) frequentemente não executam JavaScript nenhum. Para eles, uma página CSR é literalmente em branco. Por isso, conteúdo que precisa ser descoberto e compartilhado deve estar no HTML inicial, ponto.
Performance: o impacto nas métricas
Cada modelo afeta os Core Web Vitals de forma diferente. O Google reforça que essas métricas refletem a experiência real do usuário (Google Web.dev, 2020), então a escolha de renderização tem efeito direto no ranqueamento.
- LCP: SSG e SSR vencem, pois entregam conteúdo cedo; CSR atrasa.
- INP: CSR e SSR pesado podem sofrer com muito JavaScript a hidratar.
- CLS: independe do modelo, mas hidratação mal feita pode causar saltos.
A regra de ouro: quanto mais trabalho você empurra para o servidor ou para o build, mais leve fica o navegador do usuário — e melhor tende a ser a performance percebida.
Vale separar duas coisas que costumam ser confundidas: quando o conteúdo aparece e quando ele fica interativo. SSG e SSR fazem o conteúdo aparecer cedo (bom LCP), mas se você sobrecarregar a página de JavaScript, a interatividade pode chegar tarde (INP ruim). Otimizar renderização não é só escolher o modelo; é também controlar o tamanho do bundle que hidrata a página.
Trade-offs de custo e operação
Além de SEO e performance, há a dimensão de custo, que muita gente esquece até a fatura chegar.
- SSG é o mais barato de operar: arquivos estáticos numa CDN custam quase nada e escalam infinitamente. O custo está no tempo de build, que cresce com o número de páginas.
- SSR é o mais caro: cada requisição consome CPU no servidor. Sem cache, o custo cresce linearmente com o tráfego, e um pico inesperado pode gerar uma conta alta.
- CSR transfere o custo de computação para o dispositivo do usuário. O servidor é barato (serve estáticos), mas usuários com aparelhos fracos pagam o preço em lentidão.
- ISR fica no meio: barato como o SSG na maior parte do tempo, com picos pontuais de custo nas regenerações.
Para sites com milhares de páginas, o tempo de build do SSG puro pode virar gargalo — um build de 30 minutos atrasa cada publicação. É exatamente esse problema que o ISR resolve, gerando páginas sob demanda na primeira visita em vez de todas de uma vez.
Como decidir: um guia rápido
Use estas perguntas para orientar a escolha:
- O conteúdo muda raramente e é igual para todos? → SSG.
- O conteúdo é dinâmico, personalizado ou frequente, e precisa de SEO? → SSR.
- É um app atrás de login, sem necessidade de SEO? → CSR.
- Precisa de frescor sem abrir mão da velocidade do estático? → ISR/híbrido.
Na maioria dos sites de conteúdo, uma base SSG ou SSR com ilhas de interatividade entrega o melhor equilíbrio entre SEO, performance e custo. Para aprofundar a otimização depois de escolher, veja o guia de performance web.
Um ponto prático: você não precisa de uma única estratégia para o site inteiro. A página de marketing pode ser SSG, o blog pode ser ISR, o painel logado pode ser CSR e a busca pode ser SSR. Os frameworks modernos permitem decidir por rota, e essa granularidade costuma render o melhor resultado.
Perguntas frequentes
SSR é sempre melhor que CSR para SEO? Para conteúdo que precisa ser indexado, sim, porque entrega HTML completo logo de cara. Mas se a página é um app atrás de login, SEO é irrelevante e o CSR pode ser a escolha mais simples e barata.
SSG funciona com conteúdo que muda? Funciona com rebuild ou, melhor ainda, com ISR. Para dados que mudam a cada segundo (cotações, placares ao vivo), nenhuma das duas serve sozinha — aí você hidrata a parte dinâmica no cliente ou usa SSR.
O que é melhor para Core Web Vitals? SSG tende a vencer no LCP por servir HTML pronto da CDN. Mas qualquer modelo pode ter INP ruim se carregar JavaScript demais. A renderização é só metade da história; o tamanho do bundle é a outra metade.
Preciso escolher um modelo para o site inteiro? Não. Os frameworks atuais permitem misturar estratégias por rota. Misturar é a norma, não a exceção.
ISR substitui SSR? Para muitos casos de conteúdo, sim — entrega frescor "quase em tempo real" com custo de estático. Mas conteúdo verdadeiramente personalizado por usuário ou que muda a cada requisição ainda pede SSR.
Conclusão
SSR, SSG e CSR não são certos ou errados em absoluto — são ferramentas com trade-offs distintos. SSG maximiza velocidade e SEO para conteúdo estável; SSR equilibra frescor e indexação para conteúdo dinâmico; CSR brilha em aplicações interativas onde SEO não pesa. As abordagens híbridas, apoiadas em recursos como o HTTP/2 (Belshe, Peon e Thomson, 2015), permitem misturar o melhor de cada mundo, decidindo a estratégia rota a rota. Escolha com base no comportamento do conteúdo, no custo que você pode sustentar e nas exigências de SEO técnico e de Core Web Vitals — e lembre que a experiência real do usuário é o critério final (Google Web.dev, 2020).
Referências
- Google Web.dev (2020). Web Vitals: Essential metrics for a healthy site. Google.
- Belshe, Peon, Thomson (2015). RFC 7540: Hypertext Transfer Protocol Version 2 (HTTP/2). IETF.
- Fielding, R. et al. (2014). RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching. IETF.
