Next.js SSR vs SSG vs ISR: guia para escolher a estratégia de renderização

“Por que a página inicial demora três segundos para carregar?” O chefe olhava fixamente para a tela e para o gráfico em cascata do Chrome DevTools — a faixa vermelha do TTFB parecia uma cobra. Foi a primeira vez que percebi que talvez tivéssemos escolhido a estratégia de renderização errada logo no início.

Não é um caso isolado. Todos os dias alguém pergunta nas issues do Next.js no GitHub: “Devo usar SSR ou SSG?” ou “Por que minha configuração de ISR não funciona?”. Eu também já fiquei completamente perdido. Tinha lido toda a documentação, mas, diante de um projeto real, ainda não sabia qual opção escolher.

Talvez você já tenha enfrentado dúvidas parecidas:

• Usou SSR e o carregamento inicial ficou irritantemente lento
• Escolheu SSG e passou a precisar reconstruir o site inteiro a cada atualização de conteúdo
• Achou ISR perfeito no papel, mas descobriu que a configuração simplesmente não funcionava

Na verdade, nenhuma dessas três estratégias é a “melhor” em termos absolutos. Existe apenas a mais adequada para cada situação. Neste artigo, vamos entender de vez quando usar cada uma e como evitar as armadilhas mais comuns.

Primeiro, entenda o que são as três estratégias de renderização

Antes de discutir como escolher, precisamos deixar claros esses três conceitos. Vou explicá-los da forma mais direta possível.

SSG, ou geração de site estático: a marmita preparada com antecedência

Imagine que você tenha uma loja de marmitas e prepare cem unidades todas as manhãs, deixando-as no balcão. Quando o cliente chega, basta pegar uma e ir embora. É assim que o SSG funciona.

Na prática:

• Quando a página é gerada: ao executar next build, o Next.js gera previamente o HTML de todas as páginas
• Quando o usuário acessa: a CDN devolve diretamente o arquivo HTML já gerado, com muita rapidez
• Quando faz sentido: em páginas cujo conteúdo muda pouco, como sites institucionais, páginas de apresentação de produtos e posts de blog

As vantagens são claras:

• É muito rápido. Segundo dados da AWS, páginas SSG carregam de 40% a 60% mais rápido que páginas SSR
• O TTFB, ou tempo até o primeiro byte, costuma ficar abaixo de 50 ms, segundo testes oficiais da Vercel
• A carga no servidor é praticamente zero, mesmo com muito tráfego
• O custo é baixo, porque hospedar arquivos estáticos é bem mais barato

Mas também há limitações:

• O conteúdo mudou? Será necessário reconstruir o site inteiro
• Com muitas páginas, o build pode demorar bastante; milhares de páginas podem exigir meia hora
• Não há suporte a conteúdo personalizado: todos os usuários veem a mesma coisa

Em resumo, o SSG troca preparação antecipada por velocidade.

SSR, ou renderização no servidor: feito na hora

Vamos continuar com o exemplo da loja de marmitas, mas agora nada é preparado de antemão. O cliente faz o pedido e você cozinha na hora. É assim que o SSR funciona.

Na prática:

• Quando a página é gerada: o servidor gera o HTML em tempo real a cada requisição do usuário
• Quando o usuário acessa: ele espera o servidor consultar o banco de dados, chamar APIs, renderizar o HTML e devolver a resposta
• Quando faz sentido: em páginas cujo conteúdo muda em tempo real ou precisa ser personalizado

As vantagens são estas:

• O conteúdo está sempre atualizado, e o usuário vê os dados daquele momento
• Há suporte a personalização, com conteúdo diferente conforme cookies e permissões do usuário
• É possível acessar informações disponíveis apenas no momento da requisição, como cabeçalhos e parâmetros de consulta

Mas o custo é considerável:

• É mais lento. O TTFB costuma ficar entre 200 e 500 ms, segundo dados oficiais da Vercel
• A carga no servidor é alta e pode se tornar insustentável quando o tráfego cresce
• O custo aumenta, pois o servidor precisa permanecer em execução

