SSR, SSG, ISR: cosa chiedere a chi ti fa il sito

La titolare di un'agenzia di viaggi di Catania mi ha girato un preventivo lo scorso autunno con una domanda sola: "ma tutto questo mi serve davvero?". Nel documento c'erano tre pagine di lavoro, un prezzo quasi doppio rispetto a quello che si aspettava, e una parola che tornava di continuo, server-side rendering, insieme a due sigle, SSG e ISR.

Non aveva bisogno di diventare tecnica, aveva bisogno di capire una cosa: stava pagando qualcosa di utile o solo parole che suonano moderne?

SSR, SSG e ISR sono tre modi di costruire e mostrare un sito. Sembrano dettagli da programmatori, ma decidono quanto è veloce, quanto costa mantenerlo e quanto Google riesce a leggerlo. Te li traduco uno per uno, senza gergo, e ti dico cosa chiedere prima di firmare.

Rendering è solo la parola tecnica per dire "costruire la pagina che vedi". Ogni pagina web è codice che va trasformato in testo, immagini e pulsanti, e la domanda vera è una: dove e quando avviene questa trasformazione.

Ci sono due momenti possibili. La pagina può essere costruita in anticipo, prima ancora che qualcuno la apra, oppure sul momento, quando arriva la richiesta. Tutta la differenza tra SSR, SSG e ISR sta qui.

Esiste anche un terzo caso, che è la radice di molti problemi: la pagina costruita dentro il browser dell'utente, dopo che il sito ha scaricato una montagna di codice. È il modo in cui funzionano molte applicazioni React fatte senza attenzione alla SEO. Il visitatore aspetta, e Google, quando passa, trova una pagina quasi vuota e fatica a capire cosa contiene. Le tre sigle di cui parliamo servono, tra le altre cose, a evitare proprio questo.

Dietro le sigle ci sono tre scelte semplici. Te le do nell'ordine che ha senso per chi decide, dalla più economica alla più impegnativa.

• SSG, le pagine stampate in anticipo. Il sito viene costruito una volta sola, quando lo pubblichi, e ogni pagina diventa un file pronto da servire. Come un volantino stampato: velocissimo da consegnare, uguale per tutti. È la scelta giusta per siti vetrina, studi professionali, portfolio e blog. Questo sito che stai leggendo funziona così.
• SSR, la pagina cucinata sul momento. A ogni visita il server costruisce la pagina da capo e la consegna già pronta. Serve quando il contenuto deve cambiare a ogni richiesta o per singolo utente, per esempio un'area riservata o dati in tempo reale. In cambio devi tenere un server sempre acceso, che è un costo di mantenimento in più.
• ISR, la via di mezzo. Le pagine restano statiche e veloci come nell'SSG, ma si rigenerano da sole ogni tanto per aggiornarsi. È pensato per chi ha molti contenuti che cambiano, ma non a ogni secondo: un catalogo di offerte, le schede di un e-commerce, un listino prezzi.

Nessuna delle tre è "migliore" in assoluto. Sono attrezzi diversi, e il punto è scegliere quello giusto per il tuo lavoro, non il più costoso.

Qui sta la parte che al tuo fornitore conviene farti saltare, perché è quella che ti fa risparmiare. La regola pratica è più semplice di quanto sembri.

• Sito vetrina, studio, portfolio, blog. Pagine che cambiano di rado. Vai di SSG e non pensarci più: veloce, economico, senza server da tenere in piedi.
• Catalogo o offerte che cambiano spesso. Un'agenzia di viaggi, un e-commerce medio, un listino aggiornato di frequente. Qui SSG o ISR coprono quasi tutto: statico dove puoi, rigenerazione automatica dove serve.
• Contenuti diversi per ogni utente o in tempo reale. Area riservata, prezzi personalizzati, disponibilità aggiornata al secondo. È l'unico caso in cui l'SSR guadagna davvero il suo costo.

La maggior parte dei siti di una PMI vive benissimo con l'SSG, spesso con un pizzico di ISR dove i contenuti si muovono. L'SSR proposto "perché è la tecnologia del momento", su un sito che cambia una volta al mese, è complessità che paghi due volte: alla costruzione e poi ogni mese per mantenerla.

Non devi saper scrivere codice per fare le domande giuste. Ne bastano quattro, e le risposte ti dicono più della metà tecnica del preventivo.

• Le pagine principali sono già nel codice o si costruiscono nel browser? È la domanda che protegge la tua visibilità su Google. Se la risposta è "si costruiscono nel browser", chiedi come garantiscono che i motori di ricerca leggano lo stesso i contenuti.
• Perché questa strategia e non una più semplice? Deve esserci un motivo legato al tuo caso, non alla moda. Se la risposta è "perché è moderno" o "perché lo usano tutti", è una bandiera rossa.
• Serve un server sempre acceso? Quanto costa tenerlo? L'SSR ha un costo di gestione ricorrente che l'SSG non ha. Meglio saperlo prima, non alla prima fattura di hosting.
• Quando aggiorno un'offerta o un prezzo, quanto ci mette a comparire online? Ti dice se il sistema scelto regge il ritmo con cui cambi i contenuti, senza farti dipendere da lui per ogni modifica.

Un fornitore serio risponde a queste domande con esempi concreti sul tuo progetto. Se le liquida con sigle e "fidati", il problema non è la tecnologia, è come lavora. Su questo ho scritto una guida a parte su come scegliere un web developer.

L'agenzia di viaggi di Catania non aveva bisogno di un sito costruito sul momento a ogni visita. Aveva pagine di destinazioni che aggiorna qualche volta al mese e un pacchetto di offerte che cambia più spesso.

Con quelle quattro domande ha capito che le bastavano SSG per le pagine fisse e ISR per le offerte. Ha rifatto il preventivo su quella base, ha pagato circa un terzo in meno e si è tolta un server da mantenere che non le sarebbe mai servito.

Non ha imparato a programmare, ha imparato a chiedere. E queste tre sigle, tolte dal gergo, restano una scelta pratica: costruire in anticipo quello che cambia di rado, sul momento solo quello che deve.

Se hai un preventivo pieno di sigle e non sai se stai pagando il giusto, richiedi una consulenza.

Ti rispondo io, non un form automatico.

Questo articolo fa parte della serie SEO e Performance.

• SEO tecnico: quello che il tuo sviluppatore dovrebbe sapere
• Core Web Vitals: cosa sono e perché Google ti penalizza
• Perché il tuo sito è lento
• Schema markup: come apparire meglio su Google
• Sitemap e robots.txt: le basi che molti sbagliano in pubblicazione