Time to First Byte (TTFB)

Die Time to First Byte, kurz TTFB, gibt an, wie viel Zeit vom Start eines Seitenaufrufs vergeht, bis das erste Byte des HTML-Dokuments im Browser ankommt. Solange dieses Byte fehlt, kann der Browser weder Code auswerten noch Ressourcen anfordern oder etwas darstellen. Auf dieser Seite erfahren Sie, woraus sich die TTFB zusammensetzt, ab wann ein Wert als gut gilt, wie Sie ihn messen und welche Ursachen hinter einer hohen TTFB stecken.

Aus den Messungen von PerfDelta: In den Felddaten echter Nutzer (mobil, 75. Perzentil) erreichen 61 % von 5.544 Websites bei Time to First Byte einen guten Wert, 6 % einen schlechten. Der Median liegt bei 693 ms, die mittlere Hälfte zwischen 490 ms und 1009 ms. Mehr dazu im Datenblock unten.

Time to First Byte besteht aus mehreren Phasen

Im Alltag wird die TTFB oft mit der Serverantwortzeit gleichgesetzt. Die Feldmetrik reicht jedoch weiter. Sie umfasst alle Schritte zwischen dem Beginn der Navigation und dem ersten Byte der Antwort auf das Hauptdokument:

1. Weiterleitungen: Jede Umleitung, etwa von http:// auf https:// oder von der Domain ohne auf die Domain mit www, erzeugt eine vollständige zusätzliche Anfrage.
2. Start des Service Workers: Nutzt Ihre Website einen Service Worker, zählt dessen Startzeit mit.
3. DNS-Auflösung: Der Browser ermittelt die IP-Adresse zum Domainnamen.
4. Verbindungsaufbau und TLS: Für eine neue HTTPS-Verbindung sind mehrere Rundreisen zwischen Browser und Server nötig.
5. Anfrage und Serververarbeitung: Der Server nimmt die Anfrage entgegen, erzeugt die Antwort und schickt das erste Byte zurück.

Für die Fehlersuche ist diese Aufteilung entscheidend. Eine hohe TTFB entsteht längst nicht immer im Anwendungscode. Häufig kostet eine Kette von Weiterleitungen oder die räumliche Entfernung zum Server mehr Zeit als die eigentliche Verarbeitung.

Guter TTFB-Wert: 0,8 Sekunden am 75. Perzentil

Google bewertet die TTFB anhand realer Seitenaufrufe am 75. Perzentil. Drei von vier Aufrufen sollten den Zielwert also erreichen:

Bewertung	TTFB (p75)
Gut	bis 0,8 Sekunden
Verbesserungswürdig	über 0,8 bis 1,8 Sekunden
Schlecht	über 1,8 Sekunden

Diese Werte verstehen sich als Orientierung. Eine Website, die die komplette Seite serverseitig ausliefert, kann eine etwas höhere TTFB verkraften, weil danach wenig Arbeit im Browser folgt. Baut dagegen JavaScript den Großteil der Inhalte erst im Browser auf, sollte das erste Byte umso früher kommen.

TTFB zählt nicht zu den Core Web Vitals, verzögert aber FCP und LCP

Die TTFB ist keine der drei Core Web Vitals und wird nicht als eigenes Ranking-Signal bewertet. Ihre Bedeutung ergibt sich aus der Reihenfolge des Ladens: Jede Millisekunde bis zum ersten Byte verschiebt First Contentful Paint und Largest Contentful Paint um denselben Betrag nach hinten. Für einen guten LCP stehen 2,5 Sekunden zur Verfügung. Liegt die TTFB bereits bei 1,5 Sekunden, bleibt für Stylesheets, Schriften und das Hero-Bild nur noch eine Sekunde. Scheitert der LCP trotz sauber optimiertem Frontend, lohnt deshalb zuerst der Blick auf die TTFB.

Labor und Feld messen die TTFB unterschiedlich

Felddaten aus dem Chrome UX Report

Der Chrome UX Report (CrUX) erfasst die TTFB bei echten Chrome-Nutzern über ein nachlaufendes Fenster von 28 Tagen. PageSpeed Insights zeigt den Wert im Bereich der Felddaten. Er enthält alle oben genannten Phasen, gemessen auf realen Geräten, in realen Netzen und an realen Standorten. Hat eine einzelne URL zu wenig Verkehr, weist CrUX den Wert für den gesamten Origin aus.

Lighthouse-Prüfung zur Serverantwortzeit