Em um caso real, um e-commerce usava SSR e levava 2,3 segundos para exibir a primeira tela. Depois de migrar para ISR, o tempo caiu diretamente para 0,8 segundo.

ISR, ou regeneração estática incremental: a combinação de comida pronta e feita na hora

Agora você adota uma solução mais inteligente: prepara as marmitas com antecedência, mas renova o estoque em intervalos definidos, por exemplo, a cada hora. Na maior parte do tempo, o cliente recebe algo já pronto, sem que o conteúdo fique antigo demais. É assim que o ISR funciona.

Na prática:

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

• Build inicial: gera HTML estático durante o next build, como no SSG
• Atualizações posteriores: regenera a página automaticamente em segundo plano conforme o intervalo definido em revalidate
• Quando o usuário acessa: na maior parte do tempo, recebe o HTML em cache rapidamente; quando ele expira, uma atualização acontece em segundo plano

É uma solução de equilíbrio:

• Oferece a velocidade do SSG, pois o usuário recebe um arquivo estático
• Oferece a atualização do SSR, pois o conteúdo é renovado periodicamente
• Dispensa a reconstrução do site inteiro a cada mudança

A configuração é simples, usando a sintaxe do App Router:

// app/posts/[id]/page.tsx
export const revalidate = 60; // Revalidar após 60 segundos

export default async function Post({ params }) {
  const post = await getPost(params.id);
  return <div>{post.content}</div>;
}

Mas existem algumas armadilhas:

• Configurou e não funcionou? Talvez você esteja testando no ambiente de desenvolvimento com next dev. ISR só funciona no ambiente de produção, com next build + next start
• A plataforma de implantação não oferece suporte? A Vercel tem suporte nativo, mas outras plataformas podem exigir configuração adicional

Sinceramente, ISR é hoje a estratégia que mais uso. Ela resolve os principais problemas de SSG e SSR e funciona muito bem na prática.

Árvore de decisão: qual estratégia usar em cada cenário

Agora que os conceitos estão claros, chegamos à pergunta mais importante: qual deles usar no meu projeto?

Sem pânico. Organizei um processo de decisão que você pode seguir passo a passo conforme as características do projeto.

Primeira etapa: responda a três perguntas

Pergunta 1: o conteúdo precisa ser personalizado?

Se a página precisa mostrar conteúdo diferente conforme a identidade, as permissões ou as preferências do usuário, escolha SSR diretamente.

Cenários típicos:

• Painel do usuário, pois cada pessoa vê dados diferentes
• Página de perfil pessoal
• Carrinho de compras
• Qualquer página que exija autenticação

Por quê? Conteúdo personalizado não pode ser gerado antecipadamente; ele precisa ser criado de forma dinâmica quando o usuário faz a requisição.

Pergunta 2: com que frequência o conteúdo é atualizado?

A resposta determina se você deve usar SSG ou ISR.

• Atualização a cada poucos segundos ou minutos: use SSR

  • Por exemplo, cotações de ações, placares esportivos e mensagens de chat
  • Quando a exigência de tempo real é alta, SSR é a única escolha

• Atualização a cada poucos minutos ou horas: use ISR

  • Por exemplo, sites de notícias, página inicial de blogs, listas de produtos e estoque de e-commerce
  • Você pode definir revalidate: 300, ou cinco minutos, para ter velocidade e conteúdo atualizado

• Atualização rara ou acionada manualmente: use SSG

  • Por exemplo, sites institucionais, páginas de apresentação de produtos e documentação de ajuda
  • Esse conteúdo pode passar semanas ou até meses sem mudar

Pergunta 3: qual é o volume de tráfego?

O volume de tráfego influencia as decisões de custo e desempenho.

• Tráfego muito alto, com milhões de visualizações de página por dia: priorize SSG ou ISR

  • Arquivos estáticos podem ser entregues diretamente pela CDN, com baixo custo e bom desempenho
  • Com SSR, a carga e o custo do servidor podem disparar

