Time to First Byte (TTFB): serverseitige Optimierung im Detail

1. Warum TTFB fälschlich als reine Netzwerkmetrik gilt

Wenn ein Performance-Report einen hohen TTFB anmahnt, ist die erste Reaktion vieler Teams, über ein CDN, einen näher gelegenen Serverstandort oder ein schnelleres Hosting-Paket nachzudenken. Diese Reaktion ist verständlich, weil TTFB als Netzwerkmetrik klassifiziert wird und in Tools wie den Chrome DevTools direkt neben DNS-Lookup und Verbindungsaufbau erscheint. Sie führt aber in den meisten Fällen in die falsche Richtung, weil der Netzwerkanteil an TTFB bei gut angebundenen Servern nur einen kleinen Bruchteil der Gesamtzeit ausmacht.

Der weitaus größere Anteil entsteht durch die Zeit, die der Server tatsächlich braucht, um die Anfrage zu verarbeiten und die Antwort zusammenzustellen. Diese Verarbeitungszeit umfasst das Ausführen von Anwendungscode, das Absetzen von Datenbankqueries, das Rendern von Templates und gegebenenfalls das Aufwärmen einer neuen Serverinstanz. Ein Team, das ausschliesslich am Netzwerk optimiert, verbessert im schlimmsten Fall nur einen kleinen Teil der Gesamtzeit und übersieht die eigentliche Bremse in der eigenen Anwendung.

# TTFB-Teilzeiten mit curl aufschluesseln (keine Browser-Interpretation noetig)
curl -o /dev/null -s -w '\
DNS-Lookup:        %{time_namelookup}s\n\
TCP-Handshake:      %{time_connect}s\n\
TLS-Handshake:       %{time_appconnect}s\n\
Zeit bis Anfrage raus: %{time_pretransfer}s\n\
TTFB (time_starttransfer): %{time_starttransfer}s\n\
Gesamtzeit:          %{time_total}s\n' \
https://www.beispiel-shop.de/checkout

# Ergebnis interpretieren: Differenz zwischen time_starttransfer und
# time_pretransfer ist die reine Server-Verarbeitungszeit ohne
# Verbindungsaufbau -- genau dieser Wert zeigt, ob das Problem im
# Netzwerk oder im Backend liegt.

2. Die vier Teilzeiten hinter TTFB im Detail

TTFB setzt sich aus vier klar abgrenzbaren Phasen zusammen, die jede für sich eine eigene Ursache und eine eigene Optimierungsstrategie hat. Die erste Phase ist der DNS-Lookup, bei dem der Domainname in eine IP-Adresse aufgelöst wird. Die zweite Phase ist der TCP-Handshake, der die Transportverbindung zwischen Client und Server aufbaut. Die dritte Phase ist der TLS-Handshake, der bei HTTPS-Verbindungen die verschlüsselte Sitzung etabliert und je nach TLS-Version ein bis zwei zusätzliche Roundtrips kostet.

Die vierte und in der Praxis meist dominante Phase ist die eigentliche Server-Verarbeitungszeit, also die Zeitspanne zwischen dem Eintreffen der Anfrage auf dem Server und dem Versand des ersten Antwort-Bytes. Nur diese vierte Phase liegt vollständig in der Hand des Backend-Teams, während DNS-, TCP- und TLS-Zeiten stark von der Netzwerkinfrastruktur, dem Hosting-Anbieter und der geografischen Distanz abhängen. Wer die vier Phasen nicht getrennt misst, vermischt Ursachen, die mit vollkommen unterschiedlichen Massnahmen behoben werden.

3. Ursache Nummer eins: langsame Datenbankqueries im Request-Pfad

In dynamischen Webanwendungen ist die Datenbank die häufigste Ursache für einen hohen TTFB, weil praktisch jede Anfrage mindestens eine, oft aber mehrere sequenzielle Queries auslöst. Fehlende Indizes, N-plus-1-Query-Muster in Object-Relational-Mappern und ungeschickt formulierte Joins führen dazu, dass eine einzelne Seitenanfrage im Backend Dutzende von Datenbank-Roundtrips auslöst, bevor die Antwort überhaupt zusammengestellt werden kann. Jede dieser Queries trägt ihre eigene Latenz bei, und bei sequenzieller Ausführung addieren sich diese Latenzen direkt zur TTFB.

