Cos’è RTT e perché è importante?
Il tempo di andata e ritorno (RTT) misura il percorso di un segnale fino all’altro estremo e ritorno. Non è il tempo di risposta completo: DNS, connessione, elaborazione del server e trasferimento possono aggiungere ritardo. Le richieste parallele non sommano necessariamente un RTT dopo l’altro.
Come il RTT influisce sui Web Vitals
- LCP: HTML e risorse critiche lenti possono ritardare il contenuto principale.
- INP: misura la risposta fino al fotogramma successivo, non il completamento di una richiesta asincrona. I risultati possono arrivare tardi anche con un buon INP: misura entrambi i tempi.
- TTFB: comprende più di un RTT, per esempio connessione ed elaborazione. Non è un Core Web Vital.
- CLS: una risorsa tardiva può spostare il layout se non è stato riservato spazio. Un RTT alto da solo non implica uno spostamento.
Cause comuni di un RTT elevato
- Server di origine lontano o passaggi aggiuntivi tra CDN e backend.
- Richieste dipendenti e catene di reindirizzamenti.
- Nuove connessioni al posto del riutilizzo possibile.
- Risorse critiche di terze parti scoperte tardi.
- Elaborazione lenta del server, che nel tempo totale può sembrare un problema di rete.
Come ridurre il RTT nella pratica
- Confronta le regioni e valuta un CDN o l’elaborazione vicina al pubblico. Controlla quali risposte vengono effettivamente servite all’edge.
- Prova HTTP/2 e HTTP/3 dove disponibili. Non eliminano la distanza; HTTP/2 mantiene il blocco a livello TCP.
- Memorizza nella cache risorse statiche versionate. Per HTML e API rispetta riservatezza e aggiornamento.
- Usa
<link rel="preconnect">,dns-prefetche preload dei font solo per risorse critiche confermate. Non riducono l’RTT fisico. - Elimina richieste inutili e rinvia JavaScript non critico. Usa lazy loading per contenuti adatti sotto la prima schermata, non per l’immagine LCP.
- Riduci i reindirizzamenti e riutilizza connessioni o sessioni TLS. Verifica 0-RTT e i certificati nell’ambiente concreto.
Indagare il RTT con i risultati di Milten
- Confronta RTT, latenza del server e throughput per origine nelle condizioni del test.
- Esamina suggerimenti e cascata delle richieste, soprattutto prima di LCP/FCP. Un suggerimento assente è un’ipotesi da verificare.
- Separa elaborazione del server e ritardo di trasporto.
- Ripeti i test dopo i rilasci. Per confrontare luoghi diversi, verifica le regioni disponibili e mantieni condizioni equivalenti.
Elenco rapido dei controlli
- Individua l’origine lenta e la catena critica.
- Verifica il protocollo browser–edge e, se presente, edge–origine.
- Aggiungi solo suggerimenti utili di connessione o preload.
- Riduci i reindirizzamenti preservando l’URL finale previsto.
- Rispetta riservatezza e aggiornamento con cache e stale-while-revalidate.
- Confronta più prove equivalenti e dati delle visite reali.
Inizia da una misurazione
Su milten.io, esegui Speed Scanner, esamina i risultati di rete e scegli un collo di bottiglia confermato. Conserva condizioni e risultato iniziale, modifica un aspetto e confronta di nuovo.
