Hosting SEO: quanto pesa il TTFB sul posizionamento

Il TTFB, Time To First Byte, è il tempo che passa dal momento in cui il browser invia la richiesta al momento in cui riceve il primo byte di risposta. È tutto quello che succede prima che ci sia qualcosa da disegnare sullo schermo, ed è anche il pezzo di performance più trascurato. Gli strumenti che la maggior parte delle persone usa per capire perché un sito è lento, da PageSpeed Insights ai report sui Core Web Vitals, restituiscono numeri già mescolati tra tempo di rete, tempo di rendering e tempo di esecuzione degli script. Non dicono mai, da soli, quanto di quel ritardo dipende dal server e quanto dal browser.

Il risultato pratico è che si passano settimane a comprimere immagini e a rimandare il caricamento del JavaScript quando il problema reale è che il server impiega 900 millisecondi solo per iniziare a rispondere, prima ancora che il browser abbia qualcosa da processare. Questo articolo si occupa solo di quella prima fetta di tempo: come scomporla nelle sue componenti, come distinguere un numero buono perché il server è davvero veloce da un numero buono perché la pagina era semplicemente in cache, e a che punto ha senso cambiare hosting invece di continuare a rincorrere ottimizzazioni lato codice.

Cosa misura davvero il TTFB, fase per fase

Quando il browser chiede una pagina, il tempo prima del primo byte si divide in quattro fasi distinte, e ognuna ha una causa diversa. Confonderle porta a diagnosi sbagliate: si incolpa il server per un ritardo che in realtà è di rete, o viceversa.

Delle quattro fasi, solo l'ultima è sotto il controllo diretto dell'hosting e dell'applicazione. Le prime tre dipendono da rete, provider DNS e configurazione del protocollo, e sono comunque un lavoro dell'hosting quando si tratta di abilitare HTTP/2, HTTP/3 o la ripresa rapida delle sessioni TLS, ma non raccontano nulla sulla capacità reale del server di elaborare la richiesta. Se il tuo TTFB totale è alto, la prima domanda da farsi non è "il server è lento", ma "in quale delle quattro fasi si sta perdendo il tempo".

• Risoluzione DNS: il tempo per tradurre il dominio in un indirizzo IP. Di norma pochi millisecondi se il DNS è su rete anycast, ma può salire se il provider DNS è sovraccarico o geograficamente lontano.
• Handshake TLS: lo scambio di chiavi che stabilisce la connessione cifrata. Un round trip in più qui, tipico di certificati mal configurati o della mancanza di TLS 1.3, si somma direttamente al totale.
• Connessione TCP: l'apertura del canale prima ancora che parta la richiesta HTTP vera e propria. Dipende soprattutto dalla distanza fisica tra client e server.
• Attesa del server (server processing time): il tempo che il server impiega a costruire la risposta una volta ricevuta la richiesta, cioè query al database, esecuzione di PHP o di altro linguaggio, chiamate a servizi esterni nel percorso della richiesta. È quasi sempre qui che si nasconde il problema quando il TTFB è alto in modo persistente.

Il trucco della cache: la stessa pagina, due tempi diversi

Il modo più veloce per farsi ingannare da un buon punteggio TTFB è testare solo pagine già in cache. Se hai una cache a pagina intera, tipo Varnish, un livello Nginx fastcgi_cache o un plugin di caching su WordPress, la seconda richiesta a un URL non tocca quasi mai il database o l'interprete del linguaggio: il server restituisce un file già pronto in memoria. Il numero che vedi in quel caso non misura la capacità reale del tuo stack applicativo, misura la velocità della cache.

Per capire cosa succede davvero, misura la stessa pagina due volte in condizioni diverse. Una prima misura con la cache calda, cioè la pagina già visitata di recente e quindi servita dalla cache. Una seconda misura a freddo, forzando una nuova generazione: puoi svuotare la cache lato server, aggiungere un parametro di query univoco che bypassa la regola di cache, oppure testare direttamente una pagina che per natura non può essere messa in cache, come un carrello, una pagina personalizzata per l'utente loggato o una pagina di risultati di ricerca interna filtrata.

Se il divario tra le due misure è largo, per esempio 80 millisecondi a caldo contro 1200 a freddo, hai la risposta: il tuo hosting sta bene finché la cache regge, e va in difficoltà ogni volta che qualcosa la invalida o che una pagina non è cacheabile per sua natura. Questo è particolarmente rilevante per e-commerce con filtri di prodotto, siti con aree riservate, o qualunque pagina che cambia in base a chi la richiede: sono esattamente le pagine che un test superficiale su PageSpeed, fatto sulla home page già calda, non intercetta mai.

