TTFB vs tempo di risposta vs latenza

Cosa significa ciascun termine

La latenza di rete, spesso riportata come round-trip time, è il tempo che un pacchetto passa viaggiando verso il server e tornando indietro, senza alcun lavoro applicativo nel mezzo. È determinata dalla distanza fisica, dal numero di hop e dalla qualità del percorso. Niente di ciò che fai nel tuo codice la modifica.

Il time to first byte (TTFB) si misura dal momento in cui il client avvia la richiesta fino a quando il primo byte della risposta lo raggiunge. Quell'intervallo contiene la risoluzione DNS, la connessione TCP, l'handshake TLS, il tempo che la richiesta passa in transito, qualunque cosa faccia il server per produrre una risposta, e il viaggio di ritorno. Il TTFB è quindi sempre maggiore di un singolo round trip, di solito di parecchio.

Il tempo di risposta è il più impreciso dei tre. La maggior parte degli strumenti di monitoraggio lo usa per il tempo totale di completamento della richiesta, dal primo pacchetto all'ultimo byte del corpo. Alcuni strumenti lo usano come sinonimo di TTFB. Prima di confrontare due numeri entrambi etichettati "tempo di risposta", controlla su cosa ciascuno strumento ha fermato il cronometro.

Come si misura ciascuno di essi

La latenza deriva da un echo ICMP, che è ciò che invia ping, oppure dalla misurazione dell'handshake TCP quando l'ICMP è bloccato. Il TTFB e il tempo totale derivano dal client HTTP stesso. Un'unica chiamata a curl stampa tutti i confini:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/

Ogni valore è cumulativo dall'inizio della richiesta, quindi li leggi come confini piuttosto che come durate. Sottrai il valore precedente per ottenere la lunghezza di una fase.

Quale numero ti sta mostrando il tuo strumento

Ogni strumento riporta una fetta diversa della stessa richiesta, ed è il motivo per cui due misurazioni di uno stesso sito spesso non coincidono:

• ping riporta solo la latenza di andata e ritorno, senza includere il lavoro del server
• curl -w riporta ogni confine elencato sopra, il che lo rende il riferimento quando i numeri non coincidono
• Gli strumenti per sviluppatori del browser mostrano il TTFB come la fase di attesa di una richiesta, separata dalla fase di download sottostante
• Lighthouse e PageSpeed riportano il server response time, che è il TTFB per la richiesta del documento
• I monitor di uptime riportano un tempo di risposta la cui definizione varia da prodotto a prodotto, e che include la configurazione della connessione da qualunque punto sia stato eseguito il controllo
• Il real user monitoring riporta il TTFB sul campo, aggregato tra visitatori reali su reti reali

Come si presenta un buon numero

La latenza è limitata dalla geografia. Sotto i 30 ms è normale all'interno di una singola area metropolitana, 50-100 ms attraverso un continente, e 150-250 ms tra continenti. Un percorso che misura ben oltre la distanza suggerisce un cattivo instradamento più che un server lento.

Per il TTFB, web.dev considera buono un valore di 800 ms o meno e scarso qualsiasi cosa oltre 1,8 secondi, mentre l'audit sul server response time di Lighthouse inizia a fallire sopra i 600 ms. Punta a stare sotto i 600 ms per la richiesta del documento e considera 200 ms come obiettivo per tutto ciò che è in cache o servito staticamente.

Il tempo di risposta totale dipende dalla dimensione di ciò che stai inviando, quindi non esiste una cifra universale. Misura la tua baseline in una giornata normale e considera lo scostamento da essa come il segnale, non il numero assoluto.

Leggere gli scarti

I numeri singoli contano meno della distanza tra loro, perché ogni scarto punta a un sottosistema diverso:

• TTFB meno la latenza di andata e ritorno è approssimativamente quanto ha "pensato" il server. Se questa è la parte più grande, il problema è nel codice applicativo, in una query lenta o in una cache fredda
• Connect meno la risoluzione DNS è un round trip per l'handshake TCP. Se è molto più grande della latenza che hai misurato, il percorso di rete è congestionato o instradato male
• TLS meno connect è il costo dell'handshake, tipicamente uno o due round trip aggiuntivi, e un valore alto indica problemi con la catena di certificati o con la ripresa di sessione
• Total meno TTFB è il tempo di trasferimento. Se questo predomina, la risposta è troppo grande o la connessione è troppo lenta, e nessuna ottimizzazione del server aiuterà
• La risoluzione DNS da sola dovrebbe essere di pochi millisecondi una volta in cache. Una risoluzione costantemente lenta è un problema del resolver o del nameserver autoritativo, non del web server

La stessa lettura funziona al contrario quando solo una postazione è lenta. Un tempo di elaborazione del server uguale ovunque, con la differenza che vive interamente nella latenza e nel trasferimento, significa che il server sta bene e non è il percorso a esserlo. Esegui il controllo da più postazioni prima di toccare l'applicazione.

Misurarlo in un unico posto

Per vedere questi numeri per una pagina senza assemblarli a mano, esegui il test di velocità della pagina, che carica la pagina da una postazione esterna e scompone il caricamento nelle sue fasi. La guida al tempo di risposta del server tratta la stessa misurazione da riga di comando. Una singola esecuzione ti dice qualcosa solo su quel momento, quindi se il numero conta, imposta un controllo pianificato: HostTracker misura il tempo di risposta a ogni controllo da oltre 300 postazioni in 158 città, ed è questo che trasforma una singola lettura in una baseline rispetto alla quale puoi individuare una regressione. Altre definizioni sono nella sezione sui concetti di monitoraggio.