SSR e CSR viraram rótulos de stack, como se a aplicação precisasse escolher um lado antes de entender o que entrega. Só que renderização é uma decisão por rota e por tipo de conteúdo. Uma página pública de documentação, um dashboard autenticado e um editor colaborativo não têm as mesmas necessidades, mesmo quando moram no mesmo produto.
A pergunta prática é simples: o que precisa existir no primeiro HTML, o que depende de interação e quanto trabalho queremos fazer no servidor e no navegador?
CSR entrega uma aplicação para o navegador montar
Na renderização no cliente, o servidor pode responder com um shell pequeno e arquivos JavaScript. O navegador baixa o código, busca dados e constrói a interface. Depois do carregamento inicial, transições e atualizações podem ser rápidas porque estado e componentes já estão ativos.
Esse modelo combina bem com ferramentas autenticadas, interfaces altamente interativas e aplicações em que descoberta por busca não é central. Também permite hospedar assets estáticos e concentrar lógica de dados numa API. O custo aparece no primeiro acesso: download, parse, execução e requisições precisam acontecer antes que conteúdo importante fique disponível.
SSR coloca conteúdo na primeira resposta
Na renderização no servidor, a resposta já contém HTML útil. Navegadores exibem conteúdo antes de executar toda a camada interativa, crawlers encontram links e texto com menos etapas e previews sociais conseguem ler metadados sem depender de JavaScript.
Isso não torna a página automaticamente rápida. Um servidor lento pode aumentar TTFB, e hidratar uma árvore grande ainda envia muito JavaScript. SSR também adiciona cache, capacidade computacional e novas formas de divergência entre o HTML do servidor e o estado encontrado pelo cliente.
Google executa JavaScript, mas a web não é só Google
O Google Search usa Chromium para renderizar páginas JavaScript, porém o processo passa por crawling, fila de renderização e indexação. A própria documentação recomenda SSR ou pré-renderização quando apropriado porque isso ajuda usuários e crawlers, e lembra que nem todos os bots executam JavaScript.
Além de busca, existem robôs de compartilhamento, leitores, arquivadores, ferramentas de acessibilidade, clientes de linha de comando e serviços internos. Para conteúdo público, colocar título, descrição, links e texto principal no HTML inicial reduz dependência de capacidades que você não controla.
SSG e híbrido completam o mapa
Se o conteúdo muda apenas no deploy ou pode aceitar alguma defasagem, geração estática entrega HTML pronto por CDN sem renderizar cada request. Revalidação permite atualizar páginas em intervalos ou sob demanda. É uma boa combinação para blogs, documentação, marketing e catálogos com cache.
Abordagens híbridas misturam estratégias. A rota chega como HTML e apenas os controles necessários hidratam. Partes estáticas permanecem sem runtime, enquanto um filtro, carrinho ou editor ganha estado no cliente. Em vez de hidratar a página inteira, ilhas interativas reduzem a fronteira de JavaScript.
Decida por rota
- Conteúdo público e estável: SSG ou SSR com cache costuma oferecer uma base simples.
- Conteúdo público e personalizado: SSR seletivo, streaming ou uma base estática enriquecida no cliente.
- Ferramenta autenticada e interativa: CSR pode ser suficiente, especialmente depois do login.
- Página com poucos controles: HTML no servidor e JavaScript progressivo evitam hidratação desnecessária.
- Dados em tempo real: renderização inicial e transporte de atualizações são decisões separadas.
Meça o sistema inteiro
Compare TTFB, LCP, INP, quantidade de JavaScript, consumo do servidor e complexidade de cache. Teste acesso direto a rotas, não apenas navegação interna. Verifique códigos HTTP de erro, metadados e conteúdo com JavaScript desativado. Uma SPA pode parecer excelente depois que o bundle está em cache e péssima para quem chega por um link compartilhado.
Também conte o custo operacional. Renderizar toda visita no servidor por causa de duas páginas de marketing pode sair caro. Manter pré-renderização exclusiva para bots, prática conhecida como dynamic rendering, adiciona bifurcação e não é a recomendação para novos projetos segundo o Google.
O framework influencia quais opções são fáceis, mas não deveria inventar a necessidade. Comece pelo conteúdo e pelas interações. A arquitetura aparece depois: HTML onde HTML resolve, JavaScript onde estado e comportamento justificam, servidor onde existe trabalho que realmente precisa acontecer antes da resposta.
Streaming e hidratação parcial mudam o momento do custo
SSR não precisa esperar a página inteira para começar a responder. Streaming entrega o shell e libera trechos conforme dados ficam prontos. Hidratação parcial ou ilhas evitam ativar JavaScript onde o HTML já resolve a interação. O ganho depende de prioridades: enviar cedo um esqueleto que bloqueia o conteúdo principal não melhora LCP por si só.
O suporte do Chrome 155 a HTML por streaming em atualizações parciais amplia as ferramentas, mas não elimina sanitização, fallback e medição. O modelo de renderização continua sendo uma decisão de produto e compatibilidade.
Cache, personalização e status de erro formam um contrato
Uma resposta SSR pública pode entrar em CDN; uma resposta com nome, carrinho ou permissão não deve vazar entre usuários. Separe shell cacheável de dados privados, use Cache-Control coerente e revise Vary. O guia de cache HTTP detalha essa fronteira.
Também preserve semântica HTTP. Uma tela de erro renderizada com status 200 pode ser indexada ou armazenada como sucesso. Timeouts downstream precisam virar fallback explícito ou status 5xx antes de a resposta ser confirmada; depois que o streaming começou, trocar o status pode não ser mais possível.
- conteúdo público e compartilhável: SSG ou SSR com cache;
- dados privados iniciais: SSR sem cache compartilhado ou shell + busca autenticada;
- interação rica após a carga: hidrate somente as ilhas necessárias;
- dashboard interno: CSR pode ser suficiente se o carregamento e o fallback forem honestos.
Compare as rotas com laboratório e RUM. A escolha certa não é a que produz o primeiro byte mais cedo em um benchmark; é a que entrega conteúdo útil, preserva segurança e mantém o custo operacional aceitável.