CSR vs SSR vs SSG vs streaming: quali sono i compromessi di prestazioni?

Question

IT Interview Practice · Accepted Answer

La strategia di rendering decide *dove e quando* viene costruito l'HTML, il che guida le metriche di caricamento. Non esiste un'opzione universalmente migliore — abbinala a quanto il contenuto è dinamico e personalizzato.

## Le strategie

```text
CSR      Il server invia HTML quasi vuoto + JS ──▶ il browser recupera i dati ──▶ renderizza   (primo paint lento)
SSR      Il server renderizza HTML completo per richiesta ──▶ il browser lo mostra ──▶ hydrate   (fresco, costo TTFB)
SSG      HTML costruito UNA VOLTA al deploy ──▶ servito da CDN ──▶ hydrate                        (il più veloce, statico)
Stream   Il server invia l'HTML a chunk man mano che è pronto ──▶ prima lo shell, poi i dati       (TTFB veloce + fresco)
```

- **CSR (client-side)** — invia uno shell vuoto + JS; il browser recupera i dati e renderizza. Economico da ospitare, ma LCP e SEO scarsi perché il contenuto aspetta il JS.
- **SSR (server-side)** — renderizza l'HTML completo per richiesta. Primo paint veloce, SEO-friendly e sempre fresco, ma aggiunge TTFB (lavoro del server per richiesta) e necessita comunque della hydration.
- **SSG (statico)** — renderizza al build time, serve da CDN. Miglior TTFB/LCP, ma il contenuto è fresco solo quanto la tua ultima build; l'**ISR** aggiunge rebuild periodiche/on demand.
- **Streaming SSR** — invia subito lo shell HTML e streamma le parti più lente (React Suspense / `renderToPipeableStream`) così gli utenti vedono il contenuto mentre i dati si caricano.

## Come scegliere

| Contenuto | Scelta migliore |
|---------|----------|
| Marketing, docs, blog | SSG (+ ISR) |
| Personalizzato, per richiesta | SSR / streaming |
| App altamente interattiva dietro autenticazione | CSR o SSR + islands |

## Il costo della hydration (insidia condivisa)

SSR/SSG fanno il paint velocemente ma la pagina non è interattiva finché il JS non fa l'**hydration** — un intervallo in cui l'INP soffre. La hydration parziale/progressiva e i React Server Components esistono per inviare meno JS al client e ridurre quell'intervallo.

## Perché è importante

I senior devono saper ragionare su questo compromesso per ogni superficie, non scegliere dogmaticamente un'opzione. L'intuizione acuta: un paint veloce (SSR/SSG) non significa interattività veloce — la hydration è la tassa nascosta, e streaming + server component sono la risposta moderna per ottenere entrambe.

Contenuto	Scelta migliore
Marketing, docs, blog	SSG (+ ISR)
Personalizzato, per richiesta	SSR / streaming
App altamente interattiva dietro autenticazione	CSR o SSR + islands

Le strategie

Come scegliere

Il costo della hydration (insidia condivisa)

Perché è importante

Domande correlate