E’ il TTFB, e NON la “velocità del sito”, ad impattare sul posizionamento!

Fra gli oltre 200 fattori che Google utilizza per determinare il posizionamento di una pagina, uno di quelli ultimamente più dibattuti è la velocità.

Google, per bocca di Matt Cutts, ha iniziato quasi 4 anni fa a fare delle dichiarazioni un po’ opache sul tema, alle quali sono seguiti, solo per citare 2 esempi fra i tanti, un post sul Google Webmaster Central Blog (Aprile 2010) e un articolo su Google Think Insights (Gennaio 2012).

Anche nei Ranking Factors – Rank Correlation 2013 di Searchmetrics il fattore site speed è stato indicato come uno fra quelli con una buona correlazione, e qualche giorno fa sul Moz Blog è stato pubblicato uno studio per determinare l’influenza di questo parametro nel posizionamento su Google.

Metodologia

Partendo dai dati del Search Engine Ranking Factors 2013 è stata creata una lista di 200 query casuali, lunghe dal minimo di un termine al massimo di 5 termini.

Sono quindi stati estratti i “top 50” risultati per ogni query, dai quali è stato ricavato un elenco di 100.000 pagine.

Infine sono state lanciate 30 istanze su Amazon EC2, all’interno di ognuna delle quali è stato caricato WebPagetest (noto tool che permette di verificare le performance di una pagina web); il test è stato effettuato con Chrome, e per ogni singola pagina testata è stata svuotata, ogni volta, la cache del browser.

Risultati

Ti rimando al Moz Blog per la lunga spiegazione di tutti i test fatti (e dei risultati ottenuti), ma se hai poco tempo ti riassumo tutto in 2 righe:

Non è emersa alcuna correlazione fra il tempo di caricamento della pagina (documento o rendering completo) e il posizionamento della stessa in Google. La cosa vale per tutte le query analizzate, sia quelle da 1-2 parole chiave, che quelle da 4-5.

In pratica, non ci sono state differenze di rilievo fra siti veloci e siti lenti: se il tempo di caricamento è un fattore di posizionamento su Google, evidentemente si perde nel rumore degli altri oltre 200 fattori.

L’eccezione del TTFB (Time to First Byte)

E’ emersa una sola correlazione degna di nota, ed è quella riguardante il TTFB (Time to First Byte).

Median Time to First Byte

Il TTFB è la quantità di tempo che deve aspettare un client, che manda una richiesta HTTP GET ad un server, per ricevere il primo byte; in altre parole è il tempo necessario ad un server per rispondere ed iniziare a sparar fuori la pagina web.

Secondo l’autore del post, il TTFB è probabilmente il parametro più semplice e veloce da “catturare” dai crawler di Google, a differenza dei tempi di download complessivi di una pagina che sono più difficili da determinare (se non utilizzando un browser). Il sospetto è che quest’ultimo segnale verrà considerato in futuro, ma per ora, probabilmente, richiede troppe risorse.

Aggiungo un dato interessante che ho trovato dentro PageSpeed Insights, il tool gratuito di Google per misurare quanto sono veloci le pagine del tuo sito: se inserisci un URL e clicchi su ANALYZE, fra i consigli inclusi nel Suggestion Summary troverai “Reduce server response time to under 200ms“.

Google definisce il server response time come “il tempo che occorre al server per iniziare il rendering della pagina, sottraendo la latenza fra Google e il server”, e suggerisce caldamente di “ridurre il tempo di risposta del server sotto i 200ms“.

Conclusioni (e qualche suggerimento)

Il TTFB è influenzato da 3 fattori:

• la latenza fra utente e server
• il carico del web server
• la velocità con cui il sito è in grado di generare il (primo) contenuto

Il primo suggerimento è dunque quello di utilizzare un Content Delivery Network (CDN), che ha il vantaggio di abbattere la latenza (utilizzando una infrastruttura con server dislocati in vari luoghi del mondo, e quindi più vicini fisicamente all’utente) e di essere particolarmente performante (il carico non è su un singolo server o database, ma viene distribuito su più macchine).

Ovviamente vale sempre il consiglio di velocizzare il proprio sito/blog, iniziando con qualche semplice plugin (se utilizzi un CMS tipo WordPress, ce ne sono moltissimi e gratuiti).

