Time to First Byte (TTFB) im SEO

TL;DR – Time to First Byte ist die Zeit, die der Browser wartet, nachdem er eine Seite angefordert hat, bis das allererste Byte der Antwort zurückkommt. Es ist ein Maß für die Server-Reaktionsfähigkeit. Ein guter TTFB liegt bei 0,8 Sekunden oder weniger. Es ist kein Core Web Vital – aber ein langsamer Wert zieht die Metriken nach unten, die es sind, denn nichts auf der Seite kann beginnen, bis dieses erste Byte eintrifft.

Was TTFB ist

Wenn Sie auf einen Link klicken, sendet Ihr Browser eine Anfrage an einen Server und wartet dann. Time to First Byte (TTFB) ist die Länge dieser Wartezeit – vom Moment des Anfragestarts bis zum Moment, in dem das erste Byte der Antwort zu empfangen beginnt.

Es ist nicht nur „wie schnell der Server denkt.“ Vieles passiert, bevor Ihr Browser überhaupt mit der richtigen Maschine spricht: Er kann einer Weiterleitung folgen, den Domainnamen in DNS nachschlagen, eine Verbindung öffnen und den sicheren (TLS-)Handshake aushandeln. TTFB fasst all das zusammen, addiert dann die eigene Verarbeitungszeit des Servers und stoppt die Uhr beim ersten Byte zurück.

Was als gut gilt

Die web.dev-Anleitung von Google ist einfach: Zielen Sie auf einen TTFB von 0,8 Sekunden oder weniger ab. Über 1,8 Sekunden gilt als schlecht. Die meisten Websites sollten den guten Wert erreichen können – und viele tun es nicht, was genau der Grund ist, warum es sich lohnt, dies zu überprüfen.

Warum es wichtig ist, obwohl es keine „Kern“-Metrik ist

Sie werden viel über Core Web Vitals hören – LCP, INP und CLS. TTFB ist keines davon. Aber es sitzt unter denjenigen, die das Laden betreffen: Sowohl First Contentful Paint als auch Largest Contentful Paint beinhalten TTFB in ihrer Messung. Der Browser kann nichts darstellen, bis die Bytes zu empfangen beginnen. Ein langsamer TTFB setzt also eine Obergrenze dafür, wie schnell sich Ihre Seite anfühlen kann.

Die praktische Erkenntnis: TTFB verschafft Ihnen allein kein Ranking, aber ein schlechter Wert hält die Metriken, die das tun, leise zurück.

Die üblichen Lösungen, einfach ausgedrückt

• Nutzen Sie ein CDN. Es platziert eine Kopie Ihrer Website auf Servern, die physisch näher an Ihren Besuchern liegen, sodass die Roundtrip-Zeit kürzer ist.
• Cachen Sie Ihre Seiten. Wenn der Server eine fertige Kopie zurückgeben kann, anstatt die Seite jedes Mal neu aufzubauen, kommt das erste Byte viel früher.
• Besorgen Sie sich besseres Hosting. Ein schnellerer Server und eine schnellere Datenbank sind die direkteste Lösung.
• Reduzieren Sie Weiterleitungen. Jede Weiterleitung ist ein zusätzlicher Roundtrip, bevor die eigentliche Seite überhaupt zu laden beginnt.

Möchten Sie die vollständige Version – die genauen Schwellenwerte, die LCP-Beziehung, die Lighthouse-vs-CrUX-Schwellenwertverwirrung, Early Hints und wie man es misst? Wechseln Sie zum Erweitert-Tab.

TL;DR – TTFB ist die Zeit vom Start der Anfrage bis zum Eintreffen des ersten Bytes der Antwort – die Summe aus Weiterleitungszeit, Service-Worker-Startzeit, DNS-Auflösung, Verbindungs- und TLS-Aushandlung sowie der Anfrage selbst, bis zu diesem ersten Byte. Es ist kein Core Web Vital; es ist eine grundlegende, diagnostische Metrik, die FCP und LCP speist. web.dev: gut ist ≤0,8 s, schlecht ist >1,8 s (75. Perzentil). Es ist sowohl eine Feld- als auch eine Labormetrik. Der Audit „Reduce server response times“ von Lighthouse ist enger – er markiert Serverzeit über ~600 ms, nicht den vollständigen TTFB, und ab Lighthouse 13 lebt er innerhalb der Erkenntnis „Document request latency“. Beheben Sie es mit einem CDN, Edge-/HTML-Caching, schnellerem Hosting, weniger Weiterleitungen, 103 Early Hints und effizientem TLS. Und ein hoher TTFB bedeutet nicht immer eine langsame Website.

Was TTFB tatsächlich misst

TTFB misst die Zeit zwischen dem Beginn der Navigation zu einer Seite und dem Eintreffen des ersten Bytes der Antwort. Die Sache, die Leute falsch verstehen, ist, es als reine Backend-Verarbeitungszeit zu behandeln. Das ist es nicht. Es ist die Summe von allem, was abgeschlossen sein muss, bevor dieses erste Byte zurückkommen kann:

