Time to First Byte (TTFB): Was sie ist und wie du sie senkst

Ist die TTFB ein Core Web Vital?

Nein. Die TTFB gehört nicht zu den drei Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Google führt die TTFB als Diagnosemetrik für einen langsamen LCP auf, und die Search Console hat keinen TTFB-Bericht. Laut dem State of Web Vitals bestehen auf Smartphones 70,8 % der Websites alle drei, aber nur 47,7 % mit einer guten TTFB: Für ein Bestehen ist eine gute TTFB also nicht nötig. Für das Ranking zählt die TTFB nur als erster Teil des LCP.

Googles 0,8 Sekunden für eine gute TTFB sind ein grober Richtwert. Eine serverseitig gerenderte Seite kann eine höhere TTFB und trotzdem einen schnelleren LCP haben als eine Seite, die JavaScript im Browser aufbaut, weil ihr HTML den Inhalt bereits enthält (web.dev).

Warum ist die TTFB wichtig?

Auf einer Seite kann nichts starten, bevor das erste Byte ihres HTML eintrifft: Bis dahin sieht der Besucher die vorherige Seite oder einen weißen Bildschirm. Mit einer langsamen TTFB ist ein guter LCP fast unmöglich.

Laut dem State of Web Vitals ist die TTFB auf Smartphones der größte der vier Teile des LCP – bei 67,6 % der Websites mit einem Bild als LCP-Element und allen vier Teilen in CrUX. Bei den 149 Websites, die mit CoreDash messen, entfielen in den 28 Tagen bis zum 7. November 2026 bei Smartphone-Seitenaufrufen mit einem Bild-LCP von 2,5 Sekunden oder mehr beim 75. Perzentil allein 1,8 Sekunden auf die TTFB – gegenüber 0,47 Sekunden bei einem Bild-LCP unter 2,5 Sekunden.

Folgt der First Contentful Paint (FCP), der erste Text oder das erste Bild auf dem Bildschirm, kurz nach einer späten TTFB, ist der Server der langsame Teil; eine große Lücke zwischen beiden weist auf die Stylesheets und Skripte im Head hin.

Was ist ein guter TTFB-Wert?

Eine gute TTFB liegt bei 0,8 Sekunden oder weniger beim 75. Perzentil der Seitenaufrufe. 0,8 bis 1,8 Sekunden gelten als verbesserungswürdig, mehr als 1,8 Sekunden als schlecht. PageSpeed Insights zeigt Mobil und Desktop getrennt an.

Unter 0,8 Sekunden ist niedriger immer noch besser: Jede Millisekunde, die der Server einspart, lässt mehr von den 2,5 Sekunden des LCP für die Seite selbst übrig. Laut dem State of Web Vitals haben 59,0 % der Websites eine gute TTFB auf Smartphones, gegenüber 81,8 % mit einem guten LCP. 32,0 % der WordPress-Websites haben eine gute TTFB, 95,7 % der Shopify-Shops. Shopify sendet 103 Early Hints, die Chrome als erstes Byte zählt – dieser Wert misst also teilweise den Hint, nicht das HTML.

Warum ist meine TTFB langsam?

Auf den meisten Websites baut der Server die Seite für jeden Besucher neu auf: Es gibt keinen Page-Cache, oder ein Cookie oder Query-String umgeht ihn. Danach kommen Entfernung ohne CDN sowie Redirects.

Aus welchen Teilen besteht die TTFB vom Request bis zur Response?

Die TTFB hat fünf aufeinanderfolgende Teile: Waiting (vor allem Redirects), Cache (der HTTP-Cache des Browsers und ein Service Worker), DNS, Connection (TCP und TLS) und Request (die Arbeit des Servers plus Hin- und Rückweg über das Netzwerk). In CoreDash heißt Waiting Waiting + Redirect und Cache Worker & Cache.

Ein realer Erstbesuch einer WordPress-Seite ohne Cache, gemessen in Chrome. Von den 875 ms TTFB entfielen 657 ms auf den Request und 174 ms auf den Redirect davor.

Ist die TTFB dasselbe wie die Server-Antwortzeit?

Nein. Die Server-Antwortzeit ist nur das Warten zwischen dem Absenden des Requests und dem Empfang des ersten Bytes: die Arbeit des Servers plus ein Weg über das Netzwerk. Die TTFB rechnet die Redirects, die Cache-Prüfung, DNS und den Verbindungsaufbau davor hinzu. Ein Server, der in 100 ms antwortet, kann einem Besucher auf einem anderen Kontinent trotzdem eine TTFB von fast einer Sekunde bescheren, weil jeder dieser Schritte auf einen Roundtrip wartet.

