---
term: 'SSR vs. CSR vs. SSG'
seoTitle: 'SSR vs. CSR vs. SSG: padrões de renderização, SEO e métricas'
headline: 'SSR vs. CSR vs. SSG: como funciona a renderização web'
slug: ssr-vs-csr-vs-ssg
category: frontend-web
shortDefinition: 'SSR vs. CSR vs. SSG é uma comparação de estratégias de renderização por onde e quando o HTML é gerado: no build, no servidor ou no navegador.'
relatedTerms:
  - jamstack
  - cdn-content-delivery-network
  - progressive-web-app-pwa
  - api
contrastsWith:
  - jamstack
aboutTerms:
  - 'Hidratação (Hydration)'
  - 'ISR e Streaming'
  - 'TTFB / FCP / TTI'
faq:
  - question: 'O que é CSR (renderização no cliente)?'
    answer: 'O servidor envia um HTML quase vazio mais um bundle de JavaScript; o navegador baixa, interpreta e executa o JS, busca os dados numa API e monta a página. O usuário vê uma tela em branco ou um spinner até o JavaScript rodar — a melhor interatividade, o pior carregamento inicial e SEO.'
  - question: 'O que é SSR (renderização no servidor)?'
    answer: 'O servidor gera o HTML completo a cada requisição — executando código e buscando dados — e envia um documento pronto para pintar, que depois é hidratado para ganhar interatividade. SEO forte e primeira pintura rápida com dados sempre frescos, ao custo de computação no servidor e um time-to-first-byte maior.'
  - question: 'O que é SSG (geração de site estático)?'
    answer: 'O HTML de cada página é pré-construído no build em arquivos estáticos e servido de uma CDN, sem trabalho de servidor por requisição. A opção mais rápida, barata e amigável a SEO — mas os dados só são tão frescos quanto o último build, e ela encaixa mal em rotas desconhecidas ou altamente dinâmicas.'
  - question: 'Qual a diferença entre SSR, CSR e SSG?'
    answer: 'Onde e quando o HTML é gerado: no build (SSG), no servidor a cada requisição (SSR) ou no navegador em runtime (CSR). Todo o resto — SEO, performance, frescor dos dados, custo — decorre dessa única escolha.'
  - question: 'Qual estratégia de renderização é melhor para SEO?'
    answer: 'SSG e SSR, porque os crawlers recebem HTML completo. CSR é a mais arriscada, já que os bots precisam executar JavaScript para ver o conteúdo, o que atrasa ou pode custar a indexação. A nuance: crawlers modernos renderizam JavaScript, mas com um orçamento — CSR serve para superfícies não indexáveis e é uma aposta para conteúdo que precisa ranquear.'
  - question: 'O que é hidratação (hydration)?'
    answer: 'Anexar JavaScript — event listeners e estado — a um HTML já renderizado no servidor, para que uma página de aparência estática se torne interativa. A pegadinha: o JS ainda precisa baixar, interpretar e executar, então a página pode parecer pronta e continuar sem responder a cliques, atrasando o time-to-interactive mesmo quando a primeira pintura foi rápida.'
  - question: 'Qual a diferença entre SSR e SSG?'
    answer: 'SSG para conteúdo igual para todo mundo e que muda raramente — docs, blogs, marketing. SSR para páginas personalizadas, atrás de autenticação ou que mudam com frequência suficiente para dados de build ficarem velhos. O conselho padrão: prefira SSG e recorra a SSR só onde o frescor por requisição é obrigatório.'
  - question: 'Dá para misturar estratégias no mesmo app?'
    answer: 'Sim — a prática moderna é por rota, até por componente: páginas de marketing estáticas, catálogo regenerado, dashboards renderizados no servidor e widgets renderizados no cliente convivem num mesmo app. Renderização é uma decisão que você toma por página, não uma vez para o site inteiro.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Client-side rendering (CSR) — MDN Web Docs'
    url: 'https://developer.mozilla.org/en-US/docs/Glossary/CSR'
  - name: 'Server-side rendering (SSR) — MDN Web Docs'
    url: 'https://developer.mozilla.org/en-US/docs/Glossary/SSR'
  - name: 'Rendering patterns — patterns.dev'
    url: 'https://www.patterns.dev/'
  - name: 'Static site generator — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Static_site_generator'
cta:
  title: 'Uma API, qualquer estratégia de renderização'
  text: 'As APIs REST e GraphQL do Back4app alimentam SSG no build, SSR por requisição e CSR no navegador sem mudar nada — escolha a renderização por rota; o backend continua o mesmo.'
  linkText: 'Comece grátis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-24'
translationKey: ssr-vs-csr-vs-ssg
---

**SSR vs. CSR vs. SSG é uma comparação de estratégias de renderização por onde e quando o HTML é gerado: no build, no servidor ou no navegador.** Esse único eixo — *onde e quando* — determina SEO, performance, frescor dos dados e custo; todo o resto é consequência dele. E o esclarecimento de engenheiro de backend que os guias de frontend enterram: **renderização é uma preocupação do frontend; os dados são do backend.** As três estratégias chamam a mesma [API](/glossary/pt/api/); elas diferem apenas no momento em que a chamam.

