Warum deine Time to First Byte langsam ist und was du dagegen tun kannst

Beginne damit, was TTFB tatsächlich misst

Time to First Byte, meist als TTFB abgekürzt, ist die Zeit zwischen der Anfrage einer Ressource durch den Browser und dem Empfang des ersten Bytes der Antwort.

Das klingt nach einer Servermetrik, ist aber nicht nur eine Servermetrik. TTFB umfasst mehrere Schritte:

• DNS-Lookup, falls der Hostname noch nicht aufgelöst ist
• TCP-Verbindungsaufbau
• TLS-Aushandlung für HTTPS
• Laufzeit der Anfrage zum Server oder CDN-Edge
• Warteschlange und Verarbeitung auf dem Server
• Laufzeit der Antwort zurück zum Browser

Eine hohe TTFB kann also bedeuten, dass dein Backend langsam ist. Sie kann aber auch bedeuten, dass der Nutzer weit von deinem Origin entfernt ist, dein CDN falsch konfiguriert ist, dein Cache ständig verfehlt wird oder dein Server zu lange braucht, um zu entscheiden, was gesendet werden soll.

Das ist wichtig, weil TTFB sehr früh in der Ladekette liegt. Wenn das HTML-Dokument spät ankommt, entdeckt der Browser auch CSS, JavaScript, Fonts und Bilder spät. Du kannst eine hervorragende Frontend-Optimierung haben und dich trotzdem langsam anfühlen, wenn die erste Dokumentantwort 1,5 Sekunden dauert.

Was gilt als langsame TTFB?

Es gibt keine universelle Zahl, die zu jeder Website, Region und Architektur passt. Trotzdem helfen praktische Schwellenwerte.

Die web.dev-Empfehlung von Google stuft eine gute TTFB als unter 800 ms ein; 800–1800 ms gelten als verbesserungsbedürftig, über 1800 ms als schlecht. Für eine gut gecachte Marketing-Seite, die in der Nähe des Nutzers ausgeliefert wird, kannst du oft deutlich besser sein. Für ein komplexes authentifiziertes Dashboard mit dynamischer Arbeit kann der akzeptable Wert höher liegen, sollte aber weiterhin erklärbar sein.

Wichtig ist die Gewohnheit, die Zahl zu segmentieren. Eine globale durchschnittliche TTFB von 900 ms kann eine Antwort von 150 ms für Nutzer nahe deinem CDN-Edge und eine Antwort von 2200 ms für Nutzer in einer anderen Region verbergen. Ebenso kann deine Startseite in Ordnung sein, während Suche, Kategorien oder eingeloggte Seiten unauffällig schmerzhaft sind.

Miss an mehr als einer Stelle

Diagnostiziere TTFB nicht anhand eines einzelnen Lighthouse-Laufs. Lighthouse ist nützlich, aber es ist ein Test aus einer Umgebung. Wenn du neu darin bist, die Ergebnisse zu interpretieren, beginne mit einer ruhigen Lektüre darüber, wie man einen Lighthouse-Bericht liest, ohne in Panik zu geraten — die wichtigste Lektion ist, Laborsignale von der Realität im Feld zu trennen.

Für TTFB brauchst du mindestens drei Perspektiven:

1. Browser-Entwicklertools

Öffne das Network-Panel, lade mit deaktiviertem Cache neu und untersuche die Anfrage für das Hauptdokument. Die Timing-Aufschlüsselung zeigt DNS-, Verbindungs-, TLS-, Warte- und Download-Phasen. Die Phase „waiting“ ist oft das, was Leute mit Backend-Zeit meinen, auch wenn darin Upstream-Latenz enthalten sein kann.

2. Synthetische Tests aus mehreren Regionen

Führe Tests von Standorten aus, die nah an deinen Nutzern liegen, und von solchen, die weit entfernt sind. Wenn die TTFB in einer Region niedrig und in einer anderen hoch ist, vermute zuerst Geografie, CDN-Routing, Origin-Standort oder Cache-Abdeckung, bevor du Anwendungscode umschreibst.

3. Real User Monitoring oder Server-Logs

Felddaten zeigen dir, was echte Nutzer über Geräte, Netzwerke und Sitzungen hinweg erleben. Server-Logs können dir zeigen, ob der Origin schnell eine Antwort erzeugt hat. Die Differenz zwischen clientseitig beobachteter TTFB und Origin-Verarbeitungszeit ist oft der Bereich, in dem CDN- und Netzwerkprobleme sichtbar werden.

