Ottimizzare la sotto-parte Connection Duration (TCP + TLS) del Time to First Byte

Ottimizzare la Connection Duration (TCP + TLS) Sotto-parte del Time to First Byte

Questo articolo fa parte della nostra guida sul Time to First Byte (TTFB). La connection duration è la quarta sotto-parte del TTFB e rappresenta il tempo che il browser impiega a stabilire una connessione TCP e a negoziare la crittografia TLS con il server. Per gli utenti geograficamente distanti dal server, la connection duration può aggiungere da 100 a 500 millisecondi al TTFB a causa dei molteplici round-trip richiesti per gli handshake TCP e TLS.

Il Time to First Byte (TTFB) può essere scomposto nelle seguenti sotto-parti:

• Waiting + Redirect (o waiting duration)
• Worker + Cache (o cache duration)
• DNS (o DNS duration)
• Connection (o connection duration)
• Request (o request duration)

Vuoi ottimizzare il Time to First Byte? Questo articolo copre la parte relativa alla connection duration del Time to First Byte. Se stai cercando di capire o risolvere il Time to First Byte e non sai cosa significhi connection duration, ti preghiamo di leggere cos'è il Time to First Byte e identificare e risolvere i problemi di Time to First Byte prima di iniziare con questo articolo.

La parte relativa alla connection duration del Time to First Byte consiste nel tempo in cui il browser si connette al server web. Dopo tale connessione, il browser e il server solitamente aggiungono uno strato di crittografia (TLS). Il processo di negoziazione di queste 2 connessioni richiederà del tempo, e quel tempo viene aggiunto al Time to First Byte.

Processo di connessione in dettaglio

Il Transmission Control Protocol (TCP) è responsabile dello stabilire una connessione affidabile tra il client (browser) e il server. Questo processo comporta un handshake a tre vie (three-way handshake):

• Pacchetto SYN (Synchronize): il client invia un pacchetto SYN al server per avviare la connessione e richiedere la sincronizzazione.
• Pacchetto SYN-ACK (Synchronize-Acknowledge): il server risponde con un pacchetto SYN-ACK, confermando la ricezione del pacchetto SYN e accettando di stabilire una connessione.
• Pacchetto ACK (Acknowledge): il client invia un pacchetto ACK al server, confermando la ricezione del pacchetto SYN-ACK. A questo punto, viene stabilita una connessione TCP, consentendo il trasferimento affidabile dei dati tra client e server.

Il TCP garantisce che i dati vengano inviati e ricevuti nell'ordine corretto, reinviando eventuali pacchetti persi e gestendo il controllo del flusso per adattarsi alla capacità della rete.

Una volta stabilita la connessione TCP, viene utilizzato il protocollo Transport Layer Security (TLS) per proteggere la connessione. L'handshake TLS prevede diverse fasi per autenticare il server e stabilire un canale di comunicazione sicuro:

• ClientHello: il client invia un messaggio "ClientHello" al server, indicando le versioni TLS supportate, le suite di crittografia e un numero casuale (Client Random).
• ServerHello: il server risponde con un messaggio "ServerHello", selezionando la versione TLS e la suite di crittografia dall'elenco del client e fornendo il suo certificato digitale e un numero casuale (Server Random).
• Scambio di certificati e chiavi: il server invia il suo certificato digitale al client per l'autenticazione. Il client verifica il certificato rispetto alle autorità di certificazione attendibili.
• Premaster Secret: il client genera un premaster secret, lo crittografa con la chiave pubblica del server (contenuta nel certificato) e lo invia al server.
• Generazione della chiave di sessione: sia il client che il server utilizzano il premaster secret, insieme al Client Random e al Server Random, per generare una chiave di sessione condivisa per la crittografia simmetrica.
• Messaggi "Finished": il client e il server si scambiano messaggi crittografati con la chiave di sessione per confermare che l'handshake è riuscito e che entrambe le parti dispongono della chiave di sessione corretta.

Una volta completato l'handshake TLS, il client e il server hanno stabilito una connessione sicura e crittografata. Ciò garantisce che tutti i dati scambiati siano protetti dalle intercettazioni e dalle manomissioni da parte di terzi.

TLS 1.3 vs TLS 1.2: perché è importante per il TTFB

La versione di TLS utilizzata dal server ha un impatto diretto sulla connection duration. TLS 1.3 è più veloce di TLS 1.2 perché riduce il numero di round-trip necessari per completare l'handshake:

