7 Tipps zur Optimierung der Time To First Byte (TTFB)

Die “Time to First Byte” (kurz: TTFB oder auch First Byte Time genannt), ist einer der ersten Werte, die sich auf dem Weg zur vollständig geladenen Webseite messen lässt und stellt die Server-Antwortzeit dar, die für die DNS-, Socket- und SSL-Verhandlungen (Handshakes) benötigt wird. Wir stellen nachfolgend 7 Tipps zur Optimierung der Time to First Byte (TTFB) vor und gehen auch auf die Bedeutung der TTFB ein.

Was ist die Time To First Byte (TTFB)?

Die TTFB beschreibt den Zeitraum, ab der Anfrage einer Webseite vom Browser aus bis zur Beantwortung mit dem ersten Byte der empfangenen Daten vom Webserver. Während dieses Zeitraums finden folgende Vorgänge statt:

  – DNS-Lookup: Ermittlung der IP-Adresse des Webservers durch Auflösung der Domain
  – SSL-Handshake: Herstellung der verschlüsselten Verbindung
  – Webserver-Processing: Verarbeitung der Anfrage durch den Webserver
  – TCP-Answer: Versand des ersten Datenpakets über das TCP-Protokoll

Dies geschieht in der Regel in deutlich unter einer Sekunde. Normale TTFB-Werte liegen zwischen 200 und 400 Millisekunden. Google PageSpeed Insights empfiehlt eine Antwortzeit des Servers unter 200 ms (Stand 2019) und es ist durchaus möglich auch auf unter 100 ms zu kommen. Fällt die TTFB höher als 400 ms aus, kann dies verschiedene Ursachen haben. Beispielsweise:

  – Hohe Latenzen zwischen den DNS-Servern
  – Hohe Auslastung des Webservers
  – Probleme in der Infrastruktur des Webservers (Hard-/Software)

Hohe Latenzen können auftreten, wenn die Distanz zwischen dem Standort des Nutzers und der DNS-Server zur Auflösung des Domainnamens bzw. dem Server entstehen. Relevant sollte für die Wahl des Rechenzentrums/Hosters der Standort der Zielgruppe der Webseite sein.

Wichtig hierbei ist das korrekte Verständnis des Begriffs “Latenz”: Sie beschreibt den Weg, den ein Datenpaket vom Webserver bis zum Nutzer (Rechner, Smartphone etc.) zurücklegt. Da bei der TTFB nur die Ankunft des ersten Bytes gemessen wird, ist die Bandbreite – also wie viele Datenpakete auf diesem Weg übertragen werden können – unbedeutend für die Messung.

Ist die Betrachtung der TTFB sinnvoll?

Die TTFB ist in unseren Augen heutzutage kein alleinig relevanter Kennwert mehr, da die Aussagekraft sehr begrenzt ist. Der CDN-Anbieter Cloudflare hat bereits 2012 ein Beispiel gebracht, in dem eine langsamere TTFB nicht zu einer langsameren Pageload führt, wenn die nachgelagerten Prozesse wie z.B. Komprimierung fehlen: Cloudflare-Blog

Dennoch ist die TTFB eine der ersten Aktionen beim Aufruf einer Webseite und Grundlage aller nachfolgenden Aktionen und somit auch von nachgelagerten Tests und Auswertungen für den Pagespeed wie z.B. den
  – “First Contentful Paint” (FCP): Der Zeitpunkt, zu dem im Browser zum ersten Mal ein Darstellungselement angezeigt wird.
  – “First Meaningful Paint” (FMP): Der Zeitpunkt, zu dem der Nutzer das Gefühl hat, dass die Webseite geladen ist.
  – “Time to Interactive” (TTI): Der Zeitpunkt, zu dem die Webseite fertig gerendert und bereit zur Nutzereingabe (=Interaktion) ist.
  – Google aktualisiert immer mal wieder seine Auswertungen und Kriterien. In 2020 werden Nutzern des Pagespeed-Tests bzw. des sog. Core-Web-Vitals-Bericht auch die Begriffe “Largest Contentful Paint” (LCP), “First Input Delay” (FID sowie “Cumulative Layout Shift” CLS begegnen. Kommen wir aber nun zu den eigentlichen Tipps zur Optimierung der Time To First Byte.

7 Tipps zur Optimierung der Time to First Byte (TTFB)

1) Lokalen DNS-Server ändern

Eine kürzere Verbindungszeit kann erreicht werden, indem man die Auflösungszeit des Domainnamens beschleunigt. Für sich selbst kann man dafür den DNS-Server ändern, den der Rechner lokal verwendet. Standardmäßig wird dazu nämlich einer in der Infrastruktur deines Internetanbieters genutzt. Die Änderung kann im Betriebssystem des Endgeräts (Rechner, Smartphone etc.) erfolgen oder – sofern unterstützt – direkt im Router, damit alle Geräte im Netzwerk automatisch von der Änderung profitieren.

