Il TTFB è un fattore di ranking? Quanto conta per la SEO?

Il posizionamento organico è influenzato dal TTFB (Time To First Byte)? È il TTFB o la velocità del sito web che conta?

Confrontandomi con altri SEO, responsabili IT, ma anche blogger e webmaster, ho percepito molti dubbi in merito all’incidenza del TTFB (Time To First Byte) nel ranking e nelle performance di un sito web.

Per questo motivo ho deciso di creare un post partendo dalle opinioni di 3 figure molto autorevoli che si sono espresse in merito all’argomento, per giungere a della conclusioni molto interessanti.

 

 

Cos’è il TTFB (Time To First Byte)?

Il TTFB (Time To First Byte) viene spesso utilizzato come misura della velocità con cui un server web risponde a una richiesta, ovvero la reattività del server. I servizi che comunemente utilizziamo per misurare le performance dei nostri siti web lo indicano.

La teoria è semplice: più basso è il TTFB, migliore è il server web.
Spesso, però, la teoria non è sufficiente a comprendere di cosa realmente si sta parlando.

Wikipedia definisce il TTFB come segue.

TTFB measures the duration from the user or client making an HTTP request to the first byte of the page being received by the client’s browser.

Quindi il tempo da quando l’utente (o comunque il client) effettua una richiesta HTTP a quando il primo byte della pagina che viene ricevuto dal browser.

Cos'è il TTFB?

Cos’è il TTFB?

Il TTFB è un fattore di ranking? E’ quindi determinante per il posizionamento organico?

Per rispondere a questa domanda, vediamo alcuni pareri molto autorevoli.

 

L’esperimento di CloudFlare sul TTFB

Gli ingegneri di CloudFlare si sono chiesti:

cosa misurano in realtà (relativamente al TTFB) i servizi che usiamo comunemente per misurare la velocità delle pagine web?

Per verificarlo, hanno effettuato degli esperimenti che vi riporto.

Hanno creato un server di test che inserisce (appositamente) ritardi nella risposta HTTP per scoprire cosa viene realmente misurato.

Il risultato è stato una grande sorpresa e ha dimostrato che spesso il TTFB non è una misura utile (per come viene inteso).

Quando un browser web richiede una pagina ad un web server, insieme alla richiesta stessa invia alcune intestazioni (headers) che specificano diversi parametri, come, ad esempio, i formati accettabili per la risposta.

Il server risponde con:

  1. una riga di stato, che in genere è “HTTP / 1.1 200 OK“, la quale indica che la pagina era disponibile,
  2. seguita da più intestazioni contenenti informazioni sulla pagina,
  3. ed infine dal contenuto della pagina.

Il server di test di CloudFlare si comporta in modo leggermente diverso. Quando riceve una richiesta, invia la prima lettera della riga di stato (HTTP / 1.1 200 OK), ovvero la “H“; successivamente attende per 10 secondi prima di inviare il resto delle intestazioni e della pagina stessa.

Per chi vuole approfondire, cliccando QUI, è possibile scaricare il sorgente del server di test (scritto in GOlang).

Se, ad esempio, utilizziamo WebPageTest (recensito anche all’interno della sezione SEO Tools) e analizziamo una pagina dal server di test di CloudFlare otterremo la seguente sorpresa.

Analisi del caricamento con il server test di CloudFlare

Analisi del caricamento con il server test di CloudFlare

WebPageTest ha riportato il Time To First Byte come il tempo di ricezione di “H, e non il tempo in cui la pagina stessa è stata effettivamente inviata. L’attesa di 10 secondi (in azzurro nella timeline) lo rende evidente.

Il TTFB segnalato, quindi, non è il tempo di ricezione del primo byte di dati della pagina, ma del primo byte della risposta HTTP.

Ma cosa cambia? In realtà, sono concetti molto diversi perché le intestazioni di risposta possono essere generate molto rapidamente, ma sono i dati che influenzeranno la metrica più importante di tutte: la velocità con cui l’utente può vedere la pagina renderizzata.

CloudFlare utilizza Nginx e lo studio del TTFB ha fatto emergere un dato molto particolare relativo all’utilizzo della compressione.
La compressione Gzip delle pagine Web riduce notevolmente il tempo necessario per scaricare una pagina Web, ma le operazioni da svolgere per realizzarla, vanno ad aumentare TTFB.
Risultato: TTFB maggiore e load time inferiore.