Chrome DevTools bezeichnet die Server-Antwortzeit als „Waiting for server response“ im Tab „Timing“ des Network-Panels (ältere Versionen: „Waiting (TTFB)“); Lighthouse nennt sie Server Response Time. Beide messen nur diesen letzten Teil, die Request Duration; die TTFB in deinen Field Data besteht aus allen fünf Teilen. Der Teil Waiting in web-vitals ist etwas anderes: die Zeit vor dem Request, überwiegend Redirects.

Wie misst du die TTFB?

PageSpeed Insights zeigt die TTFB deiner echten Besucher, die Field Data, auf dem Smartphone-Tab: das 75. Perzentil der letzten 28 Tage für die URL und die gesamte Origin, direkt neben dem FCP. Ein RUM-Tool wie CoreDash schlüsselt die TTFB nach Seite, Land und Teil auf.

CoreDash TTFB Breakdown: Die fünf Teile auf einer Zeile, jeweils mit Dauer und Bewertung.

Für einen einzelnen Aufruf öffnest du den Tab „Timing“ des HTML-Dokuments im Network-Panel der Chrome DevTools: Die TTFB dieses Requests endet mit „Waiting for server response“. Lighthouse weist den HTML-Request im Hinweis „Document request latency“ aus: „Your first network request is the most important. Reduce its latency by avoiding redirects, ensuring a fast server response, and enabling text compression.“ Der Grenzwert für die Server-Antwort liegt bei 600 ms.

Lighthouse und DevTools laden deine Seite ein einziges Mal, von einem einzigen Ort, meist die finale URL. Die TTFB in deinen Field Data ist das 75. Perzentil aus 28 Tagen realer Besuche – inklusive Redirects von Werbelinks, der Entfernung und Seiten, die noch nicht im Cache lagen. Der Wert aus den Field Data, meist der höhere, ist das, was deine Besucher erleben. Lab Data und Field Data erklärt, welcher Wert wofür da ist.

Im eigenen Code liefert die Navigation Timing API die TTFB als responseStart: das erste Byte in Millisekunden ab Beginn der Navigation. Die web-vitals-Library berechnet die TTFB und meldet die fünf Teile:

import { onTTFB } from 'web-vitals/attribution';

onTTFB(({ value, attribution }) => {
  console.log('TTFB', Math.round(value), 'ms');
  console.table({
    waiting: attribution.waitingDuration,
    cache: attribution.cacheDuration,
    dns: attribution.dnsDuration,
    connection: attribution.connectionDuration,
    request: attribution.requestDuration,
  });
});

Eine langsame TTFB prüfen und beheben führt Schritt für Schritt von einem schlechten Wert zur Ursache.

Server-Timing: Welcher Teil des Servers ist langsam?

Ein Server-Timing-Header erlaubt es dem Server, eigene Messwerte mit dem HTML mitzuschicken, etwa für die Datenbank, das Template und einen Cache-Hit oder -Miss:

Server-Timing: wp;dur=27.8;desc="WordPress and query", tpl;dur=27.1;desc="Template"

Die DevTools zeigen die Einträge im Tab „Timing“ des HTML-Requests, und ein RUM-Tool kann sie bei echten Besuchen erfassen. Bevor jemand zu einem anderen Hoster umzieht, will ich per RUM und Server-Timing genau sehen, welcher Teil der TTFB langsam ist.

Ein Aufruf auf einer lokalen WordPress-Testinstallation: WordPress brauchte samt Datenbankabfrage 27,8 ms und das Template 27,1 ms – von den 59 ms, die der Browser auf den Server wartete.

Machen 103 Early Hints die TTFB schneller?

103 Early Hints senken die gemessene TTFB, weil Chrome den 103-Status als erstes Byte zählt, obwohl das HTML selbst nicht früher eintrifft. Für den Besucher beginnt der Browser bereits mit dem Laden von Stylesheets, Fonts und dem LCP-Bild, während der Server die Seite noch aufbaut – FCP und LCP treten dadurch früher ein.

