Server-Antwortzeit (TTFB) optimieren: Der vollständige Leitfaden

Was TTFB misst und warum es entscheidend ist

TTFB ist zwar kein offizieller Core Web Vital, aber die Basis für LCP, INP und damit für das gesamte Nutzererlebnis. Google hat 2023 explizit empfohlen, den TTFB unter 800 Millisekunden zu halten, wobei Werte unter 200 Millisekunden als optimal gelten (Google). Der Grund ist einfach: Alles, was der Browser anzeigt, muss zuerst vom Server geliefert werden. Ein TTFB von 800 Millisekunden bedeutet, dass der Browser fast eine Sekunde wartet, bevor er überhaupt mit dem Parsen des HTML beginnen kann.

Die Auswirkung auf Core Web Vitals ist direkt messbar: Eine Reduktion des TTFB um 500 Millisekunden verbessert den LCP um mindestens 500 Millisekunden, oft sogar mehr, weil der Browser früher mit dem Laden abhängiger Ressourcen beginnen kann. Für Websites, die den LCP-Schwellenwert von 2,5 Sekunden verfehlen, ist die TTFB-Optimierung daher oft der effektivste erste Schritt.

Die fünf Phasen des TTFB im Detail

Der TTFB setzt sich aus mehreren aufeinanderfolgenden Netzwerk- und Serverphasen zusammen. Um gezielt zu optimieren, müssen Sie verstehen, welche Phase den größten Anteil an der Gesamtzeit hat. Die Waterfall-Darstellung oben zeigt ein optimiertes Beispiel mit 162 Millisekunden Gesamtzeit.

Phase 1: DNS Lookup

Bevor der Browser eine Verbindung aufbauen kann, muss er den Domainnamen in eine IP-Adresse auflösen. Dieser DNS Lookup dauert typischerweise 10 bis 50 Millisekunden, kann aber bei schlechten DNS-Anbietern oder fehlender Cache-Nutzung über 200 Millisekunden betragen. DNS-Abfragen werden auf mehreren Ebenen gecacht: im Browser, im Betriebssystem, im Router und beim ISP. Nur die erste Abfrage nach Ablauf der TTL erfordert eine vollständige Auflösung.

• Schnellen DNS-Anbieter wählen: Premium-DNS-Dienste antworten in unter 15 Millisekunden weltweit. Der Wechsel von einem Standard-DNS zu einem spezialisierten Anbieter kann den DNS-Lookup um 50-100 Millisekunden verkürzen.
• DNS Prefetching nutzen: Das Tag <link rel="dns-prefetch" href="//cdn.example.com"> veranlasst den Browser, die DNS-Auflösung für externe Domains vorab durchzuführen.
• DNS-TTL optimieren: Eine TTL von 300 bis 3600 Sekunden bietet eine gute Balance zwischen Änderungsflexibilität und Cache-Effizienz.

Phase 2: TCP-Verbindungsaufbau

Der TCP-Drei-Wege-Handshake (SYN, SYN-ACK, ACK) dauert einen Round-Trip zwischen Browser und Server. Bei einem Server in Frankfurt und einem Nutzer in München sind das typischerweise 10 bis 20 Millisekunden. Bei einem Server in den USA und einem deutschen Nutzer können es über 100 Millisekunden sein. Die physische Distanz ist hier der entscheidende Faktor.

HTTP/2 und HTTP/3 reduzieren den TCP-Overhead erheblich. HTTP/2 multiplext alle Anfragen über eine einzige TCP-Verbindung, sodass der Handshake nur einmal stattfindet. HTTP/3 ersetzt TCP vollständig durch QUIC und kombiniert Verbindungsaufbau und Verschlüsselung in einem einzigen Round-Trip. Der Wechsel auf HTTP/3 kann bei mobilen Nutzern mit instabilen Verbindungen besonders große Verbesserungen bringen.

Phase 3: TLS-Handshake

Die Verschlüsselungsaushandlung bei HTTPS-Verbindungen erfordert mindestens einen zusätzlichen Round-Trip. TLS 1.2 benötigt zwei Round-Trips, TLS 1.3 nur einen. Da HTTPS für alle modernen Websites Standard ist, lohnt sich die Migration auf TLS 1.3 besonders. Die meisten modernen Webserver unterstützen TLS 1.3 bereits, es muss lediglich in der Konfiguration aktiviert werden.

