Optimaliseer de Connection Duration (TCP + TLS) als onderdeel van de Time to First Byte

Optimaliseer de Connection Duration (TCP + TLS) als onderdeel van de Time to First Byte

Dit artikel maakt deel uit van onze Time to First Byte (TTFB) gids. De connection duration is het vierde onderdeel van de TTFB en vertegenwoordigt de tijd die de browser besteedt aan het tot stand brengen van een TCP-verbinding en het onderhandelen over TLS-encryptie met de server. Voor gebruikers die zich geografisch ver van de server bevinden, kan de connection duration 100 tot 500 milliseconden toevoegen aan de TTFB vanwege de meerdere round trips die vereist zijn voor de TCP- en TLS-handshakes.

De Time to First Byte (TTFB) kan worden opgesplitst in de volgende onderdelen:

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

Wil je de Time to First Byte optimaliseren? Dit artikel behandelt het connection duration gedeelte van de Time to First Byte. Als je de Time to First Byte wilt begrijpen of problemen wilt oplossen en niet weet wat de connection duration betekent, lees dan wat de Time to First Byte is en hoe je Time to First Byte problemen identificeert en oplost voordat je met dit artikel begint.

Het connection duration gedeelte van de Time to First Byte bestaat uit de tijd waarin de browser verbinding maakt met de webserver. Na die verbinding voegen de browser en server meestal een encryptielaag (TLS) toe. Het proces van het onderhandelen over deze 2 verbindingen kost tijd, en die tijd wordt opgeteld bij de Time to First Byte.

Verbindingsproces in detail

Het Transmission Control Protocol (TCP) is verantwoordelijk voor het tot stand brengen van een betrouwbare verbinding tussen de client (browser) en de server. Dit proces omvat een three-way handshake:

• SYN (Synchronize) pakket: De client stuurt een SYN-pakket naar de server om de verbinding te initiëren en synchronisatie aan te vragen.
• SYN-ACK (Synchronize-Acknowledge) pakket: De server reageert met een SYN-ACK pakket, waarmee de ontvangst van het SYN-pakket wordt bevestigd en akkoord wordt gegaan met het tot stand brengen van een verbinding.
• ACK (Acknowledge) pakket: De client stuurt een ACK-pakket terug naar de server om de ontvangst van het SYN-ACK pakket te bevestigen. Op dit punt is er een TCP-verbinding tot stand gebracht, waardoor data betrouwbaar kan worden overgedragen tussen de client en de server.

TCP zorgt ervoor dat data in de juiste volgorde wordt verzonden en ontvangen, verstuurt verloren pakketten opnieuw en beheert flow control om af te stemmen op de capaciteit van het netwerk.

Zodra de TCP-verbinding tot stand is gebracht, wordt het Transport Layer Security (TLS) protocol gebruikt om de verbinding te beveiligen. De TLS-handshake omvat verschillende stappen om de server te authenticeren en een veilig communicatiekanaal op te zetten:

• ClientHello: De client stuurt een "ClientHello"-bericht naar de server met de ondersteunde TLS-versies, cipher suites en een willekeurig getal (Client Random).
• ServerHello: De server reageert met een "ServerHello"-bericht, selecteert de TLS-versie en cipher suite uit de lijst van de client, en levert zijn digitale certificaat en een willekeurig getal (Server Random).
• Certificate and Key Exchange: De server stuurt zijn digitale certificaat naar de client voor authenticatie. De client verifieert het certificaat bij vertrouwde certificaatautoriteiten.
• Premaster Secret: De client genereert een premaster secret, versleutelt dit met de publieke sleutel van de server (uit het certificaat) en stuurt het naar de server.
• Session Key Generation: Zowel de client als de server gebruiken het premaster secret, samen met de Client Random en Server Random, om een gedeelde sessiesleutel (session key) te genereren voor symmetrische encryptie.
• Finished Messages: De client en server wisselen berichten uit die zijn versleuteld met de sessiesleutel om te bevestigen dat de handshake succesvol was en dat beide partijen de juiste sessiesleutel hebben.

Zodra de TLS-handshake is voltooid, hebben de client en server een veilige, versleutelde verbinding tot stand gebracht. Dit zorgt ervoor dat alle uitgewisselde data is beschermd tegen afluisteren en manipulatie door derden.

TLS 1.3 vs TLS 1.2: Waarom het belangrijk is voor TTFB

