TTFB: Warum die Server-Antwortzeit alles bestimmt

TTFB ist kein einzelner Wert, sondern die Summe mehrerer aufeinanderfolgender Phasen. Die Gesamtzeit setzt sich zusammen aus der DNS-Auflösung (Übersetzung des Domainnamens in eine IP-Adresse), dem TCP-Verbindungsaufbau (Three-Way-Handshake), dem TLS-Handshake (Verschlüsselungsaushandlung bei HTTPS) und der Server-Verarbeitungszeit (die eigentliche Backend-Logik: Routing, Datenbankabfragen, Template-Rendering, Response-Generierung). Jede dieser Phasen bietet eigene Optimierungspotenziale.

Die Gewichtung der einzelnen Phasen variiert stark je nach Setup. Auf einem gut konfigurierten Server mit CDN macht die DNS-Auflösung typischerweise 10–30 Millisekunden aus, der TCP/TLS-Handshake 20–80 Millisekunden und die Server-Verarbeitung den Rest. Auf einem schlecht konfigurierten Shared-Hosting-Server kann allein die Server-Verarbeitung über eine Sekunde dauern. Die Chrome DevTools zeigen in der Network-Leiste die einzelnen Phasen für jeden Request – die Felder "DNS Lookup", "Initial Connection", "SSL" und "Waiting (TTFB)" schlüsseln die Zeiten präzise auf.

Wichtig ist die Unterscheidung zwischen Document TTFB und Resource TTFB. Der Document TTFB bezieht sich auf die HTML-Hauptseite und ist der Wert, den Google für die Core Web Vitals bewertet. Resource TTFB betrifft nachgeladene Ressourcen wie CSS, JavaScript und Bilder. Ein langsamer Document TTFB verzögert den gesamten Rendering-Prozess, weil der Browser erst nach Empfang des HTML-Dokuments weitere Ressourcen entdecken und laden kann.

Die DNS-Auflösung ist die erste Phase jeder HTTP-Verbindung und wird häufig übersehen. Bevor der Browser eine Verbindung zum Server aufbauen kann, muss er den Domainnamen in eine IP-Adresse übersetzen. Dieser Vorgang durchläuft mehrere DNS-Server: den lokalen Resolver des ISP, gegebenenfalls einen Recursive Resolver und schließlich den autoritativen Nameserver der Domain. Bei einer gut konfigurierten DNS-Infrastruktur dauert dieser Vorgang 10–30 Millisekunden, bei schlecht konfigurierten Setups kann er über 200 Millisekunden betragen.

Die wichtigsten DNS-Optimierungen sind: Anycast-DNS mit global verteilten Nameservern, die Anfragen automatisch zum nächstgelegenen Standort routen. Niedrige TTL-Werte (Time to Live) von 300–3600 Sekunden für häufig besuchte Domains, die den DNS-Cache der Resolver aktuell halten. DNS Prefetching über im HTML-Head für Drittanbieter-Domains, die auf der Seite benötigt werden. Und DNS-over-HTTPS (DoH) oder DNS-over-TLS (DoT) für verschlüsselte DNS-Anfragen, die Manipulation verhindern.

Ein oft vernachlässigter Aspekt ist die Anzahl der DNS-Lookups pro Seite. Jede eingebundene Drittanbieter-Domain – Analytics, Fonts, CDN, Social-Media-Widgets – erfordert einen separaten DNS-Lookup. Eine typische E-Commerce-Seite mit 15–20 Drittanbieter-Domains kann allein für DNS-Auflösungen 500–800 Millisekunden aufwenden. Die Konsolidierung von Ressourcen auf wenige Domains und die Nutzung von dns-prefetch für unvermeidbare externe Domains reduziert diesen Overhead erheblich. In der technischen Analyse identifizieren wir alle DNS-Lookups und ihre jeweilige Auflösungszeit.

Der TLS-Handshake ist der Prozess, bei dem Browser und Server die Verschlüsselung für die HTTPS-Verbindung aushandeln. Mit TLS 1.2 erfordert dieser Vorgang zwei Roundtrips (Hin- und Rückweg der Datenpakete), was je nach Netzwerklatenz 50–150 Millisekunden kostet. TLS 1.3 – seit 2018 standardisiert und von allen modernen Browsern unterstützt – reduziert dies auf einen einzigen Roundtrip und unterstützt darüber hinaus 0-RTT Resumption: Bei wiederholten Besuchen kann die Verschlüsselung ohne zusätzlichen Roundtrip wiederaufgenommen werden (Quelle: IETF RFC 8446).