Phase 4: Server Processing

Die Server-Verarbeitungszeit ist in der Regel die längste und am besten beeinflussbare Phase des TTFB. Sie umfasst alles, was auf dem Server passiert: Request-Routing, Authentifizierung, Datenbankabfragen, Template-Rendering und Response-Generierung. Bei einer unkonfigurierten WordPress-Installation mit 30 Plugins kann diese Phase allein 500 Millisekunden bis 2 Sekunden dauern.

Die Server-Verarbeitungszeit hängt von drei Faktoren ab: der Komplexität der Anwendung, der verfügbaren Server-Hardware und der Effizienz des Codes. Alle drei lassen sich optimieren, wobei der größte Hebel fast immer beim Caching liegt.

Phase 5: Antwortgenerierung und erstes Byte

Nachdem der Server die Antwort berechnet hat, muss er das erste Byte der HTTP-Response zurück an den Browser senden. Dieser letzte Schritt ist bei korrekter Konfiguration minimal (wenige Millisekunden), kann aber durch fehlende Komprimierung, übergrosse Response-Header oder Output-Buffering verzögert werden. Aktivieren Sie Brotli-Komprimierung für alle textbasierten Antworten und minimieren Sie Response-Header auf das Notwendige.

Server-seitiges Caching: Die effektivste Maßnahme

Caching ist die mit Abstand wirksamste Methode zur TTFB-Reduktion. Statt bei jedem Seitenaufruf die gesamte Verarbeitungskette durchzulaufen, wird die fertige HTML-Antwort im Speicher vorgehalten und direkt ausgeliefert. Der TTFB sinkt dabei von typischerweise 500 bis 1.000 Millisekunden auf 20 bis 50 Millisekunden.

Cache-Invalidierung richtig handhaben

Die größte Herausforderung beim Caching ist die Invalidierung: Wann wird der Cache geleert, damit Änderungen sichtbar werden? Zu aggressive Invalidierung reduziert die Cache-Hit-Rate und damit den Performance-Gewinn. Zu seltene Invalidierung zeigt veraltete Inhalte an. Die bewährte Strategie ist event-basierte Invalidierung: Der Cache wird nur dann geleert, wenn sich der Inhalt tatsächlich ändert, zum Beispiel bei Veröffentlichung eines neuen Blog-Posts oder bei Aktualisierung einer Produktseite.

Datenbankoptimierung für schnellere Antworten

Datenbankabfragen sind bei dynamischen Websites häufig der größte Zeitfresser in der Server-Verarbeitungsphase. Eine einzelne komplexe Abfrage kann 200 bis 500 Millisekunden dauern, und CMS-Systeme führen typischerweise 20 bis 100 Abfragen pro Seitenaufruf durch. Die Summe dieser Abfragen bestimmt maßgeblich den TTFB.

1. Slow-Query-Log aktivieren: Identifizieren Sie Abfragen, die länger als 100 Millisekunden dauern. Diese sind die ersten Kandidaten für Optimierung.
2. Indizes prüfen und erstellen: Fehlende Indizes auf häufig abgefragten Spalten sind die häufigste Ursache für langsame Abfragen. Ein passender Index kann eine Abfrage von 500 Millisekunden auf 5 Millisekunden beschleunigen.
3. N+1-Queries eliminieren: Dieses Anti-Pattern führt für jeden Datensatz eine separate Abfrage durch statt alles in einem Join zu laden. ORMs wie Eloquent oder Doctrine bieten Eager Loading als Lösung.
4. Query-Caching implementieren: Häufig ausgeführte Abfragen mit stabilen Ergebnissen sollten in Redis oder Memcached zwischengespeichert werden.
5. Connection Pooling nutzen: Jede neue Datenbankverbindung kostet 5 bis 15 Millisekunden. Connection Pooling hält Verbindungen offen und eliminiert diesen Overhead.
6. Datenbankwartung durchführen: Regelmäßiges OPTIMIZE TABLE bei MySQL oder VACUUM bei PostgreSQL verhindert Fragmentierung und hält die Abfrageleistung stabil.

Hosting-Infrastruktur: Die Hardware-Grundlage

