Blog / SSR, SSG ou SPA? Um estudo de caso (com cara de TCC) para escolher a arquitetura do seu site
SSR, SSG ou SPA? Um estudo de caso (com cara de TCC) para escolher a arquitetura do seu site
Por Marcos Henrique Corrêa · tecnologia ·
Todo site novo começa com uma decisão que quase ninguém vê, mas que define velocidade, custo, SEO e segurança pelos próximos anos: como as páginas vão ser montadas. No servidor a cada visita? Uma vez só, na hora do deploy? Ou direto no navegador de quem acessa?
Essas três respostas têm nome: SSR, SSG e SPA. Para fugir do texto "lista de prós e contras" que existe aos montes por aí, organizei este artigo como um pequeno TCC: com problema, hipóteses, metodologia, estudo de caso e conclusão. O estudo de caso é real: o Noite a Dois, um jogo que desenvolvemos, e o próprio blog que você está lendo.
Resumo: não existe arquitetura vencedora. Existe a arquitetura certa para o tipo de conteúdo, para o volume de acesso e para o nível de risco dos dados envolvidos. No fim do artigo há um guia rápido de decisão.
1. Introdução: qual é o problema?
Quem contrata ou desenvolve um site costuma discutir cor, layout e copy. Raramente se discute a forma como o HTML chega até o usuário. Só que é essa decisão que responde perguntas como:
O Google vai conseguir ler meu conteúdo?
O site aguenta se uma campanha trouxer 50 mil visitas em uma hora?
Quanto vou pagar de servidor por mês?
Onde ficam os dados sensíveis, e quem consegue vê-los?
Escolher errado não quebra o site no primeiro dia. Ele quebra quando começa a dar certo: quando o tráfego cresce, quando o SEO vira canal importante ou quando entram login e pagamento.
2. Hipóteses
Antes de analisar, partimos de quatro hipóteses, que serão revisitadas na discussão:
H1: SSG é a opção mais rápida e barata para conteúdo que muda pouco.
H2: SPA entrega a melhor experiência para aplicações muito interativas, mas perde em SEO se nada for feito a respeito.
H3: SSR é a melhor escolha para conteúdo dinâmico que precisa ranquear, ao custo de mais servidor e mais complexidade.
H4: nenhuma das três é segura ou insegura por si só. A segurança depende de onde ficam os dados e as regras de negócio.
3. Objetivo: para quê?
Dar a você critérios claros para escolher (ou questionar) a arquitetura de um projeto, sem precisar saber programar. A ideia é que, ao final, você consiga olhar para um site e dizer "isso aqui deveria ser estático" ou "isso aqui precisa de servidor".
4. Público: para quem?
Donos de negócio e gestores que vão contratar um site ou sistema e querem entender o que estão comprando.
Profissionais de marketing e tráfego, porque arquitetura afeta diretamente SEO, velocidade de carregamento e, portanto, custo por conversão.
Devs em início de carreira que já ouviram as siglas, mas ainda não sabem quando usar cada uma.
5. Metodologia: como?
O estudo foi feito em três etapas:
Referencial: definir cada modelo e listar pontos positivos e negativos.
Critérios de comparação: SEO, desempenho, custo, escalabilidade e segurança.
Estudo de caso: aplicar os critérios a projetos reais que já desenvolvemos, principalmente o Noite a Dois e este blog.
6. Referencial: o que é cada um
Uma analogia ajuda. Pense em um restaurante:
SSG é a marmita pronta: preparada antes, só entregar.
SSR é o prato feito na hora: a cozinha monta cada pedido quando ele chega.
SPA é o kit para montar em casa: o restaurante manda ingredientes e receita, e o cliente monta no próprio fogão.
SSG, SSR e SPA explicados como pedidos de restaurante.
6.1 SPA (Single Page Application)
O servidor entrega um HTML quase vazio e um pacote de JavaScript. O navegador executa esse código, busca os dados em uma API e monta a tela. A partir daí, trocar de página não recarrega nada: o JavaScript só troca o que muda. É o modelo de ferramentas como React com Vite, Gmail e Trello.
Pontos positivos
Navegação fluida, com sensação de aplicativo.
Hospedagem barata: são arquivos estáticos, servidos por CDN.
Separação clara entre front-end e API, o que facilita ter app mobile usando o mesmo back-end.
Pontos negativos
Primeiro carregamento mais lento, principalmente em celulares fracos e internet ruim.
SEO e compartilhamento em redes sociais prejudicados: muitos robôs e prévias de link leem o HTML vazio.
Tudo que está no pacote JavaScript é público. Qualquer pessoa consegue abrir e ler.
6.2 SSR (Server-Side Rendering)
A cada visita, o servidor busca os dados, monta o HTML completo e envia pronto. Depois, o JavaScript "acorda" a página para deixá-la interativa (a chamada hidratação). É o modelo de frameworks como Next.js, Nuxt e também do PHP clássico.
Pontos positivos
Excelente para SEO: o robô recebe o conteúdo completo.
Conteúdo sempre atualizado e personalizável por usuário.
Dados sensíveis e chaves de API podem ficar no servidor, longe do navegador.
Pontos negativos
Custo de servidor proporcional ao tráfego: cada visita é processamento.
Mais complexidade de infraestrutura, cache e monitoramento.
Se o servidor ficar lento ou cair, o site inteiro sente.
6.3 SSG (Static Site Generation)
As páginas são montadas uma única vez, no momento do build (deploy), e publicadas como arquivos HTML prontos. Quando alguém acessa, não há processamento: a CDN só entrega o arquivo. É o modelo de Astro, Hugo, Gatsby e do modo estático do Next.js.
Pontos positivos
O mais rápido possível no carregamento.
Custo de hospedagem perto de zero, mesmo com muito tráfego.
Ótimo para SEO e com a menor superfície de ataque das três.
Pontos negativos
Qualquer mudança de conteúdo exige um novo build.
Com milhares de páginas, o build fica lento.
Não serve, sozinho, para conteúdo personalizado por usuário.
6.4 E os híbridos?
Na prática, os frameworks modernos misturam os três. Existe o ISR (regeneração incremental, em que a página estática é atualizada de tempos em tempos sem rebuild total) e a pré-renderização de rotas específicas de uma SPA. Guarde essa ideia, porque ela aparece no estudo de caso.
O que muda entre os três modelos é onde o HTML é montado.
7. Onde cada um se encaixa
Cada tipo de projeto tem uma arquitetura que faz mais sentido.
Site institucional, landing page, portfólio: SSG. Conteúdo muda pouco e precisa carregar rápido. Um exemplo é o site que fizemos para a arquiteta Taís Regina Müller: páginas de apresentação, portfólio e contato.
Blog e conteúdo editorial: SSG ou SSR com cache, dependendo da frequência de publicação. O site da Veterinária Tamires, por exemplo, usa PHP, um modelo SSR tradicional, em que cada página é montada pelo servidor.
E-commerce e marketplaces: SSR ou ISR. Muitas páginas, preço e estoque mudando, e SEO crítico.
Painéis, sistemas internos e ferramentas: SPA. Ficam atrás de login, então SEO não importa e interatividade sim. É o caso do nosso Dashboard de Marketing Integrado, que conecta Meta Ads, Google Ads e LinkedIn, e da Lista de Tarefas com autenticação.
Apps que consomem APIs públicas: SPA funciona bem, como no Next Movies, que lista filmes em cartaz. Se esse projeto precisasse ranquear cada filme no Google, o próximo passo natural seria SSR ou ISR.
8. Pensando em escala: qual aguenta crescer?
Escalar não é só "aguentar mais visitas". É aguentar mais visitas sem o custo e a complexidade crescerem na mesma proporção.
Como o custo de cada modelo se comporta quando o tráfego cresce.
SSG escala melhor para leitura. Arquivo estático em CDN aguenta picos enormes de tráfego com custo quase fixo. O limite aparece em outro lugar: quantidade de páginas e frequência de atualização, que deixam o build lento. A saída costuma ser ISR.
SPA escala bem no front, mas empurra o peso para a API. Os arquivos são estáticos e baratos, porém cada usuário dispara requisições ao back-end. Quem precisa escalar aqui é a API e o banco de dados.
SSR é o que mais custa para escalar. Cada visita consome processamento. Funciona muito bem em grande escala, mas exige cache (CDN, edge, cache de dados) bem pensado. Sem cache, a conta cresce junto com o tráfego.
Regra prática: tudo que puder ser estático deve ser estático. Use servidor só onde ele agrega valor (dados dinâmicos, personalização, segredo) e cache em tudo que der.
9. O que precisa de segurança reforçada?
Aqui está um erro comum: achar que uma arquitetura é "mais segura" que outra. O que define o risco é o que o sistema guarda e o que ele permite fazer. Precisam de segurança reforçada, independentemente do modelo:
Qualquer coisa com login e dados por usuário.
Pagamentos e dados financeiros.
Dados pessoais protegidos pela LGPD (nome, e-mail, telefone, saúde).
Painéis administrativos, como a área onde este post foi escrito.
Integrações com tokens de terceiros, como as APIs de anúncios de um dashboard de marketing.
Cada arquitetura tem seus pontos de atenção:
SPA: o código é público. Nunca coloque chave de API, senha ou regra de permissão só no front. Toda checagem precisa acontecer de novo na API. Esconder um botão não protege nada.
SSR: o servidor é uma superfície de ataque. Cuidado com dados que vazam para o HTML ou para o JSON de hidratação, e com cache que acaba servindo a página personalizada de um usuário para outro.
SSG: menor risco, porque não há servidor executando código a cada visita. Mas formulários, comentários e integrações continuam precisando de proteção do lado de quem os recebe.
Tudo que está no front-end é público. A proteção de verdade fica na API.
Aprofundei esse tema, com checklist, no artigo Dashboards com IA: funcionar não é estar pronto.
10. Estudo de caso: Noite a Dois
O Noite a Dois é um jogo de verdade ou desafio para casais adultos, com quatro níveis, cronômetro e cartas personalizáveis. Roda no navegador, sem cadastro e sem instalar nada.
No Noite a Dois, os dados do jogo ficam no aparelho e nada é enviado a servidor.
Como os critérios se aplicam:
Interatividade: alta. Sortear cartas, trocar a vez, subir de nível e criar cartas próprias são interações instantâneas. Perfil típico de SPA.
Dados: os nomes dos jogadores e as cartas personalizadas ficam salvos no próprio navegador e não são enviados a nenhum servidor. Isso resolve boa parte da questão de segurança e privacidade: o dado mais íntimo do produto simplesmente não sai do aparelho.
SEO: importa, porque o jogo depende de ser encontrado. Por isso a seção "Sobre o jogo" (como jogar, níveis, privacidade) é texto legível, e as metatags descrevem o produto e a classificação etária.
Escala: como não há servidor processando partidas, cada novo jogador custa praticamente nada. Mil ou cem mil casais jogando ao mesmo tempo é, para a infraestrutura, só entrega de arquivos.
Leitura: o Noite a Dois é o cenário em que a SPA brilha. A decisão de não ter back-end não foi economia, foi arquitetura: menos servidor significa menos custo, menos ponto de falha e menos dado sensível para proteger. Se um dia ele ganhar contas de usuário ou recursos pagos, aí sim entra uma API com autenticação e segurança reforçada.
11. Estudo de caso bônus: este blog
O blog é um exemplo de híbrido. A base é uma SPA em React, mas as rotas públicas de artigos passam por uma etapa de pré-renderização que injeta título, descrição e metadados no HTML antes de chegar ao navegador. Assim, Google e prévias de link no WhatsApp e no LinkedIn enxergam o conteúdo certo, sem abrir mão da navegação fluida.
Já a área administrativa, onde os posts são escritos e os e-mails disparados, é SPA pura, atrás de login, conversando com uma API separada. Ela não precisa de SEO, mas precisa de segurança reforçada, porque é ali que ficam o controle do conteúdo e a lista de assinantes.
Ou seja: cada parte do mesmo produto usa a estratégia que faz sentido para ela. Se quiser entender a parte de infraestrutura, contei o caminho completo em Do zero ao ar: DNS, versionamento e deploy.
12. Discussão: as hipóteses se confirmaram?
H1, confirmada. Para conteúdo que muda pouco, SSG é imbatível em velocidade e custo. O limite está no volume de páginas e na frequência de atualização.
H2, confirmada com ressalva. A SPA é ótima para interação, e o problema de SEO tem solução: pré-renderizar as rotas que precisam ser encontradas, como fazemos aqui no blog.
H3, confirmada. SSR é a escolha para conteúdo dinâmico que precisa ranquear, mas só escala com cache bem planejado.
H4, confirmada. O Noite a Dois mostra isso: o produto lida com conteúdo íntimo e, ainda assim, tem risco baixo, porque o dado não sai do navegador. Segurança é decisão de arquitetura de dados, não de sigla.
13. Conclusão
SSR, SSG e SPA não competem entre si. São ferramentas para problemas diferentes, e os melhores projetos combinam as três. Para decidir, faça quatro perguntas:
Precisa ser encontrado no Google? Então o HTML precisa chegar pronto: SSG, SSR ou pré-renderização.
O conteúdo muda a cada visita ou por usuário? Se não, estático. Se sim, SSR ou SPA com API.
É muito interativo, quase um aplicativo? SPA.
Tem login, pagamento, dados pessoais ou tokens de terceiros? Segurança reforçada no servidor ou na API, sempre, qualquer que seja o front.
Guia rápido para decidir a arquitetura do seu próximo projeto.
Se você tem um projeto e quer saber qual caminho faz mais sentido, dá uma olhada no portfólio com os sites e sistemas que já desenvolvemos e me chama para conversar.
Para continuar lendo