SSR, CSR, SSG e ISR: la differenza reale
SSG crea HTML prima della request, di solito nel build. SSR lo crea sul server per ogni request. CSR costruisce gran parte dell'interfaccia dopo l'esecuzione di JavaScript nel browser. ISR mantiene un risultato statico ma consente la rigenerazione dopo il deploy. [6][9][16]
Le domande utili sono quindi quando nasce l'HTML, quanto viene mantenuto in cache e quanto lavoro resta al browser.
SEO: Google renderizza JavaScript, ma CSR non equivale al prerendering
Google descrive il trattamento dei siti JavaScript in tre fasi: crawling, rendering e indexing. Se l'HTML iniziale non contiene il vero contenuto, il Web Rendering Service deve eseguire JavaScript e la pagina entra in una coda di rendering. [1]
Google continua a consigliare SSR o prerendering perché accelera utenti e crawler e non tutti i bot eseguono JavaScript. [1]
CSR può funzionare, ma HTML significativo già nella risposta è più robusto per contenuti pubblici importanti.
SSG: ottimo punto di partenza per contenuti poco variabili
Con SSG, l'HTML viene generato nel build e può essere servito come file statico da CDN. Next.js consiglia Static Generation quando la pagina può essere preparata prima della request. [9][12]
Landing page, documentazione, articoli, help, portfolio e parte dei cataloghi sono casi tipici. [10][16]
Il limite emerge con dati molto frequenti o build troppo lunghi.
SSR: quando il contenuto deve essere fresco o dipendere dalla request
SSR genera HTML per una request specifica e può usare dati aggiornati, headers, cookies, localizzazione o parametri. [6][10][11]
Il contenuto arriva in HTML, ma ogni request richiede lavoro server e un rendering lento può aumentare TTFB. [6]
Le parti stabili possono essere cacheate lasciando dinamico solo ciò che dipende davvero dalla request.
ISR: HTML statico con freschezza controllata
ISR mantiene i vantaggi dell'HTML statico consentendo la rigenerazione dopo il deploy. Next.js documenta l'aggiornamento di pagine statiche dopo il build e Nuxt 4 offre meccanismi simili con `isr` e `swr`. [9][13][16]
È adatto a cataloghi, articoli, documentazione e categorie che cambiano periodicamente ma non richiedono real time.
Con stale-while-revalidate, il primo visitatore dopo la scadenza può ricevere la versione precedente mentre quella nuova viene generata. [13][16]
CSR: adatto ad applicazioni che non devono essere indicizzate
Con CSR, il browser deve scaricare, analizzare ed eseguire JavaScript prima di costruire buona parte del DOM. web.dev segnala che bundle grandi possono peggiorare INP, soprattutto su mobile. [6][7]
Nuxt cita SaaS, back-office, giochi e interfacce fortemente interattive senza necessità SEO come casi adatti. [13]
Per contenuti pubblici, CSR aumenta la dipendenza dal rendering JavaScript dei crawler. [1][2]
Confronto SEO e prestazioni
| Modalità | Quando viene generato HTML | Contenuto nell'HTML iniziale | Freschezza | Costo per request | SEO |
|---|---|---|---|---|---|
| SSG | Build | Sì | Fino al prossimo build | Molto basso | Molto buono |
| ISR | Build o revalidazione | Sì | Dipende dalla revalidazione | Basso | Molto buono |
| SSR | Ogni request | Sì | Molto alta | Più alto | Molto buono |
| CSR | Nel browser | Spesso limitato | Alta dopo fetch | Server basso, client più alto | Possibile, meno ottimale |
Non esiste una classifica universale. SSG e ISR hanno spesso vantaggi di cache e costo, SSR di freschezza, CSR di flessibilità lato client. [6][9][13]
Per SEO, SSG, ISR e SSR possono restituire HTML significativo subito. CSR può essere indicizzato da Google, ma richiede una fase di rendering aggiuntiva. [1][9]
Core Web Vitals: il rendering è solo una parte
| Metrica | Buono | Scarso | Cosa misura |
|---|---|---|---|
| LCP | ≤ 2.5 s | > 4.0 s | Caricamento del contenuto principale |
| INP | ≤ 200 ms | > 500 ms | Reattività alle interazioni |
| CLS | ≤ 0.1 | > 0.25 | Stabilità visiva |
Google usa i Core Web Vitals nei sistemi di ranking, ma chiarisce che buoni valori non garantiscono posizioni elevate. Le metriche attuali sono LCP, INP e CLS. [4][5]
Le soglie consigliate sono LCP ≤ 2,5 s, INP ≤ 200 ms e CLS ≤ 0,1 al 75° percentile. [4][8]
SSG può consegnare HTML rapidamente e avere comunque INP scarso per troppo JavaScript. SSR può migliorare il primo render, ma un backend lento può peggiorare TTFB. [6][7]
Hydration: SSR non finisce con l'HTML
Molti framework idratano l'output SSR o SSG aggiungendo stato ed eventi dopo l'arrivo dell'HTML. web.dev avverte che la rehydration completa può aumentare TBT e peggiorare INP. [6]
Una pagina può quindi sembrare pronta ma non rispondere subito alle interazioni.
Ridurre JavaScript, usare code splitting, lazy loading e hydration parziale o ritardata aiuta. Nuxt 4 documenta pagine quasi statiche con pochissimo JavaScript. [7][14]
Cache e freschezza: la differenza chiave
SSG riusa il risultato fino al prossimo build. ISR aggiunge revalidazione. SSR può ricalcolare a ogni request ma può anche usare cache server o CDN. [6][13][16]
La scelta deve partire dall'età massima accettabile dei dati. Alcuni minuti possono andare bene per una pagina prodotto, non per un saldo account.
Quando possibile, l'invalidazione dovrebbe seguire cambi reali del contenuto.
La SEO non finisce con il rendering
L'HTML non sostituisce status HTTP corretti, link crawlable, canonical, sitemap, titoli e metadati. Google raccomanda URL propri e link crawlable per i contenuti importanti. [1][2]
SSR implementato male può comunque produrre 200 errati, duplicati o metadata sbagliati. Il rendering è solo una parte della SEO tecnica.
Google non raccomanda più Dynamic Rendering come soluzione di lungo periodo e preferisce SSR, static rendering o hydration. [3]
Cosa scegliere per i diversi tipi di pagina
Landing page, blog e documentazione si adattano spesso a SSG. Cataloghi grandi o news periodiche a ISR. Pagine pubbliche dipendenti dalla request possono richiedere SSR. Dashboard privati possono restare CSR. [9][13]
Un e-commerce può combinare categoria statica, ISR per i prodotti, SSR per dati di sessione e CSR per filtri interattivi.
La scelta va fatta per route.
Realtà 2026: i modelli ibridi diventano più granulari
Next.js 16.3.4 documenta Cache Components, `use cache`, revalidazione di dati e UI, shell statica e streaming per dati request-time. La guida attuale è stata aggiornata il 25 agosto 2026. [11]
Nuxt 4 permette `prerender`, `ssr`, `swr` e `isr` per route tramite Route Rules. [13][14]
I quattro termini restano utili, ma non descrivono più ogni componente di un'app moderna.
Migliorare un'app CSR per la SEO senza riscriverla
Per prima cosa individua le route pubbliche che devono davvero acquisire traffico organico. Non serve trasformare un dashboard privato in SSR solo per uniformità.
Poi sposta contenuto critico, titoli, metadati e link in HTML generato prima del JavaScript client. Google consiglia SSR o prerendering rispetto a Dynamic Rendering. [1][3]
Infine verifica Search Console, HTML renderizzato e dati reali dei Core Web Vitals.
Regola pratica di scelta
Se la pagina può essere generata prima e il contenuto è uguale per tutti, parti da SSG. Se cambia periodicamente, considera ISR. Se il risultato dipende dalla request e deve essere in HTML, usa SSR. Se è un'app privata senza obiettivo SEO, CSR spesso basta. [9][13]
Poi valida TTFB, LCP, INP, CLS, costo server, frequenza di aggiornamento, numero di pagine e personalizzazione.
- Il contenuto principale deve essere indicizzato?
- L'HTML può essere generato prima della request?
- Quanto devono essere freschi i dati?
- Il risultato dipende da cookies, sessione o request?
- Quante route vanno generate?
- La pagina può essere cacheata in sicurezza?
- Quanto JavaScript deve eseguire il browser?
- Quali sono LCP, INP, CLS e TTFB reali in produzione?