Im Performance-Score von Lighthouse taucht die TTFB nicht als eigene Kennzahl auf. Stattdessen prüft das Audit „Reduce initial server response time“ (server-response-time), wie lange der Browser auf die Antwort des Servers für das Hauptdokument wartet. Ab 600 Millisekunden schlägt die Prüfung an. Sie betrachtet einen engeren Ausschnitt als die Feld-TTFB, denn Weiterleitungen und Verbindungsaufbau bewerten andere Audits, und sie beruht auf einem einzelnen Testlauf von einem Standort. Eine Seite kann das Audit also bestehen und im Feld trotzdem schlecht abschneiden, etwa weil viele Besucher weit entfernt sind, über Weiterleitungen kommen oder ungecachte Seiten aufrufen.

Ursachen einer hohen TTFB

• Weiterleitungsketten: Alte URLs, Kampagnenlinks und Umleitungen zwischen Protokoll und Hostname summieren sich. Zwei Umleitungen im Mobilfunknetz können mehr kosten als die gesamte Serververarbeitung.
• Aufwendige Serverlogik: Pro Anfrage läuft zu viel Code, zum Beispiel durch zahlreiche Plugins oder durch Aufrufe externer Schnittstellen während des Seitenaufbaus.
• Langsame Datenbankabfragen: Fehlende Indizes oder eine eigene Abfrage für jedes Listenelement halten die Antwort auf.
• Kein Seitencache: Ohne Full-Page-Caching entsteht das HTML bei jedem Aufruf neu, obwohl sich der Inhalt nicht geändert hat.
• Entfernung ohne CDN: Steht der Server in Deutschland und kommen Besucher aus Übersee, verlängert jede Rundreise die DNS-Auflösung, den Verbindungsaufbau und die Anfrage selbst.
• Kaltstarts: Serverless-Funktionen und ruhende Instanzen brauchen Zeit zum Hochfahren. Auch der erste Aufruf nach einem Deployment oder dem Leeren des Caches ist spürbar langsamer.

Serverantwortzeit reduzieren und TTFB senken

Lighthouse meldet ein spätes erstes Byte im Befund zur Serverantwortzeit, neuere Versionen im Befund zur Latenz der Dokumentanfrage. Die folgenden Hebel gelten für beide, in der Reihenfolge, in der sie sich meist lohnen.

Fertige Seiten cachen

Ein Full-Page-Cache liefert das bereits erzeugte HTML aus, ohne Anwendungscode auszuführen. Bei Inhalten, die sich selten ändern, bringt das die größte Einzelverbesserung. Für Bilder, Skripte und Stylesheets ergänzt Browser-Caching den Seitencache.

CDN mit HTML-Caching einsetzen

Viele CDNs speichern in der Grundeinstellung nur statische Dateien. Aktivieren Sie das Edge-Caching auch für HTML, damit das erste Byte von einem Knoten in der Nähe des Besuchers kommt und nicht vom Ursprungsserver.

Weiterleitungen abbauen

Verlinken Sie in Navigation, Sitemap, Canonical-Tags und Kampagnen direkt auf die endgültige URL. Wo eine Umleitung bleiben muss, sollte sie in einem einzigen Schritt ans Ziel führen.

PHP aktuell halten und Objekt-Cache nutzen

Eine aktuelle PHP-Version mit OPcache und ein persistenter Objekt-Cache für Datenbankergebnisse verkürzen die Verarbeitung.

Datenbank und Anwendungscode optimieren

Langsame Abfragen bremsen vor allem Seiten, die nicht aus dem Cache kommen. Legen Sie Indizes für die Spalten an, nach denen gefiltert wird, beseitigen Sie N+1-Abfragemuster und profilieren Sie die langsamsten Anfragen. Das Slow-Query-Log und EXPLAIN zeigen, ob eine Abfrage einen Index nutzt oder die ganze Tabelle durchsucht.

Hosting passend wählen

Die Art des Hostings setzt eine Untergrenze, die keine Software unterschreiten kann. Shared Hosting ist günstig, liefert aber schwankende Antwortzeiten, sobald andere Websites auf demselben Server Last erzeugen. Ein VPS oder dedizierter Server reserviert Ressourcen, Managed Hosting bringt Seiten- und Objekt-Cache vorkonfiguriert mit, Edge-Plattformen liefern vorgerenderte Antworten nahe am Besucher aus. Bleibt die TTFB trotz sauberem Caching und optimierter Datenbank hoch, ist der Wechsel der Hosting-Klasse oft der wirksamste einzelne Schritt.

Wartezeit mit 103 Early Hints nutzen

Unterstützen Server oder CDN die Antwort 103 Early Hints, kann der Browser kritische Ressourcen bereits laden, während der Server die Seite noch erzeugt. Der Server wird dadurch nicht schneller, die Wartezeit bleibt aber nicht ungenutzt.

TTFB in WordPress, Shopify und Next.js

