SSR vs SSG: quando gerar uma página no servidor ou ao construí-la

Publicado em 2026-10-20 por frfrand

Qué son SSR y SSG, diferencias en rendimiento, SEO, personalización, caché y cuándo elegir cada estrategia.

SSR significa renderização do lado do servidor e SSG significa geração estática de páginas. As duas estratégias podem entregar HTML ao navegador, mas diferem em quando esse HTML é preparado e como é atualizado.

Se você está criando um site com Next.js ou outro framework moderno, essa escolha afeta velocidade, custos de servidor, conteúdo dinâmico e manutenção.

A diferença com um cardápio de restaurante

Pense em imprimir o cardápio do restaurante cada vez que um cliente se senta, com os pratos disponíveis naquele instante. Isso se parece com SSR: o servidor prepara a resposta quando chega uma solicitação.

Agora imagine que você imprime cem cardápios no início do dia e os distribui quando alguém os pede. Isso se parece com SSG: o HTML é gerado antes, durante a construção ou publicação do site.

A segunda opção pode ser muito rápida, mas é preciso decidir quando regenerar os cardápios se os preços mudarem.

O que acontece com SSR?

O navegador solicita uma página; o servidor obtém os dados de que precisa e gera HTML para essa solicitação. Pode incluir informações atualizadas ou personalizadas, de acordo com a arquitetura.

Mas cada solicitação pode implicar trabalho adicional. Uma consulta lenta ao banco de dados pode atrasar a resposta. Também é possível adicionar cache onde for seguro, sem entregar informações privadas a outra pessoa.

SSR não significa que todo o JavaScript desapareça: uma página pode precisar de código no cliente para interatividade.

E com SSG?

O sistema constrói o HTML antes da chegada dos visitantes. É especialmente útil para documentação, páginas informativas, artigos ou catálogos onde o conteúdo muda de forma controlada.

Esse HTML pode ser servido a partir de arquivos ou uma CDN com pouca lógica de servidor por visita. Se o conteúdo mudar, talvez seja necessário reconstruir ou invalidar uma versão armazenada.

Nem todas as plataformas geram páginas estáticas exatamente da mesma forma; algumas permitem estratégias de regeneração incremental.

Qual se posiciona melhor no Google?

Não existe uma regra que diga «SSR vence» ou «SSG vence». Ambos podem entregar HTML indexável corretamente. Importam o conteúdo real, links, metadados, acessibilidade, estabilidade e desempenho percebido.

Se uma página tem excelente conteúdo e uma estrutura clara, a estratégia de renderização é uma decisão de implementação, não uma garantia de ranqueamento.

Também convém evitar gerar centenas de URLs vazias ou duplicadas apenas para aumentar o número de páginas indexáveis.

Um exemplo com um site de passeios

A descrição de um passeio por Copenhague poderia ser gerada estaticamente. Fotografias, itinerário e perguntas frequentes mudam pouco.

Mas a disponibilidade de vagas para amanhã depende de reservas recentes. Essa parte pode consultar um backend ou utilizar uma estratégia dinâmica bem projetada.

Um aplicativo real pode combinar estratégias em vez de escolher uma só para todo o domínio.

SSR é o mesmo que SPA?

Não. SPA descreve um padrão de navegação e interação do aplicativo; SSR e SSG descrevem como o HTML é obtido ou gerado. Muitos frameworks combinam renderização de servidor, conteúdo estático e interatividade do navegador.

Um site pode entregar HTML do servidor e depois hidratar componentes interativos. Conhecer esses conceitos evita discussões em que cada pessoa compara coisas de categorias diferentes.

Erros que convém evitar

Criar conteúdo privado como HTML estático público. Uma página personalizada exige políticas de cache e acesso adequadas.

Consultar dados dinâmicos desnecessariamente a cada visita. Se um artigo muda uma vez por mês, recalcular tudo pode desperdiçar recursos.

Medir somente a primeira carga. A navegação posterior e as métricas de usuários reais importam.

Onde entra o ArduMaker?

Em um despliegue Git do ArduMaker você pode hospedar um frontend gerado estaticamente ou executar o servidor de um aplicativo SSR, de acordo com seus requisitos. A plataforma de hospedagem não substitui a decisão de como renderizar cada rota.

Em uma frase: SSR prepara HTML ao atender a solicitação; SSG o prepara antecipadamente. A escolha depende de mudanças, personalização e custo de geração.

Fontes: Renderização web em web.dev · Renderização em Next.js.