Scopri come il rendering lato server (SSR) accelera il primo caricamento, migliora i Core Web Vitals e aiuta i motori di ricerca a scansionare e indicizzare le pagine in modo più affidabile.
Il rendering lato server (SSR) è un modo di costruire pagine web in cui il server prepara la prima versione della pagina prima che arrivi al browser.
In una tipica app JavaScript, il browser spesso deve scaricare codice, eseguirlo, recuperare dati e poi assemblare la pagina. Con l'SSR, il server svolge gran parte di quel lavoro in anticipo e restituisce HTML pronto da visualizzare. Il browser scaricherà comunque il JavaScript in seguito (per pulsanti, filtri, form e altre interazioni), ma parte da una pagina già popolata invece che da una shell vuota.
La differenza principale che si percepisce è che i contenuti appaiono prima. Invece di fissare uno schermo vuoto o uno spinner mentre gli script si caricano, le persone possono iniziare a leggere e scorrere più velocemente—soprattutto su reti mobili o dispositivi più lenti.
Questa vista iniziale anticipata può tradursi in una migliore percezione della velocità e può sostenere segnali di performance come Largest Contentful Paint e, in alcuni casi, Time to First Byte. (SSR non migliora automaticamente tutto; dipende da come le pagine sono costruite e servite.)
L'SSR può migliorare le prestazioni web e aiutare la SEO per siti pesanti di JavaScript, ma introduce anche compromessi: lavoro extra sul server, più cose da mettere in cache e tempo di “hydration” (quando la pagina diventa pienamente interattiva).
Nel resto di questo articolo confronteremo SSR e CSR in modo semplice, vedremo le metriche di performance che l'SSR può migliorare, spiegheremo perché l'SSR aiuta la crawlability e l'indicizzazione, e copriremo costi reali e insidie—oltre a come misurare i risultati con KPI di velocità e SEO.
Server‑side rendering (SSR) e client‑side rendering (CSR) descrivono dove viene prodotto l'HTML iniziale per una pagina: sul server o nel browser dell'utente. La differenza può sembrare sottile, ma cambia ciò che gli utenti vedono per primi—e quanto velocemente.
Con l'SSR, il browser chiede una pagina e riceve HTML che contiene già il contenuto principale della pagina.
A questo punto la pagina può sembrare “fatta”, ma potrebbe non essere ancora completamente interattiva.
Con il CSR, il server spesso restituisce una shell HTML minima—poi il browser fa la maggior parte del lavoro.
Questo significa che gli utenti possono passare più tempo a guardare un'area vuota o uno stato di caricamento, specialmente su connessioni o dispositivi lenti.
Le pagine SSR tipicamente inviano prima l'HTML, poi il JavaScript “hydrate” la pagina—collegando i gestori di evento e trasformando l'HTML statico in un'app funzionante (pulsanti, form, navigazione).
Un modo semplice per pensarci:
Immagina una pagina prodotto.
L'SSR cambia quando il browser riceve HTML significativo. Questo può migliorare diverse metriche rivolte agli utenti—ma può anche peggiorare le cose se il server è lento.
TTFB (Time to First Byte) misura quanto velocemente il server inizia a rispondere. Con l'SSR il server può fare più lavoro (rendering HTML), quindi il TTFB può migliorare (meno round trip del client) o peggiorare (tempo extra di rendering).
FCP (First Contentful Paint) traccia quando l'utente vede il primo testo o immagine. L'SSR spesso aiuta perché il browser riceve HTML pronto da dipingere invece di una shell vuota.
LCP (Largest Contentful Paint) riguarda quando l'elemento principale della pagina (titolo hero, immagine banner, foto prodotto) diventa visibile. L'SSR può ridurre l'attesa per la “pagina reale”—soprattutto quando l'elemento LCP è testo presente nell'HTML iniziale.
CLS (Cumulative Layout Shift) misura la stabilità visiva. L'SSR può aiutare quando produce markup e dimensioni coerenti (per immagini, font e componenti). Può però peggiorare se l'hydration cambia il layout dopo il primo render.
INP (Interaction to Next Paint) riflette la reattività durante le interazioni. L'SSR non risolve automaticamente l'INP perché il JavaScript deve comunque idratare. Puoi però migliorare l'INP inviando meno JS, suddividendo i bundle e differendo script non critici.
Anche se la pagina non è ancora interattiva, vedere contenuti prima migliora la velocità percepita. Gli utenti possono iniziare a leggere, comprendere il contesto e fidarsi che qualcosa sta succedendo.
Se il rendering server è costoso—chiamate al database, alberi di componenti pesanti, middleware lento—l'SSR può aumentare il TTFB e ritardare tutto.
Una solida strategia di caching può ribaltare drasticamente l'esito: metti in cache l'HTML completo per il traffico anonimo, cache le risposte dei dati e usa caching edge/CDN quando possibile. Con il caching, l'SSR può offrire TTFB veloce e FCP/LCP rapidi.
Quando una pagina è renderizzata sul server, il browser riceve subito HTML significativo—intestazioni, testo e layout primario sono già al loro posto. Questo cambia l'esperienza della prima vista: invece di aspettare che il JavaScript si scarichi e costruisca la pagina, gli utenti possono iniziare a leggere quasi subito.
Con il client-side rendering, la prima risposta spesso contiene una shell quasi vuota (un <div id="app"> e script). Su connessioni lente o dispositivi appesantiti, questo può diventare un periodo visibile in cui le persone guardano uno schermo vuoto o parzialmente stilato.
L'SSR aiuta perché il browser può dipingere contenuti reali non appena arriva l'HTML iniziale. Anche se il JavaScript impiega più tempo, la pagina sembra viva: gli utenti vedono il titolo, il copia principale e la struttura, riducendo la percezione di attesa e i rimbalzi iniziali.
L'SSR non elimina il JavaScript—cambia quando è necessario. Dopo che l'HTML è mostrato, la pagina ha comunque bisogno di JS per idratare e rendere funzionanti le parti interattive, come:
L'obiettivo è che gli utenti possano vedere e iniziare a capire la pagina prima che tutta l'interattività sia pronta.
Se vuoi che il primo caricamento sembri veloce, prioritizza l'SSR per i contenuti che gli utenti si aspettano above the fold:
Fatto bene, l'SSR offre agli utenti qualcosa di utile immediatamente—poi il JavaScript aggiunge progressivamente rifiniture e interazioni.
La performance mobile non è solo “desktop ridotto”. Molti utenti navigano su telefoni di fascia media, dispositivi più vecchi, modalità risparmio batteria o in aree con connettività incoerente. L'SSR può rendere queste situazioni molto più veloci perché sposta dove avviene il lavoro più pesante.
Con il client-side rendering, il dispositivo spesso deve scaricare JavaScript, analizzarlo, eseguirlo, recuperare dati e infine costruire la pagina. Su CPU lente, quel passo di “parsing + esecuzione + render” può essere il collo di bottiglia.
L'SSR restituisce HTML che contiene già il contenuto iniziale. Il browser può iniziare a dipingere immediatamente, mentre il JavaScript si carica in parallelo per l'interattività (hydration). Questo riduce la quantità di lavoro pesante che il dispositivo deve fare prima che l'utente veda qualcosa di utile.
I telefoni di fascia bassa faticano con:
Con un HTML pronto da renderizzare, l'SSR può ridurre il tempo in cui il main thread è bloccato prima del primo paint e prima che i contenuti chiave compaiano.
Su connessioni lente, ogni round trip e ogni megabyte in più pesa. L'SSR può ridurre la quantità di JavaScript “critico” per la prima schermata perché la vista iniziale non dipende dall'esecuzione di molto codice solo per mostrare contenuti. Potresti comunque spedire lo stesso JS totale per la funzionalità completa, ma spesso puoi differire codice non essenziale e caricarlo dopo il primo render.
Non affidarti solo ai risultati Lighthouse desktop. Testa con throttling mobile e su dispositivi reali, concentrandoti su metriche che riflettono l'esperienza su dispositivi più deboli (soprattutto LCP e Total Blocking Time).
I motori di ricerca sono molto bravi a leggere HTML. Quando un crawler richiede una pagina e riceve subito HTML testuale e significativo (intestazioni, paragrafi, link), può capire di cosa parla la pagina e iniziare a indicizzarla subito.
Con server-side rendering (SSR), il server restituisce un documento HTML completo per la richiesta iniziale. Questo significa che i contenuti importanti sono visibili nel "view source" HTML, non solo dopo che il JavaScript viene eseguito. Per la SEO, questo riduce la probabilità che un crawler perda informazioni chiave.
Con il client-side rendering (CSR), la prima risposta spesso contiene una shell leggera e un bundle JavaScript che deve scaricarsi, eseguirsi e poi richiedere i dati prima che il contenuto reale appaia.
Questo può generare problemi SEO come:
Google può renderizzare JavaScript per molte pagine, ma non è garantito che sia veloce o affidabile come il parsing dell'HTML puro. Il rendering del JavaScript richiede passaggi e risorse extra e, nella pratica, può significare scoperta più lenta degli aggiornamenti, indicizzazione ritardata o lacune occasionali quando qualcosa nel percorso di rendering si rompe.
L'SSR riduce questa dipendenza. Anche se il JavaScript arricchisce la pagina dopo il caricamento (per l'interattività), il crawler ha già il contenuto core.
L'SSR è particolarmente utile per pagine in cui indicizzare rapidamente e correttamente è importante:
Se il valore principale della pagina è il suo contenuto, l'SSR aiuta a garantire che i motori di ricerca lo vedano immediatamente.
L'SSR non aiuta solo il caricamento—fa sì che le pagine si descrivano chiaramente nel momento in cui vengono richieste. Questo è importante perché molti crawler, strumenti di anteprima link e sistemi SEO si affidano alla risposta HTML iniziale per capire di cosa tratta una pagina.
Al minimo, ogni pagina dovrebbe inviare metadata accurati e specifici nell'HTML:
Con l'SSR, questi tag possono essere renderizzati server-side usando dati reali della pagina (nome prodotto, categoria, titolo articolo) invece di segnaposto generici. Questo riduce il rischio di problemi come “stesso titolo per tutte le pagine” che avvengono quando i metadata vengono iniettati solo dopo l'esecuzione del JavaScript.
Quando qualcuno condivide un link in Slack, WhatsApp, LinkedIn, X o Facebook, lo scraper della piattaforma recupera la pagina e cerca i tag Open Graph (e spesso i Twitter Card). Esempi: og:title, og:description, og:image.
Se questi tag mancano nell'HTML iniziale, l'anteprima può ricadere su qualcosa di casuale—or mostrare nulla. L'SSR aiuta perché la risposta del server contiene già i valori Open Graph corretti per quell'URL, rendendo le anteprime coerenti e affidabili.
I dati strutturati—più comunemente JSON-LD—aiutano i motori a interpretare il contenuto (articoli, prodotti, FAQ, breadcrumb). L'SSR rende più semplice garantire che il JSON-LD sia inviato con l'HTML e sia coerente con il contenuto visibile.
La coerenza è importante: se i dati strutturati descrivono un prezzo o una disponibilità che non corrisponde a ciò che è renderizzato sulla pagina, rischi problemi di idoneità per i rich result.
L'SSR può generare molte varianti di URL (filtri, parametri di tracking, paginazione). Per evitare segnali di contenuto duplicato, imposta un canonical URL per tipo di pagina e assicurati che sia corretto per ogni route renderizzata. Se supporti intenzionalmente più varianti, definisci regole canoniche chiare e applicale in modo coerente nella logica di routing e rendering.
Il rendering lato server sposta lavoro importante dal browser ai tuoi server. Questo è lo scopo—ma anche il compromesso. Invece di far costruire la pagina dal dispositivo di ogni visitatore, la tua infrastruttura ora è responsabile di generare HTML (spesso ad ogni richiesta), oltre a eseguire le stesse chiamate ai dati che l'app richiede.
Con l'SSR, i picchi di traffico possono tradursi direttamente in picchi di CPU, memoria e uso del database. Anche se la pagina sembra semplice, renderizzare template, chiamare API e preparare i dati per l'hydration si accumula. Potresti anche vedere un aumento del TTFB se il rendering è lento o se servizi a monte (come il DB) sono sotto pressione.
Il caching è come l'SSR resta veloce senza pagare il costo completo del render ogni volta:
Alcuni team renderizzano le pagine “all'edge” (più vicino all'utente) per ridurre il round-trip verso un server centrale. L'idea è la stessa: genera HTML vicino al visitatore, mantenendo comunque un unico codebase applicativo.
Metti in cache dove puoi, poi personalizza dopo il caricamento.
Servi una shell cached veloce (HTML + dati critici) e recupera i dettagli specifici dell'utente (info account, offerte basate sulla posizione) dopo l'hydration. Questo mantiene i benefici di velocità dell'SSR evitando che i server ricalcolino tutto per ogni visitatore unico.
L'SSR può rendere le pagine più veloci e indicizzabili, ma introduce anche modalità di errore che non vedi con app puramente client-side. La buona notizia: la maggior parte dei problemi è prevedibile—e risolvibile.
Un errore comune è recuperare gli stessi dati sul server per renderizzare l'HTML, poi recuperarli di nuovo sul client dopo l'hydration. Questo spreca banda, rallenta l'interattività e può aumentare i costi delle API.
Evitare questo pattern incorporando i dati iniziali nell'HTML (o JSON in-line) e riutilizzandoli sul client come stato iniziale. Molti framework supportano questo direttamente—assicurati che la cache client sia inizializzata dal payload SSR.
L'SSR aspetta i dati prima di poter inviare HTML significativo. Se il tuo backend o API terze parti sono lente, il TTFB può aumentare.
Mitigazioni:
È allettante renderizzare tutto server-side, ma risposte HTML enormi possono rallentare il download—soprattutto su mobile—and spostare più avanti il momento del paint.
Mantieni l'output SSR snello: renderizza prima i contenuti above-the-fold, pagina le liste lunghe e evita di iniettare dati eccessivi inline.
Gli utenti possono vedere i contenuti rapidamente, ma la pagina può sembrare “bloccata” se il bundle JS è grande. L'hydration non può completarsi finché il JS non viene scaricato, analizzato ed eseguito.
Fix rapidi: code splitting per route/componenti, differire script non critici e rimuovere dipendenze inutilizzate.
Se il server renderizza una cosa e il client un'altra, puoi avere warning di hydration, shift di layout o UI rotta.
Evita mismatch mantenendo il rendering deterministico: evita timestamp random o ID solo-server nel markup, usa formattazioni locali/timezone coerenti e assicurati che gli stessi feature flag siano attivi su entrambi i lati.
Comprimi le risposte (Brotli/Gzip), ottimizza le immagini e adotta una strategia di caching chiara (CDN + cache server + cache client) per ottenere i benefici dell'SSR senza gli inconvenienti.
SSR (server-side rendering) significa che il server invia HTML che contiene già il contenuto principale della pagina.
Il tuo browser può rendere immediatamente quell'HTML, quindi scaricare dopo il JavaScript per “idratare” la pagina e abilitare l'interattività (pulsanti, form, filtri).
CSR (client-side rendering) normalmente invia una shell HTML minima e si affida al browser per eseguire JavaScript, recuperare i dati e costruire l'interfaccia.
SSR invia HTML significativo subito, quindi gli utenti vedono i contenuti prima, mentre CSR spesso mostra un'area vuota o uno stato di caricamento finché il JavaScript non termina.
L'hydration è la fase in cui il JavaScript collega i gestori di evento all'HTML renderizzato dal server in modo che la pagina diventi interattiva.
Una pagina può sembrare “completa” dopo l'SSR, ma restare poco reattiva finché l'hydration non è terminata—soprattutto se il bundle JS è grande.
L'SSR può migliorare:
Potrebbe o no migliorare TTFB, a seconda del costo del rendering server e delle chiamate ai dati.
L'SSR riduce la fase della “pagina bianca” consegnando subito HTML reale.
Anche se la pagina non è ancora interattiva, gli utenti possono leggere e capire il contenuto prima, riducendo la percezione di attesa e i rimbalzi iniziali.
L'SSR può peggiorare le performance quando il rendering server è lento (componenti pesanti, API lente, query DB costose), il che aumenta il TTFB.
Mitiga con caching (full-page/fragment/CDN), timeout e fallback per dati non critici, e mantenendo l'output SSR snello.
L'SSR aiuta la SEO perché i crawler ricevono subito HTML significativo (intestazioni, paragrafi, link) senza dover eseguire JavaScript.
Questo riduce rischi tipici del CSR, come contenuto iniziale scarso, link interni scoperti in ritardo o gap di indicizzazione se il JS fallisce o scade.
L'SSR rende più facile restituire metadata pagina-specifici nell'HTML iniziale, tra cui:
<title> e meta descriptionQuesto migliora gli snippet nei risultati di ricerca e rende le anteprime social più affidabili, perché molti scraper non eseguono JavaScript.
I problemi più comuni includono:
Soluzioni: riutilizzare i dati iniziali SSR sul client, mantenere il rendering deterministico, suddividere e differire il JS, paginare o limitare l'output SSR above-the-fold.
Usa SSG per pagine per lo più statiche (blog, documentazione, marketing).
Usa SSR per pagine che devono riflettere dati freschi o specifici della request (listings, prezzi, alcune esperienze personalizzate), idealmente con caching.
Usa CSR (o ibrido SSR+CSR) per schermate altamente interattive, dove l'SEO è meno importante e l'interattività domina.