A dimostrazione del fenomeno, hanno fatto un test servendo una pagina web con e senza compressione Gzip.
Ecco i risultati.

  • Senza Gzip:  TTFB: 213us – Load time: 43ms
  • Con Gzip: TTFB: 1.7ms – Load time: 8ms

Si noti come, con la compressione Gzip attivata, la pagina è stata scaricata 5 volte più velocemente, ma il TTFB era 8 volte maggiore.

CloudFlare, ovviamente, spiega anche i motivi tecnici per i quali avviene questo fenomeno, e spiega anche che la misurazione del TTFB da remoto non ha molto senso a causa della latenza di rete, ma non è interessante approfondire tali aspetti in questo momento.

Quello che è interessante, invece, è la conclusione che ClouFlare rilascia. Dicono, infatti, che per loro TTFB (così come viene considerato) non rappresenta una metrica significativa, in quanto l’obiettivo è ottimizzare l’esperienza per gli utenti finali, ovvero il tempo che impiega la pagina per essere consultabile.

 

La risposta di Ilya Grigorik: Web Performance Engineer di Google

Ilya Grigorik (Web Performance Engineer di Google) dopo la pubblicazione dei risultati del test di CloudFlare ha creato un post di commento sostenendo che si stavano sbagliando.
Secondo Ilya, infatti, non è solo il tempo che conta, ma anche il contenuto del primo pacchetto di informazioni.

Ilya Grigorik: Web Performance Engineer di Google

Ilya Grigorik: Web Performance Engineer di Google

E’ possibile, infatti (continuo a riportare le affermazioni, anche se abbastanza tecniche), fare in modo che il primo pacchetto sia in grado di svuotare l’header HTML, per consentire al browser di iniziare l’analisi ed avviare il pre caricamento delle risorse (JS, CSS, ecc.).
In questo modo, mentre la connessione TCP sta ancora attraversando la fase di avvio, il browser può avviare le connessioni, rendendo l’esperienza molto più veloce.

Scrive, inoltre, che i riferimenti sul comportamento di Nginx con la compressione Gzip sono derivanti da un fattore di architettura scelto da Cloudflare e non sono da prendere come riferimento.

Tra un commento e l’altro al suo post giunge l’affermazione più interessante. Conclude affermando di essere assolutamente in accordo con l’importanza delle metriche “percepite dall’utente” e con il miglioramento dell’esperienza dell’utente finale, e di ritenere il TTFB un componente importante di questa metrica.

 

Lo studio di MOZ sull’incidenza del TTFB nel ranking

In casa MOZ hanno testato le prestazioni di 100.000 siti web presenti nelle SERP di 2.000 query di ricerca.

Il test ha rilevato una correlazione (che definiscono “evidente“) tra un basso TTFB ed il miglior ranking nei motori di ricerca.
Non hanno, però, potuto dimostrare che la diminuzione del TTFB causa una effettiva variazione del ranking (e io, sinceramente, ne ho seri dubbi).

Test di MOZ sul TTFB per l'incidenza sul ranking

Test di MOZ sul TTFB per l’incidenza sul ranking

MOZ spiega che i risultati sono stati rilevati sia per parole chiave composte da 1 o 2 vocaboli, sia da keywords a coda lunga (long tail – 4 o 5 vocaboli).

Anche le loro misurazioni del TTFB sono state realizzate usando WebPageTest.

La ricerca ha rilevato che i siti web con le migliori posizioni in SERP avevano TTFB a partire da 350 ms, ed i siti con posizione più alta arrivavano a 650 ms.
MOZ consigliava un TTFB totale inferiore a 500 ms. Ammetto che, secondo me, la soglia è un po’ troppo elevata, ma noto che viene presa come riferimento generatle.

Secondo MOZ, il TTFB è influenzato da 3 elementi:

  1. il tempo impiegato dalla richiesta per propagarsi attraverso la rete e giungere al server web;
  2. il tempo impiegato dal server web per elaborare la richiesta e generare la risposta;
  3. il tempo necessario perché la risposta si propaghi attraverso la rete e giunga al browser.

Migliorare il TTFB, quindi, prevede una riduzione dei tempi relativi a queste 3 componenti, e nella parte finale del loro articolo danno dei consigli per effettuare tale operazione.

Sintetizzando, consigliano l’utilizzo di una CDN per la riduzione della latenza e un lavoro sul software e sulla configurazione del server per l’elaborazione della risposta.

Per approfondire questo tipo di ottimizzazioni, consiglio la lettura del post dal titolo “Velocizzare WordPress per la SEO e arrivare a 100/100 su PageSpeed Insight. Guida e Riflessioni“, dove spiego le operazioni che ho eseguito nel mio sito per ottenere degli ottimi risultati.

 