1. Weiterleitungszeit
2. Service-Worker-Startzeit (falls einer zutrifft)
3. DNS-Auflösung
4. Verbindungs- und TLS-Aushandlung
5. Die Anfrage – bis zu dem Punkt, an dem das erste Byte der Antwort eingetroffen ist

Die Serververarbeitung ist darin enthalten, aber auch die gesamte Verbindungsaufbau-Last. Diese Unterscheidung wird wichtig, sobald Sie anfangen, Tools zu lesen, denn sie messen nicht alle denselben Ausschnitt (dazu weiter unten mehr).

Es ist keine Core Web Vital

Ich sage es deutlich, weil es das häufigste Missverständnis ist: TTFB ist keine Core Web Vital. Die drei Core Web Vitals sind LCP (Laden), INP (Interaktivität) und CLS (visuelle Stabilität). TTFB ist eine grundlegende, diagnostische Metrik – Googles eigene Darstellung ist, dass es “a foundational metric for measuring connection setup time and web server responsiveness in both the lab and the field” ist.

Google stellt auch klar, dass Sie den guten TTFB-Schwellenwert nicht strikt erreichen müssen: Da es keine Core Web Vital ist, ist es “not absolutely necessary that sites meet the ‘good’ TTFB threshold, provided that it doesn’t impede their ability to score well on the metrics that matter.” Dieser letzte Satz ist der Haken – für die meisten Websites behindert ein schlechter TTFB definitiv die Metriken, die zählen.

Wie es FCP und LCP begrenzt

TTFB geht jeder nutzerzentrierten Lade-Metrik voraus. Sowohl First Contentful Paint als auch Largest Contentful Paint enthalten TTFB in ihrer Messung – die Uhr für diese Metriken läuft bereits, während Sie auf das erste Byte warten. web.dev zerlegt LCP in Unterteile, und TTFB ist der erste davon, weshalb Sie kein schnelles LCP auf einem langsamen TTFB haben können.

Hier werden auch die realen Daten deutlich. Der Web Almanac des HTTP Archive fand heraus, dass auf Websites mit schlechtem LCP allein TTFB etwa 2,27 Sekunden verbrauchte – fast das gesamte 2,5-Sekunden-Budget für “gutes LCP” – bevor überhaupt ein Bild oder Text zu rendern begann. Wenn Ihr LCP schlecht ist und Ihre On-Page-Inhalte optimiert aussehen, ist TTFB der erste Ort, an dem ich suchen würde.

Die Ranking-Geschichte ist also indirekt, aber real: TTFB ist kein Google-Ranking-Signal (die Ranking-Signale sind LCP, INP und CLS – TTFB ist in dieser Gruppe nicht genannt). Aber es ist in LCP eingebacken, das ist ein Ranking-Signal. Der Weg führt über LCP, nicht direkt über TTFB.

Schwellenwerte: gut, verbesserungswürdig, schlecht

Die Anleitung von web.dev, gemessen am 75. Perzentil der realen Nutzerlasten:

• Gut: ≤ 0,8 s
• Schlecht: > 1,8 s

“Most sites should strive to have a TTFB of 0.8 seconds or less.” Es lohnt sich, die Geschichte zu kennen: Google hat die “gute” Linie 2022 von 500 ms auf 800 ms verschoben, und ältere Daten wurden unter dem neuen Standard neu berechnet – vergleichen Sie also keine rohen historischen TTFB-Zahlen, ohne zu prüfen, welchen Schwellenwert sie verwendet haben.

Die Verwirrung um 600 ms vs. 800 ms

Das stolpert viele Leute, daher lohnt es sich, präzise zu sein. Es gibt zwei verschiedene Zahlen, die kursieren:

• CrUX / web.dev TTFB-Schwellenwert: 800 ms. Dies ist der Feld-Schwellenwert für volles TTFB (DNS + Verbindung + TLS + Weiterleitungen + Serverzeit).
• Lighthouse “Reduce server response times”-Audit: ~600 ms. Dies ist ein Labor-Audit, das meldet, wenn der Browser mehr als etwa 600 ms auf die Antwort des Servers auf die Hauptdokumentanfrage wartet. Entscheidend ist, dass es nur die Serverantwortzeit misst – es enthält kein DNS, keinen Verbindungsaufbau und kein TLS.

Die Lighthouse-Zahl wirkt also strenger, aber sie misst einen schmaleren Ausschnitt. Wie die Dokumentation sagt, “server response time is only part of the full Time to First Byte (TTFB).” Behandeln Sie ein bestandenes Lighthouse-Audit nicht als Beweis für ein gutes Feld-TTFB, und geraten Sie nicht in Panik, dass 600 < 800 bedeutet, dass die Schwellenwerte sich widersprechen – sie messen verschiedene Dinge.

