Per quel che riguarda la velocità complessiva dei nostri siti, spesso tendiamo a concentrarci sulle prestazioni e sulle ottimizzazioni del front-end per migliorare la velocità di caricamento delle pagine.

Tuttavia, a volte è bene spostarsi dal lato server, dove ha inizio il caricamento del sito.

Oggi analizzeremo approfinditamente il modo in cui il TTFB (time to first byte) influenza le prestazioni del vostro sito e scopriremo insieme alcuni semplici soluzioni per ridurlo. Il TTFB è un fattore delle prestazioni spesso trascurato, eppure dovrebbe essere tenuto in conto ogni volta che si testa la velocità del proprio sito.

Cos’è il TTFB

TTFB è l’acronimo di time to first byte (tempo al primo byte). In parole semplici, è la misura di quanto deve aspettare il browser prima di ricevere il primo byte di dati dal server. Maggiore è il tempo necessario a ricevere questi dati, maggiore sarà il tempo necessario a visualizzare le vostre pagine. Un errore frequente è che il TTFB viene calcolato dopo il tempo della risoluzione del DNS, tuttavia il calcolo iniziale del TTFB nelle comunicazioni di rete comprende sempre la latenza del network. Questo comporta un processo in 3 fasi e ritardi e latenza possono presentarsi in qualsiasi fase del processo, aumentando così il valore complessivo del TTFB.

Attesa TTFB
Tempo di attesa (TTFB)

1. Richiesta al server

Quando qualcuno visita il vostro sito, per prima cosa una richiesta HTTP viene inviata dal client (il browser) al server. In questa fase ci sono diversi fattori che possono generare ritardi. Lenti tempi di risoluzione del DNS possono contribuire a far aumentare il tempo della richiesta. Se il server è collocato in una località geograficamente distante, può introdursi latenza nella distanza che i dati devono attraversare. Inoltre, se sono in atto regole firewall complicate, queste possono aumentare i tempi di routing. E non dimentichiamo la velocità di rete del client.

2. Elaborazione del server

Dopo l’invio, il server deve elaborare la richiesta e generare una risposta. Questo potrebbe generare una serie di ritardi, come chiamate al database lente, un numero eccessivo di script di terze parti da eseguire, assenza nella cache della prima risposta, cattivo codice o mancata ottimizzazione del tema e risorse server, come disk I/O e memoria, inefficienti.

3. Risposta al client

Quando il server ha elaborato la richiesta, deve rispondere al client (o piuttosto restituire il primo byte). Questa trasmissione è fortemente influenzata dalla velocità di rete del server e del client. Se il client ha una connessione Internet lenta da un hotspot Wi-Fi, questa si rifletterà nel TTFB.

Il TTFB è importante?

È importante capire che il TTFB (time to first byte) non corrisponde alla velocità del sito. In realtà è una misura della reattività. In rete si discute molto se il TTFB sia importante o meno. Alcuni dicono che non è rilevante (Cloudflare, LittleBizzy), e altri dicono che sia importante (Ilya Grigorik, Web Performance Engineer di Google). Entrambe le parti riportano elementi validi sul perché sia o non sia importante, e anche alcune questioni su come questo tempo debba essere calcolato.

Moz ha addirittura fatto uno studio approfondito sulla correlazione tra ranking di ricerca e tempo al primo byte. É comunque difficile dire se questa correlazione è determinante oppure se i siti con basso TTFB sono semplicemente più veloci in generale, cosa su cui può influire il fattore di indicizzazione di Google legato alla velocità.

Comunque, piuttosto che sprecare tempo a rimuginare se sia importante o meno, preferiamo concentrarci sulle ottimizzazioni utili a migliorare questo indicatore. Tutto ciò che farete potrà contribuire alla velocità complessiva del vostro sito, e questo a sua volta influenzerà il vostro TTFB. Nei nostri test i siti con TTFB molto alti semplicemente caricano più lentamente.

In genere, qualunque valore sotto i 100 ms è ottimo ed è un buon valore del TTFB. Google PageSpeed Insights raccomanda tempi di risposta dei server inferiori ai 200 ms. L’intervallo di 300-500 ms è abbastanza nella media. E se avete più di 600 ms, potrebbe esserci qualcosa che è stato configurato male sul vostro server o potrebbe essere il momento di passare a uno stack web migliore. Oppure seguite i nostri consigli qui di seguito su come ridurre il TTFB. E ricordate che un un altro fattore può essere la negoziazione SSL/TLS.

