TTFB verbessern: So sinkt die Time to First Byte

Die TTFB verbesserst du, indem du die Zeit verkürzt, die zwischen der Anfrage des Browsers und dem ersten Byte der Antwort vergeht. Dafür gibt es drei Hebel: Server und Anwendung erzeugen das HTML schneller, fertige Seiten kommen aus dem Cache, und die Antwort entsteht näher an deinen Besuchern. Hier erfährst du, wie du herausfindest, welcher dieser Hebel bei dir klemmt, und was du jeweils tun kannst.

Was die TTFB misst

Die Time to First Byte ist keine einzelne Messgröße, sondern die Summe mehrerer Schritte, die ablaufen, bevor überhaupt Inhalt ankommt:

1. Weiterleitungen, falls die aufgerufene URL zuerst woanders hinzeigt.
2. DNS-Abfrage, also die Übersetzung deines Domainnamens in eine IP-Adresse.
3. Verbindungsaufbau mit TCP-Handshake und bei HTTPS zusätzlich der TLS-Aushandlung.
4. Verarbeitung auf dem Server: PHP läuft, die Datenbank wird abgefragt, Templates werden gerendert.
5. Der Rückweg des ersten Bytes zum Browser.

Deshalb können zwei Websites auf identischen Servern eine völlig unterschiedliche TTFB haben. Die eine steht nah bei ihren Besuchern und liefert gecachte Seiten aus, die andere steht auf einem anderen Kontinent und baut jede Seite neu.

Zu den drei Core Web Vitals gehört die TTFB nicht, sie liegt aber unter allen dreien. Denn solange das erste Byte fehlt, kann der Browser nichts darstellen. Eine langsame TTFB verzögert also direkt den Largest Contentful Paint. Ist dein LCP schlecht, lohnt sich deshalb zuerst ein Blick auf die TTFB. Wie die Kennzahlen zusammenhängen, erklärt der Ratgeber zu den Core Web Vitals.

Welche TTFB ist gut?

Google empfiehlt in seinem Leitfaden zur TTFB auf web.dev, dass die meisten Websites eine TTFB von 0,8 Sekunden oder weniger anstreben, gemessen am 75. Perzentil echter Seitenaufrufe. Werte über 1,8 Sekunden gelten als schlecht.

Zwei Dinge solltest du dabei im Kopf behalten. Erstens beschreiben diese Werte echte Nutzer in echten Netzen, auch mit schwachem Mobilfunk und weit weg von deinem Server. Ein Test aus dem Büro neben dem Rechenzentrum sieht deutlich besser aus als das, was ein Besucher aus Übersee erlebt. Zweitens sind 0,8 Sekunden ein Richtwert und keine feste Bestehensgrenze. Seiten, die komplett im Browser rendern, vertragen etwas mehr. Serverseitig gerenderte Seiten, also die meisten WordPress-Websites und Onlineshops, profitieren davon, klar darunter zu bleiben.

Messen und den langsamen Schritt finden

Bevor du etwas änderst, solltest du wissen, wo die Zeit verloren geht. Für einen schnellen Check reicht curl auf der Kommandozeile:

curl -o /dev/null -s -w "dns:      %{time_namelookup}\nconnect:  %{time_connect}\ntls:      %{time_appconnect}\nttfb:     %{time_starttransfer}\ntotal:    %{time_total}\n" https://example.com/

Die Werte sind kumuliert und in Sekunden angegeben. Die einzelnen Schritte bekommst du durch Subtraktion:

• connect - dns ist der Netzwerk-Roundtrip zum Server.
• tls - connect ist der HTTPS-Handshake.
• ttfb - tls ist grob die Verarbeitungszeit auf dem Server plus ein Roundtrip.

Führe den Befehl mehrmals aus, denn die erste Anfrage zahlt oft für einen kalten Cache oder eine frische DNS-Abfrage. Bleibt ttfb - tls hoch, etwa bei mehreren hundert Millisekunden, während die Netzwerkwerte klein sind, bremst dein Server. Sind dagegen die Netzwerkwerte groß, liegt das Problem bei Entfernung und Verbindungsaufbau.

Echte Nutzerdaten findest du auf corewebvitals.page bei den Felddaten aus Chrome, sofern deine Website genug Besucher hat. In den Chrome DevTools zeigt der Tab „Network" für jede Anfrage eine Aufschlüsselung, und „Waiting for server response" ist der Serveranteil der TTFB. Wie du diese Quellen kombinierst, ohne dich selbst zu täuschen, steht im Ratgeber Ladezeit richtig messen.

Server und Anwendung beschleunigen

Frisst die Verarbeitung die meiste Zeit, liegt die Lösung auf dem Ursprungsserver. Geh die Punkte am besten der Reihe nach durch, vom einfachsten zum aufwendigsten.

Laufzeitumgebung aktualisieren

Neuere Versionen von PHP, Node.js oder Python erledigen dieselbe Arbeit oft spürbar schneller. Schau nach, welche Version dein Hoster einsetzt und ob dein CMS samt Plugins schon eine neuere unterstützt.

Objekt-Cache einrichten

WordPress, WooCommerce, Shopware, Magento und Drupal stellen viele Datenbankabfragen immer wieder. Ein persistenter Objekt-Cache wie Redis oder Memcached hält die Ergebnisse zwischen den Anfragen im Arbeitsspeicher. Viele Managed-Hoster bieten das per Schalter an.

Langsame Abfragen und Plugins aufspüren

Ein einziges Plugin, das bei jedem Seitenaufruf eine teure Abfrage startet, kann die TTFB dominieren. Nutze auf einer Staging-Kopie einen Profiler oder Query Monitor, deaktiviere Verdächtige einzeln und miss danach neu. In Shops sind Filternavigation, Widgets für ähnliche Produkte und Live-Bestandsabfragen typische Kandidaten.

Serverressourcen prüfen

Ist die TTFB nachts in Ordnung und in Stoßzeiten schlecht, gehen dem Server CPU, Arbeitsspeicher oder PHP-Worker aus. Dann sind mehr Ressourcen oder ein besserer Hostingtarif die richtige Antwort, und keine Frontend-Optimierung ändert daran etwas.

Komplette HTML-Seiten cachen

Die meisten Anfragen an eine typische Website betreffen Seiten, die für alle anonymen Besucher gleich aussehen. Diese Seiten jedes Mal neu zu erzeugen, ist verschenkte Arbeit. Ein Full-Page-Cache speichert das fertige HTML und liefert es aus, ohne PHP oder die Datenbank anzufassen. Das bringt bei der TTFB meist den größten einzelnen Effekt.

Cachen kannst du auf verschiedenen Ebenen:

• In der Anwendung, mit einem Caching-Plugin oder dem eingebauten HTTP-Cache (Shopware und Drupal bringen einen mit). Für WordPress gibt die offizielle Dokumentation zum Caching einen guten Überblick.
• Auf dem Server, mit einem Reverse Proxy wie Varnish oder dem Nginx-Cache.
• Am Edge, also in einem CDN oder Edge-Netzwerk, sodass gecachte Seiten von einem Standort nahe beim Besucher kommen.

Egal welche Ebene du wählst, sei streng bei dem, was nicht in den Cache darf: Warenkorb, Checkout, Kundenkonto, eingeloggte Sitzungen und alles Personalisierte. Solche Anfragen müssen den Cache umgehen und jedes Mal zum Ursprungsserver gehen. Schicken deine Seiten sinnvolle Cache-Control-Header, kann sich jede Ebene danach richten.

Ob eine Seite wirklich aus dem Cache kam, verraten die Antwort-Header:

curl -sI https://example.com/ | grep -i -E "cache|age"

Ein Cache, der kaum Treffer liefert, bringt wenig. Schuld sind meist Cookies oder Query-Parameter, durch die jede Anfrage einzigartig aussieht, oder zu kurze Cache-Laufzeiten.

Den Weg zum Besucher verkürzen

Jeder Roundtrip zwischen Browser und Server kostet Zeit, und eine neue HTTPS-Verbindung braucht mehrere davon, bevor das erste Byte fließt. Steht dein Server in Frankfurt und sitzt der Besucher in Sydney, verlängert allein die Physik jeden dieser Roundtrips spürbar, ganz gleich, wie schnell der Server ist.

Den Weg verkürzt du auf zwei Arten:

• Nah an deiner Zielgruppe hosten. Kommen fast alle Besucher aus Deutschland, ist ein Server in Deutschland oder in der Nähe der einfachste Gewinn.
• Über ein Edge-Netzwerk ausliefern. Ein CDN nimmt die Verbindung an einem Standort nahe beim Besucher an und antwortet bei gecachten Seiten, ohne deinen Server überhaupt zu fragen. Was das bringt und wo die Grenzen liegen, erklärt der Ratgeber Was ist ein CDN.

Auch ungecachte Anfragen profitieren ein wenig, weil der TLS-Handshake in der Nähe stattfindet und der Edge eine bereits offene Verbindung zum Ursprungsserver weiternutzen kann. Der große Gewinn kommt aber von den Cache-Treffern.

Weiterleitungen und Verbindungs-Overhead abbauen

Kleinigkeiten summieren sich, vor allem im Mobilfunk:

• Weiterleitungsketten vermeiden. Von http://example.com über https://example.com und https://www.example.com bis https://www.example.com/de/ sind es drei zusätzliche Roundtrips, bevor irgendetwas Nützliches passiert. Verlinke direkt auf die finale URL und erlaube höchstens eine Weiterleitung.
• HTTP/2 oder HTTP/3 und TLS 1.3 nutzen. Diese Protokolle sparen Roundtrips beim Verbindungsaufbau und laden viele Ressourcen über eine einzige Verbindung.
• Einen schnellen DNS-Anbieter wählen. Für Erstbesucher ist die DNS-Abfrage Teil der TTFB. Anbieter mit Anycast oder GeoDNS antworten von Standorten in der Nähe.
• Komprimierung aktivieren. Brotli oder gzip für HTML ändern am ersten Byte wenig, verkürzen aber den restlichen Download danach.

So hilft dir fast.site

fast.site sitzt vor deinem bestehenden Hosting und setzt bei den Netzwerk- und Caching-Anteilen der TTFB an. Dein Hoster bleibt, du stellst lediglich die Nameserver deiner Domain auf fast.site um. Nach der Verifizierung läuft dein Traffic über das Edge-Netzwerk.

Der Fast Edge Cache™ speichert cachebare Seiten am Edge. Bei einem HIT kommt die Antwort direkt vom Edge, ohne deinen Server zu kontaktieren. Bei einem MISS wird die Seite einmal geholt und gespeichert. Wie lange sie gültig bleibt, bestimmen die Cache-Control-Header deines Servers oder deine eigenen Regeln, und ein Cache-Warmer hält wichtige Seiten vorgewärmt. Warenkorb, Checkout und eingeloggte Sitzungen umgehen den Cache, was der Header fs-cache als BYPASS anzeigt. Wie du das für jede URL prüfst, steht unter Cache prüfen, die Regeln erklärt die Caching-Dokumentation.

GeoDNS leitet Besucher zum nächsten funktionierenden Edge, mit Regionen in Nordamerika, Europa, Asien-Pazifik und Südamerika, je nach Tarif (siehe Regionen).

Eine langsame Datenbankabfrage macht fast.site nicht schneller, für ungecachte Seiten bleibt die Arbeit am Server also wichtig. Die Analytics im Dashboard zeigen TTFB und Cache-Trefferquote, sodass du die Wirkung auf deiner eigenen Website messen kannst, zum Beispiel in einer kostenlosen 7-Tage-Testphase.

Häufige Fragen

Beeinflusst die TTFB das Google-Ranking?

Die TTFB gehört nicht zu den Core Web Vitals, die Google als Signal für die Page Experience nutzt. Eine hohe TTFB verzögert aber den Largest Contentful Paint, und der gehört dazu. Eine bessere TTFB zahlt also vor allem auf einen besseren LCP und eine schneller wirkende Website ein, nicht auf einen direkten Rankingvorteil.

Warum ist die TTFB nur beim ersten Aufruf hoch?

Die erste Anfrage enthält oft eine DNS-Abfrage, einen frischen TLS-Handshake und trifft auf einen kalten Cache. Spätere Anfragen nutzen offene Verbindungen und einen warmen Cache. Zählt für dich der erste Eindruck, und bei Landingpages tut er das fast immer, schau dir DNS, Weiterleitungen und das Vorwärmen des Caches an.

Warum ist meine TTFB im eigenen Test gut, bei echten Nutzern aber schlecht?

Dein eigener Test läuft meist über eine schnelle Leitung nah am Server und mit warmem Cache. Felddaten, wie du sie auf corewebvitals.page oder in der Search Console siehst, stammen von echten Chrome-Nutzern aus allen möglichen Netzen und Regionen, ausgewertet am 75. Perzentil. Der Unterschied deutet oft auf Entfernung hin oder auf Seiten, die selten im Cache liegen.

Behebt ein CDN eine langsame TTFB?

Ein CDN behebt den Anteil, der durch Entfernung und das ständige Neuerzeugen von Seiten entsteht, vorausgesetzt, deine Seiten lassen sich cachen. Anfragen, die zwingend zum Server müssen, etwa im Checkout oder bei eingeloggten Nutzern, beschleunigt es nicht. Dafür brauchst du weiterhin Optimierungen an Server und Anwendung.