Ottimizza la componente della durata della connessione (TCP + TLS) del Time to First Byte

Ottimizza la durata della connessione (TCP + TLS) del Time to First Byte

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

Il Time to First Byte (TTFB) si scompone nelle seguenti sotto-parti:

• Attesa + Redirect (o durata dell'attesa)
• Worker + Cache (o durata della cache)
• DNS (o durata del DNS)
• Connessione (o durata della connessione)
• Richiesta (o durata della richiesta)

Vuoi ottimizzare il Time to First Byte? Questo articolo copre la durata della connessione del Time to First Byte. Se vuoi comprendere o correggere il Time to First Byte e non sai cosa significa durata della connessione, leggi cos'è il Time to First Byte e correggi e identifica i problemi del Time to First Byte prima di iniziare con questo articolo.

La durata della connessione nel Time to First Byte consiste nel tempo in cui il browser si connette al server web. Dopo questa connessione, il browser e il server di solito aggiungono un livello di crittografia (TLS). Il processo di negoziazione di queste 2 connessioni richiede tempo. Questo tempo si somma al Time to First Byte.

Il processo di connessione in dettaglio

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

• Pacchetto SYN (Synchronize): Il client invia un pacchetto SYN al server. Questo avvia la connessione e richiede la sincronizzazione.
• Pacchetto SYN-ACK (Synchronize-Acknowledge): Il server risponde con un pacchetto SYN-ACK. Questo conferma la ricezione del pacchetto SYN e accetta di stabilire una connessione.
• Pacchetto ACK (Acknowledge): Il client invia un pacchetto ACK al server. Questo conferma la ricezione del pacchetto SYN-ACK. A questo punto, la connessione TCP è stabilita. Questo permette di trasferire i dati in modo affidabile tra client e server.

Il TCP assicura che i dati vengano inviati e ricevuti nell'ordine corretto. Reinvia i pacchetti persi e gestisce il controllo di flusso per adattarsi alla capacità della rete.

Una volta stabilita la connessione TCP, il protocollo Transport Layer Security (TLS) mette in sicurezza la connessione. L'handshake TLS prevede vari passaggi per autenticare il server e stabilire un canale di comunicazione sicuro:

• ClientHello: Il client invia un messaggio "ClientHello" al server. Indica le versioni TLS supportate, le cipher suite e un numero casuale (Client Random).
• ServerHello: Il server risponde con un messaggio "ServerHello". Seleziona la versione TLS e la cipher suite dalla lista del client. Fornisce 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 con le autorità di certificazione attendibili.
• Premaster Secret: Il client genera un premaster secret. Lo crittografa con la chiave pubblica del server (estratta dal certificato) e lo invia al server.
• Generazione della chiave di sessione: Sia il client che il server usano il premaster secret, insieme al Client Random e al Server Random. Questo genera 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. Questo conferma che l'handshake ha avuto successo e che entrambe le parti hanno la chiave di sessione corretta.

Completato l'handshake TLS, client e server hanno stabilito una connessione sicura e crittografata. Questo assicura che qualsiasi dato scambiato sia protetto da intercettazioni e manomissioni da parte di terzi.

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

La versione di TLS usata dal tuo server ha un impatto diretto sulla durata della connessione. 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 dal server (tempo di round trip), questo risparmia circa 100 ms su ogni nuova connessione. Per i visitatori di ritorno, la ripresa 0-RTT (zero round trip time) di TLS 1.3 permette al client di inviare dati crittografati immediatamente alla riconnessione. Lo fa riutilizzando le informazioni di sessione scambiate in precedenza. Questo può ridurre l'overhead dell'handshake TLS quasi a zero per i visitatori di ritorno.

HTTP/3 e QUIC: il futuro delle connessioni veloci

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

HTTP/3 porta diversi miglioramenti rispetto ad HTTP/2 che influenzano direttamente la durata della connessione:

• 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 l'handshake di trasporto e TLS in un singolo round trip. Per le nuove connessioni questo fa 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 di ritorno possono iniziare a inviare dati immediatamente. Non devono aspettare il completamento di alcun handshake. Questo è particolarmente efficace per gli utenti mobile che passano spesso tra Wi-Fi e connessioni cellulari.
• 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 usa UDP e gestisce gli stream in modo indipendente. Quindi un pacchetto perso influenza solo lo stream specifico a cui appartiene. Questo garantisce prestazioni di connessione più coerenti su reti inaffidabili.
• Migrazione della connessione: Le connessioni QUIC sono identificate da un ID di connessione, non da un IP di origine e da una porta. Questo significa che quando un utente mobile passa da Wi-Fi a cellulare (e il suo indirizzo IP cambia), la connessione QUIC sopravvive senza dover essere ristabilita. Questo evita l'handshake completo TCP + TLS che sarebbe altrimenti necessario.

Come impatta il tempo di connessione sul Time to First Byte?

Come minimizzare l'impatto del tempo di connessione sul TTFB

Usa il preconnect per le origini critiche

Il resource hint <link rel="preconnect"> dice al browser di stabilire una connessione (DNS + TCP + TLS) verso un'origine specificata prima che le risorse da quell'origine siano effettivamente necessarie. Questo elimina la durata della connessione dal percorso critico quando la risorsa viene infine richiesta:

<!-- Preconnettiti alle 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 o 5 origini). Ogni preconnect apre una connessione TCP + TLS completa, consumando CPU e risorse di rete. Usa il preconnect solo per le origini necessarie ad ogni caricamento di pagina. Per le origini necessarie solo occasionalmente, usa invece dns-prefetch (leggi la nostra guida sulla durata del DNS).