Come misurare il TTFB

Ci sono svariati metodi per testare il TTFB. Ne analizzeremo alcuni qui di seguito. Ma ricordate, ogni strumento vi darà risultati leggermente diversi, per questo è importante utilizzarne uno solo e utilizzarlo come linea guida.

Misurare il TTFB con Google Chrome DevTools

Potete misurare il TTFB in Google Chrome lanciando i DevTools. Ricordate però che, se state effettuando i test dal vostro computer, il TTFB sarà influenzato dalla latenza del network e dalla vostra connessione internet. Per questo è forse più attendibile utilizzare uno strumento di terze parti (come vedremo meglio di seguito) che effettua i test da un data center.

  • Selezionate Altri strumenti > Strumenti per sviluppatori dal menu di Chrome.
  • Fate clic con il tasto destro su un elemento della pagina e selezionate Ispeziona
  • Usate la scorciatoia da tastiera Ctrl+Shift+I (Windows) o Cmd+Opt+I (Mac)

Avviate la finestra Network per visualizzare le prestazioni del sito.

TTFB in Google Chrome devtools
TTFB in Google Chrome devtools

Misurare il TTFB con il tool di Geekflare

Geekflare offre una fantastica raccolta di strumenti gratuiti utili per testare e risolvere i problemi del vostro sito web. Lo strumento per la misurazione del TTFB di Geekflare è semplice, veloce, e vi permette di vedere quanto sia veloce (basso) è il vostro time to first byte da tre diverse località del mondo.

 Lo strumento di test del TTFB di Geekflare
Lo strumento di test del TTFB di Geekflare

Misurare il TTFB con WebPageTest

Un altro strumento di misurazione del TTFB è WebPageTest. Secondo il loro glossario, il tempo obiettivo è il tempo richiesto per il DNS, per il socket e per le negoziazioni SSL + 100ms. La valutazione espressa da una lettera sarà ridotta ogni 100ms di ritardo rispetto all’obiettivo. Come potete vedere nei nostri test riportati di seguito, questo sito ha riportato un TTFB di 0,256s o 256 ms.

TTFB Webpagetest
Il Tempo del Primo Byte in Webpagetest

Misurare il TTFB con Pingdom

Chrome e WebPageTest lo definitscono TTFB. Se state utilizzando Pingdom lo troverete indicato con “Wait” (tempo di attesa). Ricordatevi di dare un’occhiata alla nostra guida approfondita su come utilizzare Pingdom.

Tempo di attesa in Pingdom
Tempo di attesa in Pingdom

Misurare il TTFB con GTmetrix

Anche in GTmetrix, così come in Pingdom, ci si riferisce al TTFB come al tempo di attesa. Ricordatevi di dare un’occhiata alla nostra guida approfondita su come utilizzare GTmetrix.

Attesa in GTmetrix
Misurare il TTFB in GTmetrix

Misurare il TTFB con il tool di KeyCDN

KeyCDN dispone di un ottimo strumento di misurazione delle prestazioni con cui è possibile misurare il TTFB da 14 diverse località contemporaneamente. Come potete vedere qui sotto, nel nostro test il TTFB è basso negli Stati Uniti e molto più alto oltreoceano. Questo perché il nostro server è collocato fisicamente negli Stati Uniti. Questa è la prova che latenza e distanza influenzano il TTFB.

Test del TTFB in KeyCDN
Test del TTFB in KeyCDN

Ci sono anche altri strumenti per misurare il TTFB, come il Sucuri Performance Tool e il ByteCheck. Lo sapevate? Anche Google Analytics ha una sezione che permette di vedere il tempo medio di risposta. Basta fare clic su “Comportamento > Velocità del sito > Panoramica”.

TTFB in Google Analytics
Report del TTFB di Google Analytics

4 Metodi per ridurre il TTFB del proprio sito

Analizziamo ora in modo approfondito alcune soluzioni per ridurre il TTFB nel vostro sito.

1. Scegliere un host veloce

