Fidati dei benchmark che misurano ciò che fa davvero il tuo sito: il tempo di risposta di una pagina dinamica con alcune richieste simultanee, i percentili p95 e p99, le operazioni casuali su disco a blocchi piccoli e la stabilità nelle diverse ore del giorno. La lettura sequenziale del disco, le richieste al secondo su una pagina statica o una singola esecuzione di un test CPU su un server vuoto mostrano il potenziale dell’hardware, non la velocità del tuo sito. Sul nostro banco di prova lo stesso disco ha dato da 20 a 7241 MB/s a seconda del test, e lo stesso nginx ha servito una pagina statica 294 volte più velocemente di una semplice pagina PHP.
Come abbiamo verificato
L’11.11.2026 abbiamo eseguito i benchmark più comuni su un banco di prova: container Ubuntu 24.04.5, 2 vCPU (Intel Xeon 2,1 GHz), 7 GB di RAM, disco virtuale; fio 3.36, sysbench 1.0.20, ioping 1.3, wrk 4.1.0, nginx 1.24.0, PHP-FPM 8.3.6. Server e client giravano sulla stessa macchina, quindi la rete non è inclusa in questi numeri. È un banco di prova, non i server di RichHost o di un altro provider: contano non i valori assoluti ma la differenza tra i test. Le soglie di Core Web Vitals e TTFB provengono da web.dev.
Disco: da 20 a 7241 MB/s sullo stesso server
Il numero più popolare nella pubblicità dell’hosting è la velocità del disco in megabyte al secondo. Abbiamo eseguito quattro test sullo stesso file da 1 GB:
$ dd if=/dev/zero of=test.bin bs=1M count=1024 conv=fdatasync
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.0949 s, 981 MB/s
$ fio --name=seqread --filename=test.bin --rw=read --bs=1M --direct=1 --ioengine=libaio --iodepth=16 --runtime=15 --time_based --group_reporting
READ: bw=6905MiB/s (7241MB/s)
$ fio --name=rand4k --filename=test.bin --rw=randread --bs=4k --direct=1 --ioengine=libaio --iodepth=1 --runtime=15 --time_based
read: IOPS=27.3k, BW=106MiB/s (112MB/s)(1597MiB/15001msec)
| 99.00th=[ 60], 99.50th=[ 75], 99.90th=[ 161], 99.95th=[ 273],
$ fio --name=rand4kw --filename=test.bin --rw=randwrite --bs=4k --direct=1 --ioengine=libaio --iodepth=1 --fsync=1 --runtime=15 --time_based
write: IOPS=4946, BW=19.3MiB/s (20.3MB/s)(290MiB/15001msec); 0 zone resets
| 99.00th=[ 131], 99.50th=[ 169], 99.90th=[ 881], 99.95th=[ 1844],
| Test | Cosa simula | Risultato |
|---|---|---|
| fio, lettura sequenziale a blocchi da 1 MB, coda 16 | Copia di file grandi, video | 7241 MB/s |
| dd, scrittura sequenziale di 1 GB con fdatasync | Scrittura di un archivio o di un backup | 981 MB/s |
| fio, lettura casuale 4 KB, coda 1 | Lettura del database e dei file piccoli del CMS | 112 MB/s (27,3 mila IOPS) |
| fio, scrittura casuale 4 KB con fsync dopo ogni operazione | Transazioni del database, sessioni, cache | 20 MB/s (4,9 mila IOPS) |
Tra la prima e l’ultima riga c’è un fattore superiore a 350, mentre il 99% delle letture casuali si è concluso entro 60 µs. 7241 MB/s per un singolo disco virtuale includono probabilmente la cache dell’hypervisor, ed è proprio per questo che un numero senza metodologia non significa nulla. Un sito con database vive nella riga della scrittura casuale con fsync, non in quella della lettura sequenziale. L’altra metà del problema è quante operazioni su disco servono a ogni pagina, ed è proprio ciò che riduce l’ottimizzazione del database con indici, query più leggere e cache. Per una misura rapida della latenza esegui ioping -c 20 .: sul banco, 145 µs in media.
CPU: una sola esecuzione su un server vuoto
I risultati di Sysbench o Geekbench sulla pagina di un provider sono di solito ottenuti su un server nuovo senza clienti. Abbiamo eseguito tre volte sysbench cpu a thread singolo su una macchina libera e poi altre tre volte mentre due thread dello stesso test in background occupavano entrambe le vCPU, come farebbe un vicino attivo:
$ sysbench cpu --threads=1 --time=10 run | grep "events per second"
events per second: 2412.24
events per second: 2432.10
events per second: 2431.77
# mentre due thread sysbench in background occupano entrambe le vCPU
events per second: 1518.50
events per second: 1564.40
events per second: 1529.42
Il risultato è sceso in media da 2425 a 1537 eventi al secondo, cioè del 37%, con lo stesso processore. Un benchmark della CPU mostra il tetto dell’hardware, non la tua quota, e quella quota dipende dai vicini e dai limiti del piano. Come più siti condividono un server lo spiega la nostra guida che cos’è l’hosting condiviso, mentre cosa succede quando un sito raggiunge i limiti di risorse del piano è descritto nell’articolo sull’errore 508.
HTTP: richieste al secondo per contenuti statici e per PHP
Il terzo trucco diffuso è mostrare quante richieste al secondo (RPS) regge un server. Abbiamo lanciato wrk con 20 connessioni simultanee per 15 secondi contro un file HTML statico e contro una semplice pagina PHP che imita un CMS senza cache (circa 9 ms di calcolo e 5 ms di attesa, come una query al database):
$ wrk -t2 -c20 -d15s --latency http://127.0.0.1:8661/static.html
Latency 479.79us 1.05ms 28.72ms 91.31%
50% 135.00us
99% 4.30ms
Requests/sec: 92317.17
$ wrk -t2 -c20 -d15s --latency http://127.0.0.1:8661/page.php
Latency 63.59ms 9.79ms 116.39ms 68.10%
50% 62.20ms
99% 91.91ms
Requests/sec: 313.72
92.317 richieste al secondo contro 314: nginx ha servito il file statico 294 volte più velocemente, quindi gli RPS di una pagina statica non dicono nulla su WordPress o su un negozio online. Le stesse righe nascondono un secondo dettaglio: per il file statico la latenza media è 0,48 ms, ma il p99 arriva a 4,3 ms, quasi 9 volte di più. La media nasconde le richieste lente, quindi guarda p95 e p99. Cosa rende davvero più veloce una pagina dinamica, misurato anche questo su un banco di prova, lo spieghiamo nella guida per velocizzare WordPress.
Cinque trucchi che abbelliscono i numeri
- Server vuoto. Il test è stato fatto prima dell’arrivo dei clienti, come la nostra prima esecuzione di sysbench.
- Operazioni sequenziali invece che casuali. Megabyte al secondo a blocchi grandi invece di IOPS a blocchi piccoli con fsync.
- Test dall’interno del data center. Client e server sono vicini, quindi nel tempo di risposta non c’è la rete fino al tuo pubblico.
- Cache. La pagina di test viene servita dalla cache, mentre la prima richiesta non in cache è molte volte più lenta.
- Media invece dei percentili. La media nasconde la coda delle risposte lente.
Cosa misurare da soli e con quali soglie
Ai tuoi visitatori non interessano gli IOPS, ma quanto velocemente si apre la pagina. Secondo web.dev un TTFB è buono fino a 0,8 secondi e scarso oltre 1,8 secondi; per i Core Web Vitals i valori buoni sono LCP fino a 2,5 secondi, INP fino a 200 ms e CLS fino a 0,1, valutati al 75° percentile delle visite reali (web.dev, verificato l’11.11.2026). L’ordine dei controlli:
- TTFB dalla rete del tuo pubblico. Esegui
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com/10-20 volte e confronta la mediana. Se il valore è alto, la nostra guida per diagnosticare un sito lento mostra dove cercare. - Latenza del disco, se hai SSH.
ioping -c 20 .e un breve fio con scrittura casuale 4 KB e fsync su un file piccolo. - Pagina dinamica sotto carico. wrk o hey con alcune connessioni su una copia del sito, guardando p95 e p99.
- Stabilità nell’arco di una settimana. Misure del TTFB ogni mezz’ora o un monitoraggio del server con un grafico del tempo di risposta mostreranno le ore in cui il server rallenta.
- Dati sul campo. Il rapporto Core Web Vitals in Search Console o CrUX mostra ciò che vedono i visitatori reali.
I test lunghi con centinaia di connessioni su un hosting condiviso caricano anche i vicini, quindi concordali prima con il supporto. L’accesso SSH è incluso in tutti i piani RichHost: una volta che sai connetterti via SSH, puoi eseguire curl, ioping e brevi misure sul tuo account; cosa include ogni piano è indicato nella pagina delle tariffe di hosting.
Se X, fai Y
| Cosa ti hanno mostrato | Cosa fare |
|---|---|
| Velocità del disco in MB/s (dd, lettura sequenziale) | Chiedi o esegui fio con scrittura casuale 4 KB e fsync, guarda IOPS e latenza |
| Punteggio Geekbench o sysbench | Chiedi dei limiti CPU del piano e del numero di account per server; misura in orario lavorativo |
| RPS di una pagina statica | Testa una pagina dinamica senza cache con più connessioni |
| TTFB misurato nello stesso data center | Misura con curl dalla rete del tuo pubblico, 10-20 volte, mediana |
| Tempo di risposta medio | Chiedi p95 e p99 |
| Niente SSH | TTFB con curl, monitoraggio della disponibilità e rapporto Core Web Vitals |
Domande frequenti
Ci si può fidare dei benchmark pubblicati sul sito di un provider?
Come riferimento, se indicano comando, parametri, dimensione del file, data e carico del server. Senza metodologia il numero non è confrontabile con nessun altro: il nostro disco ha dato sia 20 sia 7241 MB/s.
Quanto dovrebbe essere il TTFB?
Secondo web.dev un buon TTFB arriva fino a 0,8 secondi, uno scarso supera 1,8 secondi. È un riferimento per server e rete insieme, non una metrica dei Core Web Vitals.
Perché il mio test dà una velocità diversa da quella del provider?
Un altro test, un’altra rete, la cache, i vicini e l’ora del giorno. Sul banco, il solo carico in background di un vicino ha ridotto il risultato di sysbench del 37%.
Cosa conta di più: il tempo di risposta medio o il p99?
p95 e p99, perché sono le risposte lente quelle che i visitatori notano. La media può restare bassa anche quando una richiesta su cento impiega molto più tempo.
