Serverantwortzeit reduzieren (TTFB)

Wenn PageSpeed Insights oder Lighthouse „Serverantwortzeit reduzieren" meldet (die genaue Formulierung kann je nach Lighthouse-Version abweichen), wurde gemessen, wie lange der Server gebraucht hat, um das erste Byte des Hauptdokuments zu senden, und dieser Wert war zu hoch. Diese Zeit ist Ihre Time to First Byte, kurz TTFB, und alles Weitere auf der Seite muss darauf warten. Lighthouse schlägt an, wenn sie etwa 600 Millisekunden überschreitet. Dieser Leitfaden erklärt, was TTFB ist und wie Sie die Serverantwortzeit reduzieren.

Was die Serverantwortzeit bedeutet

Fordert ein Browser eine Seite an, hat der Server Arbeit zu erledigen, bevor er antworten kann: die Anfrage zu einem Ziel routen, Anwendungscode ausführen, die Datenbank abfragen, das HTML zusammenbauen und mit dem Senden beginnen. TTFB ist die Zeit vom Verlassen der Anfrage bis zum Eintreffen des ersten Byte dieser Antwort. Gemessen wird sie am Hauptdokument, also am initialen HTML, nicht an Bildern oder Skripten, weshalb diese Prüfung auf den Server zeigt und nicht auf das Frontend.

Eine langsame Antwort stammt meist von nicht optimiertem Anwendungscode, schweren oder wiederholten Datenbankabfragen, fehlendem Caching, einem weit entfernten Server oder schlicht schwachem Hosting. Weil TTFB auch eine Feldmetrik im Chrome UX Report ist, zeigen echte Nutzerdaten, ob das Problem Besucher betrifft und nicht nur den Labortest.

Was ist die Time to First Byte (TTFB)?

Die Time to First Byte ist die konkrete Zahl, auf der diese Prüfung beruht. Sie misst die Zeit von dem Moment, in dem der Browser die Anfrage sendet, bis das erste Byte der Antwort zurückkommt. TTFB deckt drei aufeinanderfolgende Dinge ab: die Netzwerkzeit bis zum Server, die Zeit, die der Server zum Bauen der Antwort braucht, und die Zeit, bis dieses erste Byte zurückreist. Ein guter TTFB-Wert liegt in der Regel unter 800 Millisekunden. Weil das erste Byte eintreffen muss, bevor irgendetwas anderes geschehen kann, ist TTFB der Boden unter jeder anderen Ladekennzahl: Kein noch so gutes Frontend kann Inhalt zeichnen, den der Browser noch nicht empfangen hat.

Warum es für Ladezeit und Core Web Vitals zählt

TTFB steht ganz am Anfang der Ladesequenz, deshalb schiebt eine langsame Antwort jede folgende Kennzahl nach hinten. Der Browser kann nicht mit dem Parsen der HTML beginnen, keine Ressourcen entdecken und nichts zeichnen, bevor das Dokument da ist, was First Contentful Paint und Largest Contentful Paint direkt verzögert. Die Serverantwortzeit zu senken hebt also die Obergrenze für jede weitere Optimierung. Weil die Core Web Vitals ein Google-Ranking-Signal sind, nützt eine schnellere Antwort Nutzererfahrung und Sichtbarkeit zugleich. Der Bezug zu den Ladekennzahlen ist in den Seiten zu Largest Contentful Paint und First Contentful Paint vertieft.

Häufige Ursachen einer hohen TTFB

Einige Ursachen wiederholen sich über fast alle Seiten. Fehlendes oder unwirksames Caching, sodass jede Anfrage die Seite neu aufbaut. Schwere oder wiederholte Datenbankabfragen, oft das N+1-Muster, bei dem eine Liste eine Abfrage pro Element auslöst. Zu viele oder schlecht geschriebene Plugins und Erweiterungen, die früh im Ladevorgang laufen. Ein Server, der geografisch weit vom Publikum entfernt steht. Und Shared Hosting, dessen Ressourcen sich viele Websites teilen. Meist sind es nicht alle gleichzeitig, sondern eine oder zwei dominante Ursachen, die den Großteil der Zeit ausmachen.

TTFB messen

Bevor Sie etwas ändern, feststellen, wo die Zeit hingeht. Eine schnelle Prüfung auf der Kommandozeile zeigt die Serverantwortzeit isoliert:

curl -w "TTFB: %{time_starttransfer}s\n" -o /dev/null -s https://example.com

Einige wichtige Vorlagen testen und aus einer Region messen, die Ihrem Publikum ähnelt, denn Entfernung allein fügt Latenz hinzu. PageSpeed Insights zeigt TTFB in den Felddaten, WebPageTest schlüsselt die Antwortzeit weiter auf, und der Core-Web-Vitals-Bericht der Search Console zeigt, ob viele URLs betroffen sind.