Le mie riflessioni, tra TTFB ed esperienza dell’utente

Il messaggio che voleva dare CloudFlare, evidentemente è stato frainteso; complice anche l’aggressività comunicativa che è stata utilizzata, di certo non premeditata.

Il loro intento, secondo la mia interpretazione, era quello di dimostrare che ciò che misuriamo con i tool online spesso non è ciò che crediamo sia; e le metriche, per essere interpretate correttamente, vanno comprese al 100%.

Vorrei riportare una frase di Ilya Grigorik in risposta ad un utente che chiedeva se il TTFB è effettivamente importante per Google e per la SEO; secondo me è la chiave di tutti i dubbi, e mi trova completamente d’accordo.

Dice, infatti:

Non preoccuparti di ciò che Google considera. Ciò che va fatto, è tutto quello che rende l’esperienza dei tuoi utenti migliore. Il resto, andrà bene di conseguenza.

In questo concetto, CloudFlare e Google si sono incontrati.

Se l’analisi dei dati di una ricerca (mi riferisco allo studio di MOZ) afferma che i siti web nelle prime posizioni in SERP hanno TTFB basso, e che quindi, per questo, il TTFB potrebbe essere un fattore di ranking, non è necessario farlo diventare un’ossessione.
Per assurdo, potrei dedurne che i siti web con miglior posizionamento sono sviluppati in maniera migliore e curano la scelta dell’hosting e la configurazione del server.

Ma soprattutto, nell’analisi di MOZ mancano i riferimenti al load time completo della pagina. E se TTFB fosse influente per il ranking solo come componente della velocità di caricamento complessiva?
Non a caso, infatti, il post di MOZ ha fatto nascere ulteriori test di risposta, che dimostrano proprio questo concetto.
Un esempio: “Elegant hack links speed & Google PageRank“.

L’importanza dell’esperienza utente

Quello che conta, secondo me, è l’esperienza utente, e la riduzione del TTFB potrebbe contribuire a migliorarla.
Ma se il comportamento degli utenti nella pagina non conferma la qualità dell’esperienza, di certo Google lo rileverà, e probabilmente con un peso superiore al TTFB basso.

Mi immagino questo tipo di ottimizzazioni come il setup di un’auto da corsa. Ha senso regolare i flap di decimi di millimetro per migliorare il tempo sul giro di qualche frazione di secondo se il motore non è competitivo?

Riportato nel mondo del web: abbiamo contenuti di qualità che possono mirare ad essere di valore per gli utenti, e quindi tra le prime posizioni (il motore competitivo)?

Se la risposta è sì, possiamo curare i dettagli SEO, fino ad arrivare al TTFB (regolazione flap).
Viceversa, consiglierei di spostare l’attenzione sui altri aspetti molto più importanti.

Dopo le riflessioni, chiudo con un paio di recenti tweet di John Mueller, Webmaster Trends Analyst di Google.

Tweet di John Mueller relativo al TTFB

Tweet di John Mueller relativo al TTFB

 

Tweet di John Mueller relativo alla SEO

Tweet di John Mueller relativo alla SEO

 

Anche se non è da prendere come “oro colato“, non credo lasci troppo spazio alla filosofia. Dice, infatti che il TTFB non è una metrica che viene considerata da Google (search/ranking).

 

Pillole da ricordare

  • Il TTFB può essere diverso in base al servizio che utilizziamo per misurarlo.
  • Più il TTFB è basso, e migliori saranno i presupposti per la riduzione del Load time complessivo.
  • L’ottimizzazione del TTFB non rende automaticamente più veloce un sito web.
  • Non è detto che un TTFB basso indichi un hosting migliore e più veloce.

 

Concludo con un’immagine che indica un test delle performance di questo sito web (il quale lavora con il proxy di CloudFflare) realizzata con WebPageTest, dove possiamo vedere anche il TTFB.

Risultati di WebPagetest da Amsterdam per alessiopomaro.com

Risultati di WebPagetest da Amsterdam per alessiopomaro.com

E questa è la valutazione del TTFB del test.

Valutazione di WebPagetest - Amsterdam - alessiopomaro.com

Valutazione di WebPagetest

Il sistema valuta in base ad una soglia target di 500 ms, infatti nei dettagli, specifica:

First Byte Time (back-end processing): 100/100

  • 144 ms First Byte Time
  • 500 ms Target First Byte Time

 

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *