21 ott 2025·8 min
Server-Side Rendering (SSR) nei siti web: una guida chiara
Scopri cosa significa SSR (server-side rendering) per i siti web, come funziona e quando usarlo rispetto a CSR o SSG per SEO, velocità ed esperienza utente.
Scopri cosa significa SSR (server-side rendering) per i siti web, come funziona e quando usarlo rispetto a CSR o SSG per SEO, velocità ed esperienza utente.
Il server-side rendering (SSR) è un modo di costruire pagine web in cui il server genera l'HTML per una pagina nel momento in cui qualcuno la richiede, quindi invia quell'HTML già pronto al browser.
In termini semplici, SSR ribalta il consueto schema della “shell vuota prima”: invece di spedire una pagina per lo più vuota e chiedere al browser di assemblare subito i contenuti, è il server a fare il lavoro iniziale di rendering.
Con SSR le persone in genere vedono il contenuto della pagina prima: testo, titoli e layout possono apparire rapidamente perché il browser riceve subito HTML reale.
Dopo, la pagina ha comunque bisogno di JavaScript per diventare completamente interattiva (pulsanti, menu, form, filtri dinamici). Il flusso comune è:
Questo schema “mostra prima i contenuti, poi aggiungi l'interattività” è il motivo per cui SSR viene spesso citato nelle conversazioni sulle prestazioni (soprattutto sulla velocità percepita).
SSR non significa “ospitato su un server” (quasi tutto lo è). Si tratta specificamente di dove viene prodotto l'HTML iniziale:
Quindi puoi usare SSR su molti tipi di hosting—server tradizionali, funzioni serverless o runtime edge—a seconda del framework e della distribuzione.
SSR è solo un'opzione tra le strategie comuni di rendering. Nei prossimi paragrafi confronteremo SSR vs CSR (client-side rendering) e SSR vs SSG (static site generation), e spiegheremo cosa cambia per velocità, UX, strategia di caching e risultati SEO.
SSR significa che il server prepara l'HTML della pagina prima che arrivi al browser. Invece di inviare una shell HTML vuota e lasciare che il browser costruisca la pagina da zero, il server invia una versione “pronta da leggere” della pagina.
/products/123). Il browser invia una richiesta al tuo web server.SSR tipicamente invia HTML più un bundle JavaScript. L'HTML serve per la visualizzazione immediata; il JavaScript abilita comportamenti lato client come filtri, modal e “aggiungi al carrello”.
Dopo che l'HTML è caricato, il browser scarica il bundle JS e aggancia gli event handler al markup esistente. Questo passaggio è quello che molti framework chiamano hydration.
Con SSR il tuo server fa più lavoro per ogni richiesta—recupera dati e rende il markup—quindi i risultati dipendono molto dalla velocità delle API/database e da quanto bene metti in cache l'output.
SSR spedisce una pagina HTML “pronta da leggere” dal server. È ottimo per mostrare velocemente contenuti, ma non rende automaticamente la pagina interattiva.
Un setup molto comune è:
SSR può migliorare la velocità con cui le persone vedono la pagina, mentre la hydration è ciò che fa comportare la pagina come un'app.
La hydration è il processo in cui il JavaScript lato client prende il controllo dell'HTML statico e vi aggancia l'interattività: gestori di click, validazione dei form, menu, filtri dinamici e qualsiasi UI con stato.
Questo passaggio aggiuntivo costa tempo CPU e memoria sul dispositivo dell'utente. Su telefoni più lenti o in schede con molte attività, la hydration può essere visibilmente ritardata—anche se l'HTML è arrivato rapidamente.
Quando il JavaScript è lento a caricarsi, gli utenti possono vedere contenuto ma sperimentare una UI “morta” per un attimo: i pulsanti non rispondono, i menu non si aprono e gli input possono avere ritardi.
Se il JavaScript fallisce completamente (bloccato, errore di rete, crash dello script), SSR garantisce che il contenuto principale possa comunque apparire. Ma le funzionalità tipiche di un'app che dipendono dal JS non funzioneranno, a meno che tu non abbia progettato fallback (per esempio link che navigano normalmente, form che inviano senza codice client).
SSR riguarda dove viene generato l'HTML. Molti siti SSR inviano ancora una quantità significativa di JavaScript—a volte quasi quanto una app CSR—perché l'interattività richiede codice che gira nel browser.
Il server-side rendering (SSR) e il client-side rendering (CSR) possono produrre la stessa pagina visivamente, ma l'ordine del lavoro è diverso—e questo cambia la percezione di velocità.
Con CSR, il browser di solito scarica prima un bundle JavaScript e poi lo esegue per costruire l'HTML. Finché quel lavoro non termina, gli utenti possono vedere uno schermo vuoto, uno spinner o una UI a shell. Questo può far sembrare lenta la prima vista anche se l'app è potente una volta caricata.
Con SSR, il server invia HTML pronto da visualizzare subito. Gli utenti possono vedere titoli, testo e layout più presto, il che spesso migliora la velocità percepita—soprattutto su dispositivi o reti lente.
CSR spesso brilla dopo il caricamento iniziale: la navigazione tra schermate può essere molto veloce perché l'app è già in esecuzione nel browser.
SSR può sembrare più veloce all'inizio, ma la pagina ha comunque bisogno di JavaScript per diventare pienamente interattiva (pulsanti, menu, form). Se il JS è pesante, gli utenti possono vedere i contenuti rapidamente ma attendere un breve ritardo prima che tutto risponda.
SSR (Server-Side Rendering) e SSG (Static Site Generation) possono sembrare simili ai visitatori—entrambi spesso inviano HTML reale al browser. La differenza chiave è quando quell'HTML viene creato.
Con SSG, il sito genera l'HTML in anticipo—di solito durante una fase di build al momento del deploy. Quei file possono essere serviti da una CDN come qualsiasi altro asset statico.
Questo rende SSG:
Il compromesso è la freschezza: se i contenuti cambiano spesso, o ricostruisci e ridistribuisci, o usi tecniche incrementali per aggiornare le pagine.
Con SSR, il server genera l'HTML ad ogni richiesta (o almeno quando la cache non ha la risposta). Questo è utile quando i contenuti devono riflettere gli ultimi dati per quel visitatore o momento.
SSR è adatto a:
Il compromesso è tempo di build vs tempo di richiesta: eviti lunghe ricostruzioni per contenuti dinamici, ma introduci lavoro per richiesta—il che impatta TTFB e costi operativi.
Molti siti moderni sono ibridi: pagine marketing e documentazione con SSG, aree account o risultati di ricerca con SSR.
Un modo pratico per decidere è chiedersi:
Scegliere la strategia di rendering per route spesso dà il miglior equilibrio tra velocità, costo e contenuti aggiornati.
Il server-side rendering spesso migliora la SEO perché i motori di ricerca vedono contenuti reali e significativi appena richiedono la pagina. Invece di ricevere una shell HTML quasi vuota che richiede JavaScript per riempirsi, i crawler ottengono subito testo, titoli e link completi.
Scoperta dei contenuti più rapida. Quando l'HTML contiene già il contenuto della pagina, i crawler possono indicizzarlo più velocemente e in modo più coerente—soprattutto per siti grandi dove budget di crawl e tempistiche contano.
Rendering più affidabile. I motori di ricerca moderni possono eseguire JavaScript, ma non è sempre immediato o prevedibile. Alcuni bot eseguono il JS lentamente, lo rimandano o lo saltano per risorse limitate. SSR riduce la dipendenza dal “sperare che il crawler esegua il mio JS”.
Essenziali SEO nella prima risposta HTML. SSR rende più semplice includere segnali chiave nella risposta iniziale HTML, come:
Qualità e intento del contenuto. SSR aiuta i motori a vedere il contenuto, ma non lo rende utile, originale o allineato con le ricerche degli utenti.
Struttura del sito e linking interno. Una navigazione chiara, URL logici e link interni forti sono ancora importanti per discoverability e ranking.
Igiene tecnica SEO. Problemi come pagine sottili, URL duplicati, canonical rotti o risorse bloccate possono comunque impedire buoni risultati anche con SSR.
Considera SSR come un miglioramento dell'affidabilità di crawl-and-render. È una base solida, non una scorciatoia verso il posizionamento.
Le discussioni sulle prestazioni relative a SSR spesso ruotano attorno a poche metriche chiave—e a una sensazione dell'utente: “la pagina è apparsa rapidamente?” SSR può migliorare ciò che le persone vedono all'inizio, ma può anche spostare lavoro sul server e sulla hydration.
TTFB (Time to First Byte) è quanto tempo impiega il server a iniziare a inviare qualcosa. Con SSR, il TTFB diventa spesso più importante perché il server potrebbe dover recuperare dati e renderizzare HTML prima di rispondere. Se il server è lento, SSR può peggiorare il TTFB.
FCP (First Contentful Paint) è quando il browser dipinge per la prima volta qualsiasi contenuto (testo, sfondo, ecc.). SSR spesso aiuta FCP perché il browser riceve HTML pronto invece di una shell vuota.
LCP (Largest Contentful Paint) è quando l'elemento principale più grande (spesso un hero, un'immagine o il titolo di prodotto) diventa visibile. SSR può aiutare LCP—se l'HTML arriva rapidamente e CSS/asset critici non bloccano il rendering.
SSR aggiunge lavoro sul server ad ogni richiesta (a meno che non sia in cache). Due colli comuni sono:
Una conclusione pratica: la performance SSR spesso dipende meno dal framework e più dal tuo percorso dati. Ridurre i round-trip API, usare query più veloci o precomputare parti della pagina può fare più differenza che ottimizzare solo il front-end.
SSR è ottimo per la “prima vista”: gli utenti possono vedere contenuto prima, scorrere e avere l'impressione che il sito sia reattivo. Ma la hydration richiede ancora JavaScript per collegare pulsanti, menu e form.
Questo crea un compromesso:
Il SSR più veloce è spesso SSR in cache. Se puoi mettere in cache l'HTML renderizzato (al CDN, reverse proxy o a livello di app), eviti di renderizzare e rifetchare dati ad ogni richiesta—migliorando il TTFB e di conseguenza il LCP.
La chiave è scegliere una strategia di caching che corrisponda ai tuoi contenuti (pubblici vs personalizzati) così ottieni velocità senza servire dati sbagliati all'utente.
SSR può sembrare lento se ogni richiesta forza il server a renderizzare l'HTML da zero. Il caching risolve questo—ma solo se sei attento a cosa è sicuro cacheare.
La maggior parte degli stack SSR finisce per avere più cache:
Una risposta SSR cacheata è corretta solo se la chiave di cache corrisponde a tutto ciò che cambia l'output. Oltre al percorso URL, variazioni comuni includono:
HTTP aiuta qui: usa l'header Vary quando l'output cambia in base agli header della richiesta (per esempio Vary: Accept-Language). Fai attenzione con Vary: Cookie—può distruggere il tasso di hit della cache.
Usa Cache-Control per definire il comportamento:
public, max-age=0, s-maxage=600 (cache al CDN/proxy per 10 minuti)stale-while-revalidate=30 (servi HTML leggermente vecchio mentre lo aggiorni in background)Non cacheare mai HTML che include dati privati dell'utente a meno che la cache non sia strettamente per utente. Un pattern più sicuro è: cachea una shell pubblica SSR, poi recupera i dati personalizzati dopo il caricamento (o renderizzali server-side ma segnala la risposta con private, no-store). Un errore qui può esporre dettagli di account ad altri utenti.
SSR può rendere le pagine più rapide e complete al primo caricamento, ma sposta anche la complessità sul server. Prima di adottarlo, vale la pena sapere cosa può andare storto e cosa sorprende i team.
Con SSR, il tuo sito non è più solo file statici su una CDN. Ora hai un server (o funzioni serverless) che renderizza HTML su richiesta.
Questo significa che sei responsabile di configurazione runtime, deploy più sicuri (rollback importanti) e monitoraggio del comportamento in tempo reale: tassi di errore, richieste lente, uso di memoria e fallimenti di dipendenze. Un rilascio sbagliato può rompere ogni richiesta di pagina immediatamente, non solo un singolo download di bundle.
SSR spesso aumenta il compute per richiesta. Anche se il rendering HTML è rapido, rimane lavoro che i tuoi server devono eseguire per ogni visita.
Rispetto all'hosting statico, i costi possono aumentare a causa di:
Perché SSR avviene a richiesta, puoi incontrare casi limite come:
Se il tuo codice SSR chiama una API esterna, una dipendenza lenta può rendere lenta anche la homepage. Per questo timeout, fallback e caching non sono opzionali.
Un errore comune degli sviluppatori è quando il server renderizza HTML che non corrisponde esattamente a quello che il browser renderizzerà durante la hydration. Il risultato può essere warning, flicker o interattività rotta.
Cause tipiche includono valori casuali, timestamp, dati specifici dell'utente o API disponibili solo in browser durante il render iniziale senza adeguate protezioni.
Scegliere “SSR” di solito significa scegliere un framework che può renderizzare HTML sul server e poi renderlo interattivo nel browser. Ecco le opzioni comuni e i termini che incontrerai.
Next.js (React) è una scelta diffusissima. Supporta SSR per route, generazione statica, streaming e diversi target di deployment (server Node, serverless e edge).
Nuxt (Vue) offre un'esperienza simile per team Vue, con routing basato su file e modalità di rendering flessibili.
Remix (React) punta agli standard web e al routing annidato. È spesso scelto per app ricche di dati dove routing e caricamento dati devono essere strettamente accoppiati.
SvelteKit (Svelte) combina SSR, output statico e adapter per diversi host, con una sensazione leggera e un caricamento dati semplice.
Scegli in base alla libreria UI del tuo team, a come vuoi ospitare (server Node, serverless, edge) e a quanto controllo vuoi su caching, streaming e caricamento dati.
Se vuoi sperimentare prima di impegnarti con un intero stack SSR, una piattaforma come Koder.ai può aiutare a prototipare un'app pronta per la produzione a partire da un'interfaccia chat—di solito con frontend React e backend in Go + PostgreSQL—poi iterare con funzionalità come planning mode, snapshot e rollback. Per i team che valutano i trade-off SSR, quel loop “prototipo->deploy” può rendere più semplice misurare l'impatto reale su TTFB/LCP invece di indovinare.
SSR è più prezioso quando hai bisogno che le pagine appaiano pronte in fretta e siano leggibili in modo affidabile da motori di ricerca e bot di anteprima social. Non è un pulsante magico per la velocità, ma può essere il compromesso giusto quando la prima impressione conta.
SSR tende a dare il massimo per:
Se le tue pagine sono accessibili pubblicamente e ti interessa la discoverability, SSR vale quasi sempre la pena valutarlo.
SSR può essere una cattiva scelta quando:
In questi casi, il rendering client-side o un approccio ibrido spesso mantiene l'infrastruttura più semplice.
Considera SSR quando queste condizioni sono vere:
SSR può essere una buona soluzione, ma è più facile avere successo quando si decide con vincoli reali—non solo “pagine più veloci”. Usa questa checklist per mettere alla prova la scelta prima di investire.
Misura una baseline in condizioni simili alla produzione, poi confronta dopo un prototipo:
Imposta alert e dashboard per:
Se la checklist solleva dubbi, valuta un approccio ibrido (SSR + SSG): prerenderizza pagine stabili con SSG e usa SSR solo dove la freschezza o la personalizzazione è davvero necessaria. Spesso questo dà il miglior compromesso tra velocità e complessità.
Se decidi di prototipare, mantieni il ciclo corto: rilascia una route minima in SSR, aggiungi caching, poi misura. Strumenti che semplificano build e deployment possono aiutare—per esempio, Koder.ai supporta il deploy e l'hosting di app (con domini personalizzati ed export del codice sorgente), rendendo più semplice validare le prestazioni SSR e gestire roll-out/rollback mentre iteri.
SSR (server-side rendering) significa che il tuo server genera l'HTML della pagina quando un utente richiede un URL, poi invia quell'HTML pronto per essere mostrato al browser.
È diverso dall’“essere ospitato su un server” (quasi tutto lo è). SSR descrive specificamente dove viene prodotto l'HTML iniziale: sul server per ogni richiesta (o al momento di un miss della cache).
Un tipico flusso SSR sembra così:
/products/123).La grande differenza UX è che gli utenti possono spesso leggere i contenuti prima perché arriva prima l'HTML reale.
SSR migliora principalmente la velocità con cui gli utenti vedono i contenuti, ma JavaScript è ancora necessario per il comportamento da applicazione.
La maggior parte dei siti SSR invia:
Quindi SSR è di solito “contenuto prima, interattività dopo”, non “niente JavaScript”.
Hydration è il passaggio lato client in cui il tuo JavaScript “attiva” l'HTML renderizzato dal server.
Praticamente, la hydration:
Su dispositivi lenti o con bundle grandi, gli utenti possono vedere il contenuto subito ma sperimentare un breve periodo di UI “morta” finché la hydration non termina.
CSR (client-side rendering) di solito scarica prima un bundle JavaScript e poi costruisce l'HTML nel browser, il che può lasciare schermo vuoto, spinner o una shell finché il JS non finisce.
SSR invia prima HTML pronto da visualizzare, migliorando spesso la percezione di velocità per la prima visita.
Regola pratica comune:
SSG (static site generation) crea l'HTML al momento del build/deploy e lo serve come file statici: molto cacheable e prevedibile sotto carico.
SSR crea l'HTML al momento della richiesta (o al miss della cache), utile quando le pagine devono essere aggiornate, personalizzate o dipendono dal contesto della richiesta.
Molti siti mescolano entrambi: SSG per marketing/documentazione stabile, SSR per risultati di ricerca, inventario o pagine dipendenti dall'utente.
SSR può aiutare la SEO mettendo contenuti e metadata direttamente nella risposta HTML iniziale, rendendo crawling e indicizzazione più affidabili.
SSR aiuta con:
SSR non risolve:
Metriche rilevanti:
La performance SSR spesso dipende più dal tuo (latency API/DB, round trip) e dal che dal framework UI.
Il caching dell'output SSR è potente, ma devi evitare di servire l'HTML di un utente a un altro.
Precauzioni pratiche:
Problemi comuni con SSR:
Cache-Control (es., s-maxage, stale-while-revalidate).Vary quando necessario (es., Vary: Accept-Language) e fai attenzione a Vary: Cookie.private, no-store o cache per utente (solo se davvero necessario).Quando hai dubbi, cachea una shell pubblica e recupera i dettagli personalizzati dopo il caricamento.
Mitigazioni: imposta timeout/fallback, riduci round trip dei dati, aggiungi livelli di cache e mantieni server/client render deterministici.