Die Migration auf TLS 1.3 ist eine der effektivsten Maßnahmen zur TTFB-Reduktion. Weitere TLS-Optimierungen umfassen OCSP Stapling: Statt dass der Browser den Zertifikatsstatus beim OCSP-Server der Zertifizierungsstelle abfragen muss (was einen zusätzlichen DNS-Lookup und HTTP-Request erfordert), liefert der Server die OCSP-Antwort direkt mit dem Zertifikat. HTTP/2 und HTTP/3: Während HTTP/2 Multiplexing über eine einzige TLS-Verbindung ermöglicht, geht HTTP/3 mit QUIC noch weiter und integriert den TLS-Handshake direkt in den Verbindungsaufbau – der erste Request kann bereits mit dem TLS-Handshake gesendet werden.

Die Zertifikatskette spielt ebenfalls eine Rolle: Ein Zertifikat mit einer langen Kette (Root CA, Intermediate CA, Server-Zertifikat) erfordert mehr Daten im Handshake als ein Zertifikat mit kurzer Kette. ECDSA-Zertifikate sind dabei deutlich kleiner als RSA-Zertifikate (256 Bit vs. 2048–4096 Bit Schlüssellänge) und beschleunigen den Handshake spürbar. In der Server-Optimierung konfigurieren wir die optimale TLS-Konfiguration für minimale Handshake-Zeiten.

Die Server-Verarbeitungszeit ist in den meisten Fällen die dominierende Komponente des TTFB. Sie umfasst alles, was auf dem Server passiert, nachdem die Anfrage empfangen wurde: Routing, Middleware-Ausführung, Datenbankabfragen, Template-Rendering und Response-Generierung. Auf einem typischen PHP-basierten CMS oder Shop-System (WordPress, Shopware, TYPO3) besteht die Verarbeitungszeit aus hunderten von Funktionsaufrufen, dutzenden Datenbankabfragen und dem Zusammensetzen des HTML-Dokuments.

Der effektivste Hebel ist der OPcache (Opcode Cache). PHP-Code wird bei jedem Request interpretiert: Quellcode wird gelesen, geparst, in Opcodes kompiliert und ausgeführt. OPcache speichert die kompilierten Opcodes im Arbeitsspeicher und überspringt die Parse- und Kompilierungsphase bei nachfolgenden Requests. Die Aktivierung von OPcache reduziert die PHP-Ausführungszeit typischerweise um 50–70 % (Quelle: PHP.net, 2024). Der JIT-Compiler in PHP 8.x geht noch weiter und übersetzt häufig ausgeführte Opcodes in nativen Maschinencode.

Der zweite große Hebel sind Datenbankabfragen. Eine typische Shopware-Produktdetailseite führt 30–80 SQL-Queries aus – für Produktdaten, Varianten, Preise, Bilder, Kategorien, SEO-URLs und Cross-Selling. Jede einzelne Query wird an die Datenbank gesendet, dort geparsed, optimiert, ausgeführt und das Ergebnis zurückgesendet. Fehlende Indizes, nicht-optimale JOINs und unnötige Abfragen summieren sich schnell zu mehreren hundert Millisekunden Verarbeitungszeit. Das systematische Analysieren und Optimieren der Datenbankabfragen ist einer der wirkungsvollsten Schritte in der Server-Optimierung.

Die Datenbankoptimierung beginnt mit der Aktivierung des Slow-Query-Logs. MySQL und MariaDB können alle Queries protokollieren, die länger als einen konfigurierbaren Schwellenwert dauern (empfohlen: 0,1 Sekunden). Dieses Log zeigt die langsamsten Queries, ihre Häufigkeit und den fehlenden Index – das sind die Queries, die den TTFB am stärksten belasten.

