Quando si parla di tempo di risposta del server, si pensa di solito al lavoro dell’applicazione: PHP che esegue WordPress, le query al database, la generazione dell’HTML. Ma prima che il server riceva anche solo la richiesta, il browser deve compiere una serie di passaggi: scoprire l’indirizzo del server, aprire una connessione, negoziare la cifratura. Ciascuno richiede uno o più viaggi di andata e ritorno sulla rete, e su una connessione mobile ogni viaggio può valere 50, 80, a volte 150 millisecondi.
Questi millisecondi fanno parte del TTFB che gli utenti sperimentano e che il Chrome UX Report misura: il Time to First Byte di campo parte dall’inizio della navigazione e include reindirizzamenti, risoluzione DNS, connessione e negoziazione TLS, non solo il tempo di elaborazione del server. Su un sito con una cache di pagina efficiente, possono rappresentare la parte principale del TTFB. In questo articolo vediamo cosa succede prima del primo byte, quanto costa ogni fase e cosa si può fare per ridurla.
Le fasi, in ordine
Quando un utente apre un indirizzo, il browser esegue in sequenza: eventuali reindirizzamenti, ciascuno con il proprio ciclo completo; la risoluzione DNS del nome del dominio; l’apertura della connessione TCP, con un viaggio di andata e ritorno; la negoziazione TLS, con uno o due viaggi a seconda della versione del protocollo; l’invio della richiesta e l’attesa della risposta, con un altro viaggio più il tempo di elaborazione del server. Con HTTP/3, TCP e TLS si fondono in un’unica fase, come abbiamo visto nell’articolo su HTTP/3 e QUIC.
I reindirizzamenti: il costo più evitabile
Il caso peggiore, ed è ancora frequente, è quello in cui l’utente arriva a un indirizzo che viene reindirizzato. Un link pubblicato come http://esempio.it produce una richiesta in chiaro, un reindirizzamento verso https://esempio.it, poi magari un secondo verso https://www.esempio.it, e un terzo per aggiungere la barra finale all’indirizzo. Ogni reindirizzamento è un ciclo completo di richiesta e risposta, a volte con una nuova connessione, e il tempo si somma prima ancora che la pagina venga richiesta.
Le soluzioni sono semplici. I link interni, le campagne, le condivisioni sui social e i profili devono puntare sempre all’indirizzo definitivo, con il protocollo, il dominio e il formato corretti. Le regole di reindirizzamento lato server devono portare direttamente alla destinazione finale in un solo passaggio, senza catene. E l’intestazione HSTS, con l’eventuale inclusione nella lista di precaricamento dei browser, fa sì che il browser passi direttamente a HTTPS senza nemmeno tentare la richiesta in chiaro.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preloadUn caso particolare riguarda le campagne pubblicitarie e i servizi di tracciamento dei link, che spesso passano per uno o più domini intermedi prima di arrivare al sito. Questi reindirizzamenti non sono controllabili dal sito, ma il loro costo si vede nei dati di campo delle pagine di destinazione, e vale la pena conoscerlo quando si analizza il TTFB del traffico a pagamento.
Il DNS
La risoluzione DNS traduce il nome del dominio nell’indirizzo del server. Il browser chiede prima alla propria cache, poi al sistema operativo, poi al resolver configurato, di solito quello del provider di connessione o un servizio pubblico, che a sua volta, se non conosce la risposta, interroga la catena di server fino a quello autoritativo per il dominio. La risposta si ferma al primo livello che la conosce ancora, e ogni livello la conserva per il tempo indicato dal TTL, il time to live del record.
Per il sito, le leve sono quattro. La prima è il provider DNS: un servizio con una rete anycast, cioè con server distribuiti in molte località che rispondono allo stesso indirizzo, risponde più rapidamente di un singolo server in un unico centro dati, soprattutto per utenti lontani. Molte CDN e registrar offrono DNS di questo tipo senza costi aggiuntivi. La seconda è il TTL: valori troppo bassi, di pochi secondi, costringono i resolver a interrogare spesso il server autoritativo; valori di qualche minuto o qualche ora permettono alle cache di rispondere nella maggior parte dei casi. I TTL molto bassi hanno senso solo quando si prevede di cambiare spesso gli indirizzi, per esempio durante una migrazione.
La terza sono le catene CNAME: un dominio che è un alias di un altro dominio, che a sua volta è un alias di un terzo, richiede più risoluzioni in sequenza. Le configurazioni con CDN e servizi esterni le producono facilmente; molti provider DNS offrono la risoluzione diretta degli alias alla radice del dominio per evitarle. La quarta è il record HTTPS, un tipo di record più recente che permette di comunicare al browser, già nella risposta DNS, i protocolli supportati dal server, come HTTP/3, e altri parametri di connessione, risparmiando tentativi successivi.
Per i domini di terze parti usati dalla pagina, come quelli di font, analytics o CDN esterne, la risoluzione DNS può essere anticipata con dns-prefetch o, per i domini critici, con preconnect, come spiegato nell’articolo su preload, preconnect e fetchpriority. La soluzione più efficace, però, resta ridurre il numero di domini diversi da cui la pagina dipende.
TCP e la distanza
L’apertura di una connessione TCP richiede un viaggio di andata e ritorno tra il dispositivo e il server, e la durata di quel viaggio dipende soprattutto dalla distanza fisica e dalla qualità della rete. Un utente a Milano che si collega a un server a Milano può avere pochi millisecondi di latenza; lo stesso utente verso un server negli Stati Uniti ne avrà più di cento, e ogni fase che richiede un viaggio li pagherà di nuovo.
Per questo la posizione del server conta: un sito con il pubblico in Italia dovrebbe avere il server, o almeno i punti di contatto con gli utenti, in Italia o nell’Europa vicina. Una CDN risolve il problema per i siti con un pubblico distribuito: la connessione viene aperta con il nodo più vicino all’utente, e il tratto verso il server d’origine avviene su connessioni già aperte e su reti di qualità. È uno dei vantaggi concreti delle CDN, da distinguere dalla cache delle pagine, come abbiamo visto parlando di Cloudflare.
TLS: versione, certificati e ripresa
La negoziazione TLS stabilisce la cifratura della connessione. Con TLS 1.2 richiede due viaggi di andata e ritorno; con TLS 1.3, standard dal 2018 e supportato da tutti i browser moderni, ne basta uno. Abilitare TLS 1.3 sul server, o verificare che lo sia, è quindi uno degli interventi più semplici e con il miglior rapporto costo beneficio. Quasi tutti i server web e le CDN moderne lo supportano; vale la pena disattivare le versioni obsolete, TLS 1.0 e 1.1, anche per ragioni di sicurezza.
Con TLS 1.3 esiste anche la ripresa della sessione: un browser che si è già collegato di recente allo stesso server può riutilizzare le chiavi negoziate in precedenza, e in modalità 0-RTT inviare la richiesta insieme al primo messaggio della negoziazione. Come per HTTP/3, la modalità 0-RTT viene usata solo per richieste senza effetti collaterali, perché i dati del primo messaggio potrebbero essere ritrasmessi da un aggressore.
Il certificato stesso ha un peso. Durante la negoziazione, il server invia il proprio certificato e quelli intermedi della catena: una catena lunga, o certificati con chiavi RSA di grandi dimensioni, aumentano i dati da trasmettere, e su reti lente possono richiedere pacchetti aggiuntivi. I certificati con chiavi ECDSA sono più piccoli e più rapidi da verificare, e sono ormai supportati ovunque; molte configurazioni servono entrambi i tipi, lasciando al client la scelta. Va inoltre verificato che il server invii la catena completa: se manca un certificato intermedio, alcuni client devono recuperarlo separatamente, con un ritardo ulteriore.
Un’ultima voce riguarda la verifica della revoca dei certificati. Per anni il meccanismo OCSP ha permesso ai client di chiedere all’autorità di certificazione se un certificato fosse ancora valido, con una richiesta aggiuntiva che la tecnica dell’OCSP stapling evitava includendo la risposta nella negoziazione. Negli ultimi anni diverse autorità di certificazione hanno iniziato ad abbandonare OCSP a favore di altri meccanismi, e i browser non effettuano più questa verifica in modo bloccante: oggi è un aspetto meno critico per le prestazioni di quanto fosse in passato, ma resta utile controllare la configurazione consigliata dalla propria autorità di certificazione.
# nginx: protocolli moderni e ripresa delle sessioni
ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_cache shared:SSL:20m;
ssl_session_timeout 1d;
ssl_early_data on; # 0-RTT: da valutare con attenzione
http2 on;Riutilizzare le connessioni
Il modo più efficace di ridurre il costo delle connessioni è aprirne meno. Con HTTP/2 e HTTP/3, tutte le risorse di un dominio viaggiano su un’unica connessione, e il costo di apertura si paga una volta sola. Ogni dominio aggiuntivo, invece, richiede la propria catena di DNS, TCP e TLS. Una pagina che carica font da un servizio esterno, librerie da una CDN pubblica, immagini da un sottodominio e script da cinque fornitori diversi apre sette o otto connessioni, ciascuna con il proprio costo, e spesso proprio nel momento critico del caricamento.
Ospitare sul proprio dominio le risorse necessarie al primo disegno, come font, CSS e script principali, elimina queste connessioni. Le pratiche di un tempo, come distribuire le risorse su più sottodomini per aumentare il numero di download paralleli, erano utili con HTTP/1.1 e sono oggi controproducenti. Anche il mantenimento delle connessioni aperte tra una richiesta e l’altra, con tempi di inattività adeguati, evita di riaprirle durante la navigazione tra le pagine.
Come misurare
Da riga di comando, curl permette di misurare con precisione il tempo di ciascuna fase:
curl -so /dev/null https://esempio.it/ -w '
reindirizzamenti: %{time_redirect}s
DNS: %{time_namelookup}s
TCP: %{time_connect}s
TLS: %{time_appconnect}s
primo byte: %{time_starttransfer}s
totale: %{time_total}s
'I valori sono cumulativi: il tempo del TLS include quelli di DNS e TCP, e così via. Eseguire il comando da località diverse, o da un server vicino agli utenti, dà un’idea realistica dei tempi di connessione. Nel browser, il pannello Network dei DevTools mostra le stesse fasi nella scheda Timing di ogni richiesta, e il waterfall le rende visibili a colpo d’occhio con i segmenti colorati all’inizio delle barre.
Sugli utenti reali, l’API Navigation Timing espone l’inizio e la fine di ogni fase: domainLookupStart e domainLookupEnd per il DNS, connectStart e connectEnd per la connessione, secureConnectionStart per il TLS, redirectStart e redirectEnd per i reindirizzamenti. Un sistema di Real User Monitoring che registra queste fasi separatamente permette di capire quale parte del TTFB dipende dalla rete e quale dal server, e di vedere come varia per paese, tipo di connessione o sorgente di traffico.
const n = performance.getEntriesByType( 'navigation' )[ 0 ];
const fasi = {
redirect: n.redirectEnd - n.redirectStart,
dns: n.domainLookupEnd - n.domainLookupStart,
connessione: n.connectEnd - n.connectStart,
tls: n.secureConnectionStart > 0 ? n.connectEnd - n.secureConnectionStart : 0,
server: n.responseStart - n.requestStart,
};Una lista di controllo
- Nessun reindirizzamento per gli indirizzi più usati; catene ridotte a un solo passaggio; HSTS attivo.
- Provider DNS con rete anycast, TTL di minuti o ore, poche catene CNAME, record HTTPS dove supportato.
- Server o CDN vicini agli utenti.
- TLS 1.3 attivo, versioni obsolete disattivate, ripresa delle sessioni configurata, catena del certificato completa, preferibilmente con certificati ECDSA.
- HTTP/2 o HTTP/3, poche connessioni verso domini diversi, risorse critiche sul proprio dominio, preconnect solo per i domini indispensabili.
In sintesi
Prima del primo byte ci sono reindirizzamenti, DNS, connessione e cifratura: fasi che dipendono dalla configurazione del sito più che dalla potenza del server, e che su una rete mobile possono valere diverse centinaia di millisecondi. Sono incluse nel TTFB misurato sul campo e quindi, a cascata, nell’LCP. Su un sito con una buona cache di pagina, sono spesso la parte più grande del tempo di risposta.
Gli interventi sono quasi tutti di configurazione e raramente costosi: eliminare i reindirizzamenti, scegliere un provider DNS veloce con TTL ragionevoli, avvicinare i server agli utenti, abilitare TLS 1.3 e la ripresa delle sessioni, ridurre i domini da contattare. Nessuno di questi interventi è spettacolare da solo, ma insieme possono dimezzare il tempo prima del primo byte, per tutte le pagine e per tutti gli utenti.
