Was ist TTFB (Time To First Byte)? Was ist gut und wie reduziert man ihn (2026)

  • vuetelemetry
  • Leitfäden
  • 6 Min. Lesezeit

TTFB ist die Zeit von der Anfrage einer Seite bis zum Empfang des ersten Bytes der Antwort. Was er misst, was als guter TTFB gilt (unter ~800 ms), wie er in den LCP einfließt und welche Server-, Caching- und CDN-Hebel ihn senken.

TTFB oder Time To First Byte ist die Zeit zwischen dem Moment, in dem Ihr Browser einen Server nach einer Seite fragt, und dem Moment, in dem das erste Byte der Antwort zurückkommt. Er wird in Millisekunden gemessen und umfasst alles, was geschehen muss, bevor der Browser überhaupt anfangen kann, die Seite zu lesen: das Auflösen der Domain, das Öffnen der Verbindung und - der Teil, der meist dominiert - der Server, der seine Arbeit verrichtet und dieses erste Byte sendet.

Er ist wichtig, weil der TTFB die Steuer ist, die auf jede einzelne Anfrage entrichtet wird, bevor etwas Sichtbares geschehen kann. Ein Browser kann kein einziges Pixel rendern, bevor Bytes eintreffen, sodass ein langsamer TTFB die gesamte Seite um genau diesen Betrag verzögert, ganz gleich, wie gut Ihre Bilder, Ihr CSS und Ihr JavaScript optimiert sind. Er ist die Untergrenze Ihrer Ladegeschwindigkeit.

Was TTFB wirklich misst

Blaue Ethernet-Kabel, die an einen Netzwerk-Switch angeschlossen sind - der Netzwerkpfad, den eine Anfrage zurücklegt, ist ein Teil des Time To First Byte einer Seite.
Blaue Ethernet-Kabel, die an einen Netzwerk-Switch angeschlossen sind - der Netzwerkpfad, den eine Anfrage zurücklegt, ist ein Teil des Time To First Byte einer Seite.

Unter der Haube ist der TTFB eine Summe kleinerer Wartezeiten: etwaige Weiterleitungen, die DNS-Auflösung, die Ihre Domain in eine IP-Adresse verwandelt, die TCP-Verbindung und der TLS-Handshake, der sie absichert, die Zeit, die die Anfrage bis zum Server unterwegs ist, und schließlich die Verarbeitungszeit des Servers, bis das erste Byte zurückgeschrieben wird. Auf den meisten Websites ist dieser letzte Teil - wie lange der Server braucht, um die Antwort aufzubauen - der größte und der am ehesten behebbare.

Entscheidend ist, dass der TTFB eine Back-End- und Netzwerkmessung ist, keine Front-End-Messung. Wenn Ihr TTFB hoch ist, liegt das Problem am Server, am Hosting oder am Netzwerkpfad, nicht in Ihrem React- oder Vue-Code. Das ist eine nützliche Diagnose: Sie sagt Ihnen, dass Sie sich Ihren Host, Ihr Caching und Ihre Datenbank ansehen sollten statt der Größe Ihres Bundles.

Was als guter TTFB gilt

Die Empfehlung von Google, veröffentlicht auf web.dev, lautet, dass ein guter TTFB für die meisten Websites grob unter 800 Millisekunden liegt, wobei alles über 1.8 s als schlecht gilt. Das sind Feldschwellenwerte - gemessen bei echten Besuchen - sie berücksichtigen also bereits reale Netzwerke und Geräte statt eines Labortests auf schneller Hardware.

  • Langsames oder überlastetes Hosting - ein Shared-Server, der unter dem Traffic anderer Websites ächzt
  • Ungecachte dynamische Seiten, die bei jeder einzelnen Anfrage von Grund auf neu generiert werden
  • Schwere Datenbankabfragen oder langsamer Back-End-Code, die die Serververarbeitungszeit aufblähen
  • Kein CDN, sodass jeder Besucher sich mit einem einzigen weit entfernten Origin-Server verbindet
  • Weiterleitungsketten, die zusätzliche Roundtrips hinzufügen, bevor die eigentliche Antwort beginnt
  • Langsame TLS-Handshakes oder ein Server, der weit von einem Großteil Ihres Publikums entfernt liegt

Der TTFB ist selbst keiner der drei Core Web Vitals, aber er fließt direkt in den Largest Contentful Paint ein. Der LCP kann niemals schneller sein als der TTFB, der ihm vorausgeht, denn der Hauptinhalt kann nicht erscheinen, bevor die Antwort begonnen hat. Einen langsamen TTFB zu verbessern hebt oft den LCP ganz nebenbei, und deshalb beginnt Performance-Arbeit so oft hier.

Wie man TTFB reduziert

Der größte serverseitige Hebel ist das Caching. Eine Seite aus einem Full-Page-Cache oder einem CDN-Edge-Cache auszuliefern spart die Arbeit, sie bei jeder Anfrage neu zu generieren, und verwandelt Hunderte von Millisekunden Verarbeitung in einen nahezu sofortigen Treffer. Darüber hinaus senken schnelleres oder weniger ausgelastetes Hosting, schlankerer Back-End-Code und das Ausmisten langsamer Datenbankabfragen allesamt den Verarbeitungsanteil direkt.

Auf der Netzwerkseite verkürzt ein CDN die physische Distanz zwischen Ihrem Server und jedem Besucher, sodass Anfrage und Antwort weniger weit reisen. Eine moderne Verbindungsverarbeitung - HTTP/2 oder HTTP/3, keep-alive und eine gut konfigurierte TLS-Einrichtung - reduziert den Handshake-Overhead, und wo eine Seite zu statischen Dateien vorgerendert werden kann, entfernt statisches Hosting die Serververarbeitung fast vollständig aus dem kritischen Pfad.

Auf der Netzwerkseite verkürzt ein CDN die physische Distanz zwischen Ihrem Server und jedem Besucher, sodass Anfrage und Antwort weniger weit reisen. Eine moderne Verbindungsverarbeitung - HTTP/2 oder HTTP/3, keep-alive und eine gut konfigurierte TLS-Einrichtung - reduziert den Handshake-Overhead, und wo eine Seite zu statischen Dateien vorgerendert werden kann, entfernt statisches Hosting die Serververarbeitung fast vollständig aus dem kritischen Pfad.

- vuetelemetry

Fazit

Kurz gesagt, der TTFB ist die Server-Antwort-Steuer auf jede Seite, die Sie ausliefern, und er legt die Obergrenze dafür fest, wie schnell sich der Rest Ihrer Website anfühlen kann. Ein leistungsfähiger Host, aggressives Caching und ein CDN sind die drei Hebel, die ihn am stärksten bewegen - deshalb ist die Behebung des TTFB in der Regel die Performance-Arbeit mit der größten Hebelwirkung, die Sie leisten können, bevor Sie eine einzige Zeile Front-End-Code anfassen.

Verwandter Stack