Il Round Trip Time (RTT) misura quanto tempo impiega una comunicazione a partire da un punto, raggiungere una destinazione e tornare indietro. Viene normalmente espresso in millisecondi e, nelle reti, è uno dei modi più utili per capire quanto ritardo esiste tra due endpoint.
La definizione sembra semplice. Il problema arriva quando RTT viene usato come sinonimo di latenza, ping, risposta del server o TTFB. Sono concetti collegati, ma non equivalenti.
La definizione di Round Trip Time di MDN descrive l’RTT come il tempo necessario a inviare un pacchetto a una destinazione e ricevere nuovamente l’acknowledgment all’origine.
Per un sito web questa distinzione conta parecchio. Se una parte rilevante dell’attesa deriva dal percorso fra utente e infrastruttura, ottimizzare PHP, database o WordPress può produrre risultati modesti. Se invece la rete è rapida e l’attesa nasce dopo che la richiesta ha raggiunto il server, il problema è altrove.
Capire l’RTT serve proprio a separare il costo della comunicazione di rete dal resto della pipeline.
Cos’è il Round Trip Time e cosa misura davvero
Immagina che il tuo computer invii un piccolo messaggio a un server.
Il messaggio attraversa la rete, raggiunge la destinazione e genera una risposta che torna verso il punto di partenza. Il tempo trascorso fra l’invio e il ritorno della risposta costituisce il round trip.
In una rappresentazione molto semplificata:
client → rete → destinazione → rete → client
e quindi:
RTT ≈ tempo di andata + tempo di ritorno
Quella formula serve a costruire il modello mentale, non a descrivere ogni dettaglio di una rete reale. I due percorsi non devono necessariamente essere identici e il ritardo può variare in base a routing, congestione, code, tecnologia di accesso e altri fattori.
Per questo due richieste verso lo stesso server possono produrre RTT diversi anche a distanza di pochi secondi.
RTT, latenza e ping non sono la stessa cosa
Il termine latenza è più ampio di RTT.
In senso generale indica un ritardo. In networking può riferirsi al tempo impiegato dai dati per attraversare una rete in una direzione oppure, nel linguaggio di molti strumenti, essere utilizzato più liberamente per descrivere un ritardo misurato attraverso un round trip.
L’RTT è invece esplicitamente una misura di andata e ritorno.
Il ping è ancora un’altra cosa: è uno strumento utilizzato per verificare la raggiungibilità di un host e misurare il tempo di risposta. Su Windows, per esempio, il comando invia messaggi ICMP Echo Request e mostra il tempo trascorso fino alla ricezione dell’Echo Reply. La documentazione Microsoft del comando ping lo descrive espressamente come strumento di diagnostica che riporta i round-trip time.
Quindi:
| Concetto | Che cosa indica |
|---|---|
| Latenza | Termine generale per il ritardo nella comunicazione |
| One-way delay | Tempo impiegato in una sola direzione |
| RTT | Tempo di andata e ritorno |
| Ping | Strumento che può misurare un RTT tramite ICMP |
La distinzione diventa importante perché un ping ICMP non replica necessariamente il comportamento di una vera richiesta HTTPS. Firewall, router e sistemi intermedi possono gestire ICMP diversamente dal traffico applicativo.
Un ping è quindi un buon segnale diagnostico. Non è una riproduzione completa del caricamento di una pagina web.
RTT e TTFB: la differenza che evita diagnosi sbagliate
RTT e Time to First Byte sono particolarmente facili da confondere perché entrambi possono riflettere problemi di rete.
Il Time to First Byte misura però un intervallo molto più ampio: dalla navigazione o richiesta fino al momento in cui inizia ad arrivare il primo byte della risposta.
Secondo la documentazione web.dev sul TTFB, questo intervallo può comprendere redirect, avvio del service worker, DNS, apertura della connessione, negoziazione TLS e attesa della risposta.
Il modello corretto è quindi:
RTT → costo della comunicazione
mentre:
TTFB → rete + setup della connessione + richiesta + attesa della risposta
Un RTT elevato può contribuire a un TTFB elevato, ma un TTFB elevato non dimostra che l’RTT sia elevato.
Esempio: un utente può avere un percorso di rete rapido e raggiungere il server con poca latenza, ma aspettare molto perché WordPress deve eseguire query lente, attendere un’API esterna o generare dinamicamente la pagina.
All’opposto, un backend molto veloce non elimina il tempo necessario per attraversare migliaia di chilometri di rete.
Questa è la prima distinzione da fare prima di qualsiasi ottimizzazione.
Come nasce l’RTT durante una connessione
Il round trip non dipende da un singolo componente.
Fra il dispositivo dell’utente e il server possono esserci rete Wi-Fi, router locale, provider, reti di transito, peering, backbone, apparati intermedi, eventuali infrastrutture edge e infine la rete che ospita la destinazione.
Ogni tratto può aggiungere una parte del ritardo.
Dal client al server e ritorno: cosa succede a un pacchetto
Quando un pacchetto lascia il dispositivo, normalmente attraversa diversi router prima di arrivare alla destinazione.
Ciascun passaggio richiede tempo. A questo si sommano propagazione fisica del segnale, trasmissione, elaborazione negli apparati e possibili tempi di coda.
Quando la destinazione risponde, inizia il percorso di ritorno.
Non bisogna inoltre assumere che andata e ritorno seguano necessariamente la stessa strada. Il routing Internet può essere asimmetrico: la rete decide i percorsi in base alle proprie tabelle e politiche, non in base al desiderio di produrre una misura perfettamente simmetrica.
Di conseguenza:
RTT / 2
non è automaticamente la vera latenza one-way.
Può essere una semplificazione utile in alcuni ragionamenti, ma non una misura precisa dei due percorsi separati.
Perché distanza, routing e code di rete aumentano il tempo
La distanza fisica crea un limite che nessuna ottimizzazione software può eliminare.
I dati devono comunque attraversare un mezzo fisico. Una richiesta tra due sistemi nello stesso datacenter parte quindi da condizioni profondamente diverse rispetto a una comunicazione tra un utente europeo e un’origine su un altro continente.
Ma la distanza geografica non racconta tutto.
Conta anche come la rete collega realmente quei due punti. Due server geograficamente simili possono produrre RTT differenti se uno viene raggiunto tramite un percorso di peering più efficiente e l’altro richiede più transiti o attraversa segmenti congestionati.
Alle condizioni strutturali si aggiungono poi le code.
Quando un’interfaccia deve gestire più traffico di quanto riesca a trasmettere immediatamente, i pacchetti possono aspettare. Un collegamento apparentemente molto veloce può quindi avere comunque latenza problematica durante periodi di congestione.
Ecco perché larghezza di banda e RTT rispondono a domande diverse.
Una connessione da molti gigabit può trasferire enormi quantità di dati una volta avviato il flusso e avere comunque un round trip elevato verso una destinazione lontana.
TCP, TLS e QUIC: quando conta anche il numero di round trip
L’RTT diventa ancora più importante quando un protocollo necessita di più scambi prima di poter completare un’operazione.
TCP utilizza le misurazioni RTT anche per il proprio funzionamento interno. L’RFC 6298 definisce, per esempio, come i sender TCP utilizzano campioni di RTT per calcolare e gestire il retransmission timeout.
Anche QUIC mantiene stime del percorso. L’RFC 9002 definisce latest_rtt, smoothed_rtt e la variazione dei campioni per loss detection e congestion control.
Dal punto di vista delle performance web, però, il concetto più utile è un altro: se per iniziare a scambiare dati servono più round trip, il costo della latenza viene pagato più volte.
Le tecnologie moderne cercano proprio di ridurre questo costo.
L’RFC 9001 dedicato a TLS e QUIC spiega che, in assenza di perdita, molte nuove connessioni QUIC possono essere stabilite e protette entro un singolo round trip; nelle connessioni successive può essere possibile inviare dati applicativi in 0-RTT. Quest’ultima modalità non è però garantita e introduce considerazioni di sicurezza, compreso il rischio di replay.
Il punto pratico è semplice: non puoi sempre ridurre l’RTT fisico, ma puoi evitare di pagarlo inutilmente troppe volte.
Come misurare il Round Trip Time
Non esiste un singolo test capace di descrivere da solo tutte le condizioni di rete.
La misurazione più utile nasce dalla combinazione di strumenti diversi: uno per avere un’indicazione del round trip, uno per osservare il percorso e uno per verificare come si comporta il traffico web reale.
Ping: cosa misura e come interpretare il risultato
Su Windows puoi utilizzare:
ping example.com
Su macOS o Linux, per limitare il numero di richieste:
ping -c 10 example.com
Il risultato normalmente mostra più campioni, non un solo numero.
Un output può contenere:
time=23 ms time=25 ms time=24 ms time=41 ms
La cosa interessante non è soltanto la media.
Guarda almeno:
- il valore tipico;
- quanto oscillano i campioni;
- eventuali picchi;
- la presenza di packet loss.
Un RTT medio relativamente basso con occasionali picchi enormi racconta una situazione diversa da un RTT costantemente elevato.
Per una diagnosi seria, la stabilità conta quasi quanto il valore medio.
Traceroute e tracert: individuare dove cresce il ritardo
Ping ti dice che esiste un certo tempo di andata e ritorno. Non ti mostra però il percorso.
Su Windows puoi usare:
tracert example.com
Su molti sistemi macOS/Linux:
traceroute example.com
La documentazione Microsoft di tracert spiega che il comando incrementa progressivamente il valore TTL per far emergere i router intermedi lungo il percorso.
Questo permette di osservare dove cambia sensibilmente il tempo.
C’è però un caveat importante: un asterisco in traceroute non dimostra automaticamente che quel router stia perdendo il normale traffico applicativo. Alcuni apparati non restituiscono i messaggi ICMP attesi oppure li trattano con priorità differente.
Traceroute serve quindi a costruire indizi.
Non è una radiografia perfetta della rete.
Perché il ping può differire dall’RTT del traffico web reale
Un browser che apre una pagina HTTPS non sta semplicemente inviando un ICMP Echo Request.
Deve lavorare attraverso lo stack applicativo e di trasporto effettivamente usato dalla pagina. Possono entrare in gioco TCP o QUIC, TLS, HTTP, proxy, CDN, firewall, bilanciatori, politiche di routing e infrastruttura edge.
Per questo può capitare di osservare un ping ottimo e un caricamento HTTP lento.
Oppure il contrario: ICMP può essere limitato o deprioritizzato mentre il traffico HTTPS funziona normalmente.
La regola pratica è:
ping descrive il comportamento del ping; non usarlo come prova definitiva della velocità HTTP.
Quando stai diagnosticando un sito, affiancalo quindi al waterfall di rete e alle metriche applicative.
La nostra guida a GTmetrix mostra perché località, connessione e condizioni del test devono rimanere comparabili quando analizzi le performance.
CrUX: come leggere l’RTT degli utenti reali di un sito
Dal punto di vista web c’è oggi un’altra fonte interessante: Chrome UX Report.
La metodologia CrUX relativa al Round Trip Time descrive RTT come una stima del round trip HTTP a livello applicativo all’inizio della navigazione, derivata da connessioni di rete recenti.
Qui serve molta attenzione.
Il dato CrUX non deve essere interpretato come:
RTT CrUX = velocità del server
Chrome chiarisce che il valore descrive le condizioni di connessione osservate dagli utenti e deriva da misurazioni applicative recenti. Le note di rilascio CrUX precisano inoltre che non si tratta esclusivamente di connessioni verso il sito che stai analizzando.
È quindi prezioso per rispondere alla domanda:
“Che tipo di condizioni di rete sta sperimentando il pubblico reale?”
È molto meno adatto a dimostrare:
“Il mio origin server impiega esattamente X millisecondi.”
Questa distinzione segue la stessa logica spiegata nella nostra guida a PageSpeed Insights: dati sul campo e test di laboratorio osservano scenari differenti.
C’è infine un dettaglio importante per chi sviluppa applicazioni web. L’API NetworkInformation.rtt esiste ancora nella documentazione, ma MDN la indica come deprecated e la Network Information API non è Baseline. Non costruirei quindi una nuova funzionalità pubblica facendo affidamento su questa proprietà lato JavaScript.
Questo non significa che CrUX abbia smesso di utilizzare le proprie stime RTT. Significa che il dato aggregato CrUX e l’uso diretto dell’API nel browser sono due decisioni tecniche differenti.
Qual è un buon RTT? Perché non esiste un valore valido per tutti
Una delle domande più frequenti è anche una delle più facili da semplificare male:
qual è un buon Round Trip Time?
Non esiste un confine universale che separa in modo affidabile RTT “buoni” e “cattivi” per qualunque rete, località e applicazione.
Un valore deve essere interpretato rispetto al percorso e al task.
Un RTT che sarebbe molto strano tra due macchine nello stesso datacenter può essere perfettamente comprensibile tra utenti e server collocati su continenti diversi.
Allo stesso modo, applicazioni interattive e comunicazioni in tempo reale sono molto più sensibili alla latenza rispetto al download di un file che, una volta avviato il trasferimento, dipende in misura importante anche dalla capacità disponibile.
Geografia, rete e applicazione cambiano il giudizio
Quando giudichi un RTT, chiediti prima:
| Contesto | Domanda utile |
|---|---|
| Utente e server vicini | Il percorso è insolitamente lento rispetto a quanto ci aspettiamo localmente? |
| Utente e server lontani | Quanto del ritardo è spiegabile dalla distanza e dal routing? |
| Applicazione interattiva | Il ritardo è percepibile durante le interazioni frequenti? |
| Pagina web | Quanti round trip vengono pagati prima dell’arrivo del contenuto? |
| CDN | La richiesta arriva davvero a un edge vicino o torna spesso all’origine? |
| Diagnosi tecnica | Il valore è stabile o cambia fortemente nel tempo? |
Questo approccio evita di trasformare una cifra isolata in un obiettivo artificiale.
Se ieri, nelle stesse condizioni, un percorso stabile mostrava valori molto inferiori e oggi l’RTT è raddoppiato, hai un segnale da investigare anche senza conoscere una fantomatica “soglia SEO”.
Minimo, media, picchi e variabilità: quali numeri servono davvero
Un singolo valore medio può nascondere parecchio.
Immagina due connessioni.
La prima produce quasi sempre valori vicini fra loro.
La seconda alterna campioni molto rapidi a picchi elevati.
Potrebbero avere la stessa media e offrire un’esperienza completamente diversa.
Per questo durante i test conviene osservare:
minimo → valore tipico/media → massimo → dispersione → packet loss → andamento nel tempo
La variabilità dell’RTT è spesso indicata come jitter, soprattutto nei contesti realtime. Per una normale diagnosi web non serve necessariamente trasformarla in una nuova metrica da ottimizzare: basta riconoscere che un percorso instabile richiede un’analisi diversa da un percorso semplicemente lontano.
Cosa causa un RTT elevato
Un round trip elevato può avere una causa strutturale oppure temporanea.
La diagnosi deve partire dalla rete, non dal prodotto che vuoi vendere o dal plugin che vuoi installare.
Distanza geografica e routing inefficiente
La prima causa è inevitabile: client e destinazione possono essere lontani.
Ma distanza geografica e distanza di rete non coincidono sempre.
Il traffico può attraversare più carrier, punti di interconnessione e percorsi non intuitivi. Un datacenter apparentemente vicino sulla mappa può quindi essere raggiunto attraverso una strada di rete meno efficiente di un’altra infrastruttura geograficamente più distante.
Per questo scegliere la regione di hosting soltanto guardando il nome della città non basta.
Conta dove si trovano realmente gli utenti e come i loro provider raggiungono quella rete.
Congestione, packet loss e accodamento
Quando una parte del percorso è congestionata, i pacchetti possono attendere in coda.
Questo fa crescere l’RTT anche se la distanza fisica è rimasta identica.
In presenza di perdita, inoltre, i protocolli affidabili devono recuperare i dati mancanti. Il problema non si limita quindi a un singolo ping più lento: aumentano anche il tempo necessario per completare determinate operazioni e la variabilità della connessione.
Se l’RTT aumenta soprattutto nelle ore di maggiore traffico, la congestione diventa una delle ipotesi da verificare.
Wi-Fi, rete mobile e apparati intermedi
Non tutto ciò che chiamiamo “Internet lento” nasce su Internet.
Il primo collo di bottiglia può trovarsi dentro casa o in ufficio.
Wi-Fi congestionato, segnale debole, interferenze, access point saturi, VPN, firewall, hotspot e collegamenti mobili possono aggiungere ritardo prima ancora che il traffico raggiunga la rete del provider.
Questo è uno dei motivi per cui un test deve registrare le condizioni.
Se confronti:
desktop Ethernet → server
con:
smartphone Wi-Fi congestionato → VPN → server
non stai semplicemente ripetendo la stessa misurazione.
Hai cambiato il percorso.
Quando un RTT alto non dipende dal server
Questo errore merita di essere isolato.
Il server può essere perfettamente efficiente e avere comunque utenti con RTT elevato.
Se l’origine si trova molto lontano, la rete deve percorrere quella distanza indipendentemente dal tempo necessario a eseguire PHP.
Viceversa puoi avere un RTT eccellente e un server lentissimo.
Un modo utile per pensarlo è:
RTT basso + TTFB alto → investigare soprattutto ciò che accade oltre la semplice rete
RTT alto + TTFB alto → la rete contribuisce, ma potrebbe non essere l'unica causa
RTT alto + backend rapido → lavorare su percorso, distribuzione e costo dei round trip
È una matrice diagnostica, non una formula matematica universale.
Come l’RTT influenza le prestazioni di un sito web
Un sito non carica i propri contenuti istantaneamente appena l’utente fa clic.
Prima che arrivino HTML, CSS, JavaScript, font e immagini devono avvenire scambi di rete.
Ogni volta che il protocollo o l’architettura richiede di attendere un altro round trip, la latenza torna a presentare il conto.
Il costo dei round trip prima di ricevere il primo byte
Il TTFB include fasi precedenti all’arrivo della risposta.
Se una nuova connessione deve essere stabilita, devono avvenire scambi fra client e infrastruttura. Se esistono redirect, possono essere necessarie ulteriori richieste. Se l’origine è lontana, ciascuno di questi passaggi diventa più costoso.
Per questo eliminare un redirect non significa semplicemente “togliere qualche millisecondo al server”.
Significa evitare un’interazione aggiuntiva che può richiedere un altro viaggio attraverso la rete.
L’impatto aumenta con l’RTT.
Un passaggio superfluo è relativamente meno doloroso su un percorso rapidissimo e molto più costoso quando ogni round trip richiede parecchio tempo.
La relazione tra RTT, TTFB, FCP e LCP senza confondere le metriche
RTT non è un Core Web Vital.
Non è neppure equivalente a FCP, LCP o TTFB.
La relazione è causale solo nel senso corretto: la rete fa parte della pipeline che precede il rendering.
Web.dev spiega che TTFB precede le principali metriche di caricamento e che un TTFB elevato può rendere più difficile ottenere un buon LCP.
FCP include a sua volta tempi che precedono il primo rendering, compresi setup della connessione e TTFB.
Quindi una catena possibile è:
RTT elevato → connessioni/scambi più costosi → TTFB potenzialmente maggiore → meno tempo disponibile prima di FCP/LCP
Ma attenzione alla parola potenzialmente.
Un LCP lento può dipendere da un’immagine enorme, dalla scoperta tardiva della risorsa, da JavaScript, da CSS o da molti altri fattori anche in presenza di una rete eccellente.
Ridurre l’RTT non è quindi una scorciatoia per “risolvere i Core Web Vitals”.
Serve a togliere uno specifico collo di bottiglia quando quel collo di bottiglia esiste.
Connection reuse, TLS 1.3 e HTTP/3: ridurre il costo della latenza
Una strategia importante consiste nel non ristabilire inutilmente connessioni già disponibili.
Se client e server possono riutilizzare una connessione esistente, evitano una parte del costo di setup che sarebbe necessario per aprirne una nuova.
Anche l’evoluzione dei protocolli lavora in questa direzione.
HTTP/3 utilizza QUIC, che integra il trasporto con TLS. Questo permette di ridurre alcuni passaggi necessari nella creazione di una nuova connessione e gestire in modo diverso la perdita rispetto alla tradizionale combinazione HTTP/2 + TCP.
Se vuoi distinguere i livelli dello stack, nella guida HTTP vs HTTPS trovi anche la separazione tra HTTP, TLS, HTTP/2 e HTTP/3.
L’idea da portare via da questa sezione non è “HTTP/3 è sempre più veloce”.
È più precisa:
quando l’RTT è significativo, ridurre il numero di round trip necessari può produrre un vantaggio materiale.
L’effetto reale dipende poi da connessioni già aperte, packet loss, supporto dei protocolli, cache, infrastruttura e caratteristiche del traffico.
Come ridurre l’impatto dell’RTT
La parola corretta qui è impatto.
Non puoi comprimere arbitrariamente il tempo necessario a un segnale per attraversare una lunga distanza. Puoi però cambiare la distanza logica fra utente e contenuto, migliorare il percorso o evitare round trip inutili.
Avvicinare contenuti e utenti con CDN ed edge
Una CDN distribuisce contenuti e servizi attraverso una rete di nodi.
Quando la richiesta può essere gestita da un punto vicino all’utente, diminuisce la distanza che quella comunicazione deve percorrere rispetto a una richiesta che raggiunge ogni volta l’origine lontana.
Web.dev indica proprio il minore RTT dovuto alla prossimità degli edge server tra i principali vantaggi di una Content Delivery Network.
Questo spiega anche perché servizi come Cloudflare possono essere utili in un’architettura con pubblico distribuito geograficamente.
Ma la CDN non risolve automaticamente tutto.
Se una risposta personalizzata deve comunque raggiungere ogni volta l’origine, se la cache non può essere utilizzata o se il backend stesso impiega molto tempo a generare la risposta, una parte del vantaggio può ridursi.
edge vicino ≠ backend automaticamente veloce
Eliminare redirect e round trip non necessari
Una catena di redirect può costringere il browser a effettuare più richieste prima di raggiungere la destinazione definitiva.
Per esempio:
https://example.com
→
https://example.com
→
https://www.example.com
→
https://www.example.com/pagina
Se conosci già la destinazione finale, internal link, canonical, sitemap e configurazioni applicative dovrebbero normalmente puntare direttamente lì.
Questo non significa eliminare redirect che servono realmente per migrazioni, canonicalizzazione o compatibilità.
Significa evitare le catene che non aggiungono alcuna funzione.
Scegliere server e regione vicini al pubblico reale
Se la maggior parte dei tuoi utenti è in Italia, un’origine molto lontana può introdurre una latenza strutturale evitabile.
La decisione non deve però basarsi solo sulla distanza chilometrica.
Confronta regioni e provider nelle condizioni che contano per il pubblico reale.
La domanda non è:
“Quale datacenter sembra più vicino?”
ma:
“Quale infrastruttura offre al mio pubblico un percorso stabile e sufficientemente breve?”
Per un ecommerce locale con quasi tutti gli utenti italiani la risposta potrebbe essere molto diversa da quella di un SaaS utilizzato in Europa, Stati Uniti e Asia.
Ottimizzare protocolli e connessioni invece di intervenire alla cieca sul backend
Se hai già dimostrato che il problema è di rete, continuare a ottimizzare query SQL già rapide non cambia la distanza.
Guarda invece:
connessioni riutilizzate, protocollo negoziato, redirect, località dell’origine, CDN, cache edge, routing e comportamento in condizioni reali.
Se al contrario RTT è basso e il TTFB resta elevato, sposta la diagnosi sul backend.
Questa separazione evita uno dei pattern più costosi nelle ottimizzazioni web: cambiare la tecnologia sbagliata perché il sintomo è stato interpretato male.
Come diagnosticare un RTT alto: workflow pratico
Una diagnosi utile deve rendere il problema ripetibile.
Vedere una volta 180 ms sul terminale non basta per decidere che il sito abbia un problema di rete.
Procederei così:
- Definisci origine, destinazione e condizioni del test. Annota rete utilizzata, Wi-Fi o Ethernet, eventuale VPN, località del client, hostname di destinazione e momento del test. Ripeti più campioni anziché basarti su una sola richiesta.
- Confronta ping e percorso. Usa ping per osservare RTT, stabilità e perdita; affianca tracert/traceroute per capire il percorso. Un hop che non risponde non è automaticamente il colpevole: cerca pattern coerenti e variazioni che continuano anche negli hop successivi.
- Confronta la rete con il traffico applicativo. Apri il waterfall del browser o uno strumento di performance e verifica cosa accade alla richiesta HTTP. Se ping è rapido ma il documento passa molto tempo in attesa della risposta, il problema può essere applicativo. Se anche il percorso di rete è lento, la rete ha invece un ruolo più evidente.
- Isola una variabile e ripeti il test. Prova una rete differente, una località diversa o una configurazione modificata. Se stai valutando una CDN, confronta lo stesso scenario prima e dopo. Se stai valutando un cambio backend, mantieni il resto delle condizioni il più possibile stabile.
La logica è sempre:
misura → formula un'ipotesi → modifica una variabile → misura di nuovo
Non:
numero alto → installa qualcosa
Quando la diagnosi diventa complessa, il dato più utile spesso nasce dal confronto.
Se da una rete italiana l’RTT verso l’origine è elevato ma verso il nodo edge è sensibilmente inferiore, hai un’indicazione concreta sul ruolo della distanza.
Se entrambi sono rapidi e il TTFB resta lento, devi cercare altrove.
Se tutto peggiora soltanto in determinate ore, congestione e condizioni di rete diventano ipotesi più credibili.
È qui che il Round Trip Time smette di essere un numero da screenshot e diventa una metrica utile.
Conclusione
Il Round Trip Time non ti dice se un sito è “veloce” o “lento” in assoluto. Ti dice quanto costa completare un viaggio di andata e ritorno tra due punti della comunicazione.
Questa informazione diventa potente quando viene messa nel contesto corretto.
Se RTT è elevato, devi guardare distanza, percorso, rete dell’utente, congestione e numero di round trip richiesti dall’architettura. Se RTT è basso ma TTFB è elevato, il problema si sposta probabilmente verso altre fasi della richiesta. Se una CDN riduce il percorso verso il contenuto senza obbligare continuamente a tornare all’origine, può ridurre materialmente il costo della latenza.
Il punto quindi non è inseguire un valore RTT universale.
È capire quale parte dell’attesa appartiene alla rete e intervenire su quella parte, senza attribuire al server problemi che il server non può risolvere.
Quando questa separazione non è evidente, una diagnosi di ottimizzazione del sito web dovrebbe partire proprio dalla scomposizione delle fasi: rete, connessione, backend, delivery e rendering. Solo dopo ha senso decidere dove intervenire.