Aktiviere Early Hints bei Cloudflare unter Speed > Settings > Content Optimization. Cloudflare speichert die Preload- und Preconnect-Link-Header, die dein Server für eine Seite mitsendet, und schickt sie ab dem nächsten Request als 103 über HTTP/2 und HTTP/3 voraus. Shopify sendet 103 Early Hints bereits standardmäßig. Auf dem eigenen Server bietet Apache H2EarlyHints on, und nginx leitet ab Version 1.29 einen 103-Status deiner Anwendung über die Direktive early_hints weiter. Verweise auf Dateien auf deiner eigenen Domain und nutze Preconnect nur für kritische Ressourcen, die dort nicht liegen können:

HTTP/2 103
link: </css/style.css>; rel=preload; as=style
link: </img/hero.webp>; rel=preload; as=image

HTTP/2 200
content-type: text/html
...

Ein Hoster oder CDN, das einen 103-Status sendet, wirkt in TTFB-Vergleichen auf Basis von Chrome-Daten schnell, selbst wenn der Server langsam ist; Server-Timing zeigt die echte Serverzeit. 103 Early Hints beschreibt das Setup pro Server.

Können Speculation Rules die TTFB auf null senken?

Speculation Rules laden die nächste Seite vorab: Eine vorgerenderte Seite ist in dem Moment auf dem Bildschirm, in dem der Besucher klickt, und die web-vitals-Library weist ihre TTFB mit 0 aus; eine Seite mit Prefetch überspringt das Warten auf das HTML. Die Field Data von Chrome (CrUX) misst die TTFB nur bei vollständigen Seitenaufrufen – bei einer vorgerenderten Seite zeigt sich der Gewinn daher im LCP.

WordPress ab Version 6.8 fügt eigenständig eine Prefetch-Regel ein; WP Core Web Vitals kann eine offensivere Regel setzen, wenn der Page-Cache aktiv ist. Als Code rendert diese Regel einen Menü-Link vorab, sobald der Besucher eine Absicht zeigt: auf dem Desktop beim Hovern oder Drücken, auf Smartphones bei einem sichtbaren Link, sobald das Scrollen stoppt:

<script type="speculationrules">
{"prerender":
[{
  "source": "document",
  "where": {"selector_matches": "nav a"},
  "eagerness": "moderate"
}]}
</script>

Jeder spekulierte Link ist ein Request an deinen Server – ohne Page-Cache erhöht Prerendering also die Serverlast. Nur Chromium-Browser wie Chrome und Edge unterstützen Speculation Rules. Der Speculation-Rules-Generator erstellt die passenden Regeln für deine Website; Speculation Rules geht noch weiter.

Wie senkst du eine langsame TTFB?

Fang mit dem Teil der TTFB an, der am größten ist. Bei 82 von 86 CoreDash-Websites mit mindestens 1.000 Smartphone-Aufrufen in den 28 Tagen bis zum 9. November 2026 war der Request beim 75. Perzentil der größte Teil der TTFB. Er umfasst das Generieren der Seite durch den Server plus Hin- und Rückweg über das Netzwerk. Starte also mit einem Page-Cache, cache das HTML anschließend auf einem CDN und reduziere die Redirects.

Ein Page-Cache

Aktiviere den Page-Cache in deinem Cache-Plugin oder beim Hoster, damit der Server eine gespeicherte Kopie der Seite ausliefert, statt sie neu aufzubauen. Teste das ausgeloggt in einem privaten Fenster: Eingeloggte Nutzer, ein Warenkorb-Cookie und unbekannte Query-Strings (gclid, utm_source aus Anzeigen und Mails) umgehen den Cache. Eine Seite, die bei jeder Response ein Cookie für eine Session oder einen A/B-Test setzt, wird oft überhaupt nicht gecacht. Für Entwickler: Dieser Header erlaubt es einem CDN oder Proxy, das HTML zehn Minuten lang vorzuhalten und noch eine Minute lang weiter auszuliefern, während eine frische Kopie geholt wird – und lässt den Browser bei jedem Besuch neu nachfragen:

Cache-Control: public, max-age=0, s-maxage=600, stale-while-revalidate=60

Seiten, die du nicht cachen kannst

Seiten für eingeloggte Nutzer, der Warenkorb und Suchergebnisse werden für jeden Besucher individuell aufgebaut – hier muss der Server selbst schneller werden: ein Object-Cache wie Redis für wiederholte Datenbankabfragen, Indizes für langsame Queries. Eine Seite, die vor ihrer Antwort auf eine Datenbank oder eine API in einem anderen Rechenzentrum wartet, schlägt diesen Roundtrip auf jede TTFB auf. Server-Timing zeigt, was davon bremst.