Kein noch so guter Code kann die Limitierungen schlechter Hardware ausgleichen. Shared Hosting teilt CPU, RAM und I/O-Kapazität mit dutzenden anderen Websites. Wenn ein Nachbar-Account eine CPU-intensive Aufgabe ausführt, leidet Ihre TTFB. Für geschäftskritische Websites ist ein Upgrade auf dediziertere Ressourcen fast immer der wirtschaftlichere Weg.

Die Investition in besseres Hosting amortisiert sich über bessere Conversion-Raten, höhere Rankings und niedrigere Absprungraten. Für einen Online-Shop mit 500.000 Euro Jahresumsatz kann eine TTFB-Verbesserung von 800 auf 200 Millisekunden durch besseres Hosting eine Umsatzsteigerung von 3 bis 5 % bewirken (Aberdeen Group). Der Hosting-Uptime-Vergleich zeigt weitere Aspekte bei der Hosting-Wahl.

CDN-Konfiguration für optimalen TTFB

Ein Content Delivery Network reduziert den TTFB durch zwei Mechanismen: Es verkürzt die physische Distanz zwischen Nutzer und Server (niedrigere Latenz) und es cached Inhalte am Edge (weniger Server-Processing). Für eine Website mit DACH-Publikum bedeutet ein CDN, dass Besucher aus Wien, Zürich und Hamburg ihre Inhalte jeweils von einem nahegelegenen Edge-Server erhalten. Laut Akamai kann ein CDN die Ladezeit um 50 % oder mehr senken (Akamai).

Die CDN-Konfiguration entscheidet über den tatsächlichen Performance-Gewinn. Zu kurze Cache-TTLs führen zu unnötig vielen Origin-Anfragen. Zu lange TTLs verzögern Content-Updates. Die optimale Strategie hängt vom Content-Typ ab: Statische Assets wie Bilder, CSS und JavaScript sollten mit langen TTLs (1 Jahr) und Content-Hashing gecacht werden. HTML-Seiten können mit kürzeren TTLs (5 bis 60 Minuten) gecacht und bei Änderungen event-basiert invalidiert werden.

Webserver-Konfiguration: nginx, Apache und Caddy

Die Webserver-Konfiguration hat direkten Einfluss auf den TTFB. Fehlende Komprimierung, suboptimale Worker-Konfiguration und fehlende Keep-Alive-Einstellungen verschlechtern die Antwortzeit unnötig. Die folgenden Optimierungen gelten für alle gängigen Webserver.

• Komprimierung aktivieren: Brotli für statische Inhalte (voromprimiert beim Build), Gzip für dynamische Antworten. Reduziert die Transfer-Größe um 60-80 %.
• Keep-Alive konfigurieren: Hält TCP-Verbindungen offen für Folge-Anfragen und vermeidet wiederholte Handshakes. Timeout von 60-120 Sekunden ist für die meisten Anwendungen optimal.
• Worker-Prozesse anpassen: Die Anzahl der Worker sollte der Anzahl der CPU-Kerne entsprechen. Zu wenige Worker führen zu Warteschlangen, zu viele zu Context-Switching-Overhead.
• HTTP/2 aktivieren: Multiplexing über eine einzelne Verbindung. Bei nginx mit listen 443 ssl http2 in der Server-Konfiguration.
• sendfile und tcp_nopush: Diese nginx-Direktiven optimieren die Auslieferung statischer Dateien durch Nutzung von Kernel-Funktionen statt User-Space-Kopien.

server {
    listen 443 ssl http2;
    
    # Brotli-Komprimierung
    brotli on;
    brotli_comp_level 6;
    brotli_types text/html text/css application/javascript application/json image/svg+xml;
    
    # Gzip als Fallback
    gzip on;
    gzip_comp_level 6;
    gzip_types text/html text/css application/javascript application/json;
    
    # Keep-Alive
    keepalive_timeout 120;
    keepalive_requests 1000;
    
    # Statische Assets mit langem Cache
    location ~* \.(css|js|png|jpg|webp|avif|woff2)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
    
    # TLS 1.3 priorisieren
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    
    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
}

CMS-spezifische Optimierungen

Content-Management-Systeme sind die häufigste Ursache für hohe TTFB-Werte, weil sie bei jedem Seitenaufruf eine Kette von Datenbankabfragen, Plugin-Hooks und Template-Rendering durchlaufen. Die Optimierung hängt stark vom eingesetzten CMS ab.

