Optimiere die Verbindungsdauer (TCP + TLS) als Teilbereich des Time to First Byte

Optimiere die Verbindungsdauer (TCP + TLS) als Teilbereich des Time to First Byte

Dieser Artikel ist Teil unseres Time to First Byte (TTFB)-Leitfadens. Die Verbindungsdauer ist der vierte Teilbereich des TTFB und stellt die Zeit dar, die der Browser für den Aufbau einer TCP-Verbindung und die TLS-Verschlüsselungsverhandlung mit dem Server benötigt. Bei Nutzern, die geografisch weit vom Server entfernt sind, kann die Verbindungsdauer aufgrund der mehrfachen Roundtrips für die TCP- und TLS-Handshakes 100 bis 500 Millisekunden zum TTFB hinzufügen.

Der Time to First Byte (TTFB) kann in folgende Teilbereiche unterteilt werden:

• Warten + Weiterleitung (oder Wartezeit)
• Worker + Cache (oder Cache-Dauer)
• DNS (oder DNS-Dauer)
• Verbindung (oder Verbindungsdauer)
• Anfrage (oder Anfragedauer)

Du möchtest den Time to First Byte optimieren? Dieser Artikel bietet eine detaillierte Analyse des Verbindungsdauer-Anteils am Time to First Byte. Wenn du den Time to First Byte verstehen oder beheben möchtest und nicht weißt, was die Verbindungsdauer bedeutet, lies bitte zuerst Was ist der Time to First Byte und Time to First Byte-Probleme erkennen und beheben, bevor du mit diesem Artikel beginnst.

Der Verbindungsdauer-Anteil des Time to First Byte umfasst die Zeit, in der der Browser eine Verbindung zum Webserver aufbaut. 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 zum Time to First Byte hinzuaddiert.

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 umfasst einen Drei-Wege-Handshake:

• SYN (Synchronize) Paket: Der Client sendet ein SYN-Paket an den Server, um die Verbindung zu initiieren und eine Synchronisierung anzufordern.
• SYN-ACK (Synchronize-Acknowledge) Paket: Der Server antwortet mit einem SYN-ACK-Paket, bestätigt den Empfang des SYN-Pakets und stimmt dem Verbindungsaufbau zu.
• ACK (Acknowledge) Paket: 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 aufgebaut und ermöglicht eine zuverlässige Datenübertragung zwischen Client und Server.

TCP stellt sicher, dass Daten in der richtigen Reihenfolge gesendet und empfangen werden, sendet verlorene Pakete erneut und verwaltet die Flusskontrolle, um die Netzwerkkapazität optimal zu nutzen.

Sobald die TCP-Verbindung aufgebaut ist, wird das Transport Layer Security (TLS) Protokoll zur Absicherung der Verbindung verwendet. Der TLS-Handshake umfasst mehrere Schritte zur Authentifizierung des Servers und zum Aufbau eines sicheren Kommunikationskanals:

• ClientHello: Der Client sendet eine „ClientHello“-Nachricht an den Server, die die unterstützten TLS-Versionen, Cipher Suites und eine Zufallszahl (Client Random) enthält.
• ServerHello: Der Server antwortet mit einer „ServerHello“-Nachricht, wählt die TLS-Version und Cipher Suite aus der Liste des Clients und stellt sein digitales Zertifikat sowie eine Zufallszahl (Server Random) bereit.
• Zertifikat und Schlüsselaustausch: Der Server sendet sein digitales Zertifikat an den Client zur Authentifizierung. Der Client überprüft das Zertifikat anhand vertrauenswürdiger Zertifizierungsstellen.
• Premaster Secret: Der Client erzeugt ein Premaster Secret, verschlüsselt es mit dem öffentlichen Schlüssel des Servers (aus dem Zertifikat) und sendet es an den Server.
• Sitzungsschlüssel-Generierung: Sowohl Client als auch Server verwenden das Premaster Secret zusammen mit dem Client Random und Server Random, um einen gemeinsamen Sitzungsschlüssel für die symmetrische Verschlüsselung zu erzeugen.
• Abschlussnachrichten: Client und Server tauschen mit dem Sitzungsschlüssel verschlüsselte Nachrichten aus, um zu bestätigen, dass der Handshake erfolgreich war und beide Seiten den korrekten Sitzungsschlüssel besitzen.

Nach Abschluss des TLS-Handshakes 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 den TTFB wichtig ist

Die TLS-Version deines Servers hat einen direkten Einfluss auf die Verbindungsdauer. TLS 1.3 ist deutlich schneller als TLS 1.2, da weniger Roundtrips für den Abschluss des Handshakes benötigt werden:

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

HTTP/3 und QUIC: Die Zukunft schneller Verbindungen

HTTP/3 beschleunigt TLS-Verbindungen durch die Integration mit dem QUIC-Protokoll, das die Anzahl der für eine sichere Verbindung erforderlichen Roundtrips reduziert, indem die Handshake-Prozesse zu einem kombiniert werden, und 0-RTT-Wiederaufnahme für schnellere Wiederverbindungen unterstützt. Zusätzlich eliminiert QUICs Verwendung von UDP das Head-of-Line-Blocking und verbessert die Staukontrolle, was zu einer effizienteren Datenübertragung und schnelleren Seitenladezeiten führt.

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

