Optimieren der Verbindungsdauer (TCP + TLS) als Teilbereich der Time to First Byte

Optimieren der Verbindungsdauer (TCP + TLS) als Teilbereich der Time to First Byte

Dieser Artikel ist Teil unseres Time to First Byte (TTFB)-Leitfadens. Die Verbindungsdauer ist der vierte Teilbereich der TTFB und stellt die Zeit dar, die der Browser benötigt, um eine TCP-Verbindung herzustellen und die TLS-Verschlüsselung mit dem Server auszuhandeln. Für Benutzer, die geografisch weit vom Server entfernt sind, kann die Verbindungsdauer aufgrund der mehrfachen Round-Trips, die für die TCP- und TLS-Handshakes erforderlich sind, 100 bis 500 Millisekunden zur TTFB hinzufügen.

Die Time to First Byte (TTFB) lässt sich in die folgenden Teilbereiche untergliedern:

• Waiting + Redirect (oder Wartezeit)
• Worker + Cache (oder Cache-Dauer)
• DNS (oder DNS-Dauer)
• Connection (oder Verbindungsdauer)
• Request (oder Anfragedauer)

Möchten Sie die Time to First Byte optimieren? Dieser Artikel behandelt den Teilbereich der Verbindungsdauer der Time to First Byte. Wenn Sie die Time to First Byte verstehen oder beheben möchten und nicht wissen, was die Verbindungsdauer bedeutet, lesen Sie bitte Was ist die Time to First Byte und Identifizieren und Beheben von Time to First Byte-Problemen, bevor Sie mit diesem Artikel beginnen.

Die Verbindungsdauer als Teil der Time to First Byte besteht aus der Zeit, in der sich der Browser mit dem Webserver verbindet. Nach dieser Verbindung fügen Browser und Server in der Regel eine Verschlüsselungsschicht (TLS) hinzu. Der Prozess der Aushandlung dieser beiden Verbindungen nimmt einige Zeit in Anspruch, und diese Zeit wird zur Time to First Byte addiert.

Der Verbindungsprozess im Detail

Das Transmission Control Protocol (TCP) ist für den Aufbau einer zuverlässigen Verbindung zwischen dem Client (Browser) und dem Server verantwortlich. Dieser Prozess beinhaltet einen Drei-Wege-Handshake (Three-Way-Handshake):

• SYN-Paket (Synchronize): Der Client sendet ein SYN-Paket an den Server, um die Verbindung zu initiieren und eine Synchronisierung anzufordern.
• SYN-ACK-Paket (Synchronize-Acknowledge): Der Server antwortet mit einem SYN-ACK-Paket, bestätigt den Empfang des SYN-Pakets und stimmt dem Aufbau einer Verbindung zu.
• ACK-Paket (Acknowledge): Der Client sendet ein ACK-Paket zurück an den Server und bestätigt den Empfang des SYN-ACK-Pakets. Zu diesem Zeitpunkt ist eine TCP-Verbindung hergestellt, die eine zuverlässige Datenübertragung zwischen Client und Server ermöglicht.

TCP stellt sicher, dass Daten in der richtigen Reihenfolge gesendet und empfangen werden, überträgt verlorene Pakete erneut und verwaltet die Flusskontrolle entsprechend der Netzwerkkapazität.

Sobald die TCP-Verbindung steht, wird das Transport Layer Security (TLS)-Protokoll verwendet, um die Verbindung abzusichern. Der TLS-Handshake umfasst mehrere Schritte, um den Server zu authentifizieren und einen sicheren Kommunikationskanal zu etablieren:

• ClientHello: Der Client sendet eine "ClientHello"-Nachricht an den Server, in der die unterstützten TLS-Versionen, Cipher Suites und eine Zufallszahl (Client Random) angegeben werden.
• ServerHello: Der Server antwortet mit einer "ServerHello"-Nachricht, wählt die TLS-Version und Cipher Suite aus der Liste des Clients aus und stellt sein digitales Zertifikat sowie eine Zufallszahl (Server Random) zur Verfügung.
• Zertifikats- und Schlüsselaustausch: Der Server sendet sein digitales Zertifikat zur Authentifizierung an den Client. Der Client verifiziert das Zertifikat gegen vertrauenswürdige Zertifizierungsstellen.
• Premaster Secret: Der Client generiert ein Premaster Secret, verschlüsselt es mit dem öffentlichen Schlüssel des Servers (aus dem Zertifikat) und sendet es an den Server.
• Generierung des Session-Keys: Sowohl Client als auch Server verwenden das Premaster Secret zusammen mit dem Client Random und Server Random, um einen gemeinsamen Session-Key für die symmetrische Verschlüsselung zu generieren.
• Finished-Nachrichten: Client und Server tauschen mit dem Session-Key verschlüsselte Nachrichten aus, um zu bestätigen, dass der Handshake erfolgreich war und beide Parteien über den korrekten Session-Key verfügen.