Die üblichen Ursachen für langsame TTFB

Dein HTML wird nicht gecacht

Das ist das häufigste Problem bei Content-Websites und E-Commerce-Websites. Statische Assets werden aggressiv gecacht, aber das HTML-Dokument — das, was der Browser zuerst braucht — wird bei jeder Anfrage neu erzeugt.

Manchmal ist das notwendig. Oft ist es das nicht.

Wenn sich eine öffentliche Seite nur ein paar Mal pro Tag ändert, sollte sie wahrscheinlich nicht für jeden anonymen Besucher ein frisches Datenbank-Rendering erfordern. Nutze je nach Situation Full-Page-Caching, Edge-Caching, statische Generierung oder stale-while-revalidate-Muster.

Prüfe Antwort-Header auf Signale wie Cache-Control, CDN-Cache-Status, Age, Vary und Set-Cookie. Eine Seite, die jedem Besucher ein eindeutiges Cookie sendet, kann sich versehentlich selbst uncachebar machen. Wenn du eine praktische Denkweise für diese Ebene brauchst, lassen sich dieselben Debugging-Gewohnheiten aus unserem Leitfaden zu Redirects und HTTP-Headern in Produktion direkt auf TTFB-Arbeit anwenden.

Dein CDN cached nur Assets

Viele Teams fügen ein CDN hinzu und nehmen an, dass die Performance-Arbeit erledigt ist. Wenn das CDN aber nur Bilder, CSS und JavaScript ausliefert, kann die erste HTML-Anfrage weiterhin den ganzen Weg zu einem einzelnen Origin-Server zurücklegen.

Für eine lokale Unternehmensseite mit lokalen Nutzern kann das in Ordnung sein. Für ein internationales Publikum ist es das nicht. Je weiter der Nutzer vom Origin entfernt ist, desto mehr Latenz zahlst du, noch bevor Backend-Arbeit überhaupt beginnt.

Eine gute CDN-Konfiguration für TTFB bedeutet meist:

• Öffentliches HTML dort cachen, wo es sicher ist
• Bewusste Bypass-Regeln für authentifizierte oder personalisierte Seiten respektieren
• Unnötige Vary-Header vermeiden, die den Cache zu fein aufteilen
• Cache-Purging oder Revalidierung nutzen, statt den Cache vollständig zu deaktivieren
• Bestätigen, dass Edge-Standorte tatsächlich Hits ausliefern und nicht jede Anfrage weiterleiten

Ein CDN ist keine Magie. Es ist eine Cache- und Routing-Schicht. Behandle es auch so.

Dein Server macht vor der Antwort zu viel

Ein langsamer Backend-Pfad kann aus vielen kleinen Verzögerungen entstehen: Datenbankabfragen, API-Aufrufen, Template-Rendering, Feature-Flag-Prüfungen, Authentifizierung, Personalisierung, Logging und Cold Starts.

Das schlechteste Muster ist serielle Abhängigkeitsarbeit. Zum Beispiel:

1. Seitendaten abrufen
2. Dann verwandte Produkte abrufen
3. Dann Preise abrufen
4. Dann einen Empfehlungsdienst aufrufen
5. Dann HTML rendern

Wenn jeder Schritt auf den vorherigen wartet, wächst die TTFB schnell. Parallelisiere unabhängige Arbeit, entferne nicht kritische Aufrufe aus der ersten Antwort und cache teure Ergebnisse.

Eine nützliche Regel: Wenn der Nutzer das Ergebnis nicht sofort sehen oder nutzen kann, sollte es wahrscheinlich nicht das erste Byte blockieren.

Datenbankabfragen sind langsam oder unvorhersehbar

Datenbanken verursachen häufig TTFB-Probleme, weil sie in der Entwicklung gut funktionieren und unter echtem Traffic schlecht. Fehlende Indizes, große Joins, N+1-Abfragen, Lock Contention und übergroße Ergebnismengen erscheinen alle als „der Server ist langsam“.

Rate hier nicht. Erfasse Query-Timings für langsame Anfragen. Betrachte p95 und p99, nicht nur Durchschnittswerte. Eine Seite, die normalerweise in 120 ms antwortet, aber gelegentlich 4 Sekunden blockiert, erzeugt trotzdem eine schlechte Nutzererfahrung.

