CSR vs SSR vs SSG vs streaming: os trade-offs de performance?

Question

IT Interview Practice · Accepted Answer

A estratégia de renderização decide *onde e quando* o HTML é construído, o que orienta as métricas de carregamento. Não há um melhor universal — combine-a com o quão dinâmico e personalizado é o conteúdo.

## As estratégias

```text
CSR      Servidor envia HTML quase vazio + JS ──▶ navegador busca dados ──▶ renderiza   (primeiro paint lento)
SSR      Servidor renderiza HTML completo por requisição ──▶ navegador mostra ──▶ hidrata   (fresco, custo de TTFB)
SSG      HTML construído UMA VEZ no deploy ──▶ servido do CDN ──▶ hidrata               (mais rápido, estático)
Stream   Servidor descarrega HTML em pedaços conforme pronto ──▶ shell primeiro, dados preenchem    (TTFB rápido + fresco)
```

- **CSR (client-side)** — envie um shell vazio + JS; o navegador busca os dados e renderiza. Barato de hospedar, mas LCP e SEO ruins porque o conteúdo espera pelo JS.
- **SSR (server-side)** — renderiza HTML completo por requisição. Primeiro paint rápido, amigável a SEO e sempre fresco, mas adiciona TTFB (trabalho de servidor por requisição) e ainda precisa de hidratação.
- **SSG (estático)** — renderiza em tempo de build, servido de um CDN. Melhor TTFB/LCP, mas o conteúdo só é tão fresco quanto o seu último build; o **ISR** adiciona rebuilds periódicos/sob demanda.
- **Streaming SSR** — descarrega o shell de HTML imediatamente e faz streaming das partes mais lentas (React Suspense / `renderToPipeableStream`) para que os usuários vejam conteúdo enquanto os dados carregam.

## Escolhendo

| Conteúdo | Melhor opção |
|---------|----------|
| Marketing, docs, blog | SSG (+ ISR) |
| Personalizado, por requisição | SSR / streaming |
| App altamente interativo atrás de autenticação | CSR ou SSR + islands |

## O custo da hidratação (armadilha compartilhada)

SSR/SSG pintam rápido, mas a página não fica interativa até o JS **hidratar** — uma lacuna em que o INP sofre. Hidratação parcial/progressiva e React Server Components existem para enviar menos JS ao cliente e encurtar essa lacuna.

## Por que isso importa

Espera-se que seniores raciocinem sobre esse trade-off por superfície, não que escolham um dogmaticamente. O insight afiado: paint rápido (SSR/SSG) não significa interatividade rápida — a hidratação é o imposto oculto, e streaming + server components são a resposta moderna para obter ambos.

Conteúdo	Melhor opção
Marketing, docs, blog	SSG (+ ISR)
Personalizado, por requisição	SSR / streaming
App altamente interativo atrás de autenticação	CSR ou SSR + islands

As estratégias

Escolhendo

O custo da hidratação (armadilha compartilhada)

Por que isso importa

Perguntas relacionadas