Ricorda una cosa: indipendentemente da Google e dal posizionamento sui motori, un sito veloce converte meglio, “trattiene” gli utenti, non li fa rimbalzare via.

Non ci credi? Da un recente studio di Radware sugli ecommerce è emerso che “un sito che si carica in 3 secondi ha un numero di pageview inferiore del 22%, una frequenza di rimbalzo superiore del 50% e il 22% in meno di conversioni rispetto ad un sito che si carica in 1 secondo, mentre un sito che si carica in 5 secondi ha un numero di pageview inferiore del 35%, una frequenza di rimbalzo superiore del 105% e il 38% in meno di conversioni”.

A buon intenditor…

Condividi su facebook
Facebook
Condividi su google
Google+
Condividi su twitter
Twitter
Condividi su linkedin
LinkedIn
Condividi su pinterest
Pinterest

12 Comments

  • Beh mi sembrava anche un po’ ovvio e ci si poteva benissimo arrivare facendo un ragionamento come segue:

    Sono Google.

    Propongo 10 risultati per una query.

    Se dò molta importanza alla velocità può succedere che siti con contenuti più scarsi ma molto veloci (chiamiamoli di categoria A) si posizionino prima di contenuti ottimi ma molto lenti (categoria B).

    Quanto tempo ci mette l’utente ad essere soddisfatto?

    Supponiamo che l’utente ci mette 5 secondi ad aprire la pagina di un contenuto A e 10 per quello B.

    Supponiamo che A sia posizionato sopra B. Il tempo di soddisfazione è 5 secondi + 10 secondi. (supponendo grossolanamente che l’utente viene soddisfatto con il contenuto B). Sono quindi 15 secondi di tempo.

    Supponiamo che B sia posizionato sopra A. Il tempo di soddisfazione è 10 (supponendo che l’utente viene soddisfatto subito).

    C’è una differenza di tempo “enorme”.

    Contando anche il fatto che Google dà più importanza ai brand editoriali più forti (che hanno pagine molto pesanti soprattutto per l’enorme mole di pubblicità presente tra cui skin, banner, pop under, ecc) il discorso velocità è un fattore che possiamo lasciar perdere per almeno i prossimi 5 anni.

    Credo che Google stia invece prendendo un’altra strada, ovvero nel futuro creare proprie cache di pagine da offrire velocemente all’utente, con propri servizi di CDN, ecc.

  • Per i blog che realizziamo uso questo plugin (Quick Cache) per accelerare la velocità di download. Tuttavia ce ne sono molti altri. Certo però che quello della velocità è un fattore che alla lunga rischia di favorire chi ha soldi da spendere (in server e codice html ottimizzati) e non chi ha idee e contenuti da proporre. Speriamo bene!

  • Si ma il tempo di caricamento incide indirettamente sul posizionamento e direttamente sull’esperienza utente: se un utente ci mette troppo tempo ad entrare in un sito, il sito stesso riceve meno visite e se riceve meno visite sapete anche voi cosa succede.

  • Mi raccomando ragazzi, per chi usa WordPress, non usate W3 Total Cache. Sembra proprio che per questo parametro sia il plugin di caching più lento!

    Meglio Wp Super Cache, che tra le altre cose è il plugin che ha adottato anche Matt Cutts dopo aver tolto W3 Total! 😉

  • In our test, your server responded in 0.90 seconds… è questo il dato in sintesi più importante?Grazie

  • Bell’articolo Davide. Grazie.
    ATTENZIONE: Se la velocità non è un fattore di ranking, l’eccessiva lentezza molto probabilmente invece lo è.
    Sarei davvero sorpreso se emergesse uno studio che dimostra che siti particolarmente lenti non hanno problemi a posizionarsi su query competitive.
    Da questa ricerca la cosa non poteva emergere perché vengono considerati solo siti ben posizionati, ma è chiaro che sarebbe stupido da parte di Google lasciare ai primi posti per molte query siti che ci mettono molto (troppo) tempo a caricarsi. E dalle parti di Mountain View non ce ne sono molti di stupidi 😉
    Quindi, come dice Davide, non vi cullate nella sicurezza che Google non posizioni i siti in base alle performance, ma lavorate per una esperienza utente decente, che prevede, tra le altre cose tempi di caricamento non superiori a 4-5 secondi (ad essere buoni ;-).

  • Titolo: è il TTFB e NON la velocità del sito ad impattare sul posizionamento

    Testo dell’articolo: Il sospetto è che quest’ultimo segnale verrà considerato in futuro, ma per ora, probabilmente, richiede troppe risorse.

    Al di là delle premesse un po’ disoneste (ma non voglio fare il moralista), quantomeno evitiamo di scomodare tecnicismi di cui non sappiamo neanche il significato preciso, cercando di adattarlo al caso… senza contare che ci va “di culo” che non esista alcuna correlazione a questo giro, sennò sai che delirio sulla rete, coi “SEO” improvvisati che cercano disperatamente di documentarsi… e funziona così purtroppo, dicono di pensare ai contenuti e pensiamo ai contenuti, dicono di pensare ai duplicati e pensiamo ai duplicati, in una folla di proseliti senza cervello che ricorda più i seguaci di un dittatore che dei reali professionisti.

    Perdonerete il mio tono forse poco garbato, pero’ scusatemi: qui sembra che nessuno evidenzi il vero problema che riguarda, nel caso del PageSpeed, GLI UTENTI dei siti web, senza i quali noialtri staremmo tutti a bruciare copertoni per strada per scaldarci. Ancora troppa gente gioca a fare il reverse engineering di Google senza capire, una buona volta, che i fattori che fanno il beneficio degli utenti SONO COMUNQUE essenziali, anche se Google non ci fosse, perchè a nessuno piace aspettare 10 secondi il caricamento di un sito, anche se si tratta di un banale Youporn. E quindi tanto vale parlare di come velocizzare il caricamento delle pagine, piuttosto che chiedersi se valga la pena farlo per “fare contento” Matt Cutts.

    Grazie dello spazio concesso.

  • @Fabio Manciulli: mi spiace, ma hai letto male il post.

    Il TTFB, almeno secondo Moz, è stata “sola correlazione degna di nota” emersa dallo studio che hanno effettuato sulla “velocità”. In altre parole, è stato il solo fattore correlato al posizionamento (rispetto a tutti gli altri testati).

    Quelli che (forse) verranno considerati in futuro sono i “tempi di download complessivi di una pagina che sono più difficili da determinare (se non utilizzando un browser)”.

    Se rileggi il paragrafo “L’eccezione del TTFB (Time to First Byte)”, è spiegato tutto molto chiaramente.

  • Sono davvero sorpreso di questo risultato.

    Il tempo fino al primo byte è il parametro più inutile e sbagliato da usare per una qualsiasi misurazione della velocità di un sito.

    Questo vorrebbe dire dare un vantaggio a:

    1) un sito statico ma che abbia nell’html 20 script nell’head e una marea di thumbnail che in realtà sono 1000×1000 pixel

    2) un sito velocissimo nel tempo di risposta ma magari con un html non compresso che ci mette 5 secondi a scaricarsi

    e magari penalizzare un sito:

    3) complesso nella programmazione, molto dinamico e non di facile caching MA ottimizzato perfettamente che arriva all’onload in metà del tempo rispetto agli altri due.

    O questo studio vale meno di zero o google sta facendo una cazzata. Scommetterei sulla prima 🙂

Lascia un commento

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

Max Valle

Max Valle

Da oltre 20 anni, fornisco consulenze per aziende e professionisti, che vogliono sviluppare il loro business, 
aumentando i clienti, utilizzando le ultime tecnologie e nel pieno rispetto delle normative vigenti in materia.

Seguimi sui social

Iscriviti alla Newsletter

Main sponsor

Scroll to Top

Utilizziamo i cookie per personalizzare contenuti ed annunci, per fornire funzionalità dei social media e per analizzare il nostro traffico. Condividiamo inoltre informazioni sul modo in cui utilizza il nostro sito con i nostri partner che si occupano di analisi dei dati web, pubblicità e social media, i quali potrebbero combinarle con altre informazioni che ha fornito loro o che hanno raccolto dal suo utilizzo dei loro servizi. Acconsenta ai nostri cookie se continua ad utilizzare il nostro sito web. Per maggiori informazioni visualizza la Privacy & Cookie policy