Häufige Lösungen sind:

• Indizes hinzufügen oder korrigieren
• N+1-Abfragemuster entfernen
• Leseintensive Daten cachen
• Große Abfragen paginieren
• Reporting- oder Analytics-Abfragen aus der Anfragezeit heraus verlagern
• Sinnvolle Timeouts für nachgelagerte Aufrufe setzen

Deine Anwendung hat Cold Starts

Serverless- und containerisierte Plattformen können ausgezeichnet sein, aber Cold Starts können die TTFB belasten, wenn Traffic sprunghaft ist oder Regionen unterprovisioniert sind.

Wenn deine erste Anfrage nach Leerlauf deutlich langsamer ist als spätere Anfragen, untersuche Cold Starts. Möglicherweise brauchst du provisioned concurrency, kleinere Bundles, weniger Startup-Abhängigkeiten, vorgewärmte Functions oder eine andere Deployment-Form für latenzempfindliche Routen.

Das ist kein Argument gegen Serverless. Es ist ein Argument dagegen, so zu tun, als wäre das Laufzeitmodell unsichtbar.

Redirects verschwenden die erste Anfrage

Ein Redirect fügt einen weiteren Request-Response-Zyklus hinzu, bevor der Browser das endgültige Dokument erhält. Ein Redirect von http:// zu https:// kann für alte Links unvermeidbar sein, aber Ketten sind verschwenderisch.

Häufige Ketten sind:

• http://example.com → https://example.com → https://www.example.com
• Normalisierung des abschließenden Slash nach der Protokollnormalisierung
• Geo- oder Sprach-Redirects vor dem Cache-Lookup
• Alte Kampagnenlinks, die über mehrere URLs springen

Korrigiere die Quelllinks, wo möglich, fasse Redirect-Regeln zusammen und mache kanonische URLs direkt erreichbar. Redirect-Zeit wird nicht immer als TTFB für die endgültige Anfrage ausgewiesen, aber der Nutzer bezahlt sie trotzdem.

Eine praktische Debugging-Reihenfolge

Wenn TTFB langsam aussieht, nutze diese Reihenfolge. Sie vermeidet den häufigen Fehler, Anwendungscode zu optimieren, bevor Cache- und Routing-Verhalten bestätigt sind.

Step 1: Teste das Hauptdokument, nicht nur die ganze Seite

Finde die Anfrage für das HTML-Dokument. Notiere die gesamte TTFB und die Timing-Aufschlüsselung. Wiederhole den Test mit und ohne Browser-Cache. Teste eine öffentliche Seite, eine dynamische Seite und, falls relevant, eine eingeloggte Seite.

Step 2: Vergleiche Regionen

Rufe dieselbe URL aus mehreren geografischen Standorten auf. Wenn die langsamen Regionen mit der Entfernung zum Origin korrelieren, priorisiere CDN und Edge-Caching. Wenn jede Region langsam ist, betrachte Backend-Verarbeitung und Origin-Kapazität.

Step 3: Untersuche Antwort-Header

Achte auf Cache-Header, Cookies, Age, CDN-Status und Vary. Ein fehlender Age-Header oder wiederholte Cache-Misses sind Hinweise. Ein breiter Vary: Cookie-Header auf öffentlichem HTML ist oft ein Cache-Killer.

Step 4: Prüfe Origin-Timing

Füge Server-Timing-Instrumentierung hinzu. Der Server-Timing-Header kann Backend-Phasen wie Datenbankzeit, Renderzeit und Upstream-API-Zeit sichtbar machen. Selbst einfache Labels sind nützlich:

Server-Timing: db;dur=82, render;dur=41, api;dur=210

Jetzt können deine Browser-Timings zeigen, ob der Server 300 ms mit echter Arbeit verbracht hat oder ob die Verzögerung auftrat, bevor die Anfrage deine Anwendung erreichte.

Step 5: Behebe die größte bestätigte Verzögerung

Das klingt offensichtlich, aber Teams beheben oft das, was vertraut ist, statt das, was gemessen wurde. Wenn Cache-Misses dominieren, behebe das Caching. Wenn die Datenbank dominiert, behebe Abfragen. Wenn TLS und Verbindungsaufbau für globale Nutzer dominieren, behebe Routing, CDN-Abdeckung oder Origin-Geografie.

