Todo app web moderno precisa responder à mesma pergunta antes da primeira rota existir: de onde vem o HTML? Server-Side Rendering (SSR), Static Site Generation (SSG) e Client-Side Rendering (CSR) são as três respostas centrais. Não são frameworks rivais — são estratégias de renderização que impactam performance, SEO, custo de hospedagem, limites de segurança e a forma como o time entrega funcionalidades.
Se você trabalha com Nuxt, Vue ou JavaScript full-stack, raramente escolhe um modo para sempre. Define um padrão e combina estratégias por rota. Entender esses fundamentos transforma decisões acidentais em escolhas conscientes.
Client-Side Rendering (CSR)
No CSR, o servidor envia um HTML mínimo — muitas vezes pouco mais que uma div raiz e tags de script. O navegador baixa os bundles JavaScript, executa o código, busca dados em APIs e monta a página no cliente. O SPA clássico com Vue e diversos apps com Vite seguem esse modelo.
Como funciona:
A resposta inicial é HTML leve mais assets.
Roteamento, busca de dados e atualização do DOM acontecem inteiramente no navegador.
Navegações seguintes podem parecer instantâneas por não recarregar a página inteira.
Pontos fortes: CSR se destaca em dashboards autenticados, painéis administrativos e ferramentas internas, onde SEO não importa e a interatividade pesa mais. A hospedagem é simples — qualquer CDN estática resolve. Times de backend e frontend podem publicar de forma independente quando as APIs são estáveis.
Trade-offs: A primeira pintura depende do tamanho do bundle e da rede. Motores de busca lidam melhor com JavaScript do que no passado, mas CSR ainda torna a indexação menos previsível em sites ricos em conteúdo. Usuários em dispositivos lentos podem encarar telas vazias enquanto o JavaScript é parseado e executado. O Time to Interactive frequentemente fica atrás do First Contentful Paint.
Server-Side Rendering (SSR)
No SSR, o HTML é gerado a cada requisição (ou servido de cache, mas ainda originado na lógica do servidor). O navegador recebe um documento já renderizado, faz a hidratação com JavaScript no cliente e passa a se comportar como SPA nas navegações internas.
O modo servidor padrão do Nuxt e abordagens como Laravel com Inertia (quando combinado a SSR) seguem esse padrão. Node.js, Nitro ou PHP podem atuar como camada de renderização.
Como funciona:
A requisição chega ao servidor com cookies, headers e query params.
O servidor resolve a rota, busca dados, renderiza componentes Vue em strings HTML e devolve o resultado.
O JavaScript no cliente registra eventos — hidratação — sem substituir o DOM quando implementado corretamente.
Pontos fortes: SSR entrega HTML significativo de imediato, o que ajuda SEO e previews em redes sociais. Personalização é natural: a mesma URL pode retornar HTML diferente conforme autenticação, locale ou testes A/B. Depois do primeiro carregamento, a navegação continua fluida como em um SPA.
Trade-offs: Cada requisição sem cache consome CPU no servidor. Cold starts em plataformas serverless aumentam latência. É preciso evitar vazamento de segredos — variáveis de ambiente e queries ao banco ficam só no servidor. Mismatches de hidratação (HTML do servidor difere do render no cliente) geram warnings difíceis de debugar e flicker na interface.
Static Site Generation (SSG)
SSG pré-renderiza HTML no build, não a cada acesso. O resultado são arquivos estáticos — HTML, CSS, JS — publicados em uma CDN. Quando o usuário visita, baixa páginas já prontas. O roteamento client-side ainda pode hidratar o app nas navegações seguintes.
O Nuxt suporta SSG via nuxt generate ou configuração de prerender. Sites de documentação, landing pages e blogs são casos clássicos.
Como funciona:
Durante o CI/CD, o build percorre rotas e grava cada página em disco.
Paths dinâmicos podem ser gerados a partir de CMS, filesystem ou API no momento do build.
O tráfego de produção bate em assets estáticos — sem processo Node por requisição.
Pontos fortes: SSG oferece a melhor performance bruta e o menor custo de hospedagem em escala. O TTFB fica consistentemente rápido globalmente com CDN edge. A superfície de ataque diminui — não há conexão com banco em runtime para conteúdo puramente estático.
Trade-offs: Atualizações exigem rebuild, a menos que você use regeneração incremental ou revalidação sob demanda. Tempos de build crescem com a quantidade de páginas — um catálogo com 50 mil rotas pode gerar pipelines de horas sem arquitetura cuidadosa. Páginas dinâmicas e personalizadas por usuário não cabem em SSG puro sem camadas de fetch no cliente.
Comparação lado a lado
As três estratégias divergem em eixos previsíveis:
Quando o HTML é produzido: CSR em runtime no navegador; SSR a cada requisição no servidor; SSG no build.
SEO e previews de link: Melhor com SSR e SSG; mais fraco com CSR, salvo prerender ou soluções só de meta tags.
Tempo até conteúdo útil: SSG e SSR costumam vencer; CSR depende do peso do bundle.
Custo de servidor: Menor no SSG; maior em SSR sem cache; mínimo na hospedagem estática do CSR.
Atualidade dos dados: CSR e SSR podem ser em tempo real; SSG reflete o último build ou a política de revalidação.
Complexidade: CSR é o mais simples de hospedar; SSR exige operação de servidor; SSG exige desenho de pipeline de build.
Abordagens híbridas em projetos reais
Apps em produção raramente ficam presos a um único modo. O Nuxt 3 deixa isso explícito com route rules e modos de renderização por path. Um site de portfólio ou SaaS pode ficar assim:
/ e /pricing — prerender (SSG) por velocidade e SEO.
/blog/[slug] — SSG com regeneração incremental ou revalidação sob demanda quando posts mudam.
/app/** — CSR ou SSR protegido por autenticação, conforme a necessidade de SEO.
/account — SSR para shells personalizados renderizados no servidor com hidratação no cliente.
Arquitetura de islands e hidratação parcial vão além: HTML estático para blocos de conteúdo e hidratação só de widgets interativos. Esse padrão mistura SSG e CSR de forma intencional e orientada a performance.
Framework de decisão: o que escolher?
Use este checklist prático ao definir uma feature ou projeto do zero:
Escolha CSR quando o app fica atrás de login, SEO não importa e você quer o caminho mais rápido para uma UI rica com API separada.
Escolha SSR quando páginas precisam refletir dados da requisição — auth, geolocalização, carrinho — ou quando SEO e compartilhamento importam para URLs dinâmicas que não dá para pré-gerar.
Escolha SSG quando o conteúdo é igual para todos os usuários, muda com pouca frequência e performance global é prioridade.
Considere também time e infraestrutura. Um time Laravel já rodando PHP pode preferir SSR via Inertia ou Nuxt na frente de API Laravel. Um time Jamstack com CMS headless tende ao SSG. Um produto pequeno iterando rápido em dashboard permanece em CSR até o crescimento exigir mudança.
Erros comuns para evitar
Times adotam SSR porque soa "moderno" e pagam compute em páginas que nunca mudam. Outros usam CSR em blog público e estranham tráfego orgânico estagnado. Outro armadilha é buscar os mesmos dados duas vezes — no servidor durante SSR e de novo no cliente no mount — porque os lifecycle hooks não foram alinhados.
No Nuxt, use useAsyncData e useFetch para serializar ao payload do cliente o que foi buscado no SSR. Em SPAs Vue, faça lazy load de rotas e code-split de componentes pesados para manter o first load aceitável. No SSG, defina rotas de prerender explicitamente em vez de confiar que o crawler descobrirá tudo.
Conclusão
SSR, SSG e CSR são ferramentas, não rótulos fixos. CSR prioriza velocidade de desenvolvimento e interatividade após o carregamento. SSR equilibra SEO, personalização e ergonomia de SPA ao custo de recursos no servidor. SSG maximiza velocidade e eficiência para conteúdo compartilhado. A melhor arquitetura costuma ser uma composição — estático onde der, renderizado no servidor onde for necessário e orientado ao cliente onde a interatividade domina.
Parta das necessidades do usuário: quem visita a página, o que precisa aparecer antes do JavaScript rodar e com que frequência o conteúdo muda. Responda essas três perguntas com honestidade e a estratégia de renderização muitas vezes se escolhe sozinha.