CSR, SSR, SSG e ISR: estratégias de renderização web e seu impacto em SEO e performance

Onde o HTML da sua página é montado, no servidor, no navegador ou em tempo de build, parece um detalhe técnico interno. Na prática, essa escolha define quão rápido a página aparece, quão bem ela ranqueia no Google e quanto custa operá-la. É uma das decisões de arquitetura frontend com maior impacto direto em conversão e SEO.

Neste guia, explicamos as quatro estratégias principais de renderização (CSR, SSR, SSG e ISR), como cada uma afeta os Core Web Vitals e a indexação por buscadores, e como escolher a abordagem certa para cada tipo de página.

O que é estratégia de renderização

Renderização, neste contexto, é o processo de transformar o código da aplicação no HTML que o usuário (e o buscador) efetivamente recebe. A pergunta central é quando e onde esse HTML é gerado:

• No navegador do usuário, depois de baixar o JavaScript (CSR).
• No servidor, a cada requisição (SSR).
• No momento do build, antes de qualquer visita (SSG).
• Em um modelo híbrido, que pré-gera e atualiza sob demanda (ISR).

Cada escolha desloca o trabalho para um momento diferente, e cada momento tem um custo: tempo de espera do usuário, carga no servidor ou frescor do conteúdo. Não existe opção universalmente melhor, existe a opção certa para cada caso.

CSR (Client-Side Rendering)

No CSR, o servidor envia um HTML quase vazio e um pacote de JavaScript. O navegador baixa esse JavaScript, executa, busca os dados e só então constrói a interface. É o modelo das Single Page Applications tradicionais.

• Vantagens: navegação interna fluida após o carregamento inicial, ótima para aplicações ricas em interação atrás de login (painéis, dashboards).
• Desvantagens: a primeira pintura depende de baixar e executar JavaScript, o que piora o tempo até o conteúdo aparecer. Como o HTML inicial vem vazio, o SEO sofre se o buscador não executar o JavaScript de forma confiável.

CSR é uma escolha ruim para páginas públicas que dependem de SEO, como landing pages e blogs, e uma escolha razoável para aplicações internas onde indexação não importa.

SSR (Server-Side Rendering)

No SSR, o servidor monta o HTML completo a cada requisição e o envia pronto. O navegador exibe o conteúdo de imediato e depois "hidrata" a página com JavaScript para torná-la interativa.

• Vantagens: o conteúdo aparece rápido e já vem completo no HTML, o que é excelente para SEO. Ideal para páginas com dados dinâmicos e personalizados (um feed, uma página de produto com estoque em tempo real).
• Desvantagens: cada requisição gera trabalho no servidor, o que aumenta custo e latência sob alto tráfego. Exige infraestrutura de servidor sempre ativa, diferente de servir arquivos estáticos.

SSR brilha quando o conteúdo muda a cada acesso ou por usuário, e quando o SEO é inegociável.

SSG (Static Site Generation)

No SSG, o HTML de cada página é gerado uma única vez, no momento do build, e servido como arquivo estático por uma CDN. O usuário recebe um arquivo pronto, sem nenhum processamento no servidor a cada visita.

• Vantagens: é a abordagem mais rápida e barata. Arquivos estáticos na borda (edge) carregam em frações de segundo, escalam sem esforço e oferecem SEO impecável.
• Desvantagens: o conteúdo é "congelado" no build. Para atualizar, é preciso refazer o build e publicar de novo, o que é inviável para dados que mudam a cada minuto.

SSG é a escolha natural para landing pages, sites institucionais, documentação e blogs: conteúdo que muda com pouca frequência e precisa ser rápido e bem indexado.

ISR (Incremental Static Regeneration)

O ISR é o híbrido que tenta o melhor dos dois mundos. As páginas são geradas estaticamente, como no SSG, mas podem ser revalidadas e regeneradas em segundo plano após um intervalo definido, sem refazer o build inteiro.

• Vantagens: mantém a velocidade e o baixo custo do estático, mas com conteúdo que se atualiza sozinho de tempos em tempos. Escala para milhares de páginas sem build eterno.
• Desvantagens: há uma janela em que o usuário pode ver uma versão levemente desatualizada até a regeneração ocorrer. A configuração é mais sutil que a do SSG puro.

