A pergunta mais frequente de quem adota Next.js não é sobre código; é sobre estratégia: "essa página deve ser gerada quando? No build, a cada requisição, ou algo no meio?" SSG, SSR e ISR são exatamente essas três respostas, e escolher errado custa dinheiro (servidor) ou negócio (conteúdo velho).

As três estratégias em uma cena

Imagine a página de um produto no seu e-commerce:

• SSG (Static Site Generation): a página vira HTML no build. Servida por CDN, custo perto de zero, velocidade máxima. Mas o preço que mudou às 14h só aparece no próximo deploy.
• SSR (Server-Side Rendering): a página é montada a cada requisição. Sempre atual, personalizável por usuário, e cada acesso custa processamento no servidor.
• ISR (Incremental Static Regeneration): o meio-termo esperto: a página é estática, mas se regenera sozinha após um prazo (ou sob demanda). Velocidade de estático, frescor controlado.

// App Router: a estratégia é declarada por página

// SSG (padrão): gera no build e cacheia
export default async function Sobre() { ... }

// ISR: regenera no máximo a cada 60 segundos
export const revalidate = 60;

// SSR: sempre dinâmico, a cada requisição
export const dynamic = "force-dynamic";

No App Router, o Next decide muito disso sozinho: página sem dados dinâmicos vira estática; usar cookies(), headers() ou searchParams a torna dinâmica (nextjs.org/docs). As diretivas acima são o controle explícito.

A régua de decisão (a parte que vale imprimir)

A pergunta certa por página é dupla: com que frequência o conteúdo muda e ele é igual para todos?

• Igual para todos + muda raramente → SSG. Institucional, docs, landing pages. O caso do deploy resolve.
• Igual para todos + muda de vez em quando → ISR. Blog, catálogo, listagens. revalidate: 300 entrega frescor de 5 minutos com custo de estático. É o padrão certo para a maioria dos sites de conteúdo, incluindo blogs como este.
• Igual para todos + muda a cada segundo → SSR com cache curto (ou estático + atualização no cliente para o pedaço vivo: placar, estoque).
• Diferente por usuário → SSR. Dashboard, carrinho, área logada. Não há como cachear o que é pessoal, e é onde o custo de servidor se justifica.

E o refinamento que muda o jogo: a decisão é por página, e até por pedaço. O catálogo é ISR; o preço em tempo real é um fetch no cliente; o header do usuário logado é um client component dentro da casca estática.

ISR sob demanda: o melhor dos mundos para conteúdo

O tempo de revalidate é um teto, mas dá para ser cirúrgico: revalidação sob demanda. O CMS publica um artigo, chama um webhook, e o Next regenera aquela página na hora:

// app/api/revalidate/route.js
import { revalidatePath } from "next/cache";

export async function POST(req) {
  const { path, secret } = await req.json();
  if (secret !== process.env.REVALIDATE_SECRET) {
    return Response.json({ ok: false }, { status: 401 });
  }
  revalidatePath(path); // regenera /blog/meu-artigo agora
  return Response.json({ ok: true });
}

Resultado: site inteiro estático e barato, conteúdo atualizado em segundos após a publicação. É o desenho que recomendamos para blogs e catálogos com CMS.

Os erros que vemos em auditoria

1. force-dynamic por preguiça: um cookies() num layout raiz e o site inteiro vira SSR sem ninguém perceber. Audite o que realmente precisa ser dinâmico.
2. SSG com build de 40 minutos: gerar 200 mil páginas de produto no build é abraçar o problema errado. Use ISR com generateStaticParams parcial: as top 1.000 no build, o resto na primeira visita.
3. Ignorar o cache de dados: no App Router, o fetch tem cache próprio com next: { revalidate } por chamada. Página e dados têm ciclos independentes; entender os dois evita o clássico "regenerou mas veio velho".
4. SSR para esconder lentidão de API: renderizar no servidor não acelera uma API lenta; só muda onde a espera acontece. O gargalo se mede antes.

Estratégia de renderização é decisão de arquitetura

Ela define custo de infraestrutura, SEO e experiência: exatamente o tipo de mapa (página a página) que desenhamos nos projetos Next.js do nosso serviço de Desenvolvimento Web, Mobile e Desktop.

Em dúvida sobre uma página específica? Descreva-a para a IA da Rabelo Digital, aqui no canto da tela (o que muda, para quem), e ela aplica a régua com você. Sem formulário, sem espera.

---

Leia também

• Redux vs Context: estado global sem dogma
• Hooks avançados: useMemo, useCallback e quando não usar
• Server Components: o que mudam no React