• Da riga di comando: usa curl con un formato di output personalizzato che stampa i tempi di risoluzione DNS, connessione, handshake TLS e primo byte separatamente, così vedi in quale fase si accumula il ritardo invece di un unico numero totale.
• Dal browser: apri gli strumenti per sviluppatori, scheda Rete, disabilita la cache del browser (non quella del server) e guarda la voce "In attesa" (Waiting for server response) sulla richiesta del documento principale, non su un asset secondario.
• Da uno strumento esterno con vista prima/ripetuta, come WebPageTest: confronta esplicitamente il primo caricamento con quelli successivi sullo stesso profilo, così la differenza tra freddo e caldo è già isolata nel report.

Lo spazio disco non è il collo di bottiglia: sono CPU e database

Gran parte dell'hosting condiviso venduto in Italia mette in vetrina lo spazio disco e il traffico mensile come se fossero la risorsa scarsa. Nella pratica, per un sito con una manciata di pagine e immagini, il disco non finisce mai. La risorsa che finisce prima è la CPU condivisa tra centinaia di siti sulla stessa macchina fisica, e nessun piano economico la mette in evidenza perché è più difficile da vendere con un numero grande e rassicurante come "50 GB".

Questo produce un pattern riconoscibile: il TTFB è accettabile per gran parte della giornata e poi peggiora in modo intermittente, spesso in fasce orarie ricorrenti, senza che tu abbia cambiato nulla sul tuo sito. È l'effetto "vicino rumoroso": un altro sito sullo stesso server sta ricevendo traffico o eseguendo un processo pesante, e la tua quota di CPU si riduce di conseguenza. Un grafico di monitoraggio con picchi ricorrenti alla stessa ora, in giorni diversi, è quasi sempre questo, non un problema del tuo codice.

Sopra questo, c'è lo stack applicativo tipico di molte agenzie italiane su WordPress: un page builder visuale come Elementor, Divi o WPBakery, più una manciata di plugin per moduli, popup, statistiche e sicurezza. Ogni blocco costruito con un page builder aggiunge query al database o chiamate a funzioni PHP che una pagina scritta a mano non avrebbe. Il risultato è che due siti visivamente identici possono avere un TTFB molto diverso solo perché uno genera 15 query per caricare la home page e l'altro ne genera 120.

• Conta le query effettive per pagina con uno strumento di diagnostica lato WordPress: se una pagina statica ne genera più di 40-50, è un buon punto da cui iniziare a tagliare, non necessariamente cambiando hosting ma disattivando widget e plugin non usati sul template.
• Un livello di cache degli oggetti, tipicamente Redis o Memcached, riduce drasticamente il tempo di attesa del server perché evita di ricalcolare le stesse query a ogni richiesta non cacheabile nella pagina intera.
• Se il piano di hosting non offre CPU dedicata né la possibilità di installare una cache a oggetti, nessuna ottimizzazione applicativa risolverà del tutto il problema: hai raggiunto il tetto del piano, non il tetto del tuo codice.

Dove si trova fisicamente il server, e cosa cambia con una CDN davanti

Molti siti italiani, soprattutto quelli su hosting economico, sono ospitati su server fisicamente lontani dal pubblico che li legge: negli Stati Uniti, in Irlanda o in Germania, perché costa meno o perché il pannello di gestione del provider è più semplice da usare. Per un pubblico prevalentemente italiano, questo aggiunge decine di millisecondi di sola latenza di rete prima ancora che parta l'elaborazione della richiesta, e quel ritardo si somma alla connessione TCP e all'handshake TLS descritti sopra.

Una CDN davanti al sito aiuta, ma non risolve tutto allo stesso modo. Per asset statici (immagini, CSS, JavaScript, e anche per pagine HTML intere se il CDN supporta la cache a pagina piena), il contenuto viene servito da un nodo edge vicino all'utente e la distanza dal server d'origine smette di contare. Ma per qualunque richiesta dinamica e non cacheabile, come una ricerca sul sito, un carrello, un'API interna o una pagina personalizzata per l'utente loggato, la richiesta deve comunque raggiungere il server d'origine, fare il giro completo, e tornare indietro. In quel caso la distanza fisica del server originale continua a pesare esattamente come se la CDN non ci fosse.

Per un sito prevalentemente statico (blog, sito vetrina, landing page) una CDN con cache a pagina intera copre gran parte del problema di distanza. Per un sito con molte interazioni dinamiche (e-commerce, area riservata, ricerca interna con filtri) la posizione del server d'origine resta una decisione che conta, e spostarlo più vicino al pubblico principale può abbassare il TTFB delle pagine non cacheabili più di qualunque ottimizzazione di codice.