In WordPress deutet eine hohe TTFB meist darauf hin, dass jede Seite bei jedem Aufruf neu entsteht. Ein Caching-Plugin mit Full-Page-Cache, ein persistenter Objekt-Cache und weniger Plugins, die bei jedem Aufruf laufen, bringen hier die meiste Wirkung. Eingeloggte Nutzer und Warenkorbseiten in WooCommerce umgehen den Seitencache häufig, testen Sie diese Seiten deshalb gesondert.

Bei Shopify verwaltet die Plattform Server und CDN, Ihr Einfluss auf die TTFB ist entsprechend gering. Der wirksamste Ansatz ist hier, Weiterleitungen zu vermeiden, etwa durch veraltete Links oder Länder- und Sprachumleitungen, die direkt auf die Ziel-URL zeigen könnten.

Bei Next.js und anderen React-Frameworks bestimmt der Rendering-Modus die TTFB. Statisch generierte Seiten liegen fertig bereit und antworten schnell. Serverseitiges Rendering bei jeder Anfrage addiert Datenabruf und Rendering zur Wartezeit. Mit Streaming schickt der Server das Grundgerüst der Seite früh, die langsameren Teile folgen nach.

TTFB messen und Verbesserungen prüfen

In den Chrome DevTools öffnen Sie den Tab „Network“, laden die Seite neu, klicken auf die Dokumentanfrage und wählen „Timing“. Dort sehen Sie DNS-Auflösung, Verbindungsaufbau, SSL und „Waiting for server response“ getrennt und erkennen, welche Phase dominiert.

Auf der Kommandozeile liefert curl dieselbe Aufteilung. Die Werte laufen jeweils ab dem Start der Anfrage auf:

curl -o /dev/null -s -w "DNS:     %{time_namelookup}s\nConnect: %{time_connect}s\nTLS:     %{time_appconnect}s\nTTFB:    %{time_starttransfer}s\nTotal:   %{time_total}s\n" https://example.com/

Wiederholen Sie die Messung mehrmals, weil der erste Aufruf auf einen kalten Cache treffen kann. Ohne die Option -L folgt curl keinen Weiterleitungen. Messen Sie daher die Ziel-URL und zusätzlich die Adressen, über die Besucher tatsächlich einsteigen. In der Browserkonsole lesen Sie die TTFB der aktuellen Seite über die Navigation Timing API aus:

const [nav] = performance.getEntriesByType('navigation');
console.log('TTFB:', Math.round(nav.responseStart), 'ms');

PerfDelta testet mehrere Seiten mobil und am Desktop und stellt Labor- und Felddaten nebeneinander, sodass Sie die gemessene Serverantwort mit der TTFB echter Nutzer vergleichen können. Wie die Werte eingestuft werden, beschreibt die Methodik. Laborwerte zeigen eine Verbesserung sofort, die Felddaten im CrUX folgen über das 28-Tage-Fenster.

Häufige Fragen

Was ist ein guter TTFB-Wert?

Als gut gilt eine TTFB von höchstens 0,8 Sekunden am 75. Perzentil realer Seitenaufrufe. Werte über 0,8 bis 1,8 Sekunden sind verbesserungswürdig, über 1,8 Sekunden gilt die TTFB als schlecht.

Was unterscheidet TTFB und Serverantwortzeit?

Die Feld-TTFB reicht vom Start der Navigation bis zum ersten Byte und schließt Weiterleitungen, Service Worker, DNS-Auflösung, Verbindungsaufbau und die Serverarbeit ein. Die Serverantwortzeit im Lighthouse-Audit misst nur, wie lange der Server für die Antwort auf das Hauptdokument braucht.

Beeinflusst die TTFB das SEO-Ranking?

Die TTFB ist kein Core Web Vital und kein eigenes Ranking-Signal. Indirekt wirkt sie trotzdem, weil ein spätes erstes Byte First Contentful Paint und Largest Contentful Paint verzögert, und LCP gehört zu den Core Web Vitals.

Warum ist die TTFB bei WordPress oft hoch?

Meist erzeugt WordPress jede Seite bei jedem Aufruf neu. Fehlendes Full-Page-Caching, viele Plugins, langsame Datenbankabfragen und knapp bemessenes Shared Hosting sind die häufigsten Gründe.

Was ist der Unterschied zwischen TTFB und Latenz?

Die Latenz beschreibt die Dauer einer einzelnen Rundreise zwischen Browser und Server. Die TTFB umfasst mehrere solcher Rundreisen für DNS, Verbindungsaufbau und TLS, dazu Weiterleitungen und die Zeit, die der Server für die Antwort braucht.

Warum weicht die TTFB im Labor von den Felddaten ab?

Ein Labortest misst eine einzelne Anfrage von einem Standort aus. Die Felddaten im Chrome UX Report bilden echte Besucher in unterschiedlichen Netzen und Regionen über 28 Tage ab, inklusive Weiterleitungen und ungecachter Seiten.