WordPress: Von 800 ms auf 100 ms

WordPress führt bei einem typischen Seitenaufruf 50 bis 200 Datenbankabfragen durch und lädt 20 bis 40 Plugin-Dateien. Ohne Caching resultiert das in TTFB-Werten von 500 bis 1.500 Millisekunden. Die wirksamste Maßnahme ist ein Full-Page-Cache, der den TTFB auf unter 100 Millisekunden senkt. Zusätzlich sollten Sie Plugin-Anzahl auf das Nötige beschränken, Object Cache über Redis aktivieren, PHP OPcache und JIT-Compilation aktivieren sowie PHP 8.2 oder neuer verwenden.

Shopware und andere E-Commerce-Systeme

E-Commerce-Systeme sind besonders anfällig für hohe TTFB-Werte, weil Produktseiten, Kategorien und der Warenkorb dynamische Daten erfordern. Shopware CE profitiert von HTTP-Cache, OpenSearch für Produktsuche und Redis als Session-Storage. Produktkatalog-Seiten sollten aggressiv gecacht werden, während Warenkorb und Checkout-Seiten dynamisch bleiben müssen.

TTFB messen und überwachen

Eine einmalige TTFB-Messung zeigt nur eine Momentaufnahme. Der TTFB schwankt je nach Tageszeit, Server-Last, Cache-Status und Netzwerkbedingungen. Nur kontinuierliches Monitoring zeigt den tatsächlichen Zustand und erkennt Verschlechterungen frühzeitig.

• Chrome DevTools (Network Tab): Zeigt den TTFB für jede einzelne Anfrage. Nützlich für Einzelanalysen, aber keine Langzeitüberwachung.
• WebPageTest: Detaillierte Waterfall-Analyse mit TTFB-Aufschlüsselung nach DNS, TCP, TLS und Server-Processing. Kann von verschiedenen Standorten testen.
• XICTRAQ Performance-Monitoring: Automatisierte Messung von mehreren DACH-Standorten mit Trendanalyse und Alarmierung bei Verschlechterungen. Zeigt TTFB-Aufschlüsselung nach Phasen.
• Navigation Timing API: Browser-seitige Messung des TTFB für Real User Monitoring. Die cookieless Analytics von XICTRAQ nutzen diese API für DSGVO-konforme Felddaten.

Checkliste: TTFB unter 200 ms bringen

1. Aktuellen TTFB messen und Phasen-Aufschlüsselung prüfen
2. Server-seitiges Full-Page-Caching einrichten (Varnish oder nginx FastCGI Cache)
3. Object Cache mit Redis oder Memcached aktivieren
4. Datenbankabfragen optimieren (Indizes, N+1 eliminieren, Query Cache)
5. CDN mit Edge-Caching für statische und dynamische Inhalte konfigurieren
6. TLS 1.3 und OCSP Stapling aktivieren
7. HTTP/2 oder HTTP/3 auf dem Webserver aktivieren
8. Hosting evaluieren und bei Bedarf auf VPS oder Managed Hosting upgraden
9. Komprimierung (Brotli/Gzip) für alle textbasierten Antworten aktivieren
10. Kontinuierliches TTFB-Monitoring mit XICTRAQ einrichten

Warum kontinuierliches Monitoring unverzichtbar ist

TTFB-Werte ändern sich ständig. Ein CMS-Update kann die Datenbankabfragen verändern, ein neues Plugin kann die Server-Verarbeitungszeit erhöhen, und ein Hosting-Provider kann die Server-Ressourcen neu verteilen. Ohne kontinuierliche Überwachung bemerken Sie diese Verschlechterungen erst, wenn Nutzer abspringen oder Rankings sinken.

XICTRAQ misst den TTFB Ihrer Website rund um die Uhr von mehreren Standorten und schlüsselt die Messung in DNS, TCP, TLS und Server-Processing auf. Kombiniert mit Security-Scans, SEO-Monitoring und DSGVO-Compliance-Prüfungen erhalten Sie ein vollständiges Bild der Website-Gesundheit. Starten Sie mit einer kostenlosen Demo oder registrieren Sie sich direkt.