Connessioni tra SEO e livello di trasporto TCP

Tutti i consulenti SEO sono consapevoli, più o meno, dell'importanza della velocità di caricamento di un sito web. Sanno che questo fattore influisce sia sulla riduzione del tasso di abbandono dei visitatori, sia sul buon esito della scansione degli spider-bot dei motori di ricerca. Ma perchè ? Cosa c'è dietro a questa ossessione per la velocità ? Un "mistero" che aleggia nientemeno che su un algoritmo usato per il controllo della congestione a livello di trasporto del protocollo TCP può influire addirittura sulla SEO ? ebbene si !

E' un argomento ostico, ma chi avrà la pazienza di seguirmi in questo articolo, sicuramente alla fine ne capirà qualcosa in più e avrà sprecato bene il suo tempo. Andiamo con ordine: La comparsa di reti telematiche sempre più veloci, non solo a livello di reti cablate ma anche mobile (pensiamo al 4G, e a breve il 5G) sta spingendo inevitabilmente l'utenza a ricercare delle esperienze di navigazione altrettanto veloci. Secondo Google, nel caso delle connessioni mobile (che in genere sono più lente di quelle cablate), l'utenza si aspetta in media una risposta per ogni richiesta web non superiore ad 1 secondo.

Tale secondo però è così suddiviso:

  • 300 ms di ritardo per questioni di risoluzioni DNS degli hostname in indirizzi IP, per la natura fisica della rete sottostante, interferenze o rumori di fondo ecc.
  • 300 ms per instaurare la connessione TCP
  • 200 ms per ricevere la prima porzione di codice html, quello iniziale senza interruzioni per perdita di dati
  • 200 ms di ritardo concesso al browser per il rendering della pagina.

Nei 200 ms necessari per ricevere il codice html iniziale si dovrebbe concentrare la trasmissione dei contenuti web che i professionisti SEO chiamano "above the fold", ossia quei contenuti che ricoprono lo spazio visibile in alto nella finestra del browser e a primo impatto per l'utente. Per evitare, dunque, che l'utente abbandoni il sito è fondamentale fornirgli senza perderere troppo tempo (e quindi nei tempi previsti come indicato sopra) i primi contenuti (rilevanti e possibilmente attraenti) e far in modo che, tutto il contenuto in fondo alla pagina sia eventualmente caricato in un secondo momento, magari con delle chiamate asincrone.

I 200 ms indicati da Google, in realtà non sono scelti a caso, e non sono neanche un puro capriccio degli utenti. Se da una parte l'utente pretende velocità, dall'altra ci sono limiti tecnologici che gli utenti devono inevitabilmente accettare. Citerò un valore che probabilmente nella pratica risulta già superato, ma è prassi riferirsi alle statistiche note e scientificamente accettate fin quando queste non vengono aggiorante alla situazione attuale.

Tutto nasce da un rapporto sullo stato di Internet risalente al 2010 ("The State of the Internet, 3rd Quarter 2009", Akamai Technologies, Inc., January 2010) secondo il quale si può assumere come valore medio di RTT delle connessioni TCP il valore di 200 ms.
Il Round Trip Time (o RTT) è il tempo massimo che deve impiegare un segmento TCP per viaggiare da un nodo della rete ad un altro, e restituire una notifica, o ACK al mittente per avvisare dell'avvenuta ricezione. Se l'ACK non viene ricevuto entro il tempo di RTT, il segmento di dati è andato perduto, e il mittente è obbligato a rispedirlo. Un segmento TCP è un insieme di pacchetti TCP che a loro volta possono contenere porzioni di codice html, in caso di contenuti web. In seguito a quel famoso rapporto sullo stato di salute di internet, gli esperti informatici hanno previsto di ampliare il numero di pacchetti per segmento portandoli da 2 o 3 (come erano previsti inizialmente nel protocollo TCP), a 10 adeguandoli cosi ai nuovi valori RTT medi rilevati che dimostrano un minor rischio di perdita dei pacchetti TCP.