Il primo modo per ridurre il TTFB è assicurarsi di utilizzare un host veloce. Abbiamo messo a confronto il TTFB di un host condiviso di terze parti (localizzato a Phoenix, AZ) e il TTFB di Kinsta (localizzato a Council Bluffs, Iowa). Abbiamo utilizzato la stessa identica configurazione, con il tema di default Twenty Seventeen. Ricordate che Kinsta ora dispone di tutte e 37 le location di Google Cloud Platform, dato che è importante collocare strategicamente il vostro sito il più vicino possibile ai vostri visitatori.

Kinsta, inoltre, include il network di livello premium di Google Cloud Platform in tutti i piani di hosting. Molti altri provider di hosting utilizzano il livello standard di Google Cloud Platform, e questo implica velocità inferiori.

TTFB di un host condiviso

In tutte le regioni, il TTFB medio è stato di 520ms. Nel Canada e negli Stati Uniti, il TTFB medio è stato di 240ms.

TTFB in un hosting condiviso
TTFB in un hosting condiviso

TTFB di Kinsta

In tutte le regioni, il TTFB medio è stato di 412ms. Nel Canada e negli Stati Uniti, il TTFB medio è stato di 164ms. Se il vostro host è Kinsta, potete anche scegliere di collocare il vostro sito in Europa o in Asia. Date un’occhiata alla lista delle località dei Google Cloud Data Center.

TTFB in un hosting WordPress gestito
TTFB in un hosting WordPress gestito

Così, utilizzando semplicemente un host più veloce, abbiamo registrato una riduzione del 20% del TTFB a livello globale, e una riduzione del 32% del TTFB tra Stati Uniti e Canada.

Avere una buona applicazione, un buon database e un host WordPress gestito (come Kinsta), con un’architettura attentamente studiata, è fondamentale per ridurre il TTFB.

Ciò significa anche scegliere con attenzione la località fisicamente collocata in una regione in cui risiedono i vostri clienti. Se la maggior parte dei vostri clienti sono negli Stati Uniti, non scegliete un server situato in Europa (sebbene un CDN può contraddire in parte questa affermazione).

2. Implementare un CDN

Un’altra soluzione semplice per ridurre il TTFB è utilizzare un Content Delivery Network (CDN). Se avete un sito che serve visitatori in diverse parti del paese, oppure intorno al mondo, un CDN può ridurre drasticamente il vostro TTFB. Come abbiamo visto in precedenza, la location è molto importante. Abbiamo eseguito un piccolo test per mostrare la differenza utilizzando KeyCDN come provider CDN. Ogni test è stato eseguito 5 volte ed alla fine abbiamo fatto la media.

TTFB senza CDN

Prima abbiamo eseguito un test disattivando il nostro CDN e, come si può vedere, il nostro tempo di caricamento complessivo è stato di 1,45s e il TTFB medio su una risorsa è stato di 136 ms.

TTFB prima del CDN
TTFB prima di aggiungere un CDN

TTFB con CDN

Abbiamo attivato il nostro CDN ed eseguito di nuovo il nostro test. Come vedete, i nostri tempi di caricamento complessivi sono crollati a 778 ms e il nostro TTFB medio è ora di 37 ms! Che differenza può fare un CDN! Un’altra cosa importante da notare è che abbiamo scelto la location di Stoccolma per eseguire questo test. Perché? Perché volevamo mostrarvi il miglioramento reale che si può avere diminuendo la distanza fisica. C’è un POP CDN a Stoccolma, per questo il nostro contenuto può essere servito da quella località.

TTFB dopo il CDN
TTFB dopo l’aggiunta di un CDN

Nota: Se state utilizzando Cloudflare, potreste avere un TTFB leggermente più alto. Ciò è probabilmente dovuto al sovraccarico e alla complessità aggiuntivi derivanti dall’avere in esecuzione un servizio proxy. Ricordate che Cloudflare ha firewall aggiuntivi e altre funzionalità che alcuni provider CDN non hanno. Quindi dovreste decidere in base a ciò che vi dà un beneficio maggiore. Se il vostro intero sito non è ottimizzato in modo appropriato, avere un TTFB leggermente più alto potrebbe valere lo scambio.