Eine Versionsnotiz: Ab Lighthouse 13 steht dieses Audit nicht mehr allein – es wurde in die breitere “Document request latency”-Erkenntnis integriert. Die zugrunde liegende ~600-ms-Serverantwortprüfung ist dieselbe; sie wird nur je nach Lighthouse-Version, die Ihren Bericht erstellt hat, anders dargestellt.

Feld und Labor – beides

TTFB ist eine der Metriken, die Sie in beiden Welten ablesen können. Im Feld stammt sie aus CrUX (echte Chrome-Nutzer) und wird in PageSpeed Insights und der Search Console angezeigt. Im Labor bezeichnet Chrome DevTools sie im Netzwerk-Panel-Wasserfall als „Waiting (TTFB)“ („der Browser wartet auf das erste Byte einer Antwort“), und auch Tools wie WebPageTest und Lighthouse berichten sie. Eine Einschränkung im Feld: In CrUX wird TTFB immer noch als etwas experimentell behandelt – es schließt einige erweiterte Navigationstypen wie prerenderte und Back/Forward-Cache-Navigationen aus, sodass Felddurchschnitte im Vergleich zu dem, was Nutzer tatsächlich wahrnehmen, etwas pessimistisch ausfallen können.

Ein hoher TTFB bedeutet nicht immer eine langsame Website

Hier ist die Nuance, die die Schwellenwerte verbergen. Eine serverseitig gerenderte Seite kann einen höheren TTFB aufweisen als eine clientseitig gerenderte und dennoch bessere FCP- und LCP-Werte liefern – denn wenn das erste Byte endlich ankommt, ist es vollständiges HTML, das der Browser sofort darstellen kann, statt einer dünnen Hülle, die erst ein JavaScript-Bündel abrufen und ausführen muss, bevor etwas erscheint. Google sagt es direkt: „a server-rendered site that does not require as much client-side work could have a higher TTFB, but better FCP and LCP values than an entirely client-rendered experience.“ (Übersetzung) „Eine serverseitig gerenderte Website, die weniger clientseitige Arbeit erfordert, könnte einen höheren TTFB, aber bessere FCP- und LCP-Werte aufweisen als eine vollständig clientseitig gerenderte Erfahrung.“

Die Kehrseite: Bei einer clientseitig gerenderten Single-Page-App bestimmt TTFB, wann das JavaScript-Bündel überhaupt beginnt zu laden, daher ist ein niedriger TTFB dort wichtiger, nicht weniger. Optimieren Sie TTFB nicht isoliert – optimieren Sie die gesamte Ladekette und beurteilen Sie TTFB danach, was es für FCP und LCP bewirkt.

So verbessern Sie TTFB

Ungefähr in Prioritätsreihenfolge:

• Beginnen Sie mit dem Hosting. Ein langsames Backend oder eine langsame Datenbankabfrage ist eine Steuer auf jede einzelne Anfrage, und keine noch so große Frontend-Arbeit kann sie beseitigen. Das ist das Erste, was Sie berücksichtigen sollten.
• Nutzen Sie ein CDN. Ein CDN löst das Näheproblem – ein verteiltes Netzwerk aus Edge-Servern cached Ressourcen physisch näher an Ihren Nutzern und reduziert die Lichtgeschwindigkeitskosten der Verbindung und den TLS-Handshake. Es ist die Maßnahme mit dem höchsten ROI für die meisten Websites, denn die geografische Entfernung zu Ihrem Ursprungsserver ist eine strukturelle Steuer, die nichts im Backend beseitigen kann. Die Einschränkung: Bei vollständig dynamischen, personalisierten Inhalten, die nicht gecacht werden können, fügt ein CDN einen Hop ohne Cache-Hit-Vorteil hinzu – dort sind Backend-Optimierung, Edge-Computing oder Streaming die Antwort.
• Cachen Sie Ihr HTML, auch nur kurz. Selbst eine kurze Cache-Zeit hilft einer stark frequentierten Website spürbar: Nur der erste Besucher in diesem Zeitfenster zahlt die volle Latenz bis zum Ursprungsserver; alle anderen erhalten die gecachte Kopie.
• Beseitigen Sie Weiterleitungen. Weiterleitungen sind ein häufiger Beitrag zu hohem TTFB – jede ist ein Roundtrip, bevor die eigentliche Antwort beginnt. Reduzieren Sie diejenigen, die Sie kontrollieren können.
• Streamen Sie Markup an den Browser. Browser verarbeiten Markup effizient, wenn es in Teilen gestreamt wird, während es eintrifft. Viele SSR-Frameworks unterstützen Streaming, aber es ist standardmäßig deaktiviert; das Aktivieren kann TTFB bei dynamischen Seiten ohne Infrastrukturänderung senken.
• Nutzen Sie 103 Early Hints. Der Statuscode 103 ist eine vorläufige Antwort, die der Server senden kann, während das Backend noch das Markup vorbereitet, und den Browser darauf hinweist, frühzeitig mit dem Herunterladen renderkritischer Ressourcen zu beginnen. Es senkt TTFB selbst nicht – tatsächlich kann eine 103 als „erstes Byte“ zählen –, aber es verringert die Auswirkungen eines hohen TTFB. Shopify und Cloudflare haben dadurch Verbesserungen der LCP um mehrere hundert Millisekunden gemeldet, in einigen Fällen nahezu eine Sekunde.
• Verhandeln Sie TLS effizient und optimieren Sie den Service-Worker-Start. Ein Service Worker, der noch nicht gestartet ist, addiert seine Startzeit zu TTFB; sobald er läuft, kann sein Cache (Stale-While-Revalidate oder ein App-Shell-Modell für SPAs) TTFB dramatisch reduzieren.