TLS 1.3 riduce l'handshake da due round-trip a uno. Per un utente che si trova a 100 ms di distanza dal server (tempo di round-trip), ciò consente di risparmiare circa 100 ms su ogni nuova connessione. Per i visitatori ricorrenti, la ripresa 0-RTT (zero round-trip time) di TLS 1.3 consente al client di inviare dati crittografati immediatamente dopo la riconnessione riutilizzando le informazioni di sessione precedentemente scambiate. Ciò può ridurre l'overhead dell'handshake TLS quasi a zero per i visitatori ricorrenti.

HTTP/3 e QUIC: il futuro delle connessioni veloci

HTTP/3 velocizza le connessioni TLS integrandosi con il protocollo QUIC, che riduce il numero di round-trip necessari per stabilire una connessione sicura combinando i processi di handshake in uno solo, e supporta la ripresa 0-RTT per riconnessioni più veloci. Inoltre, l'uso dell'UDP da parte di QUIC elimina l'head-of-line blocking e migliora il controllo della congestione, portando a una trasmissione dei dati più efficiente e a caricamenti di pagina più rapidi.

HTTP/3 apporta diversi miglioramenti rispetto a HTTP/2 que influenzano direttamente la connection duration:

• Handshake combinato: con HTTP/2 su TCP, l'handshake TCP e l'handshake TLS avvengono in sequenza (3 round-trip totali per una nuova connessione). HTTP/3 su QUIC combina il trasporto e l'handshake TLS in un unico round-trip. Per le nuove connessioni, ciò consente di risparmiare un intero round-trip rispetto a HTTP/2.
• Ripresa della connessione 0-RTT: come TLS 1.3, QUIC supporta la ripresa 0-RTT. I visitatori ricorrenti possono iniziare a inviare dati immediatamente senza attendere il completamento di alcun handshake. Questo è particolarmente efficace per gli utenti mobili che passano frequentemente dal Wi-Fi alla connessione cellulare.
• Nessun head-of-line blocking: con HTTP/2 su TCP, un singolo pacchetto perso blocca tutti gli stream su quella connessione finché il pacchetto non viene ritrasmesso. QUIC utilizza UDP e gestisce gli stream in modo indipendente, quindi un pacchetto perso influisce solo sullo specifico stream a cui appartiene. Ciò si traduce in prestazioni di connessione più costanti su reti inaffidabili.
• Migrazione della connessione: le connessioni QUIC sono identificate da un ID di connessione anziché da un IP e una porta sorgente. Ciò significa che quando un utente mobile passa dal Wi-Fi alla rete cellulare (e il suo indirizzo IP cambia), la connessione QUIC sopravvive senza necessità di essere ristabilita. Questo evita l'handshake TCP + TLS completo che sarebbe altrimenti richiesto.

In che modo il tempo di connessione influisce sul Time to First Byte?

Come ridurre al minimo l'impatto del tempo di connessione sul TTFB

Usa il Preconnect per le origini critiche

Il resource hint <link rel="preconnect"> indica al browser di stabilire una connessione (DNS + TCP + TLS) a un'origine specifica prima che le risorse di quell'origine siano effettivamente necessarie. Ciò elimina la connection duration dal percorso critico quando la risorsa viene infine richiesta:

<!-- Preconnessione a origini di terze parti critiche -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preconnect" href="https://cdn.example.com">

Usa il preconnect con parsimonia (massimo 3-5 origini). Ogni preconnect apre una connessione TCP + TLS completa, che consuma CPU e risorse di rete. Effettua il preconnect solo per le origini necessarie ad ogni caricamento di pagina. Per le origini che sono necessarie solo occasionalmente, usa invece dns-prefetch (vedi la nostra guida alla DNS duration).

Configurazione del server per TLS 1.3 e HTTP/3

• HTTP/3: introduce il protocollo QUIC su UDP anziché TCP, consentendo un trasferimento dati più veloce ed efficiente.
• TLS 1.3: aggiunge maggiore sicurezza e riduce i round-trip dell'handshake. Richiesto per la ripresa della connessione 0-RTT.
• Ripresa della connessione 0-RTT: funzionalità di TLS 1.3 che consente ai client ricorrenti di inviare dati crittografati immediatamente dopo la riconnessione riutilizzando le informazioni scambiate in precedenza.
• TCP Fast Open: consente l'invio di dati nel pacchetto SYN iniziale, riducendo il tempo di round-trip per l'handshake TCP.
• TLS False Start: consente l'invio anticipato dei dati prima che l'handshake TLS sia completato.
• OCSP Stapling: velocizza la convalida del certificato eliminando la necessità per il client di contattare direttamente l'autorità di certificazione.