• Tráfego baixo ou médio: as três opções são viáveis

  • Se houver uma exigência alta de dados em tempo real, SSR é perfeitamente aceitável
  • Mas, se ISR resolve o problema, por que não usá-lo?

Segunda etapa: consulta rápida por cenário

Reuni alguns cenários típicos para você identificar rapidamente qual opção se encaixa melhor.

Quando usar SSG:

• ✅ Site institucional
• ✅ Página de apresentação de produto ou de preços
• ✅ Landing page de marketing
• ✅ Post de blog que não muda depois da publicação
• ✅ Documentação técnica ou de API
• ✅ Central de ajuda ou FAQ

Lembre-se de três palavras: estático, público e pouco atualizado.

Quando usar SSR:

• ✅ Feed de rede social, no estilo Facebook ou Twitter
• ✅ Painel pessoal do usuário
• ✅ Carrinho de compras e página de pedidos
• ✅ Painel de dados em tempo real
• ✅ Página de resultados de busca gerada conforme os parâmetros da consulta
• ✅ Página que exige autenticação e toma decisões com base em cookies

Lembre-se de três palavras: dinâmico, personalizado e em tempo real.

Quando usar ISR, a minha opção favorita:

• ✅ Página inicial e lista de posts de um blog, que recebem novos conteúdos periodicamente
• ✅ Site de notícias
• ✅ Página de produto de e-commerce, com preço e estoque atualizados periodicamente
• ✅ Página de fórum, quando comentários e curtidas podem demorar alguns minutos para aparecer
• ✅ Plataforma de conteúdo gerado por usuários, com atualizações frequentes, mas sem exigência de tempo real em segundos
• ✅ Previsão do tempo e cotação de moedas

Lembre-se de três características: atualização periódica, atraso aceitável e alto tráfego.

Terceira etapa: combinar estratégias é a melhor abordagem

Precisamos acabar com um equívoco: você não é obrigado a usar uma única estratégia no site inteiro.

Na prática, a maioria dos projetos combina várias estratégias:

• ISR na página inicial e na lista de produtos, que têm muito tráfego e atualizações periódicas
• SSG nos detalhes de produtos estáveis ou ISR quando preço e estoque mudam
• SSR no painel do usuário, que precisa de personalização
• SSG nas páginas “Sobre nós” e “Contato”, que são completamente estáticas

Foi exatamente o que fizemos em um projeto de e-commerce da nossa equipe:

• Página inicial com ISR e atualização a cada 10 minutos
• Lista de produtos com ISR e atualização a cada 5 minutos
• Detalhes do produto com ISR e atualização a cada 3 minutos, pois o estoque muda
• Carrinho com SSR, porque precisa estar em tempo real
• Área do usuário com SSR, por causa da personalização
• Páginas “Sobre nós” e “Política de privacidade” com SSG, pois quase nunca mudam

Essa combinação preservou tanto o desempenho quanto a atualização dos dados.

Regra prática em uma frase

Se você ainda estiver em dúvida, lembre-se disto:

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Use SSG para conteúdo estático, SSR para tempo real e ISR para atualizações periódicas.

Se não tiver certeza, comece testando ISR. É a opção mais equilibrada das três e apresenta o menor risco de escolha inadequada.

Três armadilhas comuns e como resolvê-las

Depois da teoria, vamos à prática. Eu já caí nessas três armadilhas, e é bem provável que você também as encontre.

Armadilha 1: revalidate do ISR não funciona

Sintoma: você configura revalidate: 60 todo animado, esperando que a página seja atualizada a cada minuto. Muito tempo depois, o conteúdo continua exatamente igual.

O que aconteceu comigo: na primeira vez que usei ISR, fiquei preso nesse problema por dois dias inteiros. Li inúmeros documentos e mudei a configuração várias vezes, mas nada funcionava.

Há três causas possíveis:

