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. ...