L'infrastruttura web professionale: oltre il semplice dominio

01Un dominio è un indirizzo, non una casa

Quando un'attività decide di «andare online», il primo acquisto è quasi sempre un dominio: nomeazienda.it, qualche euro all'anno, e la sensazione di avere fatto il passo. È un passo vero, ma è il più piccolo. Un dominio è un indirizzo: dice dove andare, non cosa si trova una volta arrivati.

Dietro a quell'indirizzo ci deve essere un server, cioè un computer acceso giorno e notte in un centro dati, che riceve le richieste dei visitatori e risponde con le pagine. È lui la casa. E come per una casa vera, le domande che contano sono altre: quanto è grande, chi ci abita insieme a te, quanto regge quando arrivano cento ospiti nello stesso momento, chi ha le chiavi.

Fra l'indirizzo e la casa c'è un terzo pezzo, il DNS: lo stradario di Internet, che traduce il nome scritto dalle persone nel numero (l'indirizzo IP) che i computer capiscono. Come funzionano nel dettaglio dominio, DNS e certificato HTTPS lo racconto nel capitolo su cosa succede quando qualcuno scrive il tuo indirizzo. Qui interessa il punto d'arrivo: il server.

Per un biglietto da visita online, poche pagine che cambiano una volta all'anno, la casa può essere piccola. Per un portale aziendale, con clienti che entrano col loro accesso, prenotazioni, pagamenti, un gestionale dietro e dati personali da proteggere, la casa è il pezzo che regge tutto. Ed è lì che l'offerta «dominio + hosting a pochi euro» comincia a non bastare più.

02L'hosting condiviso: un condominio con i muri sottili

L'hosting condiviso è la formula più diffusa e più economica: un unico server fisico ospita centinaia, a volte migliaia, di siti di clienti diversi. Ognuno ha la sua cartella e il suo spazio, ma processore, memoria, disco e connessione sono in comune. Il fornitore si occupa di tutto: aggiornamenti, sicurezza del server, posta, pannello di controllo. Tu carichi i file e basta.

È un condominio: costa poco perché le spese si dividono, e qualcuno pensa alle parti comuni. Ma i muri sono sottili. Se il vicino fa una festa, cioè se un altro sito riceve un picco di visite o ha un programma scritto male che consuma tutto il processore, rallenti anche tu, senza avere fatto niente. In gergo si chiama l'effetto del «vicino rumoroso».

Quando l'hosting condiviso va benissimo

Non è un prodotto da disprezzare: è un prodotto da usare per quello per cui è fatto. Va benissimo per:

• un sito vetrina di poche pagine, soprattutto se è fatto di file statici e non interroga un database a ogni visita;
• un blog personale o di una piccola attività, con traffico regolare e senza picchi;
• una pagina di atterraggio per una campagna, o un sito di prova.

I limiti che si scoprono quando è tardi

I problemi arrivano quando al sito si chiede di diventare un'applicazione. Sull'hosting condiviso, di solito:

• non si installa software a piacere: si usa la versione di PHP e di MySQL che offre il fornitore, quando la offre;
• ci sono tetti nascosti su processi contemporanei, memoria per singola richiesta, durata massima di uno script, numero di connessioni al database;
• i lavori pianificati (l'invio delle mail della notte, il backup, la sincronizzazione col gestionale) hanno limiti di frequenza o non ci sono;
• non si può far girare un servizio sempre acceso, per esempio un'API in .NET o in Node.js, o un sistema di notifiche in tempo reale;
• la reputazione dell'indirizzo IP è condivisa: se un vicino manda spam, le mail del tuo dominio possono finire nella posta indesiderata. Ne parlo nel capitolo sulla email aziendale professionale.

03La VPS: un server tuo, senza comprarne uno

Una VPS (Virtual Private Server, server privato virtuale) è una fetta di un server fisico potente, separata dalle altre da un programma chiamato hypervisor. L'hypervisor fa una cosa sola, e la fa con rigore: assegna a ogni fetta la sua quota di processore, di memoria e di disco, e impedisce che una fetta tocchi le risorse dell'altra. Per il sistema operativo che ci gira dentro, quella fetta è un computer intero.

Nella pratica, una VPS si descrive con tre numeri: i vCPU (i processori virtuali), la RAM e lo spazio su disco, quasi sempre su dischi veloci a stato solido. Una configurazione come 2 vCPU, 4 GB di memoria e 40 GB di disco regge con calma un portale aziendale con il suo database, un'API e i lavori pianificati, finché il traffico resta quello di un'attività locale o regionale.

I quattro vantaggi che contano

Il rovescio della medaglia: le chiavi le hai tu

Una VPS «non gestita» è una casa consegnata vuota, con le chiavi in mano. Il fornitore garantisce che la macchina sia accesa e connessa; tutto il resto è responsabilità di chi la amministra:

• gli aggiornamenti di sicurezza del sistema operativo e dei programmi;
• il firewall, cioè quali porte sono aperte verso Internet e quali no;
• i certificati HTTPS e il loro rinnovo automatico;
• i backup, che devono uscire dalla macchina: un backup che vive sullo stesso server sparisce insieme a lui. Lo spiego nel capitolo sul backup aziendale e la regola del 3-2-1;
• il monitoraggio: sapere che il sito è fermo prima che te lo dica un cliente, e un servizio che lo riavvii da solo.

Per questo la vera domanda non è «hosting o VPS», ma «VPS amministrata da chi?». Una VPS lasciata a sé stessa è meno sicura di un buon hosting condiviso. Una VPS amministrata con metodo è la base più solida che una piccola o media azienda possa avere, a una frazione del costo di un server dedicato.

04Linux o Windows Server: come si sceglie il sistema operativo

Sulla VPS va installato un sistema operativo, e la scelta si fa una volta per anni. Le due famiglie sono Linux (nelle sue distribuzioni per server: Ubuntu Server, Debian, AlmaLinux, Rocky Linux) e Windows Server di Microsoft. Non è una questione di gusti: dipende da cosa deve far girare il server.

Linux: la scelta naturale per il web

La grande maggioranza dei server web del mondo gira su Linux, per ragioni molto concrete:

• stabilità: un server Linux ben configurato resta acceso per mesi; gli aggiornamenti di sicurezza si installano quasi sempre senza riavviare;
• leggerezza: senza interfaccia grafica, il sistema occupa poca memoria e lascia le risorse alle applicazioni;
• l'ecosistema del web: PHP, MySQL e MariaDB, PostgreSQL, Python, Node.js, i server web Nginx e Apache nascono e vengono provati prima di tutto su Linux;
• nessuna licenza: il sistema è open source, non si paga per processore né per utente;
• amministrazione da remoto sicura con SSH e chiavi crittografiche, senza desktop remoto esposto su Internet;
• sicurezza a strati: permessi rigorosi su file e processi, firewall integrato, aggiornamenti rapidi da parte di comunità molto grandi.

Il luogo comune da sfatare: «.NET vuol dire Windows»

Fino a qualche anno fa era vero. Oggi no. Dal 2016 Microsoft ha riscritto la sua piattaforma come .NET (prima chiamata .NET Core), che gira nativamente su Linux, ed è la versione su cui si sviluppa tutto il software nuovo. Dal 2017 anche SQL Server esiste per Linux. Un'applicazione moderna in C# può quindi stare su una VPS Linux, con gli stessi vantaggi di leggerezza e costo di un sito in PHP.

Quando Windows Server è davvero indispensabile

• quando c'è software scritto per il vecchio .NET Framework 4.x (WebForms, servizi WCF lato server), che esiste solo per Windows e non si porta a .NET senza riscriverlo in parte;
• quando l'azienda usa Active Directory per gestire utenti, computer e permessi della rete interna: il controller di dominio è un ruolo di Windows Server;
• quando bisogna far girare programmi gestionali che esistono solo per Windows, o far lavorare più persone su un desktop remoto condiviso;
• quando serve qualche funzione di SQL Server che nella versione per Linux non c'è (alcuni servizi accessori, come quelli di reportistica): va verificato caso per caso sulla documentazione di Microsoft.

In tutti gli altri casi, Windows Server aggiunge il costo delle licenze, più memoria occupata dal sistema e una superficie d'attacco più ampia, senza dare niente in cambio a un portale web.

05Il TTFB: quanto aspetta chi bussa alla porta

Il TTFB (Time to First Byte, il tempo fino al primo byte) misura quanto passa da quando il browser chiede una pagina a quando arriva il primo pezzetto della risposta. Non è il tempo di caricamento completo: è il tempo in cui chi visita guarda uno schermo bianco aspettando che il server cominci a parlare.

Google, nella sua guida per gli sviluppatori, indica come buono un TTFB di 0,8 secondi o meno e come scarso uno sopra gli 1,8 secondi. Ogni millisecondo perso qui si somma a tutto quello che viene dopo: un server lento rende lento anche il sito più leggero.

Come si misura, senza programmi speciali

• Nel browser: apri gli Strumenti per sviluppatori (tasto F12), scheda Rete, ricarica la pagina e clicca sulla prima riga. Nella sezione dei tempi la voce «In attesa della risposta del server» è la parte del TTFB che dipende dal server.
• Da riga di comando: curl -o /dev/null -s -w "%{time_starttransfer}\n" https://tuosito.it/ stampa i secondi fino al primo byte.
• Con strumenti pubblici come PageSpeed Insights, che mostrano anche i dati raccolti dai visitatori veri con Chrome.

Cosa abbassa il TTFB, in ordine di efficacia

1. Un database progettato bene: indici giusti e query che chiedono solo quello che serve (lo vediamo fra poco).
2. La cache: una pagina che è uguale per tutti si calcola una volta e si consegna pronta mille volte.
3. Il codice: meno lavoro inutile a ogni richiesta, meno librerie caricate per niente.
4. Risorse riservate: su una VPS il processore non è conteso dai vicini.
5. La vicinanza: un server in Italia o in Europa risponde più in fretta a clienti italiani di uno dall'altra parte dell'oceano.
6. Protocolli moderni: HTTP/2 o HTTP/3 e la cifratura TLS 1.3 tolgono passaggi alla connessione.

Il TTFB è solo la prima delle misure con cui Google valuta l'esperienza di chi visita. Le altre tre, quelle che si vedono nel browser, le spiego nel capitolo sui Core Web Vitals.

06Il database: il magazzino che decide la velocità

Ogni volta che un cliente entra nel suo profilo, cerca una disponibilità o guarda un ordine, il server fa domande al database, cioè al magazzino ordinato in cui stanno tutti i dati. Quanto ci mette a rispondere dipende meno dalla potenza del server e molto di più da come è organizzato il magazzino.

Gli indici: la differenza fra cercare e trovare

Immagina di cercare la parola «fattura» in un libro di mille pagine senza indice analitico: devi sfogliarlo tutto. Con l'indice, vai alla lettera F e trovi il numero di pagina. Un indice di database fa esattamente questo: invece di leggere tutte le righe di una tabella per trovare i clienti di una città, va dritto a quelle giuste.

Gli indici però non sono gratis: occupano spazio e rallentano un poco le scritture, perché a ogni nuovo dato vanno aggiornati. Si mettono sulle colonne che si usano davvero per cercare, filtrare e collegare, non su tutte per sicurezza. Decidere quali è lavoro di progettazione, e si fa guardando le domande vere che il portale farà.

Le query: chiedere solo quello che serve

Una query è la domanda che il programma fa al database. Lo stesso risultato si può chiedere in modi molto diversi, e la differenza di velocità può essere di cento volte. Gli errori più comuni, che si trovano in tanti siti lenti:

• chiedere tutte le colonne (SELECT *) quando ne servono tre, trasferendo dati inutili a ogni richiesta;
• il problema detto «N+1»: per mostrare cinquanta ordini, il codice fa una domanda per l'elenco e poi cinquanta domande separate, una per ogni cliente, invece di una sola domanda che unisce le due tabelle;
• filtrare nel programma invece che nel database: scaricare diecimila righe per mostrarne dieci;
• non guardare mai il registro delle query lente né il piano di esecuzione (EXPLAIN), che dicono esattamente dove il database sta faticando.

Sono errori che non si vedono finché i dati sono pochi, e che esplodono quando l'attività cresce: il portale che a gennaio rispondeva in un decimo di secondo, a dicembre ne impiega tre. Per questo la qualità del codice sorgente pesa sulle prestazioni del server quanto la potenza della macchina, e spesso di più: ne parlo nel prossimo capitolo, dedicato al valore di un professionista del codice e ai limiti di intelligenza artificiale e page builder.

07Come si sceglie, caso per caso

Mettendo insieme tutto quello che abbiamo visto, la scelta dell'infrastruttura si riduce a poche domande oneste su cosa farà il portale oggi e fra due anni.

L'infrastruttura è la spina dorsale di tutto quello che viene dopo: il portale con le prenotazioni e la PWA, la posta aziendale, il sito che deve farsi trovare. Un server scelto bene non si nota mai. Uno scelto male si nota sempre, di solito il giorno di massimo lavoro.

Domande frequenti

Fonti

1. web.dev (Google), «Time to First Byte (TTFB)»: definizione, fasi e soglie di 0,8 e 1,8 secondi.
2. Microsoft Learn, «Installare .NET in Linux»: le distribuzioni Linux supportate dal .NET moderno.
3. Microsoft Learn, «Panoramica di SQL Server in Linux»: SQL Server per Linux e le funzioni disponibili.
4. Manuale di MySQL, «How MySQL Uses Indexes»: come gli indici evitano la lettura completa delle tabelle.
5. Wikipedia, «Virtual private server»: la virtualizzazione e l'hypervisor.

Capitolo aggiornato a ottobre 2026. Le soglie e le compatibilità citate vengono dalla documentazione ufficiale dei produttori; i tempi delle tavole sono esempi per mostrare le proporzioni, non misure di un sito in particolare.