De TLS-versie die je server gebruikt, heeft een directe impact op de connection duration. TLS 1.3 is sneller dan TLS 1.2 omdat het aantal round trips dat nodig is om de handshake te voltooien wordt verminderd:

TLS 1.3 reduceert de handshake van twee round trips naar één. Voor een gebruiker die zich op 100 ms afstand van de server bevindt (round trip time), bespaart dit ongeveer 100 ms op elke nieuwe verbinding. Voor terugkerende bezoekers stelt de 0-RTT (zero round trip time) resumption van TLS 1.3 de client in staat om onmiddellijk versleutelde data te verzenden bij herverbinding, door eerder uitgewisselde sessie-informatie te hergebruiken. Dit kan de overhead van de TLS-handshake voor terugkerende bezoekers tot nagenoeg nul reduceren.

HTTP/3 en QUIC: De toekomst van snelle verbindingen

HTTP/3 versnelt TLS-verbindingen door te integreren met het QUIC-protocol. Dit vermindert het aantal round trips dat nodig is om een veilige verbinding op te zetten door de handshake-processen te combineren, en ondersteunt 0-RTT resumption voor snellere herverbindingen. Bovendien elimineert het gebruik van UDP door QUIC head-of-line blocking en verbetert het congestion control, wat leidt tot efficiëntere dataoverdracht en snellere laadtijden van de pagina.

HTTP/3 brengt verschillende verbeteringen ten opzichte van HTTP/2 die direct van invloed zijn op de connection duration:

• Gecombineerde handshake: Bij HTTP/2 over TCP vinden de TCP-handshake en de TLS-handshake achtereenvolgens plaats (in totaal 3 round trips voor een nieuwe verbinding). HTTP/3 over QUIC combineert de transport- en TLS-handshake in één enkele round trip. Voor nieuwe verbindingen bespaart dit een volledige round trip ten opzichte van HTTP/2.
• 0-RTT connection resumption: Net als TLS 1.3 ondersteunt QUIC 0-RTT resumption. Terugkerende bezoekers kunnen onmiddellijk beginnen met het verzenden van data zonder te hoeven wachten tot een handshake is voltooid. Dit is met name effectief voor mobiele gebruikers die vaak schakelen tussen wifi en mobiele verbindingen.
• Geen head-of-line blocking: Bij HTTP/2 over TCP blokkeert één verloren pakket alle streams op die verbinding totdat het pakket opnieuw is verzonden. QUIC gebruikt UDP en behandelt streams onafhankelijk van elkaar, dus een verloren pakket beïnvloedt alleen de specifieke stream waartoe het behoort. Dit resulteert in consistentere verbindingsprestaties op onbetrouwbare netwerken.
• Connection migration: QUIC-verbindingen worden geïdentificeerd door een connection ID in plaats van een bron-IP en poort. Dit betekent dat wanneer een mobiele gebruiker overschakelt van wifi naar mobiel (en het IP-adres verandert), de QUIC-verbinding behouden blijft zonder opnieuw te hoeven worden opgezet. Dit voorkomt de volledige TCP + TLS-handshake die anders vereist zou zijn.

Hoe beïnvloedt de verbindingstijd de Time to First Byte?

Hoe de impact van de verbindingstijd op de TTFB te minimaliseren

Gebruik Preconnect voor kritieke origins

De <link rel="preconnect"> resource hint vertelt de browser om een verbinding (DNS + TCP + TLS) op te zetten naar een opgegeven origin voordat er daadwerkelijk resources van die origin nodig zijn. Dit verwijdert de connection duration van het kritieke pad wanneer de resource uiteindelijk wordt opgevraagd:

<!-- Preconnect naar kritieke third-party origins -->
<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">

Gebruik preconnect spaarzaam (maximaal 3 tot 5 origins). Elke preconnect opent een volledige TCP + TLS-verbinding, wat CPU- en netwerkresources verbruikt. Gebruik preconnect alleen voor origins die bij elke paginalading nodig zijn. Voor origins die slechts af en toe nodig zijn, gebruik je in plaats daarvan dns-prefetch (zie onze DNS duration gids).

Serverconfiguratie voor TLS 1.3 en HTTP/3