Ein systematischer Blick in den Slow-Query-Log der Datenbank zeigt in den meisten Fällen sofort, welche Queries für den Großteil der Verarbeitungszeit verantwortlich sind. Häufige Befunde sind fehlende zusammengesetzte Indizes für Filter- und Sortierkombinationen, ungenutzte Indizes durch implizite Typumwandlungen in der WHERE-Klausel sowie Queries, die deutlich mehr Spalten oder Zeilen laden als für die Antwort tatsächlich benötigt werden. Ein Query-Profiling direkt in der Staging-Umgebung mit realistischen Datenmengen deckt solche Probleme meist schneller auf als jede Produktionsüberwachung im Nachhinein.

4. Ursache Nummer zwei: fehlendes Server-Side-Caching

Selbst gut optimierte Datenbankqueries kosten bei jedem einzelnen Request Zeit, wenn identische oder ähnliche Anfragen wiederholt neu berechnet werden. Server-Side-Caching setzt genau hier an, indem das Ergebnis einer teuren Operation (Datenbankquery, Template-Rendering, externer API-Aufruf) für eine definierte Zeitspanne zwischengespeichert und bei der nächsten identischen Anfrage direkt aus dem Cache bedient wird, statt die komplette Berechnung erneut auszuführen. Fehlt eine solche Caching-Schicht komplett, bezahlt jede einzelne Anfrage den vollen Preis der Datenverarbeitung, unabhängig davon, wie oft dieselbe Antwort in kurzer Zeit ausgeliefert wird.

In der Praxis lohnt sich eine mehrstufige Caching-Strategie: ein schneller In-Memory-Cache wie Redis oder Memcached für häufig gelesene, selten geänderte Daten, ein Opcode-Cache wie OPcache für PHP-Anwendungen, um das wiederholte Parsen und Kompilieren von Code zu vermeiden, sowie ein Full-Page-Cache für Seiten, die sich pro Nutzer kaum unterscheiden. Wichtig ist dabei eine durchdachte Invalidierungsstrategie, denn ein Cache, der veraltete Daten ausliefert, verschiebt das Problem nur von der Performance auf die Korrektheit der Anwendung.

5. Ursache Nummer drei: Cold-Start bei Serverless-Funktionen

Serverless-Architekturen wie AWS Lambda, Google Cloud Functions oder Vercel Functions skalieren automatisch, bringen aber ein spezifisches TTFB-Problem mit: den Cold-Start. Trifft eine Anfrage auf eine Funktion, für die aktuell keine warme Instanz bereitsteht, muss die Ausführungsumgebung erst neu initialisiert werden, das Laufzeitpaket geladen, Abhängigkeiten aufgelöst und in manchen Sprachen sogar Code neu kompiliert werden, bevor die eigentliche Anfrage überhaupt bearbeitet werden kann. Dieser Initialisierungsaufwand kann je nach Laufzeitumgebung und Paketgröße zwischen einigen hundert Millisekunden und mehreren Sekunden liegen.

Besonders kritisch wird das Problem bei Funktionen mit vielen Abhängigkeiten, großen Deployment-Paketen oder Laufzeitumgebungen wie der JVM, deren Startzeit strukturell länger ist als bei leichtgewichtigeren Laufzeiten. Massnahmen wie Provisioned Concurrency, bei der eine definierte Anzahl an Instanzen dauerhaft warmgehalten wird, kleinere Deployment-Pakete durch Tree-Shaking und Dependency-Trimming sowie die Wahl einer schnell startenden Laufzeitumgebung reduzieren den Cold-Start-Anteil an der TTFB deutlich. Wer Serverless für latenzkritische Endpunkte einsetzt, sollte Cold-Starts von Anfang an als eigenen Messwert im Monitoring führen.

6. Systematische Diagnose mit dem Server-Timing-Header

Um die drei genannten Ursachen im eigenen System zu unterscheiden, reicht ein einzelner TTFB-Wert nicht aus, weil er alle Teilursachen zu einer einzigen Zahl vermischt. Der HTTP-Header Server-Timing löst dieses Problem, indem die Anwendung selbst einzelne Zeitmesswerte aus dem Backend an den Browser weitergibt, etwa die Dauer der Datenbankabfrage, die Cache-Lookup-Zeit oder die reine Rendering-Zeit des Templates. Diese Werte erscheinen direkt im Network-Panel der Chrome DevTools unter dem jeweiligen Request und lassen sich ohne zusätzliches externes Tooling auslesen.