Für die genaue Diagnose lohnt es, TTFB in ihre Bestandteile zu zerlegen. Ein WebPageTest-Wasserfall trennt DNS-Auflösung, Verbindungsaufbau, TLS-Handshake und die reine Wartezeit auf den Server, sodass sichtbar wird, ob das Problem im Netzwerk oder in der Serververarbeitung liegt. Auf der Serverseite kann der Server-Timing-Header eigene Messpunkte an den Browser zurückgeben, etwa die Dauer der Datenbankabfrage oder des Renderings, die dann direkt in den DevTools erscheinen. So lässt sich die Serverzeit gezielt dort senken, wo sie tatsächlich anfällt.

Serverantwortzeit reduzieren

1. Die gerenderte Seite cachen

Der wirksamste einzelne Fix ist, die Seite nicht bei jeder Anfrage neu zu bauen. Full-Page-Caching speichert das fertige HTML und liefert es dem nächsten Besucher sofort aus, verwandelt also schwere dynamische Arbeit in einen einfachen Dateizugriff. Auf einer Content-Seite, deren Seiten sich selten ändern, bringt das allein die TTFB oft von Sekunden auf Millisekunden.

2. Anwendungs- und Objekt-Cache ergänzen

Für Seiten, die dynamisch bleiben müssen, die teuren Teile cachen. Ein Objekt-Cache speichert die Ergebnisse von Datenbankabfragen, damit sie nicht wiederholt werden, und ein PHP-Opcode-Cache wie OPcache hält kompilierten Code im Speicher, statt ihn bei jeder Anfrage neu zu kompilieren. Beides senkt die Arbeit pro Aufruf.

3. Ein CDN nutzen und Arbeit an den Rand verlagern

Ein Content Delivery Network liefert gecachte Antworten aus einem Standort nahe dem Besucher, was die Netzwerkentfernung aus der Gleichung nimmt. Viele CDNs können auch das HTML selbst am Rand cachen, sodass der Ursprungsserver deutlich seltener kontaktiert wird.

4. Datenbank und Anwendungscode optimieren

Langsame Abfragen sind ein häufiger Übeltäter. Indizes für die Spalten anlegen, nach denen gefiltert wird, N+1-Abfragemuster beseitigen und die langsamsten Anfragen profilieren. Auch das Reduzieren von Weiterleitungen hilft, weil jeder zusätzliche Sprung eine volle Rundreise addiert, bevor das eigentliche Dokument ausgeliefert wird. Zum Finden der Bremsen das Slow-Query-Log aktivieren und einzelne Abfragen mit EXPLAIN prüfen, das zeigt, ob ein Index genutzt wird oder die Datenbank die ganze Tabelle durchsucht.

5. Das Hosting richtig dimensionieren

Shared Hosting kann begrenzen, wie schnell eine Antwort überhaupt möglich ist. Eine aktuelle PHP-Version, aktiviertes OPcache und ein Tarif oder Server mit mehr Reserven bewirken oft einen Sprung, den keine Anwendungsoptimierung auf beschränkter Hardware erreicht.

6. Verbindung und Protokoll optimieren

Auf der Netzwerkseite verkürzen ein schneller DNS-Anbieter, TLS 1.3 mit Session-Wiederaufnahme und moderne Protokolle wie HTTP/2 und HTTP/3 den Weg zum ersten Byte. Keep-Alive und Kompression der Antwort runden das ab. Diese Hebel sind kleiner als das Caching, summieren sich aber, besonders für weit entfernte Besucher. HTTP/3 über QUIC verkürzt zusätzlich den Verbindungsaufbau, was auf mobilen und verlustbehafteten Verbindungen spürbar ist.

Dynamische und statische Seiten

Nicht jede Seite braucht dieselbe Lösung. Eine weitgehend statische Seite wie ein Blog oder eine Broschürenseite profitiert am meisten von Full-Page-Caching, das jede Seite in eine ausgelieferte Datei verwandelt. Eine stark dynamische Seite wie ein eingeloggter Bereich oder ein Warenkorb kann nicht vollständig gecacht werden, gewinnt aber durch Objekt-Caching, OPcache und Datenbankoptimierung. Der erste Schritt ist immer, zu klären, welcher Anteil einer Antwort wirklich pro Besucher einzigartig ist und welcher wiederverwendet werden kann.

Welches Hosting für eine niedrige TTFB

Die Art des Hostings setzt eine Untergrenze, die keine Software unterschreiten kann. Shared Hosting teilt einen Server unter vielen Websites, ist günstig, liefert aber schwankende und oft hohe Antwortzeiten, sobald die Nachbarn Last erzeugen. Ein VPS oder ein dedizierter Server reserviert Ressourcen und macht die TTFB berechenbarer. Managed-WordPress- oder Application-Hosting bringt Full-Page- und Objekt-Caching, aktuelle PHP-Versionen und oft ein CDN bereits vorkonfiguriert mit. Cloud- und Edge-Plattformen können statische oder vorgerenderte Antworten nahe am Besucher ausliefern und erreichen die niedrigsten Werte. Für eine Seite, die trotz sauberem Caching und optimierter Datenbank eine hohe TTFB behält, ist der Wechsel der Hosting-Klasse häufig der wirksamste einzelne Schritt.