1. O ambiente de desenvolvimento não oferece suporte ao ISR

   Essa é a causa mais comum. No modo de desenvolvimento com next dev, o ISR simplesmente não funciona. Ele só entra em ação no modo de produção.

   Solução:

   # Não use next dev para testar ISR
   # Primeiro crie o build e depois inicie a aplicação
   npm run build
   npm run start
   
   # Depois, acesse a página para testar

2. A plataforma de implantação não oferece suporte

   Nem todas as plataformas têm suporte nativo a ISR. A Vercel funciona muito bem, afinal é a empresa responsável pelo Next.js, mas outras plataformas podem exigir configuração adicional.

   Na Netlify, por exemplo: é necessário instalar o plugin @netlify/plugin-nextjs para usar ISR.

   Como verificar: procure por “Next.js ISR support” na documentação da sua plataforma de implantação.

3. O cache da CDN está sobrepondo o ISR

   Se houver uma CDN ou um proxy reverso, como Cloudflare, na frente do Next.js, ele pode armazenar a resposta inteira em cache e impedir que o mecanismo de atualização do ISR funcione.

   Solução: configure a CDN para respeitar o cabeçalho Cache-Control ou defina um tempo de cache menor nas páginas que usam ISR.

Minha recomendação: depois de configurar ISR, sempre teste no ambiente de produção. Você pode usar console.log(new Date()) para registrar o horário de geração da página e confirmar se revalidate está funcionando.

Armadilha 2: o carregamento inicial com SSR é lento demais

Sintoma: depois de adotar SSR, a tela inicial fica em branco por dois ou três segundos, tempo suficiente para o usuário desistir.

Caso real: em um dos nossos projetos, a página inicial usava SSR para buscar informações do usuário e conteúdo recomendado. O TTFB inicial chegou a 1,2 segundo. Somado ao tempo de renderização, o usuário precisava esperar três segundos para ver algum conteúdo. O chefe não gostou nada do resultado.

Análise das causas:

SSR costuma ficar lento porque a obtenção de dados no servidor demora. As causas podem incluir:

• Chamada de API lenta, devido à alta latência de uma API externa
• Consulta lenta ao banco de dados, por falta de índice ou alta complexidade
• Requisições sequenciais, quando uma API precisa esperar pela outra
• Servidor com baixo desempenho ou geograficamente distante do usuário

Há quatro soluções:

1. Use Streaming SSR e Suspense, disponíveis no React 18+

   Não espere todos os dados chegarem para começar a renderizar. Devolva primeiro a estrutura da página e transmita os dados conforme estiverem disponíveis.

   // app/dashboard/page.tsx
   import { Suspense } from 'react';
   
   export default function Dashboard() {
     return (
       <div>
         <h1>Painel do usuário</h1>
         {/* Parte de renderização rápida */}
         <UserInfo />
   
         {/* Dados lentos envolvidos por Suspense */}
         <Suspense fallback={<div>Carregando estatísticas...</div>}>
           <SlowStats />
         </Suspense>
       </div>
     );
   }

   Dessa forma, o usuário vê a página mais cedo e a experiência melhora bastante.

2. Faça requisições de dados em paralelo

   Execute várias chamadas de API ao mesmo tempo:

   // ❌ Sequencial: lento
   const user = await getUser();
   const posts = await getPosts(user.id);
   
   // ✅ Paralelo: rápido
   const [user, posts] = await Promise.all([
     getUser(),
     getPosts()
   ]);

3. Considere migrar para ISR

   Muitas vezes, você acredita que precisa de SSR, mas ISR já seria suficiente.

   Pergunte a si mesmo: os dados desta página realmente precisam ser atualizados em tempo real? Se um atraso de um minuto for aceitável, use ISR.

   Posteriormente, migramos aquela página inicial para ISR com revalidate: 60, e o carregamento inicial caiu de três para 0,7 segundo.