Wo Websites tatsächlich stehen

Der Grund, warum das Ihre Aufmerksamkeit verdient: Es ist ein hartnäckiges Problem im gesamten Web. Die mobile Good-TTFB-Rate des Web Almanac hat sich in fünf Jahren kaum bewegt – sie pendelt bei etwa 41–42 % –, was bedeutet, dass die Mehrheit der mobilen Websites immer noch kein „gutes“ TTFB hat. Diese Stagnation ist ehrlich gesagt eine Chance. Für eine serverlastige Website mit schlechtem LCP ist TTFB in der Regel der Hebel mit der höchsten Wirkung.

Diese Seite ist Teil des Clusters web-performance, der unter Core Web Vitals angesiedelt ist. Für die Metriken, in die TTFB einfließt, siehe Largest Contentful Paint und First Contentful Paint; um es bei echten Nutzern und im Labor zu messen, siehe CrUX, PageSpeed Insights und Lighthouse.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• TTFB = die Wartezeit auf das erste Byte. Zeit vom Beginn der Anfrage bis zum Eintreffen des ersten Bytes der Antwort – die Summe aus Weiterleitungszeit, Service-Worker-Start, DNS-Auflösung, Verbindungs- und TLS-Aushandlung sowie der Anfrage selbst. Nicht nur die Serververarbeitung.
• Es ist KEINE Core Web Vital. Die Core Web Vitals sind LCP, INP und CLS. TTFB ist eine grundlegende, diagnostische Metrik.
• Es begrenzt FCP und LCP. Beide enthalten TTFB, sodass ein langsames TTFB eine Obergrenze dafür setzt, wie schnell eine Seite geladen werden kann. Bei Websites mit schlechtem LCP betrug TTFB allein etwa 2,27 s – fast das gesamte 2,5-s-Budget für gutes LCP.
• Rankings: indirekt. TTFB ist kein Google-Ranking-Signal, aber es steckt in LCP, und das ist es. Der Weg führt über LCP.
• Schwellenwerte (75. Perzentil): gut ≤ 0,8 s, schlecht > 1,8 s. Die „gut“-Linie verschob sich 2022 von 500 ms auf 800 ms.
• 600 ms vs. 800 ms: Der Lighthouse-Audit „Reduce server response times“ markiert etwa 600 ms nur Serverzeit – enger als der 800-ms-Schwellenwert für das vollständige TTFB im Feld. „Server response time is only part of the full TTFB.“ Seit Lighthouse 13 lebt dieser Audit innerhalb der Einblicke zur „Document request latency“.
• Feld und Labor: CrUX/PSI/Search Console (Feld); DevTools „Waiting (TTFB)“, WebPageTest, Lighthouse (Labor).
• Hohes TTFB ≠ langsame Website: Eine SSR-Seite kann ein höheres TTFB, aber besseres FCP/LCP haben als eine clientgerenderte Seite, weil das erste Byte vollständiges HTML ist.
• Fixes (Priorität): zuerst Hosting, dann CDN, HTML-Caching, weniger Weiterleitungen, Streaming, 103 Early Hints, effizientes TLS, Service-Worker-Start.
• Zustand des Webs: mobiles gutes TTFB ist seit fünf Jahren bei etwa 41–42 % flach – eine echte Chance.

Offizielle Dokumentation

Primärquellen-Dokumentation von Googles Chrome- und web.dev-Teams.

• Time to First Byte (TTFB) – die Definition, die fünf Komponenten, die Schwellenwerte von 0,8 s / 1,8 s, warum es keine Core Web Vital ist, und seine Beziehung zu FCP und LCP.
• Optimize TTFB – der Optimierungsleitfaden: zuerst Hosting, dann CDN, Caching, Weiterleitungen, Streaming, 103 Early Hints und Service Worker.
• Reduce server response times – der Lighthouse-Audit (~600-ms-Serverzeit-Schwelle) und wie er sich vom vollständigen TTFB unterscheidet. Seit Lighthouse 13 ist er in die Einblicke zur „Document request latency“ integriert.
• Web Vitals – wo TTFB in der Metrik-Taxonomie steht: eine ergänzende/diagnostische Metrik, mit LCP, INP und CLS als Core Web Vitals.
• Largest Contentful Paint (LCP) – bestätigt, dass LCP TTFB-Verzögerungen einschließt.
• First Contentful Paint (FCP) – bestätigt, dass FCP TTFB einschließt, und listet „Reduce server response times (TTFB)“ als Fix auf.
• Core Web Vitals (Google Search Central) – die Dokumentation zum Ranking-Signal nennt nur LCP, INP und CLS; TTFB ist nicht aufgeführt.
• 103 Early Hints – der frühe Antwortcode, Browser-/Serverunterstützung und Ergebnisse aus der Praxis.

