Was ist der Time to First Byte (TTFB) und wie man ihn verbessert

Der Time to First Byte (TTFB) misst die Zeit in Millisekunden zwischen der Anfrage einer Seite durch den Browser und dem Empfang des ersten Bytes der Antwort vom Server. Ein guter TTFB liegt im 75. Perzentil bei 800 Millisekunden oder weniger. Der TTFB ist kein Core Web Vital, aber er ist eine kritische Diagnosemetrik, da er sich direkt auf [url=\/core-web-vitals\/largest-contentful-paint]Largest Contentful Paint (LCP)[\/url] und [url=\/core-web-vitals\/first-contentful-paint]First Contentful Paint (FCP)[\/url] auswirkt.<\/strong><\/p>

[include]toc.html[\/include]<\/p>

Was ist der Time to First Byte<\/h2>

Der Time to First Byte (TTFB) gibt an, wie viel Zeit in Millisekunden zwischen dem Beginn der Anfrage und dem Empfang der ersten Antwort (Byte) einer Webseite vergangen ist. Der TTFB wird daher auch als Wartezeit bezeichnet. Der TTFB ist eine Möglichkeit, die Reaktionsfähigkeit eines Webservers und des Netzpfads zwischen dem Benutzer und diesem Server zu messen. Der TTFB ist eine grundlegende Metrik; das bedeutet, dass die zum TTFB hinzugefügte Zeit auch zum Largest Contentful Paint und zum First Contentful Paint hinzugefügt wird. Jede am TTFB gesparte Millisekunde ist eine Millisekunde, die bei beiden Paint-Metriken gespart wird.<\/p>

<\/two-stage-img><\/p>

TTFB ist kein Core Web Vital<\/h2>

Es ist wichtig, dies klarzustellen: Der TTFB ist keiner der drei Core Web Vitals<\/strong>. Die Core Web Vitals bestehen aus [url=\/core-web-vitals\/largest-contentful-paint]Largest Contentful Paint (LCP)[\/url], [url=\/core-web-vitals\/interaction-to-next-paint]Interaction to Next Paint (INP)[\/url] und [url=\/core-web-vitals\/cumulative-layout-shift]Cumulative Layout Shift (CLS)[\/url]. Google verwendet den TTFB nicht direkt in seinen Ranking-Signalen für die Seitenerfahrung (Page Experience).<\/p>

Der TTFB wird jedoch als Diagnosemetrik<\/strong> eingestuft. Er hilft Ihnen zu verstehen, warum<\/em> Ihr LCP oder FCP langsam sein könnte. Laut dem [url=https:\/\/almanac.httparchive.org\/en\/2025\/performance]2025 Web Almanac[\/url] verbringen Websites mit schlechtem LCP durchschnittlich 2,27 Sekunden allein mit dem TTFB, was fast den gesamten LCP-Schwellenwert von 2,5 Sekunden aufbraucht, bevor der Browser überhaupt mit dem Rendern der Seite beginnt. Die Behebung des TTFB ist daher eine der wirkungsvollsten Maßnahmen, die Sie für Ihre gesamten [url=\/core-web-vitals]Core Web Vitals[\/url] Scores ergreifen können.<\/p>

Warum ist der Time to First Byte wichtig<\/h2>

Der Time to First Byte ist kein Core Web Vital, und es ist sehr gut möglich, die Core Web Vitals zu bestehen, während man bei der TTFB-Metrik durchfällt. Das bedeutet nicht, dass der TTFB nicht wichtig ist. Der TTFB ist eine extrem wichtige Metrik zur Optimierung, und die Behebung des TTFB wird die Seitengeschwindigkeit und die Seitenerfahrung erheblich verbessern.<\/p>

Die Auswirkung des TTFB für Besucher<\/h3>

Der Time to First Byte geht allen anderen Paint-Metriken voraus. Während der Browser auf den Time to First Byte wartet, kann er nichts tun und zeigt nur einen leeren Bildschirm an. Das bedeutet, dass jede Erhöhung des Time to First Byte zu zusätzlicher "leerer Bildschirm"-Zeit führt und jede Verringerung des Time to First Byte in weniger "leerer Bildschirm"-Zeit resultiert.<\/p>

Um das Gefühl von sofort ladenden Seiten zu erhalten, muss der Time to First Byte so schnell wie möglich sein.<\/p>

Warum ist der TTFB kein Core Web Vital?<\/b> Der TTFB berücksichtigt das Rendering nicht: Ein niedriger TTFB bedeutet nicht zwangsläufig eine gute Benutzererfahrung, da er die Zeit nicht berücksichtigt, die der Browser zum Rendern der Webseite benötigt. Selbst wenn alle Bytes schnell heruntergeladen werden, könnte die Anzeige der Webseite immer noch lange dauern, wenn der Browser viel JavaScript verarbeiten oder komplexe Layouts rendern muss.<\/p>

Was ist ein guter TTFB-Score?<\/h2>

<\/two-stage-img><\/p>

Es wird empfohlen, dass Ihr Server schnell genug auf Navigationsanfragen reagiert, damit das 75. Perzentil der Benutzer einen FCP innerhalb des "guten" Schwellenwerts erlebt. Als grobe Richtlinie sollten die meisten Websites einen TTFB von 0,8 Sekunden oder weniger anstreben.<\/p>

• Ein TTFB unter 800 Millisekunden<\/b> gilt als gut.<\/li>
• Ein TTFB zwischen 800 und 1800 Millisekunden<\/b> ist verbesserungswürdig.<\/li>
• Ein TTFB über 1800 Millisekunden<\/b> gilt als schlecht und sollte sofort verbessert werden.<\/li> <\/ul>

  Auswirkungen in der Praxis: die T-Mobile Fallstudie<\/h2>

  [url=https:\/\/web.dev\/case-studies\/t-mobile-case-study]T-Mobile[\/url] hat im Rahmen einer umfassenderen Initiative zur Leistungsoptimierung stark in die Reduzierung ihres Time to First Byte investiert. Die Ergebnisse waren beeindruckend: eine Steigerung der Visit-to-Order-Conversions um 60 %<\/strong>. Durch den Umstieg auf Edge-gerenderte Seiten und aggressives serverseitiges Caching konnte T-Mobile die Zeit, die Benutzer auf das erste Byte warten mussten, drastisch reduzieren, was zu einem schnelleren LCP, einem schnelleren FCP und einer messbar besseren Benutzererfahrung führte. Diese Fallstudie zeigt, dass die TTFB-Optimierung nicht nur eine technische Übung ist; sie wirkt sich direkt auf die Geschäftsergebnisse aus.<\/p>

  Der TTFB von der Anfrage bis zur Antwort<\/h2>

  Es ist wichtig zu verstehen, dass der Time to First Byte keine einzelne Metrik ist, die durch Ändern einer einzelnen Sache behoben werden kann. Der Time to First Byte ist komplexer und schwer fassbarer, als viele vielleicht denken. Jede Anfrage beginnt mit einer Browseranfrage, gefolgt von der Serververarbeitung und einer anschließenden Serverantwort.<\/div>

  Vom Browser zum Server: Die Anfrage<\/h3>

  Die Browser-Anfragezeit ist die Zeit, die vom Moment an vergeht, in dem der Browser eines Benutzers eine HTTP-Anfrage sendet, bis diese Anfrage den Server erreicht, auf dem die Website gehostet wird. Der TTFB dieses Teils liegt weitgehend außerhalb der direkten Kontrolle der Website und hängt stark ab von:<\/p>

  • Der Internetgeschwindigkeit des Benutzers.<\/li>
  • Der Qualität seiner Netzwerkinfrastruktur.<\/li>
  • Der physischen Entfernung zwischen dem Benutzer und dem Server.<\/li> <\/ul>

    Innerhalb dieser Phase nehmen DNS-Lookup, Browser-Startzeit, Browser-Cache-Lookups und das Aushandeln der Verbindung zum Server (TCP und TLS) ein wenig Zeit in Anspruch.<\/p>

    Auf dem Server: Verarbeitung<\/h3>

    Sobald die Anfrage den Server erreicht hat, muss der Server die Anfrage verarbeiten und die Antwort generieren. Die Zeit, die der Server für diesen Schritt benötigt, wird als Server-Verarbeitungszeit bezeichnet. Diese Zeit hängt von mehreren Faktoren ab, wie der Komplexität der Website, der Effizienz des serverseitigen Codes und den verfügbaren Ressourcen auf dem Server (CPU, RAM). Dies ist der Teil des TTFB, über den Sie die meiste Kontrolle haben.<\/p>

    Vom Server zum Browser: Die Antwort<\/h3>

    Nachdem der Server die Antwort generiert hat, muss er sie zurück an den Browser des Benutzers senden. Die Zeit, die das erste Byte der Antwort benötigt, um den Browser des Benutzers zu erreichen, wird als Antwortzeit bezeichnet. Ähnlich wie die Anfragezeit hängt dieser Teil des TTFB von der Internetverbindung des Benutzers und der physischen Entfernung zwischen dem Benutzer und dem Server ab.<\/p>

    Messen des TTFB mit Server-Timing<\/h2>

    Um die serverseitige Verarbeitungszeit zu messen, können Sie die Server-Timing<\/code>-API verwenden. Mit dieser API können Server Informationen über ihre Leistung an den Browser senden, die dann in den Browser-Entwicklertools (DevTools) angezeigt werden können.<\/p>

    Die Server-Timing<\/code>-API funktioniert durch Senden eines HTTP-Antwort-Headers vom Server an den Browser. Dieser Header kann mehrere Metriken enthalten, die durch Kommas getrennt sind. Jeder Eintrag besteht aus:<\/p>

    • Einem Kurznamen für die Metrik (wie database<\/code> und processing<\/code>)<\/li>
    • Einer Dauer in Millisekunden (ausgedrückt als dur=123<\/code>)<\/li>
    • Einer optionalen Beschreibung (ausgedrückt als desc="Meine Beschreibung"<\/code>)<\/li> <\/ul>

      Server-Timing: database;dur=123;desc="DB Query", processing;dur=234;desc="Template Render", cache;dur=0;desc="Cache HIT"
      <\/pre>