In der Praxis instrumentiert man kritische Codepfade mit Zeitmessung und schreibt die Ergebnisse als Server-Timing-Einträge in die Response, etwa Server-Timing: db;dur=120, cache;dur=5, render;dur=30. Über die Zeit ergibt sich so ein belastbares Bild, welcher Anteil der TTFB auf welche Komponente entfällt, und Optimierungsmassnahmen lassen sich gezielt priorisieren, statt pauschal am Server oder Netzwerk zu schrauben. Wichtig ist, diese Instrumentierung dauerhaft im Monitoring zu belassen, damit Regressionen nach Deployments sofort auffallen.

7. Konkrete Optimierungsmassnahmen für produktive Systeme

Nach der Diagnose folgt die gezielte Optimierung, und hier zahlen sich meist mehrere kleinere Massnahmen mehr aus als eine einzelne große. Connection Pooling zur Datenbank vermeidet den teuren Aufbau einer neuen Verbindung pro Anfrage, Prepared Statements reduzieren den Parsing-Aufwand wiederkehrender Queries, und ein durchdachtes Indexdesign verkürzt Lookup-Zeiten oft um eine Größenordnung. Auf Anwendungsebene helfen asynchrone, parallele Ausführung unabhängiger Datenabrufe statt sequenzieller Aufrufe sowie das konsequente Vermeiden unnötiger Serialisierung großer Datenmengen.

Auf Infrastrukturebene reduziert horizontale Skalierung mit Load Balancing die Wartezeit bei hoher gleichzeitiger Last, während Autoscaling-Regeln verhindern, dass einzelne Instanzen unter Last in die Warteschlange geraten. Bei traditionellem Hosting lohnt sich ausserdem ein Blick auf PHP-FPM- oder Worker-Pool-Konfigurationen, denn zu wenige Worker-Prozesse führen bei Lastspitzen dazu, dass Anfragen in der Queue des Application-Servers warten, bevor sie überhaupt bearbeitet werden, was sich in den TTFB-Messwerten als scheinbar zufällige Ausreisser zeigt.

8. Der Zusammenhang zwischen TTFB und Largest Contentful Paint

TTFB ist keine isolierte Metrik, sondern der frühestmögliche Startpunkt für alle nachfolgenden Rendering-Schritte einer Seite. Bevor der Browser auch nur ein einziges Byte des HTML-Dokuments erhalten hat, kann er weder mit dem Parsen beginnen noch nachgelagerte Ressourcen wie CSS, Fonts oder Bilder anfordern. Ein hoher TTFB verschiebt damit den gesamten kritischen Rendering-Pfad nach hinten und wirkt sich direkt auf den Largest Contentful Paint (LCP) aus, einen der drei Core Web Vitals.

Google empfiehlt für LCP einen Zielwert unter 2,5 Sekunden, und da TTFB in vielen Fällen den ersten nennenswerten Anteil dieser Zeitspanne ausmacht, ist die Optimierung der Server-Verarbeitungszeit oft der wirkungsvollste Hebel für schnellere LCP-Werte, noch vor Bildoptimierung oder Preloading-Strategien. Eine Faustregel aus der Praxis lautet, dass jede eingesparte Sekunde TTFB sich fast eins zu eins in schnellerem LCP niederschlägt, während Optimierungen am Frontend die Verzögerung durch einen langsamen Server nicht kompensieren können.

9. Fazit: TTFB als Einstiegspunkt für systematische Performance-Arbeit

TTFB verdient mehr Aufmerksamkeit, als ihm in vielen Performance-Audits zuteilwird, weil ein hoher Wert fast immer ein Symptom für tiefer liegende Backend-Probleme ist. Die drei häufigsten Ursachen, langsame Datenbankqueries, fehlendes Server-Side-Caching und Cold-Starts bei Serverless-Funktionen, lassen sich mit gezielter Instrumentierung über Server-Timing-Header zuverlässig identifizieren und getrennt voneinander adressieren, statt pauschal am Netzwerk oder Hosting-Paket zu optimieren.

Wer TTFB systematisch angeht, beginnt mit der Messung der vier Teilzeiten, isoliert die Server-Verarbeitungszeit vom Netzwerkanteil und instrumentiert anschliessend die kritischen Codepfade im Backend. Diese Investition zahlt sich doppelt aus, weil sie nicht nur die TTFB selbst verbessert, sondern über den direkten Zusammenhang mit dem Largest Contentful Paint auch die gesamte wahrgenommene Ladezeit der Seite spürbar senkt.

10. Zusammenfassung

11. FAQ: TTFB serverseitig optimieren: Das Wichtigste auf einen Blick