• Kombinierter Handshake: Bei HTTP/2 über TCP finden der TCP-Handshake und der TLS-Handshake nacheinander statt (insgesamt 3 Roundtrips für eine neue Verbindung). HTTP/3 über QUIC kombiniert den Transport- und TLS-Handshake in einem einzigen Roundtrip. Bei neuen Verbindungen spart dies im Vergleich zu HTTP/2 einen ganzen Roundtrip.
• 0-RTT-Verbindungswiederaufnahme: Wie TLS 1.3 unterstützt auch QUIC die 0-RTT-Wiederaufnahme. Wiederkehrende Besucher können sofort mit der Datenübertragung beginnen, ohne auf den Abschluss eines Handshakes warten zu müssen. Dies ist besonders effektiv für mobile Nutzer, 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 dieser Verbindung, bis das Paket erneut übertragen wird. QUIC verwendet UDP und verarbeitet Streams unabhängig voneinander, sodass ein verlorenes Paket nur den betroffenen Stream beeinflusst. Dies führt zu einer konsistenteren Verbindungsleistung in unzuverlässigen Netzwerken.
• Verbindungsmigration: QUIC-Verbindungen werden durch eine Verbindungs-ID identifiziert, nicht durch Quell-IP und Port. Das bedeutet, dass die QUIC-Verbindung bestehen bleibt, wenn ein mobiler Nutzer von WLAN zu Mobilfunk wechselt (und sich seine IP-Adresse ändert), ohne dass sie neu aufgebaut werden muss. Dies vermeidet den vollständigen TCP- + TLS-Handshake, der sonst erforderlich wäre.

Wie beeinflusst die Verbindungszeit den Time to First Byte?

So minimierst du den Einfluss der Verbindungszeit auf den TTFB

Verwende Preconnect für wichtige Origins

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

<!-- Preconnect to critical 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">

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

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 Handshake-Roundtrips. Voraussetzung für 0-RTT-Verbindungswiederaufnahme.
• 0-RTT-Verbindungswiederaufnahme: TLS 1.3-Funktion, die es wiederkehrenden Clients ermöglicht, sofort verschlüsselte Daten 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 Roundtrip-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, indem die Notwendigkeit entfällt, dass der Client die Zertifizierungsstelle direkt kontaktieren 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;

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

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

    # ... rest of your server configuration
}

Für Apache aktivierst du TLS 1.3 mit:

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

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

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

    # ... rest of your virtual host configuration
</VirtualHost>

Time to First Byte TIPP: Ein CDN liefert nicht nur kürzere Roundtrip-Zeiten. Der Einsatz eines CDN verbessert oft sofort die TCP- und TLS-Verbindungszeiten, da Premium-CDN-Anbieter diese Einstellungen bereits korrekt für dich konfiguriert haben. Siehe unseren Leitfaden zur Konfiguration von Cloudflare für Performance, um loszulegen.

Verbindungsdauer mit JavaScript messen

Du kannst den Verbindungsdauer-Anteil des TTFB direkt im Browser mit 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. Gängige Werte sind „h2“ (HTTP/2), „h3“ (HTTP/3) und „http/1.1“. Wenn dein Server HTTP/3 unterstützt, aber deine RUM-Daten zeigen, dass die meisten Verbindungen „h2“ verwenden, kann dies darauf hindeuten, dass die HTTP/3-Unterstützung nicht korrekt über den Alt-Svc-Header angekündigt wird.

So findest du TTFB-Probleme, die durch langsame Verbindungszeiten verursacht werden

Um die Auswirkungen zu ermitteln, die echte Nutzer durch Verbindungslatenz erfahren, benötigst du ein RUM-Tool wie CoreDash. Real User Monitoring ermöglicht es dir, die Core Web Vitals detaillierter und ohne die 28-tägige Google-Verzögerung zu verfolgen.

Klicke in CoreDash auf „Time to First Byte Breakdown“, um den Verbindungsanteil des Time to First Byte zu visualisieren.

Weiterführende Lektüre: Optimierungsleitfäden

Für verwandte Optimierungstechniken, die die Verbindungsoptimierung ergänzen, erkunde diese Leitfäden:

• 103 Early Hints: Der Server kann Resource Hints (preload, preconnect) senden, während die Hauptantwort noch verarbeitet wird, sodass der Browser früher mit dem Verbindungsaufbau beginnen kann.
• Cloudflare für Performance konfigurieren: Cloudflare aktiviert automatisch HTTP/3, TLS 1.3 und OCSP Stapling. Die Verwendung eines CDN bringt deinen Server auch näher an die Nutzer, was die Roundtrip-Zeiten für alle Verbindungen reduziert.

TTFB-Teilbereiche: Detailartikel

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

• TTFB-Probleme erkennen und beheben: Der diagnostische Ausgangspunkt für alle TTFB-Optimierungen.
• Wartezeit: Weiterleitungen, Browser-Warteschlangen und HSTS-Optimierung.
• Cache-Dauer: Service-Worker-Performance, Browser-Cache-Abfragen und bfcache.
• DNS-Dauer: DNS-Anbieterauswahl, TTL-Konfiguration und dns-prefetch.