In ogni caso, potreste anche dare un’occhiata alla guida di WP Bullet all’utilizzo del page caching di Cloudflare per abbassare il TTFB. QUesta opzione potrebbe richiedere configurazione e testing aggiuntivi. Assicuratevi di eseguire dei test specifici per voi, in quanto ogni ambiente è diverso dagli altri.

Lettura consigliata: Come configurare Cloudflare APO per WordPress.

3. Usare la cache sul sito

Una terza soluzione, probabilmente una delle più semplici per ridurre il TTFB, è quello di utilizzare la memorizzazione nella cache all’interno del vostro sito WordPress. Molti pensano che la cache può solo contribuire a ridurre i tempi di caricamento, ma nei fatti questa aiuta anche ad abbassare il TTFB, in quanto permette di ridurre i tempi di elaborazione del server. Abbiamo eseguito ancora dei test con e senza utilizzo della cache. Ogni test è stato eseguito 5 volte e quindi è stata fatta la media.

Senza utilizzare la cache
Abbiamo fatto girare il sito su Pingdom e, senza l’attivazione della cache, il nostro sito ha registrato un tempo di caricamento di 1,17 s e un TTFB di 560 ms.

TTFB non in cache
TTFB senza utilizzo della cache

Con attivazione della cache
Quindi abbiamo attivato la cache e fatto girare di nuovo il sito su Pingdom. Questa volta il nostro sito ha ottenuto un tempo di caricamento di 643 ms e un TTFB di 57 ms.

TTFB con la cache di WordPress
TTFB con la cache di WordPress abilitata

Così, abilitando la cache, ci è stato possibile ridurre il nostro TTFB di un enorme 90%! Potete leggere di più sulla cache di Kinsta. Facciamo tutto questo a livello di server, il che significa che non vi sono necessari plugin di gestione della cache. Se non usate un host WordPress gestito, vi consigliamo di utilizzare un plugin di caching gratuito come Cache Enabler.

4. Utilizzare un provider DNS premium

Infine, ultimo ma non meno importante, anche il DNS recita una parte nella misura del TTFB. É difficile calcolare esattamente quanto sia rilevante, ma potete comunque vedere i tempi complessivi di risoluzione dei DNS e concludere che ci sono provider più veloci e meno veloci. Abbiamo eseguito un paio di prove con il tool di misurazione della velocità di SolveDNS. Qui c’è un esempio di un dominio che utilizza il DNS gratuito di NameCheap e i relativi tempi di risposta.

Il DNS gratuito di NameCheap

Velocità DNS gratuito
Velocità di un DNS gratuito

E di seguito c’è un esempio d’utilizzo del DNS premium di Amazon Route 53. Come è evidente, in linea generale i tempi di risoluzione dei DNS sono molto più rapidi con Amazon. Normalmente, i provider DNS premium hanno migliori prestazioni. Claudflare è un provider gratuito ma ha delle ottime performance.

Il DNS di Amazon Route 53

Velocità Amazon premium DNS
Velocità Amazon premium DNS

Ricordatevi di dare un’occhiata al nostro articolo sul perché dovreste utilizzare un provider DNS premium. Kinsta collabora con Amazon Route 53, e il servizio è disponibile gratuitamente per tutti i nostri clienti.

Riepilogo

Ci sono moltissime altre cose che potreste ottimizzare o correggere per ridurre il TTFB, come il caching del database, il Disk IO, l’uso dello Swap, la RAM, le impostazioni PHP, le impostazioni MySQL, le impostazioni di rete, il sovraccarico TLS, ecc. Ma le soluzioni descritte qui sopra sono abbastanza semplici da implementare e vi garantiranno un rapido miglioramento delle prestazioni. Quindi, la prossima volta che qualcuno vi chiederà come ridurre il TTFB, ricordate che host, CDN, cache e DNS veloci giocano un ruolo importantissimo. Riparare o migliorare quei colli di bottiglia vi darà la soluzione.

Qual è stata la vostra esperienza con il TTFB? Ci piacerebbe saperne di più nei commenti qui sotto.

Brian Jackson

Brian ha una grande passione per WordPress, lo usa da più di dieci anni e sviluppa anche un paio di plugin premium. Brian ama i blog, i film e le escursioni. Entra in contatto con Brian su Twitter.