• HTTP/3: brengt het QUIC-protocol via UDP in plaats van TCP, wat snellere en efficiëntere dataoverdracht mogelijk maakt.
• TLS 1.3: voegt meer veiligheid toe en vermindert handshake round trips. Vereist voor 0-RTT Connection resumption.
• 0-RTT Connection Resumption: TLS 1.3-functie die terugkerende clients in staat stelt onmiddellijk versleutelde data te verzenden bij herverbinding door eerder uitgewisselde informatie te hergebruiken.
• TCP Fast Open: stelt in staat om data te verzenden in het initiële SYN-pakket, wat de round-trip tijd voor de TCP-handshake vermindert.
• TLS False Start: maakt het vroegtijdig verzenden van data mogelijk voordat de TLS-handshake is voltooid.
• OCSP Stapling: versnelt certificaatvalidatie door de noodzaak voor de client om rechtstreeks contact op te nemen met de certificaatautoriteit weg te nemen.

Hier is een voorbeeld Nginx-configuratie die TLS 1.3 en OCSP Stapling inschakelt:

server {
    listen 443 ssl http2;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;

    # TLS 1.3 cipher suites
    ssl_ciphers TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

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

    # Schakel session resumption in (TLS session tickets)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets on;

    # ... rest van je serverconfiguratie
}

Voor Apache schakel je TLS 1.3 in met:

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

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

    # Schakel session resumption in
    SSLSessionCache shmcb:/tmp/ssl_gcache_data(512000)
    SSLSessionCacheTimeout 300

    # ... rest van je virtual host-configuratie
</VirtualHost>

Time to First Byte TIP: een CDN levert niet alleen kortere round trip times op. Het gebruik van een CDN zal vaak ook onmiddellijk de TCP- en TLS-verbindingstijden verbeteren, omdat premium CDN-providers deze instellingen correct voor je hebben geconfigureerd. Bekijk onze gids over hoe je Cloudflare configureert voor prestaties om aan de slag te gaan.

De connection duration meten met JavaScript

Je kunt het connection duration onderdeel van de TTFB rechtstreeks in de browser meten met behulp van de 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('  TCP handshake:', (tcpDuration - tlsDuration).toFixed(0), 'ms');
  console.log('  TLS negotiation:', tlsDuration.toFixed(0), 'ms');

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

De nextHopProtocol eigenschap onthult welk protocol is gebruikt voor de verbinding. Veelvoorkomende waarden zijn "h2" (HTTP/2), "h3" (HTTP/3) en "http/1.1". Als je server HTTP/3 ondersteunt maar je RUM-data laat zien dat de meeste verbindingen "h2" gebruiken, kan dit erop wijzen dat HTTP/3-ondersteuning niet correct wordt geadverteerd via de Alt-Svc header.

Hoe je TTFB-problemen vindt die worden veroorzaakt door een trage verbindingstijd

Om de impact van verbindingslatentie op de ervaring van echte gebruikers te vinden, heb je een RUM-tool zoals CoreDash nodig. Met Real User Monitoring kun je de Core Web Vitals veel gedetailleerder volgen en zonder de 28 dagen vertraging van Google.

Klik in CoreDash op "Time to First Byte breakdown" om het verbindingsgedeelte van de Time to First Byte te visualiseren.

Verder lezen: Optimalisatiegidsen

Gerelateerde gidsen:

• 103 Early Hints: de server kan resource hints (preload, preconnect) verzenden terwijl de hoofdresponse nog wordt verwerkt, waardoor de browser eerder kan beginnen met het opzetten van verbindingen.
• Cloudflare configureren voor prestaties: Cloudflare schakelt automatisch HTTP/3, TLS 1.3 en OCSP Stapling in. Het gebruik van een CDN brengt je server ook dichter bij gebruikers, wat round trip times voor alle verbindingen verkort.

TTFB-onderdelen: Complete gidsen

De connection duration is een van de vijf onderdelen van de TTFB. Verken de andere onderdelen om het volledige plaatje te begrijpen:

• TTFB-problemen identificeren en oplossen: het diagnostische startpunt voor alle TTFB-optimalisatie.
• Waiting Duration: redirects, browser queuing en HSTS-optimalisatie.
• Cache Duration: service worker prestaties, browser cache lookups en bfcache.
• DNS Duration: selectie van DNS-provider, TTL-configuratie en dns-prefetch.
• Request Duration: serververwerkingstijd, database query's en backend-optimalisatie.