Le soglie che giustificano davvero una migrazione

Cambiare hosting è un lavoro rischioso: DNS da ripuntare, email da non perdere, certificati da rigenerare, tempo di indisponibilità se qualcosa va storto. Vale la pena farlo solo quando la causa del ritardo è strutturale, non quando è un sintomo che si può correggere più a buon mercato con la cache o con qualche query in meno.

Un modo pratico per decidere: misura il TTFB a freddo, come descritto sopra, sulle pagine template principali del sito (una scheda prodotto, un articolo, la pagina dei risultati di ricerca), non sulla home page già calda. Se quel numero resta stabilmente sopra i 600-800 millisecondi anche dopo aver ridotto plugin superflui e aver aggiunto una cache degli oggetti, e se il piano di hosting non offre CPU dedicata, il tetto è del piano, non del sito. È a quel punto che una migrazione, verso un piano con risorse dedicate o verso un hosting gestito pensato per il tuo CMS, produce un miglioramento reale.

Se invece il TTFB è nella norma per la maggior parte della giornata e peggiora solo in fasce orarie specifiche, è il pattern del vicino rumoroso descritto sopra: anche qui la soluzione è uscire dalla condivisione delle risorse, non ottimizzare ulteriormente un codice che non è la causa.

C'è anche un segnale collaterale da non ignorare: un server che lavora vicino al limite della propria capacità non mostra solo un TTFB che sale, mostra anche, superata una certa soglia di carico, errori 5xx intermittenti quando le richieste in coda superano quello che il server riesce a gestire in tempo. Se stai già indagando errori 502, 503 o 504 che compaiono solo nelle ore di punta, la causa è quasi sempre la stessa capacità limitata che sta gonfiando il TTFB il resto del tempo: non è un problema diverso, è lo stesso collo di bottiglia visto a due livelli di gravità.

Il caso opposto, e altrettanto comune, è quello in cui il sito è già su un piano con CPU dedicata o su un'infrastruttura cloud con risorse ampie, e il TTFB resta comunque alto. In questo scenario cambiare hosting quasi certamente non risolve nulla: entro pochi giorni il nuovo server mostrerà lo stesso ritardo, perché la causa è nel codice, non nella macchina. Query senza indici, chiamate sincrone a servizi esterni dentro il percorso della richiesta, o l'assenza totale di qualunque livello di cache sono problemi che seguono l'applicazione, non l'hardware.

Cosa provare prima di spostare tutto

Prima di affrontare il rischio di una migrazione, ha senso esaurire le leve che non richiedono di cambiare provider. Nell'ordine in cui di solito danno il ritorno più immediato:

• Attiva o verifica la cache a pagina intera per il traffico anonimo e non loggato, così la maggior parte delle visite non tocca mai il database.
• Aggiungi una cache degli oggetti (Redis o Memcached) se il piano lo permette, per accelerare tutto ciò che la cache a pagina intera non copre.
• Verifica che l'opcode cache del linguaggio server-side sia attivo: senza, ogni richiesta ricompila il codice da zero prima ancora di eseguirlo.
• Riduci il numero di plugin e blocchi del page builder effettivamente caricati sulle pagine template, non solo quelli visibili nella home.
• Individua le query più lente con il log delle query lente del database, se il piano lo espone, e aggiungi gli indici mancanti sulle colonne usate nei filtri più frequenti.
• Sposta fuori dal percorso della richiesta qualunque chiamata a servizi terzi non indispensabile per generare la risposta, così una API esterna lenta non allunga il TTFB di ogni pagina.

Misurare senza strumenti a pagamento

Non serve un abbonamento a un tool di monitoring per fare questa diagnosi. Curl con l'opzione di formato per i tempi, integrata in praticamente ogni sistema operativo, restituisce la scomposizione completa di risoluzione DNS, connessione, handshake TLS e primo byte in un'unica riga, gratis e senza installare nulla. Gli strumenti per sviluppatori di qualunque browser moderno mostrano lo stesso dettaglio in forma grafica sulla scheda Rete, con la possibilità di disattivare la cache del browser per simulare una prima visita.

Per una vista prima/ripetuta più leggibile, servizi gratuiti pensati per il testing delle performance eseguono entrambe le misure automaticamente e le mostrano affiancate, il che evita di dover ripetere il test a mano più volte per essere sicuri di non aver preso un valore anomalo. Qualunque strumento tu usi, testa da più orari della giornata e non fidarti di una singola misurazione: un valore isolato può sempre essere un picco casuale, un pattern ripetuto su più test nello stesso orario è un segnale reale su cui vale la pena agire.