wpspeed.support

TTFB verbessern WordPress: Ursachen finden und wirklich beheben

Veröffentlicht am · Zuletzt geprüft:

TTFB bei WordPress senken: Was Time to First Byte ist, wie du misst und warum es fast immer ein Hosting-Problem ist, das kein Plugin löst.

Du hast einen PageSpeed-Insights-Report vor dir und dort steht „Serverantwortzeiten reduzieren". Oder du hast schlicht das Gefühl, dass sich deine Seite träge anfühlt, noch bevor überhaupt ein Bild lädt. Beides führt zur selben Metrik: Time to First Byte, kurz TTFB. Dieser Artikel zeigt, was TTFB genau misst, wie du ihn selbst nachvollziehbar misst, welche vier Ursachen tatsächlich dahinterstecken — und warum die ehrliche Antwort in den meisten Fällen unbequem ist: Es ist dein Hosting, nicht dein Plugin-Setup.

Was TTFB ist — und was nicht

TTFB ist die Zeit vom Absenden der HTTP-Anfrage bis zum ersten Byte der Antwort. Darin stecken DNS-Auflösung, TCP-/TLS-Verbindungsaufbau, die Zeit, die dein Server braucht, um die Anfrage zu verarbeiten (PHP ausführen, Datenbank abfragen, HTML zusammenbauen), und die reine Übertragungslaufzeit über das Netz. TTFB ist kein Core Web Vital — aber er ist die Grundlage für alle, die es sind: Largest Contentful Paint (LCP) und First Contentful Paint können nicht schneller sein als TTFB plus Renderzeit. Ein schlechter TTFB begrenzt jede andere Optimierung von oben (web.dev — TTFB).

Google nennt für TTFB als Felddatenmetrik einen Wert von 0,8 Sekunden oder weniger als „gut", alles über 1,8 Sekunden als „schlecht" — bewertet am 75. Perzentil aller Seitenaufrufe (web.dev — TTFB-Schwellenwerte). Der Lighthouse-Labortest in PageSpeed Insights ist strenger: Der Audit „Serverantwortzeiten reduzieren" schlägt bereits oberhalb von 600 Millisekunden an (Chrome for Developers — Server Response Time). Für die Praxis heißt das: Miss gegen 600 ms, dann bist du auch im Feld auf der sicheren Seite.

Wie du TTFB misst

Rate nicht — miss. Drei Wege, vom einfachsten zum genauesten:

1. Unser Speed-Test-Tool. Unter /speed-test/ bekommst du TTFB zusammen mit LCP, CLS, TBT und FCP in einem Lauf, ohne eigene Kommandozeile — lokal mit Lighthouse auf unseren eigenen Servern in Deutschland gemessen.

2. curl (Kommandozeile, für Entwickler). Damit siehst du exakt, wo die Zeit verloren geht:

curl -o /dev/null -s -w "DNS: %{time_namelookup}s | Connect: %{time_connect}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" https://deine-domain.de/

time_starttransfer ist dein TTFB. Führe den Befehl mehrfach aus — ein einzelner Lauf ist eine Momentaufnahme, keine Aussage.

3. Chrome DevTools. Netzwerk-Tab öffnen, die Dokumentanfrage (die HTML-Seite selbst, meist ganz oben) anklicken, Reiter „Timing". Der Abschnitt „Warten auf Serverantwort" (Waiting, TTFB) ist getrennt von „Inhalt herunterladen" ausgewiesen — das ist wichtig, weil viele die beiden verwechseln und ein großes HTML-Dokument fälschlich für einen TTFB-Fehler halten.

Wichtig bei allen drei Methoden: Miss die Seite mehrfach und zu unterschiedlichen Tageszeiten. Laborwerte schwanken, und ein einzelner guter oder schlechter Wert ist kein Beweis.

Die vier echten Ursachen