Ecco un esempio di configurazione Nginx che abilita TLS 1.3 e OCSP Stapling:

server {
    listen 443 ssl http2;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    # Suite di crittografia TLS 1.3
    ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

    # Abilita OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;
    resolver_timeout 5s;

    # Abilita la ripresa della sessione (ticket di sessione TLS)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets on;

    # ... resto della configurazione del server
}

Per Apache, abilita TLS 1.3 con:

<VirtualHost *:443>
    SSLEngine on
    SSLProtocol -all +TLSv1.2 +TLSv1.3

    # Abilita OCSP Stapling
    SSLUseStapling On
    SSLStaplingCache shmcb:/tmp/stapling_cache(128000)

    # Abilita la ripresa della sessione
    SSLSessionCache shmcb:/tmp/ssl_gcache_data(512000)
    SSLSessionCacheTimeout 300

    # ... resto della configurazione del virtual host
</VirtualHost>

Time to First Byte TIP: un CDN non solo offre tempi di round-trip più brevi. L'uso di un CDN spesso migliora immediatamente i tempi di connessione TCP e TLS perché i fornitori di CDN premium avranno configurato correttamente queste impostazioni per te. Consulta la nostra guida su come configurare Cloudflare per le prestazioni per iniziare.

Misurare la Connection Duration con JavaScript

Puoi misurare la sotto-parte connection duration del TTFB direttamente nel browser utilizzando la Navigation Timing API:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');

  const tcpDuration = nav.connectEnd - nav.connectStart;
  const tlsDuration = nav.connectEnd - nav.secureConnectionStart;
  const totalConnection = tcpDuration;

  console.log('Connection Duration:', totalConnection.toFixed(0), 'ms');
  console.log('  Handshake TCP:', (tcpDuration - tlsDuration).toFixed(0), 'ms');
  console.log('  Negoziazione TLS:', tlsDuration.toFixed(0), 'ms');

  if (nav.nextHopProtocol) {
    console.log('  Protocollo:', nav.nextHopProtocol);
  }
}).observe({
  type: 'navigation',
  buffered: true
});

La proprietà nextHopProtocol rivela quale protocollo è stato utilizzato per la connessione. I valori comuni sono "h2" (HTTP/2), "h3" (HTTP/3) e "http/1.1". Se il tuo server supporta HTTP/3 ma i tuoi dati RUM mostrano che la maggior parte delle connessioni utilizza "h2", potrebbe indicare che il supporto HTTP/3 non è pubblicizzato correttamente tramite l'header Alt-Svc.

Come trovare i problemi di TTFB causati da un tempo di connessione lento

Per scoprire l'impatto che gli utenti reali sperimentano a causa della latenza di connessione, dovrai utilizzare uno strumento RUM come CoreDash. Il Real User Monitoring ti consentirà di tracciare i Core Web Vitals in modo più dettagliato e senza il ritardo di 28 giorni di Google.

In CoreDash, fai clic su "Scomposizione del Time to First Byte" per visualizzare la parte relativa alla connessione del Time to First Byte.

Ulteriori letture: Guide all'ottimizzazione

Guide correlate:

• 103 Early Hints: il server può inviare resource hints (preload, preconnect) mentre sta ancora elaborando la risposta principale, consentendo al browser di iniziare a stabilire le connessioni prima.
• Configurare Cloudflare per le prestazioni: Cloudflare abilita automaticamente HTTP/3, TLS 1.3 e OCSP Stapling. L'uso di un CDN avvicina inoltre il tuo server agli utenti, riducendo i tempi di round-trip per tutte le connessioni.

Sotto-parti del TTFB: Guide complete

La connection duration è una delle cinque sotto-parti del TTFB. Esplora le altre sotto-parti per comprendere il quadro completo:

• Identificare e risolvere i problemi di TTFB: il punto di partenza diagnostico per tutta l'ottimizzazione del TTFB.
• Waiting Duration: reindirizzamenti, accodamento del browser e ottimizzazione HSTS.
• Cache Duration: prestazioni del service worker, ricerche nella cache del browser e bfcache.
• DNS Duration: selezione del fornitore DNS, configurazione TTL e dns-prefetch.
• Request Duration: tempo di elaborazione del server, query del database e ottimizzazione del backend.