SSR, SSG e ISR: como escolher a renderização certa

Entenda a diferença entre gerar a página no build (SSG), a cada requisição (SSR) ou revalidar de tempos em tempos (ISR), e um critério simples pra escolher a estratégia conforme a frequência com que o conteúdo muda.


Nos posts sobre cache do Next.js, Server Components e edge functions, eu usei termos como "rota estática" e "rota dinâmica" como se todo mundo já soubesse a diferença. Vale parar e explicar a base, porque a escolha de quando a página é gerada afeta velocidade, custo de servidor e quão atualizado o conteúdo aparece pro usuário.

O que muda entre as estratégias

Toda página precisa virar HTML em algum momento. A pergunta é quando isso acontece, e as três respostas possíveis são bem diferentes.

SSG: gerada uma vez, no build

Na geração estática (Static Site Generation), o HTML é produzido durante o build do projeto, antes de qualquer visitante chegar. Quando alguém acessa a página, o servidor só entrega um arquivo pronto, sem processar nada.

// app/sobre/page.tsx
export default function Sobre() {
  return <h1>Sobre mim</h1>;
}

Sem nenhum dado dinâmico, o Next trata essa rota como estática por padrão. O resultado é a resposta mais rápida possível e o menor custo de servidor, já que o trabalho foi feito uma única vez. O limite é óbvio: o conteúdo só muda no próximo build. Pra uma página institucional ou um post de blog, isso é ótimo. Pra um preço que muda toda hora, não serve.

SSR: gerada a cada requisição

No SSR (Server-Side Rendering), o HTML é produzido no servidor a cada visita, usando o dado mais recente naquele instante.

// app/painel/page.tsx
import { cookies } from "next/headers";
 
export default async function Painel() {
  const usuario = (await cookies()).get("usuario")?.value;
  const dados = await buscarDadosDoUsuario(usuario);
 
  return <h1>Olá, {dados.nome}</h1>;
}

Ler cookies() torna a rota dinâmica automaticamente: ela precisa saber quem está pedindo, então não dá pra gerar antes. O conteúdo está sempre atualizado e pode ser personalizado por usuário, mas cada visita custa processamento no servidor e a resposta demora mais que a de um arquivo pronto.

ISR: estática, mas renovada de tempos em tempos

O ISR (Incremental Static Regeneration) fica no meio do caminho. A página é servida como estática, mas depois de um intervalo definido ela é regerada em segundo plano.

// app/produtos/page.tsx
export const revalidate = 60;
 
export default async function Produtos() {
  const produtos = await buscarProdutos();
  return <ListaDeProdutos produtos={produtos} />;
}

Com revalidate = 60, a primeira visita depois de 60 segundos continua recebendo a versão guardada, e dispara a regeração por trás. A visita seguinte já recebe a versão nova. É o mesmo princípio de stale-while-revalidate que apareceu no post sobre o Data Cache: ninguém espera a página ser reconstruída, e o conteúdo nunca fica velho por muito tempo.

Um critério simples pra escolher

Em vez de decorar sigla, vale perguntar duas coisas sobre a página:

  • O conteúdo é igual pra todo mundo? Se não (depende de quem está logado), SSR.
  • Com que frequência ele muda? Raramente: SSG. De vez em quando e tolerando alguns segundos ou minutos de atraso: ISR. A cada instante e precisando estar exato: SSR.

Um blog como este é um caso clássico de SSG: o post só muda quando eu publico, então não faz sentido processar nada a cada visita. Uma listagem de produtos com estoque que muda ao longo do dia cabe em ISR. Um painel com dados do usuário logado é SSR.

O erro comum: tudo dinâmico por padrão

O deslize mais frequente é tornar uma rota dinâmica sem querer, por exemplo lendo cookies() ou headers() num componente que está no layout, e assim arrastar todas as páginas filhas pra SSR. O site continua funcionando, só fica mais lento e mais caro do que precisava. Quando uma página estática parece lenta sem motivo, vale checar a saída do next build, que marca cada rota como estática ou dinâmica.

Fechando

SSG, SSR e ISR não são níveis de qualidade, são respostas diferentes pra mesma pergunta: quando vale pagar o custo de gerar essa página. Quanto mais cedo ela for gerada, mais rápida e barata a entrega, e quanto mais tarde, mais fresca e personalizada. O trabalho é achar, página por página, o ponto mais cedo possível que ainda entregue o conteúdo com a atualidade que ele precisa ter.

Direto na sua
caixa de entrada.

Um aviso por e-mail sempre que eu publicar um post novo. Sem spam, sem newsletter chata, só isso.