Di fatto, se un sito web è ospitato da un server moderno che implementa questa caratteristica, potrebbe servire segmenti TCP di 10 pacchetti x 1460 byte (dimensione del campo dati di un pacchetto base TCP) = 14,6 KB.

A questo punto non rimane altro che capire cosa c'entra la SEO in tutto questo. La velocità di trasmissione a livello di trasporto del protocollo TCP dipende dalla capacità di gestione e prevenzione delle congestioni. Una congestione può verificarsi per diversi motivi, tra i quali, il più intuitivo è che il ricevente (es. un browser) non sia in grado di smaltire il rendering delle pagine, perchè sovraccarico o perchè magari la rete o il server è più veloce nel trasmettere i dati. La soluzione a livello TCP consiste nel far gestire ad ogni mittente due valori o finestre. Una finestra registra la capacità in byte del ricevente di ricevere dati, l'altra chiamata finestra di congestione serve per regolare la dimensione della finestra effettiva di invio. La finestra effettiva di invio dati, è data sempre dal valore minimo tra le due finestre cioè tra quello che il mittenta pensa che sia giusto inviare e ciò che che il ricevente ritiene corretto ricevere.

La fase di avvio però richiede un'inizializzazione di tali finestre. Quando si stabilisce una connessione, il mittente imposta la finestra di congestione alla dimensione di un segmento TCP. Se questo segmento riceve l'ack prima della scadenza, il mittente raddoppia la finestra di congestione rispetto alla dimensione precedente ed invia due segmenti. Ancora una volta, se il mittente riceve l'ack dei due segmenti raddoppia di nuovo la finestra di congestione e spedisce 4 segmenti e così via. La finestra di congestione continua a crescere in modo esponenziale fino a quando non verranno persi i primi segmenti. Questo algoritmo è noto come avvio lento, ma non è lento, è esponenziale (con potenza di 2) ! L'algoritmo utilizza inoltre un parametro chiamato soglia, inizialmente posto a 64 KB. Al verificarsi di un timeout, cioè al verificarsi della perdita di un segmento o al raggiungimento della finestra di congestione alla soglia, la soglia viene reimpostata a metà della finestra di congestione corrente e la finestra di congestione a sua volta reimpostata alla capienza di un segmento. Da quel punto in poi, però le trasmissioni avvenute con successo aumenteranno la finestra di congestione in modo lineare fino al raggiungimento della soglia che riattiva il loop dell'algoritmo.

Alla luce di questo fatto, l'ottimizzazione "above the fold" si pone come obiettivo l'idea di sfruttare la massima capienza della finestra di congestione, prima che un timeout (ack e segmenti perduti) faccia riattivare il loop dell'algoritmo rallentando di fatto la trasmissione degli altri dati. E' una sorta di ricerca maniacale dell'ottimizzazione SEO portata ai livelli bassi della stratificazione TCP/IP. Avendo già visto che un segmento contiene 10 pacchetti ed è di circa 14 KB, il timeout è probabile che accada al terzo roundtrip quando la finestra di congestione raggiunge la capienza di 56 KB e non può più raddoppiare perchè in quel caso supererebbe la soglia di 64 KB.

Ricapitolando:
Al primo roundtrip il server trasmette 14 KB,
Al secondo roundtrip si trasmettono 28 KB,
Al terzo, 56 KB.
TIMEOUT

Totale = 14+28+56 KB = 98 KB.

Questo ci fa capire che quando si parla di ottimizzazione e velocità, bisogna non solo evitare di richiamare javascript o css esterni (che attivano round trip aggiuntivi e quindi ulteriori perdite di tempo), ma fare in modo che sia il codice html, sia gli script e i css che servono a renderizzare la parte "above the fold" della pagina siano concentrati ed inseriti in linea (senza riferimenti a file esterni) e nei primi 98KB della pagina web in modo da riceverla in 200 ms con un massimo di 3 roundtrip.

Lascia un commento