Was ist Time to First Byte?
Du klickst auf einen Link — und dann? Erst mal nichts. Der Browser fragt beim Server an, wartet auf Antwort, und erst wenn das erste Byte zurückkommt, kann er überhaupt anfangen, die Seite aufzubauen. Genau diese Wartezeit misst die Time to First Byte (TTFB).
Laut Google steckt in der TTFB mehr als nur dein Server. Sie läuft vom Start der Navigation bis zum ersten Antwort-Byte und umfasst:
- Weiterleitungen, etwa von http auf https oder von ohne auf mit www
- DNS-Abfrage — der Browser sucht die IP-Adresse zu deiner Domain
- Verbindungs- und TLS-Aufbau — die verschlüsselte Leitung zum Server
- Rechenzeit des Servers — PHP, Datenbank, Plugins, bis die Seite fertig ist
Gemessen wird in Millisekunden. Bei echten Nutzern zählt Google den Wert am 75. Perzentil: Drei von vier Aufrufen müssen mindestens so schnell sein. Ein einzelner Test von deinem Büro-Rechner sagt darüber wenig.
Was ist ein guter TTFB?
Google nennt auf web.dev eine grobe Richtlinie für den gesamten TTFB echter Nutzer:
TTFB
Bewertung
bis 0,8 s
gut
0,8 bis 1,8 s
verbesserungsbedürftig
über 1,8 s
schlecht
Vorsicht, hier kursieren zwei Schwellen. Lighthouse und WordPress (unter Werkzeuge → Website-Zustand) schlagen schon ab 600 Millisekunden an. Sie messen aber nur die Antwortzeit des Servers, ohne DNS und Weiterleitungen. Beide Zahlen stimmen also — sie messen nur nicht dasselbe.
Wie sieht es draußen aus? Laut Web Almanac 2025 (HTTP Archive, Felddaten aus dem Chrome UX Report, Juli 2025) erreichen 55 % der Desktop-Seiten einen guten TTFB, mobil nur 44 %. Mobil hat sich das seit Jahren kaum bewegt: 2021 waren es 41 %.
Warum TTFB trotzdem fürs SEO zählt
Der LCP misst, wann das größte sichtbare Element steht — meist das Titelbild oder die Überschrift. Die TTFB ist sein erster Teilabschnitt. Google empfiehlt als groben Richtwert, dass sie etwa 40 % der LCP-Zeit ausmachen darf. Bei einem LCP-Ziel von 2,5 Sekunden ist also nach rund einer Sekunde Schluss.
Wie stark das durchschlägt, zeigt der Web Almanac 2024: Seiten mit gutem LCP hatten am 75. Perzentil einen medianen TTFB von 600 Millisekunden, Seiten mit schlechtem LCP von 2.270 Millisekunden. Wer schon über zwei Sekunden auf den Server wartet, holt das mit Bildoptimierung nicht mehr rein.
Was den TTFB bremst — gerade bei WordPress
Bei kleinen Websites liegt der Engpass fast immer auf dem Server. Die WordPress-Dokumentation nennt die üblichen Bremsen selbst:
- Kein Seiten-Cache: WordPress baut jede Seite bei jedem Aufruf neu aus PHP und Datenbank.
- Kein Object Cache: Jede Abfrage geht wieder an die Datenbank.
- Alte PHP-Version: WordPress empfiehlt PHP 8.3 oder höher.
- Zu viele oder schwere Plugins und ein überladenes Theme.
- Günstiges Shared Hosting, das sich die Rechenzeit mit Hunderten anderer Seiten teilt.
Häufige Fehler
Fehler 1 · Nur mit warmem Cache messen
Du testest die Startseite dreimal, sie kommt aus dem Cache, alles grün. Der erste Besucher nach einem Update oder ein eingeloggter Kunde im Shop wartet trotzdem zwei Sekunden. Google warnt selbst: Caching ist gut, kann aber ein langsames Backend verstecken. Miss auch ungecachte Seiten.
Fehler 2 · Laborwert mit Felddaten verwechseln
Ein Test vom Server in Frankfurt mit Glasfaser ist nicht dein Kunde im Zug mit schwachem Netz. Für Entscheidungen zählen die Felddaten echter Nutzer, etwa aus dem Chrome UX Report in PageSpeed Insights.
Fehler 3 · TTFB für die ganze Geschwindigkeit halten
Ein niedriger TTFB heißt nicht, dass die Seite schnell ist. Laut Google kann eine Single-Page-App sehr früh antworten und trotzdem spät etwas zeigen, weil der Browser erst Unmengen JavaScript abarbeitet. TTFB ist das Fundament, nicht das ganze Haus.
So senkst du deinen TTFB
Googles Leitfaden „Optimize TTFB“ und die WordPress-Doku laufen auf dieselbe Reihenfolge hinaus:
- Seiten-Cache einschalten — bei WordPress etwa mit WP Rocket oder dem Cache deines Hosters. Der größte Hebel.
- Weiterleitungen aufräumen — jeder Umweg kostet einen kompletten Hin- und Rückweg.
- PHP aktuell halten und einen Object Cache wie Redis nutzen, wenn dein Hoster ihn anbietet.
- Plugins ausmisten — was keiner braucht, fliegt raus.
- CDN mit HTML-Cache, wenn deine Besucher weit verstreut sind.
- Hosting wechseln, wenn der Server trotz Cache über eine Sekunde braucht.
Häufige Fragen
Was ist ein guter TTFB-Wert?
Google wertet bis 0,8 Sekunden als gut und über 1,8 Sekunden als schlecht, gemessen bei echten Nutzern am 75. Perzentil. Lighthouse und WordPress schlagen schon ab 600 Millisekunden an, messen aber nur die Antwortzeit des Servers.
Ist TTFB ein Rankingfaktor?
Nicht direkt. TTFB gehört nicht zu den Core Web Vitals. Er bremst aber den Largest Contentful Paint, und der ist ein Core Web Vital. Ein langsamer Server kostet also indirekt.
Warum ist mein TTFB bei WordPress so hoch?
Meist fehlt ein Seiten-Cache, dann baut WordPress jede Seite neu aus PHP und Datenbank. Weitere Ursachen sind alte PHP-Versionen, viele Plugins und günstiges Shared Hosting.
Wie messe ich den TTFB?
Felddaten echter Nutzer zeigt PageSpeed Insights aus dem Chrome UX Report. Für eigene Tests reichen die Entwicklertools im Browser (Netzwerk → Timing) oder WebPageTest. Miss mehrmals und auch ohne Cache.
Hilft ein CDN gegen hohen TTFB?
Nur, wenn es auch das HTML zwischenspeichert. Cloudflare speichert HTML standardmäßig nicht, dafür brauchst du eine eigene Cache-Regel. Ob es klappt, zeigt der Header cf-cache-status.
Quellen
- web.dev: Time to First Byte (TTFB)
- Google Search Central: Core Web Vitals
- HTTP Archive: Web Almanac 2025, Performance
- HTTP Archive: Web Almanac 2024, Performance
- web.dev: Optimize Largest Contentful Paint
- Cloudflare Docs: Standardverhalten des Caches
- WordPress.org: Anforderungen
- web.dev: Optimize Time to First Byte