## Principais pontos

| Pergunta | Resposta |
| --- | --- |
| O eixo | *Onde e quando* o HTML nasce — build · servidor · navegador |
| CSR | O navegador monta — melhor interatividade, piores primeira carga e SEO |
| SSR | O servidor monta a cada requisição — fresco, forte em SEO, TTFB maior |
| SSG | Pré-construído no build, servido por [CDN](/glossary/pt/cdn/) — o mais rápido e barato, velho até o próximo build |
| O reenquadramento | Mesma [API](/glossary/pt/api/), três momentos de chamada — é por rota, não por app |

## Os mesmos dados, três momentos de chamada

**JavaScript:**

```javascript
// JavaScript — the SAME API call, consumed three ways.
// Rendering is a FRONTEND choice; the data is a BACKEND concern.
async function getPosts() {
  const q = new Parse.Query('Post').equalTo('published', true).limit(20);
  return q.find(); // one backend endpoint — the ONLY thing that changes is WHEN
}

// SSG — called at BUILD time; data baked into static HTML, served from a CDN.
// SSR — called PER REQUEST on the server; fresh HTML sent to the browser.
// CSR — called FROM THE BROWSER after load; the client builds the DOM.
// You don't change the backend to switch rendering — only when/where you fetch.
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// Whatever the rendering strategy, the data comes from one backend API.
Future<List<ParseObject>> getPosts() async {
  final q = QueryBuilder<ParseObject>(ParseObject('Post'))
    ..whereEqualTo('published', true)
    ..setLimit(20);
  return (await q.query()).results?.cast<ParseObject>() ?? [];
}
// SSG fetches at build, SSR fetches per request, CSR fetches in the client —
// the endpoint is identical; only the timing and location differ.
```

**Swift:**

```swift
// Swift — Back4app Swift SDK
// Whatever the rendering strategy, the data comes from one backend API.
func getPosts() async throws -> [Post] {
    try await Post.query("published" == true).limit(20).find()
}
// SSG fetches at build, SSR fetches per request, CSR fetches in the client —
// the endpoint is identical; only the timing and location differ.
```

**Kotlin:**

```kotlin
// Kotlin — Back4app Android SDK
// Whatever the rendering strategy, the data comes from one backend API.
fun getPosts(): List<ParseObject> {
    val q = ParseQuery.getQuery<ParseObject>("Post")
    q.whereEqualTo("published", true)
    q.limit = 20
    return q.find()
}
// SSG fetches at build, SSR fetches per request, CSR fetches in the client —
// the endpoint is identical; only the timing and location differ.
```

Um `getPosts()`, um endpoint de backend. O **SSG** o chama no *build* e assa o resultado em HTML estático; o **SSR** o chama *no servidor, a cada requisição*, e envia HTML fresco; o **CSR** o chama *do navegador*, depois do carregamento. Você nunca muda o backend para mudar a renderização — só o momento e o lugar do fetch. É esse fato que transforma uma comparação confusa de três vias numa única decisão.

## SSR vs. CSR vs. SSG, lado a lado

```mermaid
flowchart LR
  accTitle: Onde o HTML é gerado em CSR, SSR e SSG
  accDescr: Na renderização no cliente, o servidor envia um shell vazio e um bundle de JavaScript, e o navegador busca os dados na API e monta a página. Na renderização no servidor, o servidor busca na API a cada requisição e envia HTML completo que depois é hidratado. Na geração de site estático, o HTML é pré-construído a partir da API no build e servido de uma CDN. As três estratégias leem a mesma API de backend.
  API[("API do backend")] -->|"no build"| SSG["SSG → HTML estático → CDN"]
  API -->|"por requisição, no servidor"| SSR["SSR → HTML completo → hidratar"]
  API -->|"do navegador"| CSR["CSR → shell + JS → montar o DOM"]
```

| | CSR | SSR | SSG |
| --- | --- | --- | --- |
| HTML gerado | No navegador | No servidor, por requisição | No build |
| TTFB | Rápido | **Maior** (renderiza antes) | **O mais rápido, consistente** |
| Primeira pintura (FCP) | Lenta | Rápida | Rápida |
| Interativo (TTI) | Lento | Após a hidratação | Após a hidratação |
| SEO | O mais arriscado | Forte | Forte |
| Frescor dos dados | Ao vivo | Ao vivo | Do último build |
| Custo | Servidor barato | Servidor por requisição | O mais barato (estático) |
| Melhor para | Dashboards, apps | Personalizado, fresco | Conteúdo, docs, marketing |

## As métricas, com honestidade

