Quando un sito è lento, una delle prime domande è se la colpa sia dell’hosting. A volte lo è, a volte no, e spesso la risposta è «in parte». L’hosting determina la velocità con cui il server risponde, la capacità di reggere molti visitatori contemporaneamente e la disponibilità di strumenti come la cache di pagina e la cache degli oggetti. Non determina invece il peso delle immagini, la quantità di JavaScript o la struttura delle pagine, che dipendono dal sito stesso.
Capire cosa l’hosting può e non può fare è importante sia per chi deve scegliere un servizio sia per chi valuta se cambiarlo. In questo articolo vediamo quali aspetti dell’hosting incidono sulle Core Web Vitals, come si differenziano i principali modelli, dal condiviso al cloud, e come confrontare offerte diverse senza farsi ingannare da test poco rappresentativi.
Cosa dipende dall’hosting
Il legame principale tra hosting e Core Web Vitals passa per il TTFB, il tempo che il server impiega a iniziare a rispondere. Il TTFB è la base di tutte le altre metriche di caricamento: l’LCP non può arrivare prima che l’HTML sia arrivato, e un TTFB di un secondo lascia solo un secondo e mezzo per tutto il resto se si vuole restare nella soglia dei 2,5 secondi. La soglia considerata buona per il TTFB, al 75° percentile, è di 800 millisecondi.
Il TTFB dipende da diversi aspetti dell’hosting. La velocità del processore, soprattutto quella del singolo core, perché la generazione di una pagina WordPress è un’elaborazione in gran parte sequenziale. La versione di PHP e la configurazione della sua cache del codice compilato, OPcache. La velocità del database e dei dischi, oggi quasi sempre a stato solido, ma con prestazioni molto diverse. La disponibilità di cache: una cache di pagina a livello di server e una cache degli oggetti come Redis. E la posizione del centro dati rispetto agli utenti, con la qualità della rete che lo collega, che determina il costo di ogni viaggio di andata e ritorno, come abbiamo visto nell’articolo su DNS, TLS e connessioni.
C’è poi un aspetto che i test isolati non mostrano: la capacità sotto carico. Un server che risponde in 300 millisecondi a una richiesta alla volta può impiegarne tre secondi quando riceve cinquanta richieste contemporanee. Il numero di processi PHP disponibili, spesso chiamati PHP worker, la memoria e la potenza di calcolo riservate al sito decidono quando il servizio inizia a rallentare.
Cosa non dipende dall’hosting
Altrettanto importante è sapere cosa l’hosting non risolve. Un’immagine da tre megabyte resta di tre megabyte su qualsiasi server; due megabyte di JavaScript richiedono lo stesso tempo di esecuzione sullo smartphone dell’utente; un banner che sposta il contenuto genera CLS indipendentemente da dove è ospitato il sito. Molti siti cambiano hosting sperando di risolvere problemi che sono nel front-end, e ottengono un TTFB migliore con un LCP quasi invariato. Prima di cambiare, conviene capire quale parte del tempo di caricamento dipende dal server e quale dal browser, per esempio con la scomposizione dell’LCP in PageSpeed Insights: se il TTFB è una piccola frazione, il problema è altrove.
I modelli di hosting
Le offerte sul mercato si possono raggruppare in quattro grandi modelli, con confini sempre più sfumati. Dentro ciascuno le differenze di qualità tra un fornitore e l’altro sono enormi, per cui le caratteristiche che seguono sono tendenze, non regole.
Hosting condiviso
Nell’hosting condiviso molti siti convivono sullo stesso server e ne condividono le risorse. È la soluzione più economica e più semplice: il fornitore gestisce tutto e il cliente si occupa solo del sito. Il limite principale è l’imprevedibilità: le risorse disponibili per ciascun sito sono limitate e dipendono anche dall’attività degli altri siti, i cosiddetti vicini rumorosi. Le prestazioni possono essere buone in condizioni normali e crollare nei momenti di carico. Le formule «risorse illimitate» vanno lette con attenzione: i limiti esistono sempre, spesso espressi come processi contemporanei, utilizzo della CPU o operazioni sul disco.
Un buon hosting condiviso, con server moderni, una cache di pagina a livello di server e pochi siti per macchina, può essere adeguato per siti vetrina e blog con traffico contenuto. Diventa stretto per negozi online, siti con molti utenti collegati o con picchi di traffico prevedibili.
Server virtuale privato
Un VPS offre risorse riservate, processore, memoria e disco, su una macchina virtuale dedicata. Le prestazioni sono prevedibili e il controllo è completo: si sceglie il sistema operativo, il server web, la versione di PHP, la configurazione delle cache. Il rovescio della medaglia è la gestione: nella versione non gestita, installazione, configurazione, aggiornamenti di sicurezza, backup e monitoraggio sono a carico del cliente. Un VPS potente ma configurato male, senza cache e con parametri predefiniti, può essere più lento di un buon hosting condiviso.
Hosting WordPress gestito
Gli hosting gestiti specializzati in WordPress offrono un ambiente già ottimizzato: cache di pagina a livello di server, spesso una cache degli oggetti, versioni recenti di PHP, aggiornamenti e backup automatici, un supporto che conosce la piattaforma. Per molti siti professionali sono il miglior compromesso tra prestazioni e semplicità. I limiti vanno cercati nei dettagli delle offerte: numero di PHP worker per piano, che determina quante richieste dinamiche il sito può gestire contemporaneamente; limiti di traffico o di visite; plugin non consentiti; costi aggiuntivi per le risorse extra.
Cloud scalabile
Le infrastrutture cloud permettono di aumentare le risorse al crescere del carico, anche automaticamente, e di distribuire il sito su più server e più regioni. Sono la soluzione per siti con grandi volumi di traffico o picchi molto marcati, ma richiedono competenze specifiche per essere progettate e gestite, e i costi possono crescere in modo meno prevedibile. Esistono anche servizi gestiti costruiti sopra le infrastrutture cloud, che ne offrono la scalabilità con una gestione semplificata.
La differenza si vede sotto carico
Il modo più comune di confrontare due hosting, cioè un test di PageSpeed Insights sulla home page, è anche il meno significativo. La home è quasi sempre in cache, e un test isolato misura un server che risponde a una sola richiesta. In queste condizioni quasi ogni hosting sembra veloce. Le differenze emergono sulle pagine che non possono essere messe in cache, come carrello, checkout, area riservata e ricerca, e quando molti utenti le richiedono contemporaneamente.
Un test di carico, che simula molti utenti contemporanei, è il modo più affidabile di valutare un hosting, e lo vedremo in dettaglio nell’articolo dedicato ai picchi di traffico. Anche senza strumenti specifici, però, qualche verifica è alla portata di tutti: misurare il TTFB della bacheca di amministrazione e delle pagine dinamiche, in orari diversi della giornata e da una località vicina agli utenti; controllare i dati di Search Console e del Chrome UX Report nelle settimane di maggior traffico; chiedere al fornitore quanti processi PHP sono disponibili e cosa succede quando si esauriscono.
Va ricordato che i confronti pubblicati, anche quelli dei fornitori, misurano spesso configurazioni diverse, come abbiamo visto nell’articolo quando il benchmark non vede lo stesso sito: il confronto utile è quello fatto sul proprio sito, con le proprie pagine e i propri plugin.
Le domande da fare a un fornitore
- Dove si trovano i server? Per un pubblico italiano, in Italia o nell’Europa vicina; per un pubblico internazionale, con una CDN o più regioni.
- Quali risorse sono garantite? Processore, memoria, numero di processi PHP, limiti di utilizzo, e cosa succede quando vengono superati.
- Che cache è disponibile? Cache di pagina a livello di server, cache degli oggetti, integrazione con WordPress per lo svuotamento automatico.
- Quale stack software? Versioni di PHP e del database, server web, supporto a HTTP/2 e HTTP/3, compressione Brotli.
- Come si gestiscono i picchi? Possibilità di aumentare le risorse temporaneamente, tempi e costi.
- Chi si occupa di cosa? Aggiornamenti, sicurezza, backup, monitoraggio, supporto in caso di problemi di prestazioni.
L’hosting e la CDN
Una CDN non sostituisce un buon hosting, ma può compensarne alcuni limiti. Servendo le risorse statiche e, se configurata per farlo, le pagine in cache da nodi vicini agli utenti, riduce il carico sul server d’origine e i tempi di rete per i visitatori lontani. Non aiuta, invece, per le pagine dinamiche, che devono comunque essere generate dal server. Anche qui vale la distinzione tra CDN e cache delle pagine vista nell’articolo su Cloudflare: attivare una CDN su un hosting lento migliora la distribuzione delle immagini, ma non accelera il carrello di un negozio.
Lo stack va mantenuto
Le prestazioni di un hosting non sono fisse nel tempo. Ogni nuova versione di PHP ha portato miglioramenti di velocità, e un sito fermo su una versione vecchia di anni rinuncia a guadagni gratuiti, oltre a esporsi a problemi di sicurezza. Lo stesso vale per il database, il server web e le librerie di sistema. Molti hosting permettono di cambiare versione di PHP dal pannello di controllo: prima di farlo conviene verificare la compatibilità di tema e plugin su un ambiente di prova, ma rimandare l’aggiornamento per anni costa sia in prestazioni sia in sicurezza.
Un esempio concreto aiuta a capire l’ordine di grandezza. Un negozio online su un hosting condiviso economico ha un TTFB di circa 400 millisecondi sulle pagine in cache e di 1,8 secondi su carrello e checkout, che negli orari serali sale oltre i tre secondi. Il passaggio a un hosting gestito con cache di pagina a livello di server, cache degli oggetti e un numero adeguato di processi PHP porta le pagine in cache sotto i 100 millisecondi e le pagine dinamiche intorno ai 500, senza variazioni significative nelle ore di punta. Il resto del sito non cambia: immagini, script e struttura sono gli stessi, e i miglioramenti successivi dell’LCP dipenderanno da interventi sul front-end.
Quando cambiare
Cambiare hosting ha senso quando i dati indicano che il server è il collo di bottiglia: TTFB elevato anche sulle pagine in cache, o sulle pagine dinamiche nonostante una cache degli oggetti e un sito ben ottimizzato; rallentamenti ricorrenti negli orari di punta; errori o tempi di risposta molto alti durante le campagne; impossibilità di ottenere versioni recenti del software o gli strumenti di cache necessari. Non ha senso quando il problema principale è il peso del front-end: in quel caso un hosting migliore migliora di poco un problema che resta altrove.
Quando si decide di cambiare, la migrazione stessa va pianificata per non perdere prestazioni, con misure prima e dopo, verifica delle configurazioni di cache e monitoraggio dei dati di campo nelle settimane successive: ne parliamo nell’articolo dedicato alle migrazioni.
In sintesi
L’hosting incide sulle Core Web Vitals soprattutto attraverso il TTFB: velocità del processore, versione di PHP, database, disponibilità di cache, posizione dei server e capacità di reggere molti utenti contemporaneamente. Non incide sul peso e sulla complessità del front-end, che restano responsabilità del sito.
Condiviso, VPS, WordPress gestito e cloud rispondono a esigenze diverse, e dentro ogni modello la qualità varia molto. Per confrontarli servono misure sulle pagine dinamiche e sotto carico, non un test della home page. E prima di cambiare conviene verificare che il server sia davvero il collo di bottiglia: il miglior hosting del mondo non rende leggera una pagina pesante, ma un hosting inadeguato può rendere lenta anche la pagina più leggera.