4. Implante no Edge

   Se você usa a Vercel, pode experimentar Edge Functions. Elas distribuem a função SSR entre nós da CDN no mundo todo, aproximando-a do usuário e reduzindo a latência.

   // app/api/data/route.ts
   export const runtime = 'edge'; // Apenas esta linha

Armadilha 3: o build com SSG demora demais

Sintoma: o site tem milhares de páginas, e cada next build leva de 20 a 30 minutos ou até falha por timeout.

Cenário problemático: um e-commerce tem 5.000 produtos, ou um blog tem 3.000 posts. Com SSG, o build precisa gerar o HTML de cada página.

Por que demora:

SSG gera o HTML de todas as páginas durante o build. Quanto mais páginas houver, maior será o tempo de construção. E muitas delas talvez nunca sejam acessadas, como produtos de cauda longa ou posts antigos.

Soluções:

1. Use uma estratégia de fallback

   Em vez de gerar todas as páginas de uma só vez, gere apenas as mais acessadas e crie as demais sob demanda.

   // app/posts/[id]/page.tsx
   export async function generateStaticParams() {
     // Retorna apenas os 100 posts mais acessados
     const posts = await getTopPosts(100);
     return posts.map(post => ({ id: post.id }));
   }
   
   // As outras páginas são geradas no primeiro acesso
   export const dynamicParams = true;

2. Combine com ISR

   Durante o build, gere apenas a página inicial e as páginas mais acessadas. Gere as outras sob demanda com ISR.

   Isso reduz bastante o tempo de build, sem deixar o acesso lento, pois as páginas ficam em cache.

3. Use builds incrementais

   A Vercel oferece suporte a builds incrementais, que reconstroem apenas as páginas alteradas. Ao atualizar um post, você não precisa reconstruir o site inteiro.

   Em outras plataformas, talvez seja necessário implementar essa lógica.

Resultado real:

Um dos nossos projetos de blog tinha 2.000 posts. No início, usávamos SSG puro e o build levava 15 minutos. Depois, mudamos a configuração:

• O build gera apenas os 50 posts mais recentes
• Os demais posts usam dynamicParams = true e são gerados sob demanda
• Todas as páginas de posts usam ISR com revalidate: 3600

Agora o build leva dois minutos, e a velocidade de acesso para o usuário não diminuiu.

Novidades do Next.js 15: React Server Components e PPR

Antes de terminar, vale mencionar duas novidades do Next.js 15. Elas não são exatamente estratégias de renderização, mas influenciam diretamente a maneira como construímos páginas.

React Server Components, ou RSC: SSR no nível do componente

Se você já usou o App Router do Next.js 13 ou superior, também já usou Server Components.

Qual é a diferença em relação ao SSR tradicional?

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

• SSR tradicional: a página inteira é renderizada no servidor
• RSC: por padrão, os componentes são renderizados no servidor, e somente os que exigem interação são executados no cliente

As vantagens são claras:

1. O bundle de JavaScript fica menor

   O código de um Server Component não é incluído no pacote enviado ao cliente. Segundo dados oficiais do Next.js, o uso de RSC pode reduzir o volume de JavaScript no cliente em 30% a 50%.

   A página carrega mais rápido, e o celular do usuário também esquenta menos.

2. Acesso direto a recursos do backend

   Um Server Component pode consultar diretamente o banco de dados ou ler o sistema de arquivos, sem a necessidade de criar um endpoint de API.

   // app/posts/page.tsx
   // Este é um Server Component e pode consultar o banco diretamente
   async function getPosts() {
     const posts = await db.posts.findMany();
     return posts;
   }
   
   export default async function PostsPage() {
     const posts = await getPosts();
     return (
       <div>
         {posts.map(post => (
           <PostCard key={post.id} post={post} />
         ))}
       </div>
     );
   }

Recomendações práticas:

• Use Server Components por padrão, como já acontece no App Router
• Use Client Components, com 'use client', apenas onde houver interação
• Use Server Components para obtenção de dados e interfaces estáticas; use Client Components para botões, formulários e animações

