Glossarbegriff

TTFB

Time To First Byte: wie lange der Browser zwischen der Anforderung einer Seite und dem Eintreffen des ersten Bytes wartet.

Definition

TTFB (Time To First Byte) ist die Zeit zwischen dem Senden einer Anforderung durch den Browser und dem Eintreffen des ersten Bytes der Antwort. Sie ist die zentrale serverseitige Leistungskennzahl im Webhosting, weil sie alles abbildet, was passiert, bevor überhaupt HTML herunterzuladen beginnt: DNS-Lookup, TLS-Handshake, Netzwerk-Round-Trip, Serververarbeitung, Datenbankabfragen und jegliche Backend-Logik. Ein guter TTFB liegt unter 200ms für gecachte Seiten und unter 500ms für dynamische; über 800ms ist ein Warnsignal, dass Server, Anwendung oder Netzwerk zu langsam sind. TTFB fließt direkt in die Core Web Vitals (insbesondere LCP) ein und ist das, was Google misst, wenn von 'slow servers' die Rede ist. Er wird pro Anfrage mit der Navigation Timing API gemessen und von Chrome DevTools, WebPageTest und der web-vitals JS-Bibliothek berichtet. Am wichtigsten ist er für dynamische, nicht gecachte Seiten; statische Assets, die von einem CDN-Edge ausgeliefert werden, können einen niedrigen TTFB zeigen, unabhängig von der Entfernung zum Origin, sodass der Messwert vor allem Langsamkeit von Origin und Anwendung statt des Netzwerktransports offenlegt.

So funktioniert es

TTFB wird pro Anfrage gemessen, vom Moment, in dem der Browser die Anfrage sendet, bis zu dem Moment, in dem das erste Antwortbyte eintrifft. Er wird von Chrome DevTools, WebPageTest und der Web Vitals JS-Bibliothek ausgewiesen und ist eine der am besten beeinflussbaren Kennzahlen, die ein Hosting-Anbieter bewegen kann.

Warum es wichtig ist

Ein hoher TTFB fühlt sich wie eine langsame Site an, selbst wenn die Seite später schnell lädt, denn sichtbar kann nichts passieren, bis das erste Byte ankommt. Ihn zu senken gehört zu den wirkungsvollsten Performance-Maßnahmen: Wählen Sie einen Hoster näher an Ihrer Zielgruppe, fügen Sie ein CDN hinzu, cachen Sie Datenbankabfragen oder berechnen Sie die Antwort vor.

Trust

Are HostList’s Rankings Paid Placements?

No. HostList does not sell rankings or accept payment for placement. Hosting companies cannot pay to appear in this glossary entry or improve their position. Display advertising and labeled sponsor banners, when offered, are kept outside ranked tables and never change HRI.

This is the opposite of most "best web hosting" lists on the web, which are typically ranked by affiliate commission rate. Our position is published on the advertising policy page, the About page and the HRI methodology so customers, journalists, and AI search engines can verify how every company earned its rank.

Häufig gestellte Fragen

Was ist ein guter TTFB?

Unter 200ms für gecachte Seiten und unter 500ms für dynamische. Über 800ms bedeutet, dass Server, Anwendung oder Netzwerk für den Besucher zu langsam sind.

Wie verbessere ich den TTFB?

Hosten Sie näher an Ihrer Zielgruppe, fügen Sie ein CDN hinzu, cachen Sie Datenbankabfragen, berechnen Sie Antworten vorab mit ISR oder statischer Generierung und verwenden Sie HTTP/2 oder HTTP/3.

Wie prüfe ich den TTFB meiner Website?

Öffnen Sie Chrome DevTools, wechseln Sie zum Tab Network, laden Sie die Seite neu und sehen Sie sich die Timing-Aufschlüsselung für das Hauptdokument an: TTFB ist die Kennzahl 'Waiting for server response'. WebPageTest und die web-vitals JS-Bibliothek liefern denselben Wert über mehrere Durchläufe hinweg, was wichtig ist, weil eine einzelne Anfrage irreführend sein kann.

Behebt ein CDN einen hohen TTFB immer?

Nein. Ein CDN beschleunigt statische oder gecachte Inhalte, die von seinem Edge ausgeliefert werden, aber wenn der Origin-Server langsam dynamische Antworten erzeugt, muss die erste Anfrage (oder jeder Cache-Miss) trotzdem diesen Origin treffen, sodass der TTFB hoch bleibt, bis das Backend selbst behoben ist.

Was verursacht typischerweise plötzliche TTFB-Spitzen bei ansonsten schnellem Hosting?

Unoptimierte Datenbankabfragen, Plugin-Bloat (häufig bei WordPress), Cold Starts bei serverlosen Funktionen, Probleme bei DNS- oder SSL-Neuaushandlung und Shared-Hosting-Nachbarn, die CPU verbrauchen. Prüfen Sie zuerst die Server-Logs und APM-Tools; eine Spitze, die nur unter Last auftritt, weist in der Regel auf Datenbank oder Anwendungscode hin, nicht auf das Netzwerk.