Sobald der TLS-Handshake abgeschlossen ist, haben Client und Server eine sichere, verschlüsselte Verbindung aufgebaut. Dies stellt sicher, dass alle ausgetauschten Daten vor Abhören und Manipulation durch Dritte geschützt sind.

TLS 1.3 vs. TLS 1.2: Warum es für die TTFB wichtig ist

Die TLS-Version, die Ihr Server verwendet, hat direkte Auswirkungen auf die Verbindungsdauer. TLS 1.3 ist schneller als TLS 1.2, da es die Anzahl der für den Abschluss des Handshakes benötigten Round-Trips reduziert:

TLS 1.3 reduziert den Handshake von zwei Round-Trips auf einen. Bei einem Benutzer, der 100 ms vom Server entfernt ist (Round Trip Time), spart dies etwa 100 ms bei jeder neuen Verbindung. Für wiederkehrende Besucher ermöglicht die 0-RTT-Wiederaufnahme (Zero Round Trip Time) von TLS 1.3 dem Client, verschlüsselte Daten sofort nach der Wiederverbindung zu senden, indem zuvor ausgetauschte Session-Informationen wiederverwendet werden. Dies kann den Overhead des TLS-Handshakes für wiederkehrende Besucher auf fast null reduzieren.

HTTP/3 und QUIC: Die Zukunft schneller Verbindungen

HTTP/3 beschleunigt TLS-Verbindungen durch die Integration mit dem QUIC-Protokoll, welches die Anzahl der zum Aufbau einer sicheren Verbindung erforderlichen Round-Trips reduziert, indem die Handshake-Prozesse in einem kombiniert werden, und unterstützt die 0-RTT-Wiederaufnahme für schnellere Wiederverbindungen. Darüber hinaus eliminiert die Verwendung von UDP durch QUIC das Head-of-Line-Blocking und verbessert die Staukontrolle (Congestion Control), was zu einer effizienteren Datenübertragung und schnelleren Seitenladezeiten führt.

HTTP/3 bringt gegenüber HTTP/2 mehrere Verbesserungen mit sich, die sich direkt auf die Verbindungsdauer auswirken:

• Kombinierter Handshake: Bei HTTP/2 über TCP finden der TCP-Handshake und der TLS-Handshake sequenziell statt (insgesamt 3 Round-Trips für eine neue Verbindung). HTTP/3 über QUIC kombiniert den Transport- und TLS-Handshake in einem einzigen Round-Trip. Bei neuen Verbindungen spart dies im Vergleich zu HTTP/2 einen kompletten Round-Trip ein.
• 0-RTT Connection Resumption: Wie TLS 1.3 unterstützt QUIC die 0-RTT-Wiederaufnahme. Wiederkehrende Besucher können sofort mit dem Senden von Daten beginnen, ohne auf den Abschluss eines Handshakes warten zu müssen. Dies ist besonders effektiv für mobile Benutzer, die häufig zwischen WLAN- und Mobilfunkverbindungen wechseln.
• Kein Head-of-Line-Blocking: Bei HTTP/2 über TCP blockiert ein einzelnes verlorenes Paket alle Streams auf dieser Verbindung, bis das Paket erneut übertragen wurde. QUIC verwendet UDP und behandelt Streams unabhängig voneinander, sodass sich ein verlorenes Paket nur auf den spezifischen Stream auswirkt, zu dem es gehört. Dies führt zu einer konstanteren Verbindungsleistung in unzuverlässigen Netzwerken.
• Connection Migration: QUIC-Verbindungen werden durch eine Verbindungs-ID anstelle einer Quell-IP und eines Ports identifiziert. Das bedeutet, dass wenn ein mobiler Benutzer von WLAN zu Mobilfunk wechselt (und sich seine IP-Adresse ändert), die QUIC-Verbindung bestehen bleibt, ohne dass sie neu aufgebaut werden muss. Dies vermeidet den vollständigen TCP- + TLS-Handshake, der ansonsten erforderlich wäre.

Wie wirkt sich die Verbindungszeit auf die Time to First Byte aus?

Wie man den Einfluss der Verbindungszeit auf die TTFB minimiert

Preconnect für kritische Origins nutzen

Der <link rel="preconnect">-Resource-Hint weist den Browser an, eine Verbindung (DNS + TCP + TLS) zu einem bestimmten Origin (Ursprung) herzustellen, bevor Ressourcen von diesem Origin tatsächlich benötigt werden. Dadurch wird die Verbindungsdauer aus dem kritischen Pfad eliminiert, wenn die Ressource schließlich angefordert wird:

<!-- Preconnect für kritische Drittanbieter-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">

Setzen Sie Preconnect sparsam ein (maximal 3 bis 5 Origins). Jeder Preconnect öffnet eine vollständige TCP- + TLS-Verbindung, was CPU- und Netzwerkressourcen verbraucht. Nutzen Sie Preconnect nur für Origins, die bei jedem Seitenaufruf benötigt werden. Für Origins, die nur gelegentlich benötigt werden, verwenden Sie stattdessen dns-prefetch (siehe unseren Leitfaden zur DNS-Dauer).

