Quando un’azienda mi chiede di sviluppare una web app su misura, una delle prime decisioni tecniche che devo prendere riguarda il rendering: come e dove viene generata l’interfaccia che l’utente vede nel browser. È una scelta che sembra un dettaglio da sviluppatori, ma in realtà ha un impatto diretto su SEO, velocità di caricamento e costi di manutenzione. In questo articolo spiego come valuto SSR (server-side rendering) e SPA (single page application) e perché non esiste una risposta valida per tutti i progetti.
Cos’è una SPA e quando la scelgo
Una SPA carica una sola pagina HTML iniziale e poi gestisce tutta la navigazione via JavaScript nel browser, senza ricaricare il server ad ogni click. È l’approccio che uso per applicazioni gestionali interne, dashboard e strumenti operativi dove:
- gli utenti sono autenticati e il contenuto non deve essere indicizzato da Google;
- servono interazioni fluide e immediate, tipo desktop app (drag&drop, filtri live, aggiornamenti in tempo reale);
- il traffico arriva quasi sempre da utenti già loggati, non da ricerca organica.
È lo schema che ho usato per apicco.app, il gestionale che ho sviluppato per aziende di servizi: una volta dentro, l’utente naviga tra clienti, preventivi e fatture senza percepire nessun ricaricamento di pagina. Non serve SEO, serve reattività.
Cos’è il rendering lato server e quando conviene
Con SSR, invece, il server genera l’HTML già pronto (con i dati veri, non solo un guscio vuoto) prima di inviarlo al browser. È la scelta giusta quando la web app deve anche essere trovata su Google:
- siti vetrina, portali e piattaforme editoriali che vivono di traffico organico;
- pagine pubbliche che devono aprirsi istantaneamente anche su connessioni lente o mobile;
- contenuti che cambiano spesso e devono comparire subito nei motori di ricerca senza aspettare che il JavaScript finisca di eseguire.
Un esempio concreto è stiricrestine.ro, il portale di notizie che gestisco: ogni articolo deve essere indicizzato in fretta e caricarsi in pochi decimi di secondo, anche per un lettore che arriva da una ricerca su smartphone con connessione debole. Lì il rendering lato server non è un’opzione, è un requisito.
Il vero criterio di scelta: chi legge la pagina
La domanda che mi pongo non è “SSR o SPA” in astratto, ma: chi deve leggere questa pagina, e come ci arriva?
Scelgo SSR quando:
- la pagina deve posizionarsi su Google (SEO reale, non solo teorico);
- il pubblico è anonimo e arriva da ricerca, social o link esterni;
- la velocità del primo caricamento (First Contentful Paint) è una priorità di business.
Scelgo SPA quando:
- l’utente è autenticato e usa l’app per minuti o ore, non per una singola visita;
- servono interazioni complesse senza continui ricaricamenti;
- l’indicizzazione non è rilevante perché il contenuto è privato.
Molti progetti reali, come indelio.eu o tandemops.app, in realtà mescolano i due approcci: una landing pubblica renderizzata lato server per farsi trovare, e un’area applicativa interna in SPA per la parte operativa. Non è un compromesso, è ingegneria: si usa lo strumento giusto per ogni sezione del prodotto.
Lo stack tecnico che uso
Per il frontend lavoro principalmente con framework moderni basati su React, che oggi permettono di scegliere il tipo di rendering pagina per pagina invece di doverlo decidere una volta per tutto il progetto. Sul backend uso Node.js o soluzioni PHP a seconda del contesto, database relazionali (PostgreSQL, MySQL/MariaDB) per i dati strutturati, e infrastruttura containerizzata con Docker su server che gestisco direttamente (Nginx o Apache come reverse proxy, certificati SSL automatici, HestiaCP o Portainer per l’orchestrazione). Questo mi permette di ottimizzare ogni progetto per il suo caso d’uso reale, non per una scelta ideologica di stack.
Errori comuni che vedo commettere
Nel valutare progetti già esistenti di clienti, mi capita spesso di trovare scelte fatte “di default” senza considerare davvero chi userà la pagina. Alcuni errori ricorrenti:
- usare una SPA pura per un sito vetrina: il contenuto arriva al browser come un guscio vuoto che si riempie solo dopo il JavaScript, e Google (o un utente con connessione lenta) vede una pagina bianca per secondi preziosi;
- forzare il rendering server-side su ogni pagina di un gestionale interno: si aggiunge carico al server per generare HTML che nessun motore di ricerca leggerà mai, rallentando l’esperienza degli utenti autenticati senza alcun beneficio SEO;
- non separare le due esigenze nello stesso prodotto: trattare la landing pubblica e l’area riservata come un blocco unico, quando in realtà hanno requisiti opposti e vanno progettate diversamente fin dall’architettura.
Riconoscere questi pattern in fase di analisi, prima di scrivere una riga di codice, è spesso ciò che fa la differenza tra una web app che funziona bene sia per il marketing che per l’operatività quotidiana, e una che va rifatta a metà.
Perché questa scelta conta per la tua azienda
Sbagliare rendering ha costi concreti: un sito vetrina fatto solo in SPA senza SSR può non comparire mai su Google nonostante contenuti ottimi; una dashboard interna fatta con SSR completo può risultare più lenta e macchinosa di quanto serva. Valutare questo aspetto fin dalle prime fasi di progettazione di una web app aziendale evita di dover rifare il lavoro dopo mesi, quando i costi di migrazione sono molto più alti e coinvolgono non solo il codice ma anche la perdita di posizionamento SEO già acquisito o di dati di utilizzo storici.
Un partner che valuta anche questi dettagli
Sviluppo e gestisco web app e siti aziendali end-to-end: dalla scelta architetturale iniziale (SSR, SPA o ibrido) fino all’hosting, alla sicurezza e alla manutenzione continua. Che tu debba lanciare un sito che deve farsi trovare su Google o un gestionale interno veloce da usare, posso aiutarti a scegliere la strada giusta fin dal primo giorno.
Vuoi discutere quale approccio è più adatto al tuo progetto? Scrivimi tramite la pagina di contatto su cornelcaba.com, dove trovi anche altri esempi dei miei progetti attivi come apicco.app e stiricrestine.ro.
