SSR vs SSG vs ISR

O problema

Discussão de SSR, SSG e ISR costuma sair torta porque entra cedo demais na religião do framework.

O resultado é um monte de frase confiante e pouco útil:

• “SSR é melhor para SEO”
• “SSG é sempre mais rápido”
• “ISR resolve tudo”

Cada frase encosta em um pedaço da verdade.

Nenhuma, sozinha, ajuda muito a decidir.

Modelo mental

A diferença principal entre essas estratégias é:

quando o HTML fica pronto e quão fresco ele precisa estar no momento em que o usuário pede a página.

Pensando de forma bem direta:

• SSG: gera antes e serve pronto
• SSR: gera na hora da requisição
• ISR: serve estático, mas regenera em janelas controladas

Isso puxa trade-offs de:

• velocidade
• cache
• custo de servidor
• frescor de conteúdo
• complexidade de invalidação

Quebrando o problema

SSG

SSG funciona bem quando o conteúdo muda pouco ou tolera atraso de atualização.

Vantagens:

• entrega barata
• cache simples
• HTML pronto cedo

Custos:

• rebuild ou republish para refletir mudança
• frescor menor quando o conteúdo muda rápido

Ótimo para:

• marketing
• docs
• conteúdo editorial

SSR

SSR gera HTML por requisição.

Vantagens:

• conteúdo fresco
• possibilidade de personalizar por request

Custos:

• mais trabalho por requisição
• infra e cache mais sensíveis
• risco de TTFB pior se a página depender demais de fetch lento

Bom para:

• páginas dependentes de contexto de usuário
• conteúdo dinâmico que precisa refletir estado recente

ISR

ISR tenta ficar no meio:

• serve página estática
• revalida em janelas ou eventos

Vantagens:

• custo menor do que SSR puro em muitos casos
• frescor melhor do que SSG puro

Custos:

• invalidação precisa ser entendida
• o dado não é “sempre o mais novo”
• o time precisa saber quando aceita stale temporário

O ponto que muita gente esquece

Escolher entre SSR, SSG e ISR não resolve sozinho:

• hidratação cara
• JavaScript demais
• componente cliente pesado

Você pode ter SSR e ainda entregar experiência ruim se o cliente continuar travado depois.

Por isso essa decisão conversa com performance, mas não substitui o resto.

Exemplo simples

Imagine três páginas:

1. home editorial
2. catálogo de produto atualizado várias vezes ao dia
3. dashboard personalizado do usuário

Leitura madura:

• home editorial tende a caber bem em SSG
• catálogo pode caber em ISR se aceitar pequena janela de desatualização
• dashboard tende a pedir SSR ou outra estratégia dinâmica mais clara

Essa resposta é melhor do que:

“Nosso framework usa ISR, então vamos de ISR para tudo.”

Erros comuns

• Escolher estratégia por hype do framework.
• Tratar SEO como único critério.
• Assumir que SSG sempre é “mais rápido” em qualquer aspecto.
• Ignorar cache e invalidação ao falar de ISR.
• Confundir HTML pronto cedo com interatividade pronta cedo.

Como um senior pensa

Quem pensa melhor sobre isso costuma organizar a decisão assim:

• com que frequência o conteúdo muda?
• quão caro é servir isso por request?
• quanto stale eu tolero?
• o cache ajuda ou atrapalha aqui?
• a página precisa de contexto por usuário?

Isso faz a conversa sair de slogan e entrar em produto, operação e custo.

Senioridade aqui é saber que renderização é escolha de sistema, não decoração de stack.

O que o entrevistador quer ver

Ele quer ver se você:

• entende o momento de geração do HTML em cada estratégia
• sabe falar de frescor, cache e custo
• não confunde render inicial com interatividade
• escolhe com base em contexto, não em dogma

Se você disser “SSG me serve bem quando o conteúdo é estável; SSR me ajuda quando preciso de frescor por request; ISR entra quando quero amortecer custo com atualização controlada”, isso já é uma resposta forte.

Renderização boa nasce de trade-off claro, não de fidelidade a framework.

A melhor estratégia é a que entrega o HTML certo no momento certo com custo aceitável.