Der nächste Schritt ist die EXPLAIN-Analyse der identifizierten Slow Queries. Das EXPLAIN-Statement zeigt, wie die Datenbank eine Query ausführt: welche Indizes verwendet werden, wie viele Zeilen gescannt werden und ob ein Full Table Scan stattfindet. Ein Full Table Scan auf einer Tabelle mit 500.000 Produkten kann hunderte Millisekunden dauern – der richtige Index reduziert diese Zeit auf unter eine Millisekunde. Composite Indizes für häufig gemeinsam abgefragte Spalten, Covering Indizes für Queries, die nur indizierte Spalten abfragen, und die Vermeidung von SELECT * zugunsten spezifischer Spaltenauswahl sind die wichtigsten Optimierungsmuster.

Die Buffer-Pool-Dimensionierung ist der dritte kritische Faktor. Der InnoDB Buffer Pool ist der Bereich im Arbeitsspeicher, in dem die Datenbank häufig abgefragte Daten und Indizes zwischenspeichert. Ein zu kleiner Buffer Pool zwingt die Datenbank, Daten von der Festplatte zu lesen – um Größenordnungen langsamer als der Arbeitsspeicher. Die Faustregel: Der Buffer Pool sollte 60–80 % des verfügbaren RAM auf dedizierten Datenbankservern umfassen. Die Variable Innodb_buffer_pool_read_requests vs. Innodb_buffer_pool_reads zeigt die Cache-Hit-Rate – sie sollte über 99 % liegen.

Caching ist die wirkungsvollste Methode, den TTFB zu reduzieren, weil es die Backend-Verarbeitung teilweise oder vollständig überspringt. Ein durchdachtes Caching-Konzept arbeitet auf mehreren Ebenen: Opcode-Cache (OPcache), Objekt-Cache (Redis/Memcached), Full-Page-Cache (Varnish/Nginx FastCGI Cache) und CDN-Cache (Edge Caching). Jede Ebene reduziert den Anteil der Arbeit, die der Origin-Server leisten muss.

Der Full-Page-Cache hat den größten Impact: Statt die gesamte PHP-Verarbeitung, Datenbankabfragen und Template-Rendering bei jedem Request zu wiederholen, wird das fertige HTML-Dokument im Arbeitsspeicher eines Reverse Proxys wie Varnish gespeichert und bei nachfolgenden Requests direkt ausgeliefert. Der TTFB sinkt von typischerweise 300–800 Millisekunden (Backend-Processing) auf 5–20 Millisekunden (Varnish-Auslieferung). Die Herausforderung liegt in der korrekten Cache-Invalidierung: Bei Produktänderungen, Preisanpassungen oder Content-Updates muss der Cache gezielt für die betroffenen Seiten invalidiert werden.

Der Objekt-Cache mit Redis oder Memcached speichert häufig abgefragte Datensätze im Arbeitsspeicher: Produktkataloge, Kategoriestrukturen, Konfigurationseinstellungen und Sessiondaten. Statt diese Daten bei jedem Request aus der Datenbank zu laden, werden sie aus dem schnellen In-Memory-Cache gelesen. Redis bietet dabei den Vorteil der Persistenz: Bei einem Server-Neustart gehen die gecachten Daten nicht verloren. Für Shopware-Shops reduziert ein korrekt konfigurierter Redis-Cache die Anzahl der Datenbankabfragen pro Request typischerweise um 60–80 % (Projekterfahrung).

Ein Content Delivery Network (CDN) verteilt Inhalte auf Server (Points of Presence, PoPs) weltweit und liefert sie vom nächstgelegenen Standort aus. Der physische Vorteil: Licht benötigt ca. 5 Millisekunden pro 1.000 Kilometer Glasfaserkabel. Ein Nutzer in München, dessen Server in Frankfurt steht (300 km), hat eine minimale Netzwerklatenz von ca. 3 Millisekunden pro Roundtrip. Ein Nutzer in New York (6.000 km) dagegen mindestens 30 Millisekunden. Ein CDN-PoP in New York eliminiert diese zusätzliche Latenz für nordamerikanische Nutzer.

Moderne CDNs gehen über das reine Ausliefern statischer Dateien hinaus. Edge Computing ermöglicht die Ausführung von Logik direkt an den PoPs – etwa das Rendering personalisierter Inhalte, A/B-Test-Varianten oder Geo-basierter Anpassungen, ohne einen Roundtrip zum Origin-Server. Stale-While-Revalidate-Strategien liefern gecachte Inhalte sofort aus, während im Hintergrund eine aktualisierte Version vom Origin-Server geladen wird. Diese Technik kombiniert niedrige TTFB-Werte mit hoher Aktualität.