Zitate aus der Quelle

Aufzeichnungen von Googles web.dev- und Chrome-Teams. Jeder Link ist ein Deep-Link, der zur zitierten Passage auf der Quellseite springt, sofern eine verifiziert wurde.

web.dev – was TTFB ist

• “TTFB is a metric that measures the time between starting navigating to a page and when the first byte of a response begins to arrive.” (Übersetzung) „TTFB ist eine Metrik, die die Zeit zwischen dem Beginn der Navigation zu einer Seite und dem Eintreffen des ersten Bytes einer Antwort misst.“ Zum Zitat springen
• “Time to First Byte (TTFB) is a foundational metric for measuring connection setup time and web server responsiveness in both the lab and the field.” (Übersetzung) „Time to First Byte (TTFB) ist eine grundlegende Metrik zur Messung der Verbindungsaufbauzeit und der Webserver-Reaktionsfähigkeit sowohl im Labor als auch im Feld.“ Zum Zitat springen

web.dev — Schwellenwerte

• “Good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds.” (Übersetzung) „Gute TTFB-Werte liegen bei 0,8 Sekunden oder weniger, und schlechte Werte liegen über 1,8 Sekunden.“ Zum Zitat springen

web.dev – kein Core Web Vital

• “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold, provided that it doesn’t impede their ability to score well on the metrics that matter.” (Übersetzung) „Da TTFB keine Core-Web-Vitals-Metrik ist, ist es nicht unbedingt erforderlich, dass Websites den Schwellenwert für ‚gut‘ bei TTFB erreichen, sofern dies ihre Fähigkeit nicht beeinträchtigt, bei den relevanten Metriken gut abzuschneiden.“ Zum Zitat springen

web.dev – Beziehung zu FCP und LCP

• “Because TTFB precedes user-centric metrics such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP)…” (Übersetzung) „Da TTFB nutzerzentrierten Metriken wie First Contentful Paint (FCP) und Largest Contentful Paint (LCP) vorausgeht …“ Zum Zitat springen
• Bei einer servergerenderten Website: “a server-rendered site that does not require as much client-side work could have a higher TTFB, but better FCP and LCP values than an entirely client-rendered experience.” (Übersetzung) „Eine servergerenderte Website, die nicht so viel clientseitige Arbeit erfordert, könnte einen höheren TTFB, aber bessere FCP- und LCP-Werte aufweisen als eine vollständig clientgerenderte Erfahrung.“ (web.dev, „Time to First Byte“)

Lighthouse – Serverantwortzeit vs. vollständiger TTFB

• “Server response time is only part of the full Time to First Byte (TTFB).” (Übersetzung) „Die Serverantwortzeit ist nur ein Teil des vollständigen Time to First Byte (TTFB).“ (Lighthouse, „Serverantwortzeiten reduzieren.“)

Patrick Stox – zum Status von TTFB (aus meinem Ahrefs Core Web Vitals-Leitfaden)

• “There are additional Web Vitals that serve as proxy measures or supplemental metrics but are not used in the ranking calculations. The Web Vitals metrics for visual load include Time to First Byte (TTFB) and First Contentful Paint (FCP).” (Übersetzung) „Es gibt zusätzliche Web Vitals, die als Proxy-Maße oder ergänzende Metriken dienen, aber nicht in den Ranking-Berechnungen verwendet werden. Zu den Web-Vitals-Metriken für die visuelle Last gehören Time to First Byte (TTFB) und First Contentful Paint (FCP).“ Leitfaden lesen

TTFB-Triage-Checkliste

Wenn PageSpeed Insights, Search Console oder Lighthouse eine langsame Serverantwort meldet, arbeiten Sie diese Liste ab:

• Bestätigen Sie, was Sie betrachten — vollständiger Feld-TTFB (≤0,8 s gut) oder der Lighthouse-Audit „Serverantwortzeit reduzieren“ (~600 ms, nur Serverzeit). Es sind nicht dieselben Zahlen.
• Prüfen Sie das Feld, nicht nur das Labor — ziehen Sie TTFB aus CrUX über PageSpeed Insights oder den Core Web Vitals-Bericht der Search Console, beim 75. Perzentil.
• Prüfen Sie, ob TTFB das ist, was Ihr LCP begrenzt — wenn LCP schlecht ist und der Seiteninhalt optimiert ist, ist TTFB der erste Verdächtige.
• Zählen Sie Ihre Weiterleitungen — eliminieren Sie alle Weiterleitungsketten, die Sie kontrollieren, auf wichtigen Einstiegs-URLs.
• Bestätigen Sie, dass ein CDN Ihre Nutzer bedient (Edge-PoPs nahe Ihrer Zielgruppe) und dass HTML-/Edge-Caching tatsächlich greift, nicht nur statische Assets.
• Profilieren Sie das Backend — langsame Datenbankabfragen oder schwere serverseitige Arbeit bei der Hauptdokumentanfrage.
• Stellen Sie sicher, dass TLS effizient ist (modernes Protokoll, Session Resumption) und DNS schnell ist.
• Wenn die Seite dynamisches SSR ist, prüfen Sie, ob Streaming in Ihrem Framework aktiviert ist — es ist oft standardmäßig deaktiviert.
• Erwägen Sie 103 Early Hints für renderkritische Ressourcen, wenn Ihr Server/CDN dies unterstützt.
• Wenn Sie einen Service Worker verwenden, prüfen Sie, ob dessen Start nicht zu TTFB beim ersten Laden beiträgt und ob seine Cache-Strategie wiederholten Laden hilft.

TTFB-Spickzettel

Woraus sich TTFB zusammensetzt

1. Weiterleitungszeit
2. Service-Worker-Start (falls vorhanden)
3. DNS-Auflösung
4. Verbindungsaufbau + TLS-Aushandlung
5. Die Anfrage — bis zum ersten Byte der Antwort

Schwellenwerte (75. Perzentil der realen Nutzerlasten)

Zwei Schwellenwerte, zwei Geltungsbereiche

Schnelle Fakten

• TTFB ist kein Core Web Vital. Die Core Web Vitals sind LCP, INP, CLS.
• Es ist sowohl eine Feld- als auch eine Labor-Metrik.
• Sowohl FCP als auch LCP enthalten TTFB — es setzt eine Obergrenze für sie.
• Der Einfluss auf das Ranking ist indirekt, über LCP — TTFB selbst ist kein Ranking-Signal.
• DevTools bezeichnet es im Netzwerk-Panel als „Warten (TTFB)“.
• Die „gut“-Linie verschob sich 2022 von 500 ms auf 800 ms.

Fix-Priorität: Hosting → CDN → HTML-/Edge-Caching → Weiterleitungen reduzieren → Markup streamen → 103 Early Hints → effizientes TLS → Service-Worker-Start.

Tools zur Messung von TTFB

• PageSpeed Insights — die einfachste Feldmessung: zeigt Ihren CrUX-TTFB (echte Chrome- Nutzer) neben einem Labortest, für eine URL oder einen Ursprung.
• Search Console — Core Web Vitals-Bericht — Felddaten gruppiert nach URL-Muster; der Ort, um TTFB-Probleme im großen Maßstab zu erkennen.
• CrUX (Chrome User Experience Report) — der zugrunde liegende Felddatensatz; abfragbar direkt über die CrUX-API oder BigQuery für historische Trends.
• Chrome DevTools — Netzwerk-Panel — fahren Sie mit der Maus über die Hauptdokumentanfrage und lesen Sie die „Warten (TTFB)“-Zeit für eine präzise Laboraufschlüsselung von Verbindungs- vs. Serverzeit.
• Lighthouse — führt den Audit „Serverantwortzeit reduzieren“ aus (~600 ms Serverzeit-Flagge); integriert in DevTools und PageSpeed Insights. Ab Lighthouse 13 erscheint diese Prüfung im Insight „Dokumentanfrage-Latenz“.
• WebPageTest — detaillierte Wasserfalldiagramme mit TTFB, aufgeschlüsselt nach Verbindungsphase, und Multi-Standort-/Verbindungstests zur Isolierung geografischer Latenz.
• web-vitals-JS-Bibliothek — sammeln Sie TTFB (und den Rest) von Ihren eigenen echten Nutzern im Feld und senden Sie es an Ihre Analysen.

TTFB-Fehler, die zur falschen Lösung führen

Jede Verzögerung als Serverproblem bezeichnen

TTFB umfasst Weiterleitungen, DNS, Verbindungsaufbau, TLS, Service-Worker-Start und Serververarbeitung. Zerlegen Sie die Anfrage in Phasen, bevor Sie Anwendungscode oder Hosting ändern.

Vergleich des 600-ms-Audits von Lighthouse mit dem 800-ms-Feldschwellenwert

Der Lighthouse-Audit ist eine engere Labordiagnose, während die 0,8-Sekunden-Richtlinie das vollständige TTFB beschreibt. Kennzeichnen Sie Quelle und Umfang, wenn Sie eine der beiden Zahlen melden.

Nur von einem Standort in der Nähe des Ursprungs testen

Ein nahegelegenes Labor kann geografische Latenz verbergen. Vergleichen Sie Regionen oder verwenden Sie Daten realer Nutzer, bevor Sie annehmen, dass dieselbe Erfahrung für das gesamte Publikum gilt.

TTFB jagen, während die Seite bereits schnell ist

Ein hohes TTFB kann mit einer schnellen gestreamten oder gecachten Erfahrung vereinbar sein. Prüfen Sie, ob es tatsächlich FCP oder LCP einschränkt, bevor Sie es gegenüber einem größeren Engpass priorisieren.