Os trade-offs que nenhuma comparação enuncia com clareza. O **SSG** vence o time-to-first-byte de lavada e com consistência — a CDN devolve um arquivo pré-construído. O **SSR** *aumenta* o TTFB (o servidor precisa renderizar antes de responder), mas ainda bate o CSR na primeira pintura, e entrega dados frescos. O **CSR** tem TTFB rápido (o shell é minúsculo), mas primeira pintura e time-to-interactive lentos, porque nada aparece até o bundle rodar. E o ponto que todo mundo passa por cima: **SSR e SSG não consertam o TTI.** Ambos enviam HTML que *parece* pronto, e então a **hidratação** — baixar, interpretar e executar o JavaScript que anexa a interatividade — roda de qualquer jeito. É a lacuna do "parece pronto mas não clica", e é por isso que a conta de JS enviado é o verdadeiro imposto da interatividade — motivando islands, hidratação parcial e server components, que enviam menos dele.

## O espectro moderno: ISR, streaming, RSC

O trio é uma simplificação didática; produção é um espectro. O **ISR (incremental static regeneration)** serve páginas estáticas, mas regenera páginas individuais num intervalo de revalidação ou sob demanda — velocidade de SSG com frescor periódico, ao preço de alguma desatualização ocasional. O **SSR com streaming** envia o HTML em pedaços conforme é gerado, então o shell pinta em dezenas de milissegundos enquanto o conteúdo lento chega atrás. Os **server components** rodam só no servidor, enviam *zero* JavaScript para as partes não interativas e podem ler dados diretamente — a resposta mais nova ao custo da hidratação. Nenhum deles muda o contrato com o backend; são controle mais fino sobre *quando o HTML se forma e quanto JS vem atrás dele* — o mesmo eixo em torno do qual este verbete inteiro gira.

## É por rota, não por app

O upgrade mental que dissolve a maioria dos debates de "qual delas?": **você não escolhe uma estratégia para o site inteiro.** Um único app rotineiramente as mistura — home de marketing gerada estaticamente, catálogo de produtos regenerado via ISR, dashboard personalizado renderizado no servidor e widgets interativos renderizados no cliente — cada rota escolhendo pelas próprias necessidades. A pergunta nunca é "SSR, CSR ou SSG para o meu app?", e sim "qual para *esta página*?", e a resposta segue os dados da página: igual para todos e estável → estático; personalizado ou fresco → servidor; atrás de login e altamente interativo → cliente.

## Qual estratégia para cada página? Matriz de decisão

| Tipo de página | Renderização |
| --- | --- |
| Marketing, landing, blog, docs | SSG |
| Catálogo de produtos, notícias, feeds | ISR (estático + atualização periódica) |
| Personalizado, atrás de login, carrinho, busca | SSR (ou streaming) |
| Dashboards, ferramentas internas | CSR |
| Tempo real, altamente interativo | CSR + [dados ao vivo](/glossary/pt/live-queries-tempo-real/) |
| Conteúdo crítico para SEO | CSR não — renderize no servidor ou pré-construa |

## Casos de uso comuns

- **Sites de conteúdo** — SSG mais uma [CDN](/glossary/pt/cdn/) para páginas instantâneas e amigáveis a crawlers (o padrão [JAMstack](/glossary/pt/jamstack/)).
- **E-commerce** — catálogo em ISR, carrinho e checkout em SSR, filtros interativos em CSR — três estratégias, uma loja.
- **Dashboards SaaS** — CSR atrás do login, onde SEO não importa e interatividade importa.
- **Notícias e publishing** — SSR ou ISR para frescor com SEO.
- **[PWAs](/glossary/pt/pwa/)** — um shell renderizado mais interatividade no cliente e cache offline.

## Limitações e trade-offs

- **O risco de SEO do CSR é real, mas exagerado.** Crawlers renderizam JavaScript com um orçamento; CSR é tranquilo fora do caminho indexável e uma aposta dentro dele — nuance, não absolutismo.
- **SSR custa computação de servidor.** Renderizar cada requisição tem um preço em TTFB e infraestrutura que um arquivo estático servido por CDN não tem.
- **A defasagem de frescor do SSG.** Dados de build ficam velhos até o próximo build; sites grandes ou que mudam rápido precisam de ISR ou de builds longos.
- **Hidratação é o imposto escondido.** HTML renderizado no servidor ainda envia JS para ficar interativo; primeira pintura rápida, primeiro *clique* nem tanto.
- **Misturar adiciona carga cognitiva.** Renderização por rota é poderosa e significa raciocinar sobre vários timings de fetch num mesmo app — a flexibilidade tem custo de complexidade.

## Renderização no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. Ele é a constante por baixo da escolha de renderização: as [APIs REST e GraphQL](/glossary/pt/apis-geradas-automaticamente/) alimentam o **SSG no build**, o **SSR por requisição no servidor** e o **CSR do navegador** — o endpoint idêntico das abas de código, consumido em três momentos diferentes — de modo que trocar a estratégia de uma rota nunca toca o backend. O reenquadramento que abre este artigo vira conveniência de trabalho: como renderização é uma decisão de frontend e os dados moram atrás de uma API estável com [autenticação](/glossary/pt/autenticacao-vs-autorizacao/) e [permissões](/glossary/pt/listas-de-controle-de-acesso-acl/) próprias, um time pode pré-construir o blog, renderizar o dashboard no servidor e renderizar o shell do app no cliente contra o mesmo backend Back4app — escolhendo por página, sem mudar nada por baixo.