1. Hosting und Serverlast. Auf Shared Hosting teilst du dir CPU, RAM und I/O mit anderen Kunden auf demselben physischen Server. Wenn ein anderer Account gerade eine Crawler-Attacke, einen Traffic-Peak oder ineffizienten Code ausführt, sinkt deine Kapazität mit — unabhängig davon, wie gut deine eigene Seite gebaut ist. Das Erkennungsmuster: Ein TTFB, das zwischen Messungen stark schwankt — mal unauffällig, mal deutlich erhöht, ohne dass du etwas geändert hast — ist das klassische Symptom von Ressourcen-Konkurrenz auf überbuchtem Shared Hosting, nicht von deinem Code (GetPageSpeed — Noisy Neighbors erkennen, Liquid Web — Was ist ein „Noisy Neighbor").

2. Fehlender Server- oder Page-Cache. Ohne Full-Page-Cache baut WordPress bei jedem einzelnen Aufruf die Seite neu zusammen: PHP wird ausgeführt, Theme- und Plugin-Hooks laufen durch, Datenbankabfragen werden gestellt. Ein Server- oder Page-Cache liefert stattdessen eine bereits fertige HTML-Antwort aus dem Speicher aus. Das ist der Hebel mit dem größten Einzeleffekt auf TTFB, kostet aber nichts an Serverleistung — deshalb dazu gleich mehr im Abschnitt „Was tatsächlich hilft".

3. PHP- und Datenbank-Latenz. Viele Plugins, eine veraltete PHP-Version, unindizierte Datenbankabfragen oder ein Page Builder mit schwerem Backend-Rendering verlängern die Zeit, die der Server für die eigentliche Verarbeitung braucht — selbst mit Cache, nämlich beim ersten (nicht gecachten) Aufruf oder bei dynamischen Seiten wie dem Warenkorb. web.dev nennt explizit „aufwendige Datenbankoperationen" und „unzureichenden Arbeitsspeicher" als Ursachen für langsame Serverantworten (web.dev — TTFB optimieren).

Ein oft übersehener Teilaspekt: die PHP-Version selbst. Offiziell aktiv unterstützt (Bugfixes und Sicherheitspatches) sind aktuell nur PHP 8.4 und 8.5, während 8.2 und 8.3 nur noch Sicherheitspatches ohne Performance-Fixes erhalten und alles unter 8.2 gar keine Unterstützung mehr bekommt (php.net — Supported Versions). Läuft dein Server noch auf PHP 7.4 oder 8.0, weil ein altes Theme das verlangt, verschenkst du damit Performance, die kein Plugin zurückholt — das ist ein Hosting- beziehungsweise Wartungsthema, kein Cache-Thema.

4. Geografische Distanz. Licht und mit ihm Daten legen auf dem Glasfaser-Backbone rund 200.000 Kilometer pro Sekunde zurück — schneller geht es physikalisch nicht (Cloudflare — Round-Trip Time). Steht dein Server in den USA und dein Publikum in Deutschland, addiert allein die Laufzeit über den Atlantik spürbare Millisekunden zu jeder Anfrage — pro Hin- und Rückweg, nicht einmalig. Ein Server- oder Edge-Standort nahe an deiner Zielgruppe behebt das strukturell; ein Cache-Plugin kann diese Distanz nicht verkürzen.

Die Kernaussage: TTFB ist ein Hosting-Problem

Hier die unbequeme Wahrheit, die die meisten Ratgeber auslassen, weil sie an Plugin-Provisionen verdienen: Kein Asset-Optimierungs-Plugin senkt TTFB nennenswert. WP Rocket, Perfmatters und vergleichbare Tools sind exzellent darin, Bilder zu komprimieren, CSS/JS zu verzögern und Lazy-Loading zu steuern — das wirkt auf LCP, CLS und die Ladezeit nach dem ersten Byte. Auf die Zeit bis zum ersten Byte haben sie kaum Einfluss, weil sie im Browser beziehungsweise auf Anwendungsebene ansetzen, nicht am Server selbst.

Konkret zu WP Rocket: Der offiziell angebundene CDN-Dienst RocketCDN unterstützt laut unabhängigem Test kein vollständiges Full-Page-Caching und keine serverseitige Auslieferung, die TTFB strukturell senken würde — genau der Hebel, der bei geografischer Distanz und Serverlast greifen würde, fehlt (OnlineMediaMasters — WP Rocket Review). Das ist keine Anti-Empfehlung für WP Rocket insgesamt — für Bild- und Skript-Optimierung ist es solide, mehr dazu im Cache-Plugin-Vergleich — aber es ist die falsche Antwort auf einen TTFB-Alarm.

Entscheidungsbaum: Was du wann tust

  1. Miss zuerst. Mit /speed-test/ oder curl, mehrfach, zu unterschiedlichen Zeiten.
  2. TTFB unter 600 ms? Dein Server ist nicht das Problem. Schau dir stattdessen LCP oder Core Web Vitals insgesamt an — oder starte bei WordPress langsam — Ursachen finden, wenn du noch nicht weißt, wo überhaupt das Problem liegt.
  3. TTFB über 600 ms und noch kein Full-Page-Cache aktiv? Aktiviere zuerst serverseitiges oder Page-Caching. Bist du bei einem LiteSpeed-Host, nutze das kostenlose LiteSpeed Cache — Details und Alternativen im Cache-Plugin-Vergleich. Miss danach erneut.
  4. Immer noch über 600 ms trotz aktivem Full-Page-Cache? Jetzt bist du beim Server selbst: veraltete PHP-Version, überbuchtes Shared Hosting, oder Serverstandort weit weg von deinem Publikum. Das löst kein Plugin — das löst nur ein Hostingwechsel oder eine Serverstandort-Korrektur.
  5. Schwankt TTFB stark zwischen Messungen (mal gut, mal schlecht, ohne dass du etwas geändert hast)? Das ist das Muster von Ressourcen-Konkurrenz auf Shared Hosting. Auch hier: Hostingfrage, keine Plugin-Frage.

Was tatsächlich hilft

Nach Schritt 3 des Entscheidungsbaums bist du oft schon fertig — Full-Page-Caching löst den größten Teil der TTFB-Fälle, die nicht strukturell im Hosting liegen. Bleibt der Wert danach hoch, brauchst du einen Hoster, der serverseitiges Caching, moderne PHP-Versionen und ausreichend dedizierte Ressourcen ohne Überbuchung mitbringt statt nachzurüsten.

Für den deutschen Markt mit Server- und Support-Standort in Deutschland empfehlen wir dafür Raidboxes*, WPspace* oder HostPress* — alle drei bringen serverseitiges Caching bereits im Hosting mit, sodass ein zusätzliches Full-Page-Cache-Plugin oft gar nicht nötig ist. Einen ausführlichen, ehrlichen Vergleich inklusive DSGVO-Kriterien findest du im Hosting-Vergleich — dort auch die Antwort auf die Frage, ab welchem Preispunkt „billig" anfängt, TTFB strukturell zu gefährden.

Häufige Fragen zu TTFB bei WordPress

Was ist ein guter TTFB-Wert für WordPress?

Nach Googles Core-Web-Vitals-Definition gelten 0,8 Sekunden oder weniger als gut, alles über 1,8 Sekunden als schlecht (web.dev). Der strengere Lighthouse-Labortest in PageSpeed Insights verlangt unter 600 ms, damit der Audit „Serverantwortzeiten reduzieren" nicht mehr anschlägt (Chrome for Developers). Miss gegen 600 ms, dann bist du auf der sicheren Seite.

Senkt ein Cache-Plugin den TTFB?

Ein Full-Page- oder Server-Cache-Plugin senkt TTFB deutlich, weil es die PHP- und Datenbank-Verarbeitung bei wiederholten Aufrufen komplett umgeht. Reine Asset-Optimierungs-Plugins ohne eigenes Full-Page-Caching (Bildkomprimierung, CSS/JS-Verzögerung) verändern TTFB dagegen kaum — sie setzen zeitlich nach dem ersten Byte an.

Ist TTFB ein Ranking-Faktor?

TTFB selbst ist kein Core Web Vital und damit kein direkter Google-Ranking-Faktor. Er wirkt aber indirekt: Ein hoher TTFB verzögert zwangsläufig LCP und FCP, die wiederum Core Web Vitals sind (web.dev).

Warum schwankt mein TTFB zwischen zwei Messungen so stark?

Das ist bei Shared Hosting normal und meist ein Zeichen von Ressourcen-Konkurrenz mit anderen Kunden auf demselben Server, nicht von einem Fehler auf deiner Seite (GetPageSpeed). Miss mehrfach zu unterschiedlichen Tageszeiten, bevor du eine Ursache vermutest.

Hilft ein CDN gegen hohen TTFB?

Bei geografischer Distanz zwischen Server und Besucher: ja, weil ein CDN Inhalte näher am Nutzer ausliefert und die physikalisch bedingte Laufzeit verkürzt (web.dev — TTFB optimieren). Liegt die Ursache dagegen an Serverlast oder fehlendem Cache, löst ein CDN allein das Problem nicht — die Grundursache bleibt bestehen.