Langsames TTFB nach Symptom diagnostizieren

Die erste Anfrage ist langsam, aber Wiederholungsanfragen sind schnell

Wahrscheinliche Ursache: kalte Caches, Verbindungsaufbau oder Anwendungswarm-up. Behebung: Überprüfen Sie Cache-Header und trennen Sie kalte von warmen Tests. Bestätigung: Das Wasserfalldiagramm zeigt, welche Verbindungs- oder Serverphase bei der Wiederholungsanfrage verschwindet.

TTFB ist nur in entfernten Regionen langsam

Wahrscheinliche Ursache: physische Entfernung zum Ursprung oder ein CDN-Cache-Fehlschlag. Behebung: Liefern Sie cachebares HTML näher an den Nutzern und überprüfen Sie das Edge-Cache-Verhalten. Bestätigung: Regionale Tests zeigen eine kürzere Wartezeit, ohne den Antworttext zu ändern.

Eine URL hat ein viel schlechteres TTFB als ihre Vorlagen-Pendants

Wahrscheinliche Ursache: Weiterleitungen, eine ungecachte Route oder teure seiten spezifische Backend-Arbeit. Behebung: Vergleichen Sie die Weiterleitungskette, den Cache-Status und die Serverzeiten mit einem gesunden Pendant. Bestätigung: Die Dokumentanfrage des Ausreißers bewegt sich zurück zur Vorlagen-Baseline.

DevTools und CrUX widersprechen sich

Wahrscheinliche Ursache: Eine Laboranfrage kann die Geräte, Standorte, Cache-Zustände und das 75. Perzentil des Feldes nicht repräsentieren. Behebung: Verwenden Sie die Laboranfrage zur Diagnose und Felddaten zur Bewertung der Prävalenz. Bestätigung: Ihre RUM-Verteilung erklärt, welches Segment den langsameren Aggregatwert erzeugt.

TTFB von der Befehlszeile aus messen

Verwenden Sie die Timing-Variablen von curl, um das erste Byte von DNS-, Verbindungs- und TLS-Setup zu trennen.

curl -sS -o /dev/null \
  -w 'dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s starttransfer=%{time_starttransfer}s total=%{time_total}s\n' \
  https://example.com/

time_starttransfer ist die TTFB-artige Messung des Befehls. Führen Sie mehrere kalte und warme Anfragen aus mehr als einer relevanten Region aus; eine einzelne lokale Stichprobe ist kein Feld-Benchmark.

Navigation Timing im Browser lesen

const nav = performance.getEntriesByType('navigation')[0];
console.table({
  ttfb: Math.round(nav.responseStart - nav.requestStart),
  dns: Math.round(nav.domainLookupEnd - nav.domainLookupStart),
  connect: Math.round(nav.connectEnd - nav.connectStart),
});

Beweisen, dass eine TTFB-Änderung wirksam wurde

Edge-Cache-Test

Durchzuführender Test: Fordern Sie dasselbe Dokument zweimal mit curl -sS -D - -o /dev/null an und überprüfen Sie dann die Cache-Status- und Age-Header des CDN. Erwartetes Ergebnis: Die Wiederholungsanfrage wird gemäß dem dokumentierten Header des CDN aus dem Cache bedient. Fehlerinterpretation: Die Route umgeht den Cache oder lässt ihn sofort ablaufen. Überwachungsfenster: sofort. Rollback-Auslöser: Personalisiertes, authentifiziertes oder veraltetes HTML wird an die falsche Anfrage ausgeliefert.

Weiterleitungsentfernungstest

Durchzuführender Test: Verwenden Sie curl -sS -I auf der endgültigen öffentlichen URL und überprüfen Sie die Weiterleitungskette separat. Erwartetes Ergebnis: Die beabsichtigte Einstiegs-URL erreicht das Dokument ohne vermeidbaren Zwischenschritt. Fehlerinterpretation: Routing- oder kanonische Host-Regeln fügen weiterhin einen Roundtrip hinzu. Überwachungsfenster: sofort. Rollback-Auslöser: Die Änderung bricht die erforderliche HTTP-zu-HTTPS- oder Hostnamen-Normalisierung.

Feld-TTFB-Test

Durchzuführender Test: Vergleichen Sie nach der Veröffentlichung Navigation Timing oder web-vitals TTFB nach Region und Vorlage mit der Baseline vor der Veröffentlichung. Erwartetes Ergebnis: p75 verbessert sich in den betroffenen Segmenten ohne mehr Fehler. Fehlerinterpretation: Der Laborgewinn erreichte die realen Nutzer nicht oder verlagerte die Arbeit woanders hin. Überwachungsfenster: sobald RUM-Daten eintreffen; CrUX über sein rollierendes Fenster. Rollback-Auslöser: Fehlerrate, Cache-Korrektheit oder sichtbare Latenz verschlechtern sich.