TTFB in WordPress reduzieren

In WordPress kommt eine hohe TTFB meist aus drei Quellen: fehlendes Full-Page-Caching, zu viele Plugins, die bei jeder Anfrage Code ausführen, und schwaches Hosting. Ein Caching-Plugin mit Full-Page-Cache aktivieren, einen persistenten Objekt-Cache wie Redis ergänzen, eine aktuelle PHP-Version mit OPcache nutzen und ein CDN vorschalten. Nicht genutzte Plugins entfernen und ein schlankes Theme wählen, denn jedes Plugin, das früh im Ladevorgang läuft, verlängert die Antwort. Reicht das nicht, ist der Host die Grenze, dann auf einen schnelleren Tarif oder spezialisiertes WordPress-Hosting wechseln.

TTFB als Feldmetrik

TTFB ist nicht nur ein Laborwert, sondern eine eigene Feldmetrik im Chrome UX Report. Google weist sie, wie die Core Web Vitals, am 75. Perzentil der realen Aufrufe aus, drei von vier Besuchern sollten den Zielwert also erreichen. Wie bei den anderen Kennzahlen erfolgt die Ausweisung pro URL, sofern eine Seite genug Verkehr hat, sonst als Origin-Durchschnitt. Das erklärt, warum eine einzelne schnelle Seite trotzdem einen schlechten Feldwert zeigen kann, wenn der Rest der Domain langsam ist, und warum Verbesserungen erst über das nachlaufende 28-Tage-Fenster sichtbar werden.

Den Fix prüfen

Die curl-Prüfung und PageSpeed Insights erneut ausführen und bestätigen, dass die TTFB unter die Schwelle gesunken ist. Sowohl eine gecachte als auch eine ungecachte Anfrage testen, denn der erste Aufruf nach einer Cache-Leerung ist immer langsamer. Laborwerkzeuge reagieren sofort, die TTFB-Felddaten im Chrome UX Report folgen über ein nachlaufendes 28-Tage-Fenster, reale Verbesserungen zeigen sich also über die folgenden Wochen. Mehrere Vorlagen messen, weil ein gecachter Artikel und eine ungecachte Kassenseite sich sehr unterschiedlich verhalten können.

Häufige Fragen

Was ist eine gute Serverantwortzeit?

Lighthouse schlägt bei einer Time to First Byte über etwa 600 Millisekunden an, ein allgemein guter TTFB-Wert liegt unter 800 Millisekunden. Deutlich darunter zielen: Eine gut gecachte Seite antwortet in zweistelligen Millisekunden.

Was ist der Unterschied zwischen TTFB und Serverantwortzeit?

In diesem Zusammenhang beschreiben sie dasselbe: die Zeit von der Anfrage bis zum ersten Byte des Hauptdokuments. Lighthouse misst sie am initialen HTML, nicht an Bildern oder Skripten.

Wie messe ich die Serverantwortzeit?

Über PageSpeed Insights oder mit einer Kommandozeilen-Prüfung wie curl -w "%{time_starttransfer}" gegen Ihre URL. Aus einer Region messen, die Ihrem Publikum ähnelt, weil Entfernung Latenz hinzufügt.

Verbessert eine niedrigere Serverantwortzeit die Core Web Vitals?

Ja. TTFB steht am Anfang des Ladens, deshalb lässt eine Senkung First Contentful Paint und Largest Contentful Paint früher geschehen. Sie ist zudem selbst eine Feldmetrik, und die Core Web Vitals sind ein Ranking-Signal.

Wie reduziere ich die Serverantwortzeit in WordPress?

Full-Page-Caching mit einem Caching-Plugin aktivieren, Objekt-Caching ergänzen, eine aktuelle PHP-Version mit OPcache nutzen und ein CDN vorschalten. Begrenzt der Host die Antwort weiterhin, auf einen schnelleren Tarif wechseln.

Ist TTFB dasselbe wie die Ladezeit?

Nein. TTFB ist nur der erste Abschnitt: die Zeit bis zum ersten Byte. Die gesamte Ladezeit umfasst danach das Laden von CSS, JavaScript, Bildern und Schriften. Eine niedrige TTFB ist die Voraussetzung für eine schnelle Ladezeit, aber nicht ihr einziger Bestandteil.

Warum ist meine TTFB im Feld anders als im Test?

Ein Test misst einen einzelnen Aufruf aus einer Region, die Felddaten bilden viele reale Geräte, Standorte und Netzverbindungen über 28 Tage ab. Google nutzt die Felddaten, der Einzeltest dient der Diagnose.