Time to First Byte (TTFB): Definition, Ursachen, Optimierung

Was ist Time to First Byte (TTFB)?

Time to First Byte (TTFB) ist die Zeit zwischen dem Start einer Navigation und dem Moment, in dem das erste Byte der Antwort im Browser ankommt. Sie umfasst Weiterleitungen, den Start des Service Workers, die DNS-Auflösung, Verbindungsaufbau und TLS-Handshake, die Anfrage und die Verarbeitungszeit des Servers. Vorher kann nichts gerendert werden.

TTFB ist kein Core Web Vital, steht aber vor First Contentful Paint und Largest Contentful Paint. Eine langsame Antwort lässt also weniger vom LCP-Budget für alles andere übrig. Die Referenzdefinition steht im TTFB-Leitfaden von web.dev (englisch).

Woraus sich TTFB zusammensetzt

Die Serververarbeitung können Sie meist am stärksten beeinflussen. Die Entfernung zum Server (Netzwerk-Latenz) verbessert ein CDN.

TTFB-Schwellenwerte

Google bewertet das am 75. Perzentil echter Seitenaufrufe. web.dev nennt 0,8 Sekunden einen groben Richtwert, keine strikte Regel. Eine serverseitig gerenderte Seite mit höherer TTFB kann trotzdem einen guten LCP haben, während eine clientseitig gerenderte App stärker auf eine schnelle Antwort angewiesen ist.

Ein durchgerechnetes Beispiel

Mit Beispielzahlen: Eine Produktseite zeigt 120 ms für DNS, Verbindung und TLS zusammen und 40 ms für den Rückweg der Antwort. Der Server braucht aber 900 ms, um das HTML zu erzeugen, weil er 30 Datenbankabfragen nacheinander ausführt. Die TTFB liegt damit bei etwa 1,06 s, und der LCP kann nicht besser sein. Wird das gerenderte HTML kurz am Edge gecacht oder werden die Abfragen auf wenige indizierte zusammengefasst, entfällt der Großteil der 900 ms. Der Netzwerkanteil ändert sich kaum. Deshalb zerlegt man die TTFB in Phasen, bevor man optimiert.

So messen Sie die TTFB

Im Browser liefert die Navigation Timing API den Wert direkt. responseStart wird ab dem Start der Navigation gemessen und enthält damit Weiterleitungen, DNS und Handshake bereits:

new PerformanceObserver((list) => {
  const [nav] = list.getEntriesByType('navigation');
  console.log('TTFB:', nav.responseStart, 'ms');
}).observe({ type: 'navigation', buffered: true });

Auf der Kommandozeile zeigt curl jede Phase. time_starttransfer ist die Zeit vom Start bis zum Empfang des ersten Bytes:

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

Sie können auch den LoadFocus Website-Speed-Test nutzen oder echte Nutzerdaten mit dem Core-Web-Vitals-Checker prüfen. Labortools zeigen einen Aufruf von einem Ort. Felddaten aus Real User Monitoring oder dem Chrome UX Report zeigen, was Ihre Besucher tatsächlich erleben, inklusive Weiterleitungen.

So senken Sie die TTFB

• Cachebare Seiten über ein CDN ausliefern. Ein Content Delivery Network antwortet von einem Edge-Server in der Nähe des Besuchers, mit passenden Cache-Control-Headern. Personalisierte Seiten lassen sich so nicht cachen.
• Weiterleitungen entfernen. Beheben Sie Links, die über http auf https, ein fehlendes www oder einen Schrägstrich am Ende umleiten. Jede kostet einen Round Trip.
• Das Backend beschleunigen. Datenbankindizes anlegen, N+1-Abfragen beseitigen, teure Ergebnisse cachen und nicht auf langsame Drittanbieter-Aufrufe warten.
• Streamen oder vorrendern. HTML in Teilen senden, während es entsteht, oder statische Seiten beim Deployment bauen, wenn sie nicht personalisiert sein müssen.
• 103 Early Hints nutzen. Der Browser kann kritische Ressourcen laden, während ein langsames Backend die Antwort noch fertigstellt.
• Das Backend mit Server-Timing messen. Der Header zeigt pro Anfrage Zeiten für Datenbank, Rendering und Cache-Misses.

Häufige Fehler

• Nur die gecachte Antwort messen. Caching und Early Hints können einen langsamen Origin verbergen. Testen Sie eine ungecachte URL, um die echte Serverzeit zu sehen.
• responseStart - requestStart als "TTFB" verwenden. Das lässt Weiterleitungen, DNS und Handshake aus und unterschätzt die Wartezeit der Nutzer.
• Nach einem einzigen Labortest urteilen. Die TTFB schwankt mit Standort und Last. Betrachten Sie das 75. Perzentil über viele Besuche.
• Kaltstarts ignorieren. Eine Serverless-Funktion oder ein ruhender Container kann die erste Anfrage nach einer ruhigen Phase deutlich verzögern.
• Annehmen, dass die TTFB unter Last passt. Eine Seite, die einem Besucher in 300 ms antwortet, kann bei hunderten gleichzeitigen Besuchern Sekunden brauchen.

TTFB, Lasttests und Monitoring

Weil die Serververarbeitung die variable Größe ist, reagiert die TTFB auf Traffic. Mit dem Lasttest von LoadFocus rufen Sie Ihre Website oder API aus über 25 Cloud-Regionen auf und sehen die Antwortzeiten bei steigender Nutzerzahl. So erkennen Sie, ob das Backend langsamer wird, bevor echter Traffic es trifft. Page Speed Monitoring wiederholt Lighthouse-Audits nach Zeitplan aus 25 Regionen, sodass eine TTFB-Verschlechterung nach einem Deployment als Trend sichtbar wird. Für Core Web Vitals im Monitoring lesen Sie (auf Englisch) how to monitor Core Web Vitals with alerts and reports.

Häufige Fragen: Time to First Byte

Was ist eine gute TTFB?

0,8 Sekunden oder weniger am 75. Perzentil gelten als gut, mehr als 1,8 Sekunden als schlecht. Verstehen Sie 0,8 s als groben Richtwert: Entscheidend ist am Ende, ob FCP und LCP für Ihre Besucher gut sind.

Ist TTFB ein Core Web Vital?

Nein. Die Core Web Vitals sind LCP, INP und CLS. TTFB ist eine Diagnosemetrik, die einen Teil eines langsamen LCP oder FCP erklärt.

Wie verbessert ein CDN die TTFB?

Es beantwortet cachebare Anfragen von einem Edge-Server nahe beim Besucher. Das verkürzt den Verbindungsaufbau und spart den Weg zum Origin. Bei pro Nutzer erzeugten Antworten hilft es nur, wenn das CDN sie cachen oder die Logik am Edge ausführen kann.

Warum unterscheidet sich die TTFB in Labortools und Felddaten?

Ein Labortool misst einen Aufruf von einem Standort in einem festen Netzwerk. Felddaten umfassen echte Besucher mit ihren Weiterleitungen, Geräten und der Entfernung zu Ihren Servern, daher stimmen beide selten überein.

Was ist der Unterschied zwischen TTFB und Server-Antwortzeit?

Die Server-Antwortzeit umfasst nur die Arbeit im Backend. TTFB enthält zusätzlich Weiterleitungen, DNS, Verbindung, TLS und die Netzwerkstrecke und kann für weit entfernte Besucher deutlich größer sein.