Configurazione del server per TLS 1.3 e HTTP/3

• HTTP/3: porta il protocollo QUIC su UDP invece che su TCP. Permette 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. Permette ai client di ritorno di inviare dati crittografati immediatamente alla riconnessione riutilizzando le informazioni scambiate in precedenza.
• TCP Fast Open: permette di inviare dati nel pacchetto SYN iniziale. Riduce il tempo di round-trip per l'handshake TCP.
• TLS False Start: permette l'invio anticipato di dati prima che l'handshake TLS sia completo.
• OCSP Stapling: velocizza la validazione del certificato. Elimina 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;

    # Cipher suite 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 (TLS session tickets)
    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>

Suggerimento sul Time to First Byte: una CDN non offre solo tempi di round trip più brevi. Usare una CDN migliora spesso immediatamente i tempi di connessione TCP e TLS. Questo perché i provider CDN premium avranno già configurato correttamente queste impostazioni per te. Leggi la nostra guida su come configurare Cloudflare per le performance per iniziare.

Misurare la durata della connessione con JavaScript

Puoi misurare la sotto-parte della durata della connessione del TTFB direttamente nel browser usando 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('Durata della connessione:', 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 usato 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 usa "h2", potrebbe indicare che il supporto ad HTTP/3 non è pubblicizzato correttamente tramite l'header Alt-Svc.

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

Per scoprire l'impatto causato dalla latenza di connessione sugli utenti reali, ti serve uno strumento RUM come CoreDash. Il Real User Monitoring ti permette di tracciare i Core Web Vitals in maggiore dettaglio e senza il ritardo di 28 giorni di Google.

In CoreDash, fai clic su "Time to First Byte breakdown" per visualizzare la parte di connessione del Time to First Byte.

Letture consigliate: guide all'ottimizzazione

Guide correlate:

• 103 Early Hints: il server può inviare resource hints (preload, preconnect) mentre sta ancora elaborando la risposta principale. Questo permette al browser di iniziare a stabilire le connessioni in anticipo.
• Configura Cloudflare per le performance: Cloudflare abilita automaticamente HTTP/3, TLS 1.3 e OCSP Stapling. Usare una CDN avvicina anche il tuo server agli utenti. Questo riduce i tempi di round trip per tutte le connessioni.

Sotto-parti del TTFB: guide complete

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

• Correggi e identifica i problemi del TTFB: il punto di partenza diagnostico per tutta l'ottimizzazione del TTFB.
• Durata dell'attesa: redirect, accodamento del browser e ottimizzazione HSTS.
• Durata della cache: performance dei service worker, consultazioni della cache del browser e bfcache.
• Durata del DNS: selezione del provider DNS, configurazione del TTL e dns-prefetch.
• Durata della richiesta: tempo di elaborazione del server, query al database e ottimizzazione del backend.