Serverkonfiguration für TLS 1.3 und HTTP/3

• HTTP/3: bringt das QUIC-Protokoll über UDP anstelle von TCP und ermöglicht so eine schnellere und effizientere Datenübertragung.
• TLS 1.3: bietet mehr Sicherheit und reduziert die Handshake-Round-Trips. Erforderlich für die 0-RTT-Wiederaufnahme von Verbindungen.
• 0-RTT Connection Resumption: TLS-1.3-Funktion, die es wiederkehrenden Clients ermöglicht, verschlüsselte Daten sofort nach der Wiederverbindung zu senden, indem zuvor ausgetauschte Informationen wiederverwendet werden.
• TCP Fast Open: ermöglicht das Senden von Daten im initialen SYN-Paket und reduziert so die Round-Trip-Zeit für den TCP-Handshake.
• TLS False Start: ermöglicht das frühzeitige Senden von Daten, bevor der TLS-Handshake abgeschlossen ist.
• OCSP Stapling: beschleunigt die Zertifikatsvalidierung, da der Client nicht mehr direkt mit der Zertifizierungsstelle Kontakt aufnehmen muss.

Hier ist eine beispielhafte Nginx-Konfiguration, die TLS 1.3 und OCSP Stapling aktiviert:

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;

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

    # Session Resumption aktivieren (TLS Session Tickets)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets on;

    # ... restliche Serverkonfiguration
}

Aktivieren Sie TLS 1.3 für Apache mit:

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

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

    # Session Resumption aktivieren
    SSLSessionCache shmcb:/tmp/ssl_gcache_data(512000)
    SSLSessionCacheTimeout 300

    # ... restliche Virtual Host-Konfiguration
</VirtualHost>

Time to First Byte TIPP: Ein CDN liefert nicht nur kürzere Round-Trip-Zeiten. Die Nutzung eines CDNs verbessert TCP- und TLS-Verbindungszeiten oft sofort, da Premium-CDN-Anbieter diese Einstellungen bereits korrekt für Sie konfiguriert haben. Sehen Sie sich unseren Leitfaden zur Konfiguration von Cloudflare für Performance an, um loszulegen.

Messung der Verbindungsdauer mit JavaScript

Sie können den Teilbereich Verbindungsdauer der TTFB direkt im Browser mithilfe der Navigation Timing API messen:

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
});

Die Eigenschaft nextHopProtocol zeigt an, welches Protokoll für die Verbindung verwendet wurde. Häufige Werte sind "h2" (HTTP/2), "h3" (HTTP/3) und "http/1.1". Wenn Ihr Server HTTP/3 unterstützt, Ihre RUM-Daten jedoch zeigen, dass die meisten Verbindungen "h2" nutzen, könnte dies darauf hindeuten, dass die HTTP/3-Unterstützung nicht ordnungsgemäß über den Alt-Svc-Header angekündigt wird.

So finden Sie TTFB-Probleme, die durch langsame Verbindungszeiten verursacht werden

Um die Auswirkungen von Verbindungslatenzen auf echte Benutzer zu ermitteln, müssen Sie ein RUM-Tool wie CoreDash verwenden. Real User Monitoring (RUM) ermöglicht es Ihnen, die Core Web Vitals detaillierter und ohne die 28-tägige Verzögerung von Google zu verfolgen.

Klicken Sie in CoreDash auf "Time to First Byte breakdown", um den Verbindungsteil der Time to First Byte zu visualisieren.

Weiterführende Literatur: Optimierungsleitfäden

Verwandte Leitfäden:

• 103 Early Hints: Der Server kann Resource Hints (Preload, Preconnect) senden, während er noch die Hauptantwort verarbeitet, sodass der Browser früher mit dem Verbindungsaufbau beginnen kann.
• Cloudflare für Performance konfigurieren: Cloudflare aktiviert HTTP/3, TLS 1.3 und OCSP Stapling automatisch. Die Nutzung eines CDNs bringt Ihren Server zudem näher an die Benutzer und reduziert so die Round-Trip-Zeiten für alle Verbindungen.

TTFB-Teilbereiche: Vollständige Leitfäden

Die Verbindungsdauer ist einer von fünf Teilbereichen der TTFB. Entdecken Sie die anderen Teilbereiche, um das Gesamtbild zu verstehen:

• Identifizieren und Beheben von TTFB-Problemen: Der diagnostische Ausgangspunkt für alle TTFB-Optimierungen.
• Wartezeit (Waiting Duration): Redirects, Browser-Queuing und HSTS-Optimierung.
• Cache-Dauer (Cache Duration): Service Worker Performance, Browser-Cache-Lookups und BFCache.
• DNS-Dauer (DNS Duration): Auswahl des DNS-Anbieters, TTL-Konfiguration und dns-prefetch.
• Anfragedauer (Request Duration): Serververarbeitungszeit, Datenbankabfragen und Backend-Optimierung.