Assim, a aplicação preserva as vantagens de SEO do SSR e mantém um bundle de JavaScript pequeno.

Partial Prerendering, ou PPR: combinação de partes estáticas e dinâmicas

PPR é um recurso experimental introduzido no Next.js 15 que permite combinar partes estáticas e dinâmicas na mesma página.

Veja um exemplo:

Em uma página de produto de e-commerce:

• Descrição e imagens do produto são estáticas e geradas durante o build
• Estoque e preço são dinâmicos e obtidos a cada requisição

Com PPR, a parte estática é gerada durante o build, enquanto a parte dinâmica é calculada a cada requisição. Assim, a página permanece rápida e atualizada.

Como usar:

// next.config.js
module.exports = {
  experimental: {
    ppr: true,
  },
};

// app/products/[id]/page.tsx
export const experimental_ppr = true;

export default function ProductPage({ params }) {
  return (
    <div>
      {/* Parte estática: gerada durante o build */}
      <ProductDescription id={params.id} />

      {/* Parte dinâmica: gerada na requisição */}
      <Suspense fallback={<div>Carregando...</div>}>
        <DynamicStock id={params.id} />
      </Suspense>
    </div>
  );
}

Mas há uma condição importante:

PPR ainda é um recurso experimental e não é recomendado para ambientes de produção. Você pode testá-lo em páginas não críticas, mas não o adote no site inteiro.

Quando ficar estável, talvez no Next.js 16, será uma ferramenta muito poderosa.

Como essas novidades se combinam com SSR, SSG e ISR?

• RSC + SSG: Server Components são estáticos por padrão e combinam perfeitamente com SSG
• RSC + ISR: Server Components com revalidate, oferecendo conteúdo estático e atualizações periódicas
• RSC + SSR: uma rota dinâmica ou a configuração dynamic = 'force-dynamic' transforma a renderização em SSR
• PPR: pode ser entendido como a combinação definitiva de SSG e SSR

Na minha visão, RSC é uma evolução da arquitetura interna do Next.js, enquanto SSG, SSR e ISR são estratégias de renderização baseadas nela. Elas não entram em conflito; ao contrário, complementam-se.

Conclusão

Depois de tudo isso, voltamos à pergunta inicial: como escolher entre SSR, SSG e ISR?

Não existe uma resposta padrão. Cada projeto tem necessidades, volume de tráfego e orçamento diferentes. Mas, se você responder a três perguntas centrais, a escolha ficará muito mais fácil:

1. O conteúdo precisa ser personalizado? → Se sim, use SSR
2. Com que frequência o conteúdo é atualizado? → Use SSR para tempo real, ISR para atualizações periódicas e SSG para conteúdo que quase não muda
3. Qual é o volume de tráfego? → Em tráfego muito alto, priorize SSG ou ISR

Lembra da pergunta do chefe no começo do artigo, “Por que está tão lento?”? Depois, migramos aquela página inicial de SSR para ISR com revalidate: 60, e o carregamento inicial caiu de três para 0,8 segundo. O chefe ficou satisfeito, e a experiência do usuário também melhorou.

Minha recomendação:

• Se não tiver certeza, comece testando ISR. É a opção mais equilibrada das três: rápida e capaz de manter o conteúdo atualizado
• Depois de publicar o projeto, use o painel Performance do Chrome DevTools para medir TTFB, FCP e outros indicadores na prática
• Páginas diferentes podem usar estratégias diferentes; evite regras rígidas

Por fim, uma estratégia de renderização não precisa ser permanente. Conforme o projeto cresce, o volume de usuários aumenta e os requisitos mudam, você pode ajustar a abordagem. Não tenha medo de mudar: no Next.js, o custo de alternar entre essas estratégias costuma ser relativamente baixo.

Espero que este artigo ajude você a evitar algumas armadilhas. Se tiver experiências práticas ou histórias sobre problemas semelhantes, compartilhe nos comentários!