Frontend-Arbeit bleibt wichtig. Fonts, Bilder und JavaScript beeinflussen, was passiert, nachdem das HTML angekommen ist. Sie sind aber kein Ersatz für eine schnelle erste Antwort. Wenn du auch an Render-Performance arbeitest, bleiben Web Fonts auf vielen Websites einer der einfachsten Gewinne, weil sie beeinflussen, wie schnell Text nutzbar wird, nachdem das Dokument angekommen ist.

Lösungen, die meist funktionieren

Öffentliches HTML am Edge cachen

Für Marketing-Seiten, Dokumentation, Blogs, Landingpages und Kategorieseiten ist Edge-Caching oft die größte TTFB-Verbesserung. Nutze kurze TTLs, wenn sich Inhalte häufig ändern. Nutze stale-while-revalidate, wenn leicht veraltete Inhalte akzeptabel sind, während der Cache im Hintergrund aktualisiert wird.

Sei vorsichtig mit Personalisierung. Wenn eine Seite nach Währung, Sprache, Login-Status oder Experimentgruppe variiert, definiere diese Varianten explizit. Versehentliche Variation pro Nutzer zerstört die Cache-Effizienz.

Nicht kritische Arbeit aus dem Anfragepfad verschieben

E-Mail-Versand, Analytics-Anreicherung, Empfehlungsgenerierung, Webhook-Aufrufe und schweres Logging sollten selten das erste Byte blockieren. Lege sie in Queues oder führe sie aus, nachdem die Antwort gestartet wurde.

Backend-Abhängigkeitsketten reduzieren

Parallelisiere unabhängige Aufrufe. Cache Antworten langsamer APIs. Setze Timeouts. Entwirf Fallback-Inhalte für Dienste, die hilfreich, aber nicht essenziell sind.

Ein langsames Empfehlungs-Widget sollte nicht die gesamte Produktseite verzögern.

Compute näher zu den Nutzern bringen

Wenn deine Nutzer global sind und dein Origin in einer einzigen Region liegt, ist Latenz strukturell. CDN-Caching kann das für öffentliche Inhalte weitgehend verbergen. Für dynamische Inhalte solltest du regionale Deployments, Edge-Rendering für geeignete Routen oder APIs näher am Publikum in Betracht ziehen.

Redirects langweilig halten

Kanonisiere URLs in einem Sprung. Aktualisiere interne Links, damit Nutzer und Crawler direkt zum endgültigen Ziel gelangen. Prüfe alte Kampagnen-URLs und Plattformmigrationen. Redirects werden leicht ignoriert, weil sie unsichtbar sind, wenn sie funktionieren, aber sie kosten trotzdem Zeit.

Was du nicht tun solltest

Jage nicht für jede Route einer perfekten TTFB-Zahl hinterher. Ein authentifizierter Bericht, der echte Berechnung ausführt, verhält sich nicht wie ein gecachter Blogbeitrag.

Verwende die durchschnittliche TTFB nicht als einzige Metrik. Perzentile zählen. Geografie zählt. Seitentyp zählt.

Gehe nicht davon aus, dass ein CDN bedeutet, dass dein HTML gecacht wird. Überprüfe es.

Und behandle TTFB nicht getrennt von Produktentscheidungen. Personalisierung, Experimente, Echtzeit-Inventar und Drittanbieterdienste haben alle Latenzkosten. Manche sind es wert. Manche sind nur Gewohnheit.

<!-- tool-cta:start -->

💡 Probieren Sie das aus: Bei der Diagnose von TTFB zeigt Get Headers Cache-Status, Server-Timings und Weiterleitungen an, die oft erklären, woher die Verzögerung kommt.

<!-- tool-cta:end -->

Die ruhige Version des Plans

Eine langsame TTFB ist meist behebbar, sobald du aufhörst, sie als vages „Serverproblem“ zu behandeln. Miss die Dokumentanfrage. Segmentiere nach Region und Seitentyp. Untersuche Header. Vergleiche Client-Timing mit Origin-Timing. Behebe dann den größten bestätigten Engpass.

Die meisten Websites brauchen keine exotische Architektur. Sie brauchen weniger vermeidbare Cache-Misses, weniger blockierende Backend-Arbeit, sauberere Redirects und eine klarere Vorstellung davon, was passieren muss, bevor das erste Byte gesendet wird.