ISR é ideal para catálogos grandes, e-commerces e portais de conteúdo: muitas páginas, que mudam de vez em quando, mas que precisam de performance de estático.

Tabela comparativa

Estratégia	HTML gerado	Velocidade inicial	SEO	Frescor do dado	Custo de servidor
CSR	No navegador	Lenta	Fraco	Tempo real	Baixo
SSR	No servidor, por requisição	Boa	Forte	Tempo real	Alto
SSG	No build	Excelente	Forte	Congelado no build	Mínimo
ISR	No build + revalidação	Excelente	Forte	Periódico	Baixo

Impacto em Core Web Vitals e SEO

A estratégia de renderização afeta diretamente as métricas que o Google usa para medir experiência, os Core Web Vitals:

• LCP (Largest Contentful Paint): mede quando o maior elemento visível carrega. SSG e ISR tendem a ter o melhor LCP, porque entregam HTML pronto pela borda. CSR costuma ter o pior, porque o conteúdo só aparece após baixar e executar JavaScript.
• INP (Interaction to Next Paint): mede a resposta às interações. Páginas com muito JavaScript de hidratação podem sofrer aqui, independentemente da estratégia, se o pacote for pesado.
• CLS (Cumulative Layout Shift): mede a estabilidade visual. Reservar espaço para imagens e fontes ajuda em qualquer estratégia.

Para SEO, o ponto decisivo é o HTML inicial. Buscadores indexam de forma mais confiável quando o conteúdo já está no HTML entregue (SSR, SSG, ISR). Com CSR puro, a indexação depende de o buscador executar o JavaScript corretamente, o que adiciona risco e atraso. Para qualquer página que dependa de tráfego orgânico, entregar conteúdo no HTML é a aposta segura.

Exemplo de código: modos de renderização no Next.js

Frameworks modernos permitem escolher a estratégia por página. O exemplo abaixo ilustra, em Next.js, a diferença entre estático puro e estático com revalidação (ISR):

// SSG puro: gerado no build, sem revalidação
export async function getStaticProps() {
  const dados = await buscarConteudo();
  return { props: { dados } };
}

// ISR: estático, mas regenerado a cada 60 segundos sob demanda
export async function getStaticProps() {
  const dados = await buscarConteudo();
  return {
    props: { dados },
    revalidate: 60, // revalida em segundo plano após 60s
  };
}

// SSR: gerado a cada requisição, sempre fresco
export async function getServerSideProps() {
  const dados = await buscarConteudo();
  return { props: { dados } };
}

A única diferença prática entre as três é onde e quando os dados são buscados. A propriedade revalidate é o que separa o estático congelado do estático que se atualiza sozinho.

Como escolher a estratégia certa

Uma forma simples de decidir, por tipo de página:

• Landing page, site institucional, blog: SSG. Conteúdo estável, velocidade máxima, SEO impecável e custo mínimo.
• Catálogo grande ou e-commerce: ISR. Muitas páginas que mudam de vez em quando, com performance de estático.
• Página personalizada ou com dado em tempo real: SSR. Conteúdo que muda por usuário ou a cada acesso, sem abrir mão do SEO.
• Aplicação interna atrás de login: CSR. Interação rica, sem necessidade de indexação.

Na prática, projetos maduros misturam estratégias: o blog em SSG, o catálogo em ISR, o painel logado em CSR. O framework certo permite essa escolha página a página, e a decisão deve sempre partir de duas perguntas: o conteúdo precisa de SEO? Com que frequência ele muda?

Quer uma página rápida e que ranqueia de verdade?

Escolher a estratégia de renderização certa é o que separa uma landing page que carrega abaixo de um segundo e converte de uma que afasta o visitante e perde posição no Google. Cada decisão, da renderização ao tamanho da imagem do hero, impacta o resultado. Se você quer uma página premium, rápida e construída sobre Core Web Vitals e SEO de verdade, fale com o nosso time de Pages e saia da conversa com um plano claro para a sua próxima landing page de alta conversão.