Die CDN-Konfiguration erfordert eine differenzierte Strategie. Statische Assets (Bilder, CSS, JavaScript, Fonts) sollten mit langen Cache-TTLs (mindestens 30 Tage) gecacht werden, HTML-Dokumente mit kurzen TTLs (60–300 Sekunden) oder Stale-While-Revalidate. Personalisierte Inhalte (Warenkorb, eingeloggter Bereich) dürfen nicht gecacht werden und müssen per Cache-Bypass an den Origin weitergeleitet werden. In der Server-Optimierung konfigurieren wir die optimale CDN-Strategie für Ihre spezifische Website-Architektur.

Die systematische TTFB-Diagnose beginnt mit der Messung an mehreren Standorten. Ein TTFB von 200 Millisekunden in Frankfurt, aber 1.200 Millisekunden in New York deutet auf ein CDN-Problem hin. Ein konsistent hoher TTFB unabhängig vom Standort zeigt ein Backend-Problem. Tools wie WebPageTest ermöglichen Tests von über 30 Standorten weltweit und zeigen die TTFB-Komponenten (DNS, Connect, TLS, Wait) einzeln an.

Die nächste Ebene ist die Server-seitige Analyse. Das Xdebug-Profiling für PHP-Anwendungen zeigt exakt, welche Funktionen wie viel Zeit verbrauchen. Der MySQL Slow-Query-Log identifiziert langsame Datenbankabfragen. Tools wie top, htop und vmstat zeigen die Server-Auslastung in Echtzeit – hohe CPU-Last, Speicher-Swapping oder I/O-Engpässe sind häufige Ursachen für schwankende TTFB-Werte.

Ein häufig übersehener Faktor sind TTFB-Spitzen unter Last. Ein Server, der bei einzelnen Requests 200 Millisekunden TTFB liefert, kann bei 50 gleichzeitigen Anfragen auf 2 Sekunden ansteigen – weil PHP-Worker erschöpft sind, Datenbankverbindungen warten oder der Arbeitsspeicher nicht ausreicht. Lasttests mit Tools wie k6 oder Apache Bench simulieren realistischen Traffic und decken Skalierungsprobleme auf, bevor sie im Produktivbetrieb auftreten. Die Performance-Analyse umfasst immer auch Lasttests unter realistischen Bedingungen.

Das HTTP-Protokoll hat sich in den letzten Jahren erheblich weiterentwickelt. HTTP/2 (seit 2015 standardisiert) brachte Multiplexing – die Möglichkeit, mehrere Requests über eine einzige TCP-Verbindung parallel zu senden, statt für jeden Request eine neue Verbindung aufzubauen. Header-Kompression (HPACK) reduziert den Overhead wiederholter HTTP-Header. Server Push erlaubte es dem Server, Ressourcen proaktiv zu senden – wurde aber 2022 von Chrome eingestellt, da der Nutzen in der Praxis gering war.

HTTP/3 (seit 2022 standardisiert, Quelle: IETF RFC 9114) geht mit dem QUIC-Protokoll einen fundamentalen Schritt weiter: Es ersetzt TCP durch UDP und integriert die TLS-Verschlüsselung direkt in den Verbindungsaufbau. Der Vorteil: 0-RTT Connection Establishment – bei wiederholten Besuchen kann die erste Anfrage sofort gesendet werden, ohne auf einen Handshake zu warten. Zudem löst QUIC das Head-of-Line-Blocking-Problem von HTTP/2: Wenn bei HTTP/2 ein einzelnes TCP-Paket verloren geht, werden alle parallelen Streams blockiert. Bei HTTP/3 betrifft ein Paketverlust nur den betroffenen Stream.

Die Aktivierung von HTTP/3 ist auf modernen Webservern (Nginx ab 1.25, LiteSpeed, Caddy) unkompliziert und abwärtskompatibel – Browser, die HTTP/3 nicht unterstützen, fallen automatisch auf HTTP/2 zurück. Laut W3Techs (2025) nutzen bereits 32 % aller Websites HTTP/3. Der TTFB-Vorteil von HTTP/3 gegenüber HTTP/2 beträgt typischerweise 30–80 Millisekunden bei der ersten Verbindung und ist besonders bei hoher Netzwerklatenz (Mobile, internationale Zugriffe) spürbar.

