Wenn eine Website träge wirkt, liegt die Ursache oft nicht im Design oder in zu großen Bildern, sondern weit früher in der Kette: Der Server lässt sich schlicht Zeit, überhaupt zu antworten. Genau diese Verzögerung beschreibt die Kennzahl TTFB, die Time to First Byte. Sie misst, wie lange es dauert, bis der Browser nach dem Absenden einer Anfrage das erste Byte der Antwort empfängt. Wer die TTFB versteht und gezielt senkt, verbessert nicht nur das gefühlte Tempo, sondern oft auch messbare Werte wie den Largest Contentful Paint. In diesem Ratgeber gehe ich durch, was die TTFB wirklich misst, welche Faktoren sie nach oben treiben und mit welchen Maßnahmen sich die Server-Antwortzeit zuverlässig reduzieren lässt.
Was die TTFB eigentlich misst
Die Time to First Byte setzt sich aus mehreren Teilstrecken zusammen. Zunächst muss der Browser den Domainnamen auflösen, eine Verbindung aufbauen und bei HTTPS die Verschlüsselung aushandeln. Erst danach schickt er die eigentliche Anfrage los, und der Server beginnt, sie zu verarbeiten. Die TTFB umfasst also nicht nur die reine Rechenzeit auf dem Server, sondern auch Netzwerklatenz und Verbindungsaufbau. In den meisten Analyse-Werkzeugen wird die TTFB jedoch stark vom Anteil der serverseitigen Verarbeitung geprägt, weil sich Caching und Programmlogik dort am deutlichsten auswirken.
Wichtig ist die Abgrenzung zu anderen Begriffen. Die TTFB sagt nichts darüber aus, wann eine Seite vollständig dargestellt ist oder wann der Nutzer den ersten Inhalt sieht. Sie ist eher der Startschuss: Solange das erste Byte nicht da ist, kann der Browser mit dem Aufbau der Seite gar nicht beginnen.
Wie TTFB und LCP zusammenhängen
Der Largest Contentful Paint, also der Zeitpunkt, an dem das größte sichtbare Element geladen ist, gehört zu den Core Web Vitals und beeinflusst sowohl die Nutzererfahrung als auch das Ranking. Die TTFB ist dabei ein Vorbote: Sie bildet einen festen Sockel im LCP. Braucht der Server eine Sekunde, bis er antwortet, kann der LCP rein rechnerisch nicht schneller als diese Sekunde sein, egal wie schlank das restliche Frontend ist.
Deshalb lohnt es sich, bei LCP-Problemen zuerst die TTFB zu prüfen. Liegt sie hoch, ist eine Optimierung von Bildern oder Schriften zwar weiterhin sinnvoll, der größte Hebel sitzt aber im Backend. Umgekehrt bringt eine perfekte TTFB wenig, wenn das Frontend anschließend durch riesige Mediendateien gebremst wird. Beide Ebenen wirken zusammen.
Die wichtigsten Einflussfaktoren
Eine hohe Server-Antwortzeit hat selten nur eine Ursache. In der Praxis spielen vor allem diese Faktoren zusammen:
- Serverleistung und Hosting-Typ: Geteilte Billig-Pakete teilen sich Rechenleistung mit vielen anderen Seiten. Unter Last kann die Antwort spürbar verzögert werden.
- Datenbankabfragen: Komplexe oder unoptimierte Abfragen ohne passende Indizes blockieren die Verarbeitung, besonders bei dynamischen Seiten und großen Datenmengen.
- Geografische Distanz: Je weiter der Nutzer vom Server entfernt ist, desto mehr Latenz entsteht durch die reine Signallaufzeit im Netz.
- Fehlendes Caching: Ohne Zwischenspeicher berechnet der Server bei jedem Aufruf dieselbe Seite neu, statt ein fertiges Ergebnis auszuliefern.
- Anwendungslogik und Plugins: Viele aktive Erweiterungen, externe API-Aufrufe während des Seitenaufbaus oder ineffizienter Code summieren sich zu Wartezeit.
Einflussfaktoren, Ursachen und Gegenmaßnahmen im Überblick
Die folgende Tabelle ordnet die typischen Ursachen einer hohen TTFB den passenden Gegenmaßnahmen zu. Sie eignet sich als schnelle Checkliste, um den eigenen Fall einzugrenzen.
| Einflussfaktor | Typische Ursache | Passende Gegenmaßnahme |
|---|---|---|
| Serverleistung | Überbuchtes Shared Hosting, zu wenig Arbeitsspeicher | Auf leistungsfähigeres Hosting oder dedizierte Ressourcen wechseln |
| Datenbank | Fehlende Indizes, langsame oder verschachtelte Abfragen | Indizes setzen, Abfragen optimieren, Object-Cache nutzen |
| Distanz zum Nutzer | Einziger Serverstandort weit entfernt vom Publikum | CDN einsetzen, Serverstandort näher an die Zielgruppe legen |
| Fehlendes Caching | Jede Seite wird bei jedem Aufruf neu erzeugt | Page-Cache und Server-Cache aktivieren |
| Anwendungslogik | Viele Plugins, externe API-Aufrufe im Seitenaufbau | Code verschlanken, externe Aufrufe asynchron auslagern |
| Verbindungsaufbau | Veraltete Protokolle, langsamer TLS-Handshake | HTTP/2 oder HTTP/3 aktivieren, Verbindungen wiederverwenden |
Caching: der größte Hebel
Caching ist in den meisten Fällen die wirkungsvollste und zugleich einfachste Maßnahme. Die Idee ist denkbar simpel: Statt eine Seite bei jedem Besuch neu aus Datenbank und Programmcode zusammenzusetzen, wird das fertige Ergebnis zwischengespeichert und beim nächsten Aufruf direkt ausgeliefert. Die wiederholte Berechnung entfällt, die Antwortzeit sinkt oft drastisch.
In der Praxis gibt es mehrere Ebenen, die sich kombinieren lassen:
- Page-Cache: Speichert ganze HTML-Seiten als statische Dateien. Ideal für Inhalte, die sich nicht bei jedem Aufruf ändern.
- Object-Cache: Hält Ergebnisse einzelner Datenbankabfragen im Arbeitsspeicher, etwa über Redis oder Memcached.
- Opcode-Cache: Speichert kompilierten Programmcode, sodass Skripte nicht bei jeder Anfrage neu übersetzt werden.
Bei dynamischen Inhalten, etwa eingeloggten Nutzern oder Warenkörben, muss man genauer steuern, was zwischengespeichert wird. Eine durchdachte Cache-Strategie unterscheidet hier zwischen öffentlichen und personalisierten Bereichen.
CDN: Inhalte näher an die Nutzer bringen
Ein Content Delivery Network ist ein Netz aus Servern an vielen Standorten weltweit. Statt jede Anfrage zum Ursprungsserver zu schicken, wird sie vom nächstgelegenen Knoten beantwortet. Das reduziert die Latenz durch die geografische Distanz und kann gerade für internationale Zielgruppen einen spürbaren Unterschied machen.
Moderne CDNs liefern nicht nur statische Dateien wie Bilder und Skripte aus, sondern können über Edge-Caching auch ganze HTML-Antworten an den Rand des Netzes verlagern. Damit antwortet praktisch ein Server in der Nähe des Nutzers, was die TTFB für weit entfernte Besucher deutlich senkt. Wer überwiegend regionales Publikum hat, profitiert weniger stark, sollte den Serverstandort aber dennoch nah an der Zielgruppe wählen.
Hosting und Datenbank optimieren
Wenn Caching ausgereizt ist und die TTFB weiterhin hoch bleibt, lohnt der Blick auf die Grundlagen. Ein leistungsfähigeres Hosting mit schnellen SSD- oder NVMe-Speichern, aktueller PHP- oder Laufzeitversion und ausreichend Arbeitsspeicher bildet das Fundament. Aktuelle Sprachversionen sind oft messbar schneller als ältere, allein der Versionssprung kann die Verarbeitung beschleunigen.
Auf Datenbankseite helfen mehrere Hebel: passende Indizes für häufige Abfragen, das Vermeiden von Abfragen in Schleifen sowie das regelmäßige Aufräumen von Altlasten. Auch hier gilt: Eine Abfrage, deren Ergebnis sich selten ändert, gehört in den Cache statt bei jedem Aufruf neu ausgeführt.
Welche TTFB-Werte sind gut?
Eine exakte Grenze gibt es nicht, aber eine grobe Orientierung hilft bei der Einordnung. Gute TTFB-Werte liegen in der Regel deutlich unter einer halben Sekunde, viele gut optimierte Seiten erreichen Werte im niedrigen dreistelligen Millisekundenbereich. Werte um eine Sekunde oder darüber gelten als verbesserungswürdig und bremsen den weiteren Seitenaufbau spürbar.
Wichtig ist, realistisch zu messen: idealerweise aus der Region der echten Nutzer und über mehrere Aufrufe hinweg, da der erste, ungecachte Aufruf langsamer ausfällt. Werkzeuge zur Performance-Analyse zeigen die TTFB getrennt aus, sodass sich Fortschritte nach jeder Maßnahme nachverfolgen lassen. Für kleinere Berechnungen rund um Ladezeiten und Datenmengen finden sich praktische Helfer in den Webtools, und weitere Beiträge zu Hosting und Performance gibt es in den News.
Häufige Fragen
Was ist ein guter TTFB-Wert?
Als gut gilt meist ein Wert deutlich unter einer halben Sekunde. Gut optimierte Seiten erreichen oft den niedrigen dreistelligen Millisekundenbereich. Werte ab etwa einer Sekunde sollte man genauer untersuchen, da sie den gesamten Seitenaufbau verzögern.
Beeinflusst die TTFB das Google-Ranking?
Direkt ist die TTFB keine eigene Ranking-Kennzahl, aber sie wirkt indirekt: Sie bildet einen Sockel im Largest Contentful Paint, der zu den Core Web Vitals zählt. Eine hohe TTFB macht gute LCP-Werte praktisch unmöglich und kann dadurch das Ranking beeinträchtigen.
Hilft ein CDN immer gegen eine hohe TTFB?
Ein CDN senkt vor allem die Latenz durch geografische Distanz und hilft besonders bei internationalem Publikum. Liegt die Ursache dagegen in langsamer Anwendungslogik oder unoptimierten Datenbankabfragen, löst das CDN allein das Problem nicht. Dann sind Caching und Backend-Optimierung wichtiger.
Was bringt mehr: Caching oder besseres Hosting?
In den meisten Fällen ist Caching der erste und wirkungsvollste Schritt, weil es wiederholte Berechnungen vermeidet und sich oft ohne Umzug umsetzen lässt. Besseres Hosting lohnt sich, wenn das Caching bereits ausgereizt ist und die Grundleistung des Servers begrenzt.
Warum ist meine TTFB beim ersten Aufruf höher?
Beim ersten Aufruf ist der Cache oft noch leer, sodass die Seite vollständig neu berechnet werden muss. Folgende Aufrufe greifen auf die zwischengespeicherte Version zu und sind deutlich schneller. Für eine faire Bewertung sollte man daher über mehrere Aufrufe messen.
Spielt die PHP- oder Laufzeitversion eine Rolle?
Ja, deutlich. Aktuelle Sprachversionen arbeiten in der Regel effizienter als ältere und können die serverseitige Verarbeitung allein durch das Update beschleunigen. Ein Versionswechsel ist deshalb eine der einfachsten Maßnahmen mit oft spürbarem Effekt.