TTFB-Metriken, die es wert sind, verfolgt zu werden

TTFB realer Nutzer bei p75

Metrik: das 75. Perzentil der TTFB nach Vorlage, Region und Geräteklasse. Was sie Ihnen sagt: wie lange die Dokumentanfrage die meisten echten Besuche verzögert, bevor das Rendering beginnen kann. So ziehen Sie sie: Navigation Timing, die Bibliothek web-vitals, CrUX oder PageSpeed Insights. Benchmark / realistischer Bereich: 0,8 Sekunden oder weniger ist das in diesem Artikel beschriebene gute Ziel; interpretieren Sie Segmente separat. Häufigkeit: wöchentlich in RUM und monatlich für den rollierenden öffentlichen Feldtrend.

TTFB bei Cache-Treffer im Vergleich zu TTFB bei Cache-Fehltreffer

Metrik: p75 TTFB aufgeteilt nach dem Cache-Ergebnis des CDN. Was sie Ihnen sagt: ob die Arbeit am Ursprungsserver oder die Zustellung am Edge die Verzögerung verursacht. So ziehen Sie sie: verbinden Sie Antwort-Cache-Status-Header mit RUM- oder CDN-Protokollen. Benchmark / realistischer Bereich: verwenden Sie die eigene regionale Basislinie der Website, da Anbieter, Route und Personalisierung unterschiedlich sind. Häufigkeit: wöchentlich und nach Änderungen an Cache-Regeln.

TTFB-Anteil an LCP

Metrik: TTFB geteilt durch die LCP-Dauer für denselben Besuch. Was sie Ihnen sagt: ob Server- und Verbindungszeit der begrenzende Teil des Ladeerlebnisses sind. So ziehen Sie sie: erfassen Sie TTFB und LCP gemeinsam in RUM. Benchmark / realistischer Bereich: kein universeller Prozentsatz ist ehrlich; priorisieren Sie TTFB, wenn es konsequent einen großen Teil von LCP verbraucht. Häufigkeit: monatlich nach Vorlage.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Artikel

• Core Web Vitals: Ein Leitfaden für Einsteiger – wo TTFB unter den Lademetriken einzuordnen ist und warum es eine ergänzende Metrik und kein Ranking-Signal ist.
• Der Leitfaden für Einsteiger zu technischem SEO – das größere Bild, in das die Website-Leistung eingebettet ist.

Offiziell

• web.dev’s TTFB und TTFB optimieren – die beiden maßgeblichen Seiten.
• Der Beitrag des Chrome-Teams zu 103 Early Hints mit den Shopify/Cloudflare-Ergebnissen.

Daten

• Der HTTP Archive Web Almanac – Kapitel Leistung – die langfristigen TTFB- und LCP-Felddaten für das gesamte Web.

Aus der Branche

• Cloudflare-Blog: Early Hints – Cloudflares eigener Beitrag zur Auslieferung von 103 Early Hints, einschließlich realer Ergebnisse und Details zur CDN-Implementierung.
• web-vitals JS-Bibliothek (GitHub) – die kanonische Bibliothek zum Erfassen von TTFB (und aller Web Vitals) von echten Nutzern; verwenden Sie diese, um Feld-TTFB an Ihre eigene Analytik zu senden.
• HTTP Archive Web Almanac 2022 – Leistung – historische Basislinie, die 40 % mobile gute TTFB unter der damals neuen 800-ms-Schwelle zeigt; nützlich für den Kontext mehrjähriger Trends.
• Fastly – HTTP/2 Server Push vs. Early Hints – CDN-Perspektive, warum Early Hints Server Push zur Reduzierung der TTFB-Auswirkung ersetzt.

Statistiken, die sich zu zitieren lohnen

• ~42 % der mobilen Websites haben einen „guten“ TTFB – und das hat sich in fünf Jahren kaum verändert. Die mobile Good-TTFB-Quote des Web Almanac liegt seit fünf Jahren bei etwa 41–42 %: eine hartnäckige, webweite Stagnation. Quelle
• Bei Websites mit schlechtem LCP verbrauchte TTFB allein etwa 2,27 Sekunden – fast die gesamte 2,5-Sekunden-Schwelle für „gutes LCP“, bevor irgendwelche Inhalte gerendert wurden. TTFB ist der größte Teil von LCP für Websites, die es nicht schaffen. Quelle
• 103 Early Hints brachten mehrere hundert Millisekunden LCP-Verbesserung in Shopify- und Cloudflare-Tests – in einigen Fällen fast eine Sekunde schneller. Quelle
• Die „gute“ TTFB-Linie wurde 2022 von 500 ms auf 800 ms verschoben, und historische Daten wurden nach dem neuen Standard neu berechnet – das sollte man wissen, bevor man alte TTFB-Zahlen vergleicht. Quelle

Testen Sie sich: Time to First Byte

Fünf kurze Fragen dazu, was TTFB misst und wie man es verbessert. Wählen Sie für jede eine Antwort aus und prüfen Sie dann.

Änderungsprotokoll