Die Kompression der Server-Antwort reduziert die Datenmenge, die über das Netzwerk übertragen werden muss, und verkürzt damit die Zeit bis zum Empfang des vollständigen Dokuments. Gzip ist der Mindeststandard und wird von allen Browsern und Servern unterstützt – es reduziert HTML-, CSS- und JavaScript-Dateien typischerweise um 60–80 %. Brotli (von Google entwickelt, seit 2015 standardisiert) erreicht bei vergleichbarer Dekompressionsgeschwindigkeit 15–25 % bessere Kompressionsraten als Gzip (Quelle: Google, 2024).

Die optimale Kompressionsstruktur unterscheidet statische und dynamische Inhalte. Statische Assets (CSS, JavaScript, SVG) sollten mit maximaler Brotli-Kompression (Stufe 11) vorkomprimiert werden – die hohe Kompressionszeit spielt keine Rolle, weil die Dateien nur einmal komprimiert und dann vom CDN oder Webserver direkt ausgeliefert werden. Dynamische HTML-Antworten werden in Echtzeit komprimiert und erfordern niedrigere Kompressionsstufen (Brotli 4–6), um die CPU-Belastung gering zu halten.

Der TTFB-Impact von Brotli gegenüber Gzip ist besonders bei größeren Dokumenten spürbar. Ein 50-KB-HTML-Dokument (unkomprimiert) wird mit Gzip auf ca. 12 KB komprimiert, mit Brotli auf ca. 10 KB – die eingesparten 2 KB bedeuten bei einer 3G-Verbindung ca. 20 Millisekunden weniger Übertragungszeit. Auf einer typischen E-Commerce-Kategorie-Seite mit 150 KB HTML summieren sich die Einsparungen auf 50–80 Millisekunden. Die Aktivierung von Brotli ist eine der einfachsten und effektivsten Maßnahmen in der Server-Optimierung.

Die TTFB-Optimierung folgt einer klaren Prioritätenreihenfolge. Zunächst die Quick Wins: OPcache aktivieren und konfigurieren (validate_timestamps, memory_consumption), Brotli-Kompression aktivieren, TLS 1.3 erzwingen und OCSP Stapling einrichten, HTTP/2 oder HTTP/3 aktivieren. Diese Maßnahmen lassen sich in der Regel innerhalb einer Stunde umsetzen und senken den TTFB bereits erheblich.

Der zweite Schritt sind mittelfristige Optimierungen: Slow-Query-Log aktivieren und die Top-10 langsamsten Queries optimieren, Redis oder Memcached als Objekt-Cache einrichten, Full-Page-Cache mit Varnish oder Nginx FastCGI Cache implementieren und die PHP-Version auf die aktuelle stabile Version aktualisieren (jede PHP-Major-Version bringt typischerweise 10–20 % Performance-Verbesserung). Diese Maßnahmen erfordern Serverkonfiguration und Testing, zahlen sich aber durch drastisch reduzierten TTFB aus.

Der dritte Schritt ist die architektonische Optimierung: CDN-Integration mit differenzierter Cache-Strategie, Datenbankreplikation für Read-Heavy-Workloads, PHP-Worker-Pool-Dimensionierung basierend auf Lastprofilen und die Verlagerung von asynchronen Aufgaben (E-Mail-Versand, Indexierung) in Background-Worker. Diese Maßnahmen erfordern tieferes technisches Verständnis und werden in der Performance-Beratung individuell geplant.

Die Ergebnisse einer systematischen TTFB-Optimierung sind in der Regel beeindruckend. In einem typischen Shopware-Projekt senken wir den TTFB von initial 800–1.500 Millisekunden auf unter 200 Millisekunden für gecachte Seiten und unter 400 Millisekunden für dynamische Seiten (Projekterfahrung). Das wirkt sich direkt auf den LCP-Wert und damit auf die Core Web Vitals aus. Die Server-Antwortzeit ist das Fundament jeder weiteren Optimierung – ohne einen schnellen Server bleiben Frontend-Optimierungen in ihrer Wirkung begrenzt.