Besucher weit weg vom Server

Ein CDN bringt den Verbindungsaufbau nah an den Besucher, und das Cachen des HTML an der CDN-Edge erspart auch den Weg zu deinem Server. Ein CDN, das nur Bilder cacht und jeden HTML-Request an deinen Server durchreicht, ändert am Request-Teil kaum etwas. Bei Cloudflare benötigt das HTML eine Cache Rule oder APO für WordPress: Cloudflare für die Core Web Vitals konfigurieren liefert die Einstellungen.

Redirects

Jeder Redirect ist ein vollständiger zusätzlicher Request, bevor der eigentliche Request überhaupt beginnt. Verlinke überall auf die finale URL (https, mit oder ohne www und Trailing Slash – je nachdem, wie deine Website aufgebaut ist) und behebe Redirect-Ketten. Ein Browser merkt sich einen 301, sodass ein wiederkehrender Besucher ihn überspringt; bei http zu https leitet der Strict-Transport-Security-Header (HSTS) den Browser direkt auf https weiter. Links aus Anzeigen und Mails laufen oft zuerst über Tracking-Redirects: Prüfe, ob sie auf deiner finalen URL enden. Waiting Duration liefert die Details.

DNS und Verbindungsaufbau

Nutze einen schnellen DNS-Provider sowie einen Hoster oder ein CDN mit TLS 1.3 und HTTP/3, die weniger Roundtrips für den Verbindungsaufbau benötigen. DNS Duration und Connection Duration gehen tiefer darauf ein.

Hosting

Ein neuer Hoster hilft, wenn gecachte Seiten schnell sind, ungecachte Seiten langsam und Server-Timing direkt auf den Server weist. Achte dann auf mehr CPU und RAM: Viele Hosting-Upgrades erhöhen lediglich den Speicherplatz.

JavaScript-Frameworks

Eine Seite, die Next.js, Nuxt oder SvelteKit für jeden Request auf dem Server rendert, hat die TTFB einer ungecachten Seite. Rendere Seiten statisch oder cache das gerenderte HTML, wo immer der Inhalt es zulässt. Nutze Streaming für das HTML, damit der Head mit den Stylesheets rausgeht, bevor die langsamen Daten fertig sind.

WordPress

• Page-Cache: WP Rocket, LiteSpeed Cache oder dein Hoster. Mein Plugin, WP Core Web Vitals, liefert die gecachte Seite aus, bevor WordPress und die anderen Plugins laden.
• WooCommerce und Seiten für eingeloggte Nutzer: ein Object-Cache (Redis), oft nur ein Schalter beim Hoster.
• Ein langsames Plugin: Query Monitor listet die langsamen Datenbankabfragen und das Plugin auf, aus dem sie stammen.

Shopify

Server, Cache, CDN und die 103 Early Hints liegen bei Shopify. Die Redirects sowie der Liquid-Code deines Themes und deiner Apps liegen bei dir: Der Shopify Theme Inspector for Chrome zeigt, welcher Teil des Themes beim Rendern auf dem Server lange braucht.

Ist der Fix bei deinen Besuchern angekommen?

Prüfe zuerst den Cache: Öffne die Seite ausgeloggt, danach mit ?gclid= und einem noch nie verwendeten Wert (jeder Anzeigenklick erzeugt einen neuen), und prüfe die Response-Header auf einen Cache-Hit (cf-cache-status: HIT bei Cloudflare, ein x-cache-Header bei vielen Hostern). Leere nach einem Release auch das HTML auf dem CDN – sonst liefert es möglicherweise weiterhin die Seite der Vorwoche aus.

Ein RUM-Tool zeigt die Veränderung schon am nächsten Tag. Die Field Data von PageSpeed Insights bildet die letzten 28 Tage ab – sie bewegt sich nur langsam. Und die Search Console zeigt die TTFB nur über den LCP an.

Manche TTFB-Probleme liegen außerhalb deiner Einstellungen: ein Hoster oder ein Backend, auf das du keinen Zugriff hast, oder ein Cache, den jeder Besucher aus Gründen überspringt, an die sich niemand mehr erinnert. In einer Core-Web-Vitals-Power-Hour schauen wir uns deine TTFB nach Seite und Land sowie die Cache-Header deiner langsamsten Seiten an – und entscheiden, welchen Teil wir zuerst fixen und wer das übernimmt.