Beliebt, weil laut eigenen Angaben besonders schnell und optimiert, sind dafür die IPs der DNS-Server von Google mit der IP-Adresse “8.8.8.8” (IPv4) bzw. “2001:4860:4860::8888” (IPv6) oder auch die “1.1.1.1” (IPv4) bzw. “2606:4700:4700::1111” (IPv6) von Cloudflare.

2) Rechenzentrum ändern oder CDN nutzen

Wie eingangs erwähnt, ist der Standort der Zielgruppe der Webseite relevant. Bei einem Blog, der Wanderrouten in deutscher Sprache in Bayern vorstellt und dessen Zielgruppe der DACH-Raum ist, macht z.B. ein Webhoster Sinn, der auch ein Rechenzentrum in Bayern betreibt.

Bei einem Webshop, der weltweit verkauft und liefert, sollte der Webhoster bzw. das Rechenzentrum, in dem der Server steht, eine gute Anbindung an einen zentralen Knotenpunkt wie etwas Frankfurt haben. Zusätzlich kann über ein sog. “Content Delivery Network” (CDN) nachgedacht werden. Ein solches Netzwerk hält in Caching-Systemen eine aktuell Kopie der Webseite auf Servern in geographischer Nähe zum Nutzer vor. Das kann die Latenz deutlich verkürzen.

Die meisten CDN bieten auch Funktionen an, mit denen dynamisch generierte Inhalte schneller abrufbar sind, dank optimierter Routen innerhalb des CDN. Webseiten aus Deutschland, Österreich oder der Schweiz mit Nutzern primär im genannten DACH-Raum profitieren allerdings nicht grundsätzlich vom Einsatz eines global ausgelegten CDN. Bekannte Anbieter sind z.B. Akamai Technologies, Amazon CloudFront, Cloudflare, Google Cloud CDN, KeyCDN oder MaxCDN

3) TLS und SSL-Handshake optimieren

Sobald die Anfrage über https erfolgt – und das sollte sie – dann findet ein sog. SSL-Handshake statt, nach dem dann die verschlüsselte Verbindung aufgebaut wird.

Auch die Latenz zwischen den einzelnen Handshake-Schritten kann optimiert werden. Die verfügbaren SSL-Protokoll (TLS 1.3, 1.2, 1.1), die genutzten SSL-Ciphern und deren Reihenfolge, SSL-Caching usw. nehmen Einfluss. Für die Optimierung gilt, man sollte die jeweils neuesten bzw. empfohlenen Standards nutzen und diese bevorzugt vom Webserver anbieten / ausliefern lassen:

  – Aktuelles TLS/SSL-Protokoll
  – Aktuelle SSL Cipher-Suite
  – SSL Session-Cache nutzen (TLS resumption); für wiederkehrende Verbindungen
  – OCSP Stapling nutzen; spart zusätzliche Abfragen, um zu überprüfen, ob das Zertifikat gültig ist
  – HTTP Strict Transport Security inkl. Preload (HSTS)
  – Kurze Zertifikatskette (Certificate-Chain); idealerweise 3 Zertifikate lang: Zertifikat, Intermediate- und CA-Root-Zertifikat) Wenn ein Element in der Kette fehlt, versuchen einige Browser, das Fehlende selbst zu suchen, was zusätzliche Abfragen benötigt

Bei der Cipher-Suite und der Kombination mit dem jeweiligen TLS-Protokoll sollte die für dich am besten passende Konfiguration genutzt werden. Da sich die Technologien stetig weiterentwickeln, sollte eine regelmäßige Kontrolle und Abwägung erfolgen. Empfohlene und aktualisierte Konfigurationen stellt z.B. Mozilla bereit: Mozilla-TLS-Seite

So sind AES Ciphern schneller als RC4, DES oder Camellia. Allerdings ist es für die modernen AES wichtig, dass die CPU des Servers die sog. AES-NI Anweisungen unterstützt. Dies sind im Serverbereich nahezu alle aktuellen CPUs, die nach 2010 hergestellt wurden. Für den Austausch-Mechanismus der Schlüssel sollte AES mit ECDHE and DHE genutzt werden.

Die genannten Punkte können alle über die Webseite von SSLLabs geprüft werden.

Ist der Handshake erfolgreich abgeschlossen übernimmt die Webserver-Software anschließend die Verarbeitung der Anfrage. Die Performance dieser Software und die Auslastung der Server-Hardware sind dabei für die benötigte Zeit zur Verarbeitung ausschlaggebend was uns direkt zum nächsten Punkt bringt.

4) Hosting-Details prüfen (OS, Web-, Datenbankserver)

Ein Flaschenhals in der IT-Infrastruktur des Rechenzentrums oder ein zu schwach ausgestatteter Tarif kann ein Grund für eine niedrige TTFB sein. So sind sehr günstige Tarife oft auf vollgestopften Servern und es kann je nach Tageszeit zu stark schwankenden TTFB-Werten kommen. Da die Ursachen vielfältig sind / sein können, ist eine pauschale Aussage über den Grund nicht möglich.

Im Allgemeinen gilt auch für die Software auf Servern, dass eine aktuellere Version des Betriebssystems, des Webserver- und des Datenbank-Servers nicht nur die Performance verbessern kann, sondern auch die Sicherheit durch behobene Bugs und geschlossene Sicherheitslücken.

Ebenso kann sich auch ein kompletter Wechsel der Webserver-Software (z.B. Nginx) positiv auf die TTFB auswirken.

Da meist schon bei der ersten Anfrage auf der Seite eine Datenbankverbindung aufgebaut wird und das (nach-)laden zusätzlicher Skripte gestartet wird, ist auch ein passender/optimierter Datenbankserver relevant. So profitieren u.a. viele CMS und Shops, die mit MySQL arbeiten, von einem der existierenden sog. Forks, die eigene Optimierungen eingebracht und MySQL optimiert und an modernere Anforderungen angepasst haben. Beispiele dafür sind MariaDB, Percona oder Amazon Aurora.

5) Serverhardware verbessern

Ein Wechsel auf einen Tarif mit mehr RAM und weniger Kunden kann nicht nur bei der Verringerung der TTFB helfen, sondern generell auch im weiteren Verlauf beim Laden der Inhalte und der Performance bei vielen Besuchern/Kunden.

Ein Upgrade auf einen virtuellen Server, Cloud-Server u.ä. mit stärkerer / reservierter CPU bzw. generell zugesicherter Hardware kann ebenfalls hilfreich sein. Ob die Mehrkosten die Verbesserung rechtfertigen, ist selbstverständlich eine individuelle Überlegung. Besitzt man bereits einen Server, kann nach einigen Jahren ein Tarifwechsel in eine neuere Tarif-Generation – die im besten Fall dann auch neuere Hardware besitzt – dennoch für einen geringen Aufpreis sinnvoll sein.

6) IPv6 und AAAA-Record standardmäßig nutzen

Verbindungen über IPv6 sind grundsätzlich schneller als IPv4. Problematisch kann es werden, wenn der Server kein IPv6 unterstützt. Im Regelfall erfolgt die Anfrage aus dem Browser über die Internetverbindung heutzutage bereits per IPv6; kann nun der angefragte Server dies nicht, erfolgt ein Fallback auf IPv4, was eine erneute Anfrage zwischen den beteiligten Stellen auslöst.

V.a. bei einem Setup – wie etwa wenn die Domain bei Hoster A liegt und die Webseite bei Hoster B läuft – müssen die Nameserver des Hosters A IPv6 unterstützen (praktisch Standard) und der Server bei Hoster B ebenfalls. In diesem Fall muss natürlich die IP-Weiterleitung der Domain von A auf B per AAAA-Record erfolgen (für IPv6) und nicht nur per A-Record für IPv4.

7) HTTP/2 oder Keep-Alive nutzen

Für die TTFB zwar nur bedingt relevant, dennoch finden wir dies an dieser Stelle noch erwähnenswert:

HTTP/2 verwenden: Der aktuelle Standard des HTTP-Protokolls hat zahlreiche neue Funktionen wie Server Push, paralleles Laden von Seitenelementen über eine einzelne Verbindung, Header-Komprimierung etc.

Ist nur das ältere Protokoll HTTP/1.1 verfügbar, so sollte Keep-Alive aktiviert sein.

Zusammenfassung

Alle aufgezählten Punkte tragen zur Optimierung der Time To First Byte (TTFB) bei, sind jedoch nicht allein für die schnelle Auslieferung einer Webseite verantwortlich:

  – Lokal: DNS-Server für Namensauflösung ändern
  – Rechenzentrum-Standort ändern oder CDN nutzen
  – SSL-Handshake optimieren
  – Hosting-OS, Web-, Datenbankserver prüfen
  – Serverhardware mit mehr RAM und CPU verbessern
  – IPv6 und AAA-Record nutzen
  – HTTP/2 oder Keep-Alive nutzen

Auf den einzelnen Wert der TTFB sollte in unseren Augen allerdings nicht zu viel Wert gelegt werden, da dieser sehr abstrakt ist.

Wichtiger sollte der “First Meaningful Paint” (FMP) sein: Also der Zeitpunkt, zu dem der Nutzer das Gefühl hat, dass die Webseite geladen ist – selbst wenn Details noch nachgeladen werden. Dieses “Gefühl” ist sicherlich subjektiv und unterscheidet sich für Nutzer eines Informations-Blogs sicher von denen eines Webshops.

Habt ihr weitere Tipps für die Optimierung der TTFB, Anregungen oder Fragen? Wir freuen uns über einen Kommentar.