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>
              
              
      Server-Timing in den Chrome DevTools lesen<\/h3>
              
      Die Chrome DevTools zeigen Server-Timing-Einträge direkt im Network-Panel an. Öffnen Sie die DevTools, wählen Sie die Dokumentanfrage im Tab "Network" aus, scrollen Sie im Tab "Timing" nach unten zum Abschnitt "Server Timing". Jede Metrik, die Sie über den Server-Timing<\/code>-Header senden, wird mit ihrem Namen, ihrer Beschreibung und ihrer Dauer angezeigt. So lässt sich leicht feststellen, ob Ihre Datenbank, das Template-Rendering oder die Caching-Ebene der Engpass ist.<\/p>
              
      Sie können den Server-Timing-Header auch programmatisch auslesen und diese Zeiten an Ihr bevorzugtes RUM-Tool wie CoreDash<\/a> für langfristiges Tracking und Alarmierung senden.<\/p>
              <\/two-stage-img>
      
              
              
      TTFB beschleunigen mit 103 Early Hints<\/h2>
              
      [url=\/pagespeed\/103-early-hints]103 Early Hints[\/url] ist ein HTTP-Statuscode, der es dem Server ermöglicht, vorläufige Antwort-Header an den Browser zu senden, bevor<\/em> die endgültige Antwort bereit ist. Während der Server noch die Anfrage verarbeitet (Datenbank abfragt, das Template rendert), kann der Browser bereits mit dem Laden kritischer Ressourcen wie Stylesheets, Schriftarten und dem LCP-Bild beginnen.<\/p>
              
      Wie 103 Early Hints funktioniert<\/h3>
              
      In einem herkömmlichen Anfragefluss bleibt der Browser während der gesamten Verarbeitungszeit des Servers untätig. Mit 103 Early Hints sendet der Server unmittelbar nach Erhalt der Anfrage eine Teilantwort. Diese Teilantwort enthält Link<\/code>-Header, die dem Browser mitteilen, welche Ressourcen vorab geladen (preload) oder zu denen eine Verbindung (preconnect) hergestellt werden soll. Der Browser reagiert auf diese Hinweise, während er auf die vollständige 200-Antwort wartet.<\/p>
              
      Dies wandelt tote Wartezeit effektiv in produktive Ladezeit um. Obwohl 103 Early Hints den TTFB des Dokuments selbst nicht reduziert, verringert es die wahrgenommene<\/em> Auswirkung des TTFB auf nachfolgende Metriken wie LCP und FCP, indem es dem Browser einen Vorsprung bei der Ressourcenentdeckung verschafft.<\/p>
              
      Server-Konfigurationsbeispiel für 103 Early Hints<\/h3>
              
      Viele CDNs und Webserver unterstützen mittlerweile 103 Early Hints. Hier ist ein Beispiel mit [url=\/pagespeed\/configure-cloudflare-for-passing-the-core-web-vitals]Cloudflare[\/url], das automatisch 103 Early Hints aus Link<\/code>-Headern und preload<\/code>\/preconnect<\/code>-Tags generiert, die in Ihrem HTML gefunden werden:<\/p>
              
      HTTP\/1.1 103 Early Hints
      Link: <\/style.css>; rel=preload; as=style
      Link: <\/static\/img\/hero.webp>; rel=preload; as=image
      Link: <https:\/\/fonts.googleapis.com>; rel=preconnect
      
      HTTP\/1.1 200 OK
      Content-Type: text\/html
      ...<\/pre>
              
      Für Nginx können Sie Early Hints konfigurieren, indem Sie Link<\/code>-Header zu Ihrer Antwort hinzufügen und HTTP\/2- oder HTTP\/3-Push aktivieren. Apache unterstützt 103 Early Hints über die Direktive H2EarlyHints<\/code>. In unserem detaillierten Leitfaden zur [url=\/pagespeed\/103-early-hints]Implementierung von 103 Early Hints[\/url] finden Sie Schritt-für-Schritt-Anleitungen.<\/p>
      
              
              
      TTFB eliminieren mit der Speculation Rules API<\/h2>
              
      Die Speculation Rules API wurde entwickelt, um die Leistung für zukünftige Navigationsvorgänge zu verbessern. Sobald ein Besucher auf Ihrer Seite gelandet ist, können Sie Speculation Rules verwenden, um einen Browser anzuweisen, Seiten abzurufen (mit der prefetch<\/code>-Direktive) oder sogar vollständig zu rendern (mit der prerender<\/code>-Direktive), die der Besucher am wahrscheinlichsten als Nächstes besuchen wird.<\/p>
              
      Wie Speculation Rules den TTFB eliminiert<\/h3>
              
      Wenn eine Seite vorausgerendert (prerendered)<\/strong> wird, lädt und rendert der Browser sie vollständig in einem versteckten Tab. Wenn der Benutzer dann auf den Link klickt, wird die vorausgerenderte Seite sofort eingeblendet. Das Ergebnis: ein gemessener TTFB von 0 Millisekunden<\/strong>. Dies ist keine theoretische Zahl. CoreDash RUM-Daten von corewebvitals.io bestätigen, dass vorausgerenderte Navigationsvorgänge über Speculation Rules einen p75 TTFB von 0 ms aufweisen.<\/p>
              
      Prefetching<\/strong> ist eine leichtere Alternative. Anstatt die Seite vollständig zu rendern, ruft der Browser nur das HTML-Dokument ab und speichert es im Cache. Dies eliminiert den Netzwerkanteil des TTFB, erfordert aber dennoch, dass der Browser das Dokument bei der Navigation parst und rendert.<\/p>
              
      Speculation Rules JSON-Syntax<\/h3>
              
      Speculation Rules werden mithilfe eines <script type="speculationrules"><\/code>-Blocks definiert, der JSON enthält. Hier ist ein Beispiel, das alle Navigationslinks in Ihrer Menüleiste mit "moderatem" Eifer (ausgelöst bei Hover oder Pointer down) vorausrendert:<\/p>
              
      <script type="speculationrules">
      {"prerender":
      [{
        "source": "document",
        "where": {"selector_matches": "nav a"},
        "eagerness": "moderate"
      }]}
      <\/script><\/pre>
              
      Sie können auch einen listenbasierten Ansatz für bestimmte URLs verwenden:<\/p>
              
      <script type="speculationrules">
      {"prefetch":
      [{
        "source": "list",
        "urls": ["\/core-web-vitals\/", "\/pagespeed\/103-early-hints"]
      }]}
      <\/script><\/pre>
              
      Die Browser-Unterstützung für Speculation Rules wächst. Chrome 121+ unterstützt die vollständige API einschließlich Dokumentregeln. Für Browser, die Speculation Rules noch nicht unterstützen, könnten Sie ein leichtgewichtiges Skript wie quicklink<\/a> als Fallback verwenden. Verwenden Sie unseren [url=\/pagespeed\/speculation-rules]Speculation Rules Generator[\/url], um die richtige Konfiguration für Ihre Website zu erstellen.<\/p>
      
              
      Wie beeinflusst Hosting den Time to First Byte?<\/h2>
              
      Hosting beeinflusst den Time to First Byte auf verschiedene Weise. Durch die Investition in ein besseres Hosting ist es in der Regel möglich, den Time to First Byte sofort zu verbessern, ohne etwas anderes zu ändern. Insbesondere beim Wechsel von Low-Budget-Shared-Hosting zu ordnungsgemäß konfigurierten und verwalteten virtuellen Servern könnte sich der TTFB drastisch verbessern.<\/p>
              
      Hosting-TIPP<\/b>: Besseres Hosting bedeutet schnellere Verarbeitung, bessere Netzwerkgeschwindigkeit und mehr sowie schnelleren Serverspeicher. Teures Hosting ist nicht immer gleichbedeutend mit besserem Hosting. Viele Upgrades bei Shared-Hosting-Diensten bringen Ihnen nur mehr Speicherplatz, nicht mehr CPU-Leistung.<\/p>
              
      Ich empfehle nicht, das Hosting zu wechseln, ohne die Ursachen der TTFB-Probleme zu kennen. Ich rate Ihnen, RUM-Tracking einzurichten und Server-Timing-Header hinzuzufügen.<\/p>
              
      Wenn Sie Ihr Hosting upgraden, sollten Sie im Allgemeinen nach mindestens einer dieser drei Verbesserungen suchen:<\/p>
              
      
                
      Mehr Ressourcen erhalten (CPU + RAM):<\/b> Besonders wenn der Server zu lange braucht, um das dynamische HTML zu generieren.<\/li>
                
      Schnelleres DNS:<\/b> Viele Low-Budget-Hosting-Anbieter sind berüchtigt für ihre schlechte DNS-Leistung.<\/li>
                
      Bessere Konfiguration:<\/b> Achten Sie unter anderem auf schnellere SSL-Ciphers, HTTP\/3, Brotli-Kompression und Zugriff auf die Webserver-Konfiguration (um unnötige Module zu deaktivieren).<\/li>
              <\/ul>
      
              
      So verbessern Sie den TTFB: die erste Verbindung beschleunigen<\/h2>
              
      Ein hoher Time to First Byte kann mehrere Ursachen haben. DNS, TCP und SSL betreffen jedoch alle Time to First Bytes. Fangen wir also dort an. Auch wenn die Optimierung dieser drei Punkte nicht die größten Ergebnisse liefert, wird die Optimierung dieser Punkte jeden einzelnen TTFB optimieren.<\/p>
              
      DNS beschleunigen<\/h3>
              
      PageSpeed-TIPP<\/b>: DNS, TCP und SSL sind meist ein größeres Problem, wenn Sie einen günstigen Host verwenden oder wenn Sie ein globales Publikum bedienen, ohne ein CDN zu nutzen. Verwenden Sie RUM-Tracking, um Ihren globalen TTFB anzuzeigen und den TTFB in seine Unterbereiche aufzuschlüsseln.<\/p>
              
      Verwenden Sie einen schnellen DNS-Anbieter<\/b>. Nicht alle DNS-Anbieter sind gleich schnell. Einige (kostenlose) DNS-Anbieter sind einfach langsamer als andere (kostenlose) DNS-Anbieter. [url=\/pagespeed\/configure-cloudflare-for-passing-the-core-web-vitals]Cloudflare[\/url] bietet Ihnen zum Beispiel kostenlos einen der weltweit schnellsten DNS-Anbieter.<\/p>
              
      DNS-TTL erhöhen<\/b>. Eine andere Möglichkeit besteht darin, den TTL-Wert (Time to Live) zu erhöhen. TTL ist eine Einstellung, die bestimmt, wie lange der Lookup zwischengespeichert werden kann. Je höher die TTL, desto seltener muss der Browser einen erneuten DNS-Lookup durchführen. Es ist wichtig zu beachten, dass ISPs DNS ebenfalls zwischenspeichern.<\/p>
              
      TCP beschleunigen<\/h3>
              
      Der "TCP-Teil" des TTFB ist die erste Verbindung zum Webserver. Beim Verbindungsaufbau tauschen der Browser und der Server Informationen darüber aus, wie Daten ausgetauscht werden. Sie können TCP beschleunigen, indem Sie eine Verbindung zu einem Server herstellen, der sich geografisch in Ihrer Nähe befindet, und indem Sie sicherstellen, dass der Server über genügend freie Ressourcen verfügt. Manchmal kann der Wechsel zu einem leichtgewichtigen Server wie NGINX den TCP-Teil des TTFB beschleunigen. In vielen Fällen beschleunigt die Verwendung eines CDN die TCP-Verbindung.<\/p>
              
      SSL\/TLS beschleunigen<\/h3>
              
      Sobald die TCP-Verbindung hergestellt wurde, müssen der Browser und der Server die Verbindung durch Verschlüsselung sichern. Sie können dies beschleunigen, indem Sie schnellere, neuere und leichtgewichtigere Protokolle (SSL-Ciphers) verwenden und indem Sie geografisch näher an Ihrem Webserver sind (da die TLS-Aushandlung einige Roundtrips erfordert). Die Verwendung eines CDN verbessert oft die SSL-Verbindungszeit, da CDNs oft sehr gut konfiguriert sind und über mehrere Server auf der ganzen Welt verfügen. Insbesondere TLS 1.3 ist darauf ausgelegt, die TLS-Aushandlung so kurz wie möglich zu halten.<\/p>
      
              
      So verbessern Sie den TTFB: die Serverseite beschleunigen<\/h2>
              
      Seiten-Caching<\/h3>
              

  Der bei Weitem effizienteste Weg, den Time to First Byte zu beschleunigen, besteht darin, das HTML aus dem Server-Cache bereitzustellen. Es gibt verschiedene Möglichkeiten, ein vollständiges Seiten-Caching zu implementieren. Der effektivste Weg ist die Umsetzung direkt auf Webserver-Ebene, zum Beispiel mit dem NGINX-Caching-Modul oder durch Verwendung von Varnish als Reverse-Caching-Proxy.<\/p>

  Es gibt auch viele Plugins für verschiedene CMS-Systeme, die vollständige Seiten zwischenspeichern, und viele SPA-Frameworks wie Next.js haben ihre eigene Implementierung von Full Page Caching zusammen mit verschiedenen Invalidierungsstrategien. <\/p>

  Wenn Sie Ihr eigenes Caching implementieren möchten, ist die Grundidee einfach. Wenn ein Client eine Seite anfordert, prüfen Sie, ob sie im Cache-Ordner vorhanden ist. Wenn sie nicht existiert, erstellen Sie die Seite, schreiben Sie sie in den Cache und zeigen Sie die Seite wie gewohnt an. Bei jeder nächsten Anfrage für die Seite ist die Cache-Datei vorhanden, und Sie können die Seite direkt aus dem Cache bereitstellen.<\/p>

  Teilweises Caching<\/h3>

  Beim teilweisen Caching geht es darum, häufig verwendete, langsame oder teure Teile der Seite oder Ressourcen (wie API-Aufrufe, Datenbankergebnisse) für einen schnellen Abruf zwischenzuspeichern. Dies eliminiert Engpässe bei der Generierung einer Seite. Wenn Sie an dieser Art von Optimierungen interessiert sind, sollten Sie nach diesen Konzepten suchen: Memory Cache, Object Cache, Database Cache, Object-Relational Mapping (ORM) Cache, Content Fragment Cache und Opcode Cache.<\/p>

  Anwendungscode optimieren<\/h3>

  Manchmal kann die Seite nicht aus dem (teilweisen) Cache bereitgestellt werden, weil die Cache-Datei nicht existiert, große Teile der Seiten dynamisch sind oder weil Sie auf andere Probleme stoßen. Deshalb müssen wir den Anwendungscode optimieren. Wie dies geschieht, hängt ganz von Ihrer Anwendung ab. Es basiert auf dem Umschreiben und Optimieren langsamer Teile Ihres Codes.<\/p>

  Datenbankabfragen optimieren<\/h3>

  Meistens sind ineffektive Datenbankabfragen die Ursache für einen langsamen Time to First Byte. Beginnen Sie damit, "langsame Abfragen" und "Abfragen, die keine Indizes verwenden", auf die Festplatte zu protokollieren. Analysieren Sie diese, fügen Sie Indizes hinzu oder bitten Sie einen Experten um ein Datenbank-Tuning, um diese Probleme zu beheben. Weitere Details finden Sie im MongoDB Performance Advisor<\/a> und im MySQL Slow Query Log<\/a>.<\/p>

  Interne Netzwerklatenz reduzieren<\/h3>

  Eine schlechte Angewohnheit, der ich öfter begegne, als mir lieb ist, ist eine Verzögerung beim Time to First Byte, die durch Langsamkeit in der Kommunikation zwischen der Webanwendung und dem Datenspeicher verursacht wird. Dies geschieht normalerweise nur bei großen Websites, die ihre Datenspeicherung an Cloud-APIs ausgelagert haben.<\/p>

  So verbessern Sie den TTFB: die Clientseite beschleunigen<\/h2>

  Clientseitiges Caching<\/h3>

  Beim clientseitigen Caching speichert der Browser des Benutzers Ressourcen, auf die er bereits zugegriffen hat, wie Bilder und Skripte. Wenn der Benutzer also auf Ihre Website zurückkehrt, kann sein Browser die zwischengespeicherten Ressourcen schnell abrufen, anstatt sie erneut herunterladen zu müssen. Dies kann die Anzahl der an den Server gerichteten Anfragen erheblich reduzieren, was wiederum den TTFB verringern kann.<\/p>

  Um clientseitiges Caching zu implementieren, können Sie den HTTP-Header Cache-Control<\/code> verwenden. Mit diesem Header können Sie angeben, wie lange der Browser eine bestimmte Ressource zwischenspeichern soll.<\/p>

  Sie könnten in Erwägung ziehen, das HTML der Seite auf der Clientseite vollständig zwischenzuspeichern. Dies wird den TTFB drastisch reduzieren, da keine Serveranfrage erforderlich ist. Der Nachteil ist, dass Aktualisierungen an der Live-Version der Seite für den Benutzer erst sichtbar werden, wenn der Seitencache abläuft.<\/p>

  Service Workers<\/h3>

  Service Worker sind Skripte, die im Hintergrund des Browsers eines Benutzers ausgeführt werden und vom Browser gestellte Netzwerkanfragen abfangen können. Das bedeutet, dass Service Worker Ressourcen wie HTML, Bilder, Skripte und Stylesheets zwischenspeichern können, sodass der Browser beim nächsten Besuch Ihrer Website die zwischengespeicherten Ressourcen schnell abrufen kann, anstatt sie erneut herunterladen zu müssen.<\/p>

  Seiten-Prefetching<\/h3>

  Wenn Sie die Speculation Rules API wegen ihrer begrenzten Browserunterstützung<\/a> nicht nutzen möchten, könnten Sie ein kleines Skript namens quicklink<\/a> verwenden. Dies wird alle Links im sichtbaren Viewport vorab abrufen und den Time To First Byte für diese Links so gut wie eliminieren.<\/p>

  Der Nachteil von quicklink ist, dass es mehr Browserressourcen benötigt, aber im Moment wird es die Speculation Rules API in Bezug auf die Browserabdeckung übertreffen.<\/p>

  So verbessern Sie den TTFB: verwenden Sie ein CDN<\/h2>

  Ein Content Delivery Network oder CDN verwendet ein verteiltes Netzwerk von Servern, um Ressourcen an Benutzer auszuliefern. Diese Server befinden sich normalerweise geografisch näher am Endbenutzer und sind stark auf Geschwindigkeit optimiert. Wenn Sie Cloudflare verwenden, lesen Sie unseren Leitfaden zur [url=\/pagespeed\/configure-cloudflare-for-passing-the-core-web-vitals]Konfiguration von Cloudflare für optimale Core Web Vitals-Performance[\/url].<\/p>

  <\/two-stage-img>TTFB mit einem CDN und Edge Caching<\/i> <\/div>

  <\/two-stage-img>TTFB ohne CDN, gehostet in Deutschland<\/i><\/div> <\/div>

  Ein CDN kann helfen, 5 von 6 Teilen des Time to First Byte zu verbessern:<\/p>

  • Redirect-Zeit<\/b>: Die meisten CDNs können Redirects am Edge zwischenspeichern oder Edge Worker verwenden, um Redirects zu verarbeiten, ohne dass eine Verbindung zum Ursprungsserver hergestellt werden muss.<\/li>
  • DNS-Lookup-Zeit<\/b>: Die meisten CDNs bieten extrem schnelle DNS-Server an, die Ihre aktuellen DNS-Server wahrscheinlich übertreffen werden.<\/li>
  • TCP-Connect- und SSL-Handshake-Zeit<\/b>: Die meisten CDNs sind extrem gut konfiguriert, und diese Konfigurationen werden zusammen mit der größeren Nähe zu den Endbenutzern die Verbindungs- und Handshake-Zeit beschleunigen.<\/li>
  • Serverantwort<\/b>: CDNs können die Antwortzeit des Servers auf verschiedene Weise beschleunigen. Die erste ist das Caching der Serverantwort am Edge (Full Page Edge Caching), aber auch durch das Angebot exzellenter Kompression (Brotli) und der neuesten Protokolle (HTTP\/3).<\/li> <\/ul>

    So verbessern Sie den TTFB: vermeiden Sie Redirects<\/h2>

    Die Redirect-Zeit wird zum Time To First Byte addiert. Vermeiden Sie daher als allgemeine Regel Redirects so weit wie möglich. Redirects können auftreten, wenn eine Ressource an einem Ort nicht mehr verfügbar ist, aber an einen anderen Ort verschoben wurde. Der Server antwortet mit einem Redirect-Header, und der Browser versucht es an diesem neuen Ort.<\/p>

    Same-Origin-Redirects.<\/b> Same-Origin-Redirects stammen von Links auf Ihrer eigenen Website. Sie sollten die volle Kontrolle über diese Links haben und die Behebung dieser Links priorisieren, wenn Sie am Time to First Byte arbeiten. Es gibt viele Tools<\/a> da draußen, mit denen Sie Ihre gesamte Website auf Redirects prüfen können.<\/p>

    Cross-Origin-Redirects.<\/b> Cross-Origin-Redirects stammen von Links auf anderen Websites. Hierauf haben Sie nur sehr wenig Kontrolle.<\/p>

    Mehrfache Redirects.<\/b> Mehrfache Redirects oder Redirect-Ketten treten auf, wenn ein einzelner Redirect nicht zum endgültigen Speicherort der Ressource führt. Diese Arten von Redirects belasten den Time to First Byte stärker und sollten um jeden Preis vermieden werden. Verwenden Sie auch hier ein Tool<\/a>, um diese Arten von Redirects zu finden und zu beheben.<\/p>

    HTTP-zu-HTTPS-Redirects.<\/b> Eine Möglichkeit, dies zu umgehen, ist die Verwendung des Strict-Transport-Security<\/code>-Headers (HSTS), der HTTPS beim ersten Besuch eines Ursprungs erzwingt und dem Browser dann mitteilt, bei zukünftigen Besuchen sofort über das HTTPS-Schema auf den Ursprung zuzugreifen.<\/p>

    Wenn ein Benutzer eine Webseite anfordert, kann der Server mit einem Redirect auf eine andere Seite antworten. Dieser Redirect kann zusätzliche Zeit zum TTFB hinzufügen, da der Browser eine zusätzliche Anfrage an die neue Seite stellen muss.<\/p>

    Es gibt verschiedene Möglichkeiten, Redirects zu vermeiden oder die Auswirkungen von Redirects zu minimieren:<\/p>

    1. Aktualisieren Sie Ihre internen Links. Wann immer Sie den Ort einer Seite ändern, aktualisieren Sie Ihre internen Links zu dieser Seite, um sicherzustellen, dass keine Verweise auf den früheren Speicherort der Seite verbleiben.<\/li>
    2. Verarbeiten Sie Redirects auf Server-Ebene.<\/li>
    3. Verwenden Sie relative URLs: Wenn Sie auf Seiten Ihrer eigenen Website verlinken, verwenden Sie relative URLs anstelle von absoluten URLs. Dies hilft, unnötige Redirects zu vermeiden.<\/li>
    4. Verwenden Sie kanonische URLs: Wenn Sie mehrere Seiten mit ähnlichem Inhalt haben, verwenden Sie eine kanonische URL, um die bevorzugte Version der Seite anzugeben. Dies hilft, Duplicate Content und unnötige Redirects zu vermeiden.<\/li>
    5. Verwenden Sie 301-Redirects: Wenn Sie einen Redirect verwenden müssen, verwenden Sie einen 301-Redirect anstelle eines 302-Redirects. Ein 301-Redirect ist ein permanenter Redirect, während ein 302-Redirect ein temporärer Redirect ist. Die Verwendung eines 301-Redirects hilft, unnötige Redirects zu vermeiden.<\/li> <\/ol>

       Ressourcen-Priorisierung zusammen mit TTFB optimieren<\/h2>

       Die Reduzierung des TTFB ist nur ein Teil der Lade-Performance-Geschichte. Sobald das erste Byte eintrifft, muss der Browser wissen, welche Ressourcen er priorisieren soll. Lesen Sie unseren [url=\/pagespeed\/core-web-vitals-guide-to-resource-prioritization]Leitfaden zur Ressourcen-Priorisierung[\/url], um zu erfahren, wie fetchpriority<\/code>, preload<\/code> und preconnect<\/code> Hinweise zusammen mit einem schnellen TTFB funktionieren, um schnellstmögliche Seitenladevorgänge zu liefern. Erwägen Sie außerdem das [url=\/pagespeed\/self-host-google-fonts]Selbst-Hosten Ihrer Google Fonts[\/url], um DNS-Lookups von Drittanbietern und Verbindungszeiten zu eliminieren, die den wahrgenommenen TTFB Ihrer Benutzer erhöhen.<\/p>

       Was TTFB-Daten aus der Praxis zeigen<\/h2>

       Die folgenden Daten stammen aus dem CoreDash<\/a> Real User Monitoring und dem [url=https:\/\/almanac.httparchive.org\/en\/2025\/performance]2025 Web Almanac[\/url].<\/p>

       Die geografische Variation ist enorm<\/h3>

       Der TTFB variiert drastisch basierend auf der physischen Entfernung zwischen dem Benutzer und dem Server. CoreDash-Daten von corewebvitals.io (gehostet in Europa) verdeutlichen dies:<\/p>

       Land<\/th>	p75 TTFB<\/th>	Gut %<\/th><\/tr> <\/thead>
       Tschechien<\/td>	62 ms<\/td>	98,8 %<\/td><\/tr>
       Niederlande<\/td>	106 ms<\/td>	97,0 %<\/td><\/tr>
       Deutschland<\/td>	138 ms<\/td>	98,5 %<\/td><\/tr>
       Großbritannien<\/td>	169 ms<\/td>	97,7 %<\/td><\/tr>
       USA<\/td>	284 ms<\/td>	92,7 %<\/td><\/tr>
       Indien<\/td>	404 ms<\/td>	88,2 %<\/td><\/tr>
       China<\/td>	1.468 ms<\/td>	26,6 %<\/td><\/tr> <\/tbody> <\/table> Europäische Benutzer in der Nähe des Servers sehen einen TTFB unter 170 ms, während Benutzer in Indien einen 3-mal höheren TTFB erleben und Benutzer in China aufgrund der "Great Firewall" und der schieren physischen Entfernung einen fast 10-mal höheren TTFB (1.468 ms) sehen. Diese Daten zeigen, warum ein CDN mit globalen Edge-Standorten für ein internationales Publikum unerlässlich ist.<\/p> Speculation Rules Prerender liefert 0 ms TTFB<\/h3> Daten zum CoreDash-Navigationstyp bestätigen, dass Seiten, die über Speculation Rules vorausgerendert wurden, einen p75 TTFB von 0 Millisekunden<\/strong> erreichen. Standard-Navigationsvorgänge liegen bei 131 ms, Reloads bei 82 ms (profitieren von warmen Verbindungen) und Back-Forward-Navigationsvorgänge sind mit 244 ms am langsamsten. Dies macht Speculation Rules zur effektivsten Technik zur Eliminierung des TTFB bei nachfolgenden Seitenladevorgängen.<\/p> Mobiler TTFB ist 2,5-mal so hoch wie am Desktop<\/h3> Auf corewebvitals.io erleben mobile Benutzer einen p75 TTFB von 316 ms im Vergleich zu 124 ms am Desktop. Dieser 2,5-fache Unterschied wird durch die Latenz mobiler Netzwerke verursacht, nicht durch Serverunterschiede. Nur 88,5 % der mobilen Seitenladevorgänge erreichen eine "gute" TTFB-Bewertung, verglichen mit 96,1 % am Desktop. Testen Sie bei der Optimierung des TTFB immer in echten mobilen Netzwerken.<\/p> Neue vs. wiederkehrende Besucher sehen einen ähnlichen TTFB<\/h3> Auf dieser Website sehen neue Besucher einen p75 TTFB von 127 ms, während wiederkehrende Besucher 138 ms sehen. Die Ähnlichkeit deutet darauf hin, dass ein konsistentes serverseitiges Caching (und nicht clientseitige Cache-Vorteile) der Hauptfaktor für die TTFB-Leistung ist. Auf Websites ohne serverseitiges Caching kann die Lücke zwischen neuen und wiederkehrenden Besuchern viel größer sein.<\/p> Der globale TTFB stagniert seit 5 Jahren<\/h3> Laut dem [url=https:\/\/almanac.httparchive.org\/en\/2025\/performance]2025 Web Almanac[\/url] erreichen weltweit nur 44 % der mobilen Seiten<\/strong> einen "guten" TTFB-Score. Diese Zahl hat sich gegenüber 41 % im Jahr 2021 kaum verändert, was den TTFB zur am stärksten stagnierenden Performance-Metrik im Web macht. In der Zwischenzeit verbesserte sich der LCP von 44 % auf 59 % und der INP von 55 % auf 74 % im gleichen Zeitraum. Websites mit schlechtem LCP verbringen durchschnittlich 2,27 Sekunden allein mit dem TTFB<\/strong>, fast den gesamten LCP-Schwellenwert von 2,5 Sekunden.<\/p> Häufig gestellte Fragen zu TTFB<\/h2> Was ist ein guter TTFB?<\/h3> Ein guter Time to First Byte liegt im 75. Perzentil bei 800 Millisekunden oder weniger. Das bedeutet, dass 75 % Ihrer Benutzer das erste Byte der Antwort innerhalb von 800 ms erhalten sollten. Ein TTFB zwischen 800 ms und 1.800 ms ist verbesserungswürdig, und ein TTFB über 1.800 ms gilt als schlecht. Beachten Sie, dass diese Schwellenwerte für den vollständigen Navigations-TTFB gelten, einschließlich DNS, TCP, TLS und Server-Verarbeitungszeit.<\/p> <\/div> <\/div> <\/div> Ist der TTFB ein Core Web Vital?<\/h3> Nein, der TTFB ist kein Core Web Vital. Die drei Core Web Vitals sind Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Der TTFB wird als Diagnosemetrik eingestuft. Er wird nicht direkt in den Ranking-Signalen von Google für die Seitenerfahrung verwendet, hat aber eine große indirekte Auswirkung, da ein langsamer TTFB sowohl LCP als auch FCP direkt erhöht. Die Optimierung des TTFB ist oft der schnellste Weg, um Ihre Core Web Vitals Scores zu verbessern.<\/p> <\/div> <\/div> <\/div> Wie reduziert ein CDN den TTFB?<\/h3> Ein CDN (Content Delivery Network) reduziert den TTFB auf verschiedene Weise. Erstens platziert es Server geografisch näher an Ihren Benutzern, was die Netzwerklatenz für DNS-Lookups, TCP-Verbindungen und TLS-Handshakes verringert. Zweitens kann ein CDN Ihre Seiten auf Edge-Servern zwischenspeichern, sodass die Antwort bereitgestellt werden kann, ohne überhaupt eine Verbindung zu Ihrem Ursprungsserver herzustellen. Drittens bieten CDNs in der Regel hochoptimierte Konfigurationen wie HTTP\/3, Brotli-Kompression und schnelle TLS-Aushandlung. CoreDash-Daten zeigen, dass Benutzer in der Nähe des Servers (Tschechien: 62 ms) einen drastisch niedrigeren TTFB erleben als weit entfernte Benutzer (Indien: 404 ms, China: 1.468 ms).<\/p> <\/div> <\/div> <\/div> Was ist der Unterschied zwischen TTFB und Serverantwortzeit?<\/h3> Die Serverantwortzeit misst nur die Zeit, die der Server für die Verarbeitung der Anfrage und die Generierung der Antwort benötigt. Der TTFB umfasst die Serverantwortzeit plus<\/em> den gesamten Netzwerk-Overhead: DNS-Auflösung, TCP-Verbindung, TLS-Handshake und die Netzwerk-Transitzeit sowohl für die Anfrage als auch für das erste Byte der Antwort. Eine Website kann eine schnelle Serverantwortzeit haben (gemessen über die Server-Timing-API), aber dennoch einen langsamen TTFB aufweisen, wenn der Benutzer weit vom Server entfernt ist oder sich in einem langsamen Netzwerk befindet. Bei der Fehlersuche nach TTFB-Problemen ist es wichtig, die Metrik in ihre Unterbereiche zu zerlegen, um festzustellen, ob das Problem server- oder netzwerkseitig liegt.<\/p> <\/div> <\/div> <\/div> Warum ist mein TTFB für einige Länder hoch?<\/h3> Der TTFB variiert je nach Land aufgrund der physischen Entfernung, der Qualität der Netzwerkinfrastruktur und des Internet-Routings. Jeder Unterbereich des TTFB (DNS, TCP, TLS, Serverantwort) wird durch die Roundtrip-Zeit zwischen dem Benutzer und dem Server beeinflusst. Ein Benutzer in Indien, der eine Verbindung zu einem Server in Deutschland herstellt, erlebt mehrere Roundtrips über Tausende von Kilometern, die jeweils Latenz hinzufügen. Länder mit weniger entwickelter Internetinfrastruktur oder restriktiven Firewalls (wie China) erleben einen noch höheren TTFB. Die Lösung besteht darin, ein CDN zu verwenden, das Ihre Inhalte auf Edge-Servern in der Nähe Ihrer Benutzer zwischenspeichert, oder Ihre Anwendung in mehreren Regionen bereitzustellen.<\/p> <\/div> <\/div> <\/div> <\/div> Verwandte Leitfäden: TTFB-Unterbereiche<\/h2> Jeder Unterbereich des Time to First Byte hat seine eigenen Optimierungsstrategien:<\/p> [url=\/core-web-vitals\/time-to-first-byte\/fix-and-identify]TTFB-Probleme identifizieren und beheben<\/b>[\/url]: Ein schrittweiser Diagnoseleitfaden zur Suche nach der Ursache für langsamen TTFB unter Verwendung von DevTools, Server-Timing und RUM-Daten.<\/li> [url=\/core-web-vitals\/time-to-first-byte\/waitingduration]Die Waiting Duration reduzieren<\/b>[\/url]: Wie Sie Redirect-Zeiten und Server-Verarbeitungsverzögerungen minimieren, die Ihren TTFB erhöhen.<\/li> [url=\/core-web-vitals\/time-to-first-byte\/cacheduration]Die Cache Duration reduzieren<\/b>[\/url]: Strategien für Browser-Caching, Service Worker und den Back-Forward-Cache (bfcache), um den TTFB für wiederkehrende Besucher zu eliminieren.<\/li> [url=\/core-web-vitals\/time-to-first-byte\/dnsduration]Die DNS Duration minimieren<\/b>[\/url]: So beschleunigen Sie die DNS-Auflösung mit schnelleren DNS-Anbietern, erhöhten TTL-Werten und dns-prefetch<\/code> Ressourcen-Hinweisen.<\/li> [url=\/core-web-vitals\/time-to-first-byte\/connectionduration]Die Verbindungsdauer optimieren (TCP + TLS)<\/b>[\/url]: Reduzierung der TCP- und TLS-Handshake-Zeit mit HTTP\/3, TLS 1.3, Session Resumption und preconnect<\/code> Hinweisen.<\/li> <\/ul> [include]cwv\/authorbio.html[\/include] <\/div> [include]sidebarcwv.html[\/include] <\/div> <\/div> <\/div> <\/section>[include]blogfooter.html[\/include]