TTFB senken: Was ein CDN wirklich bringt und was nicht

Was die TTFB überhaupt misst

TTFB steht für „Time to First Byte“, also die Zeit bis zum ersten Byte. Der Wert misst, wie lange es dauert, bis der Browser Ihres Kunden nach dem Klick das erste Datenbyte Ihrer Seite empfängt. Er beschreibt die Reaktionszeit Ihres Servers samt allem, was auf dem Weg dorthin passiert.

Der eine Wert, den Ihr Messwerkzeug ausgibt, ist in Wahrheit die Summe mehrerer, sehr unterschiedlicher Vorgänge:

1. Weiterleitungen – jede Redirect-Kette verlängert die Messung, bevor überhaupt etwas passiert.
2. DNS-Auflösung – die Domain wird in eine IP-Adresse übersetzt.
3. TCP-Verbindungsaufbau – der Handshake zwischen Browser und Server.
4. TLS-Handshake – der Aufbau der verschlüsselten Verbindung, in der Regel mit weiteren Roundtrips.
5. Server-Processing – PHP, Datenbankabfragen, Template-Rendering, externe API-Calls. Die eigentliche Arbeit Ihrer Applikation.
6. Übertragung des ersten Bytes zurück zum Browser.

Punkte 2 bis 4 und 6 sind Netzwerkanteile: Sie hängen von Distanz und Latenz ab. Punkt 5 ist Backend-Arbeit und hängt von Ihrem Shop, Ihrer Datenbank und Ihrer Serverkonfiguration ab. Diese Unterscheidung entscheidet darüber, ob ein CDN Ihnen hilft.

Als Orientierung gilt: Ein guter TTFB-Wert liegt bei 0,8 Sekunden oder weniger, schlecht sind Werte über 1,8 Sekunden. TTFB ist selbst kein Core-Web-Vitals-Messwert – aber sie steht Metriken wie First Contentful Paint und Largest Contentful Paint zeitlich voran, weshalb hohe TTFB-Werte alle nachfolgenden Messwerte verlängern. Eine TTFB von 900 Millisekunden macht einen guten LCP nahezu unmöglich, egal wie sauber Ihr Frontend gebaut ist.

Beispiel einer Performance-Analyse mit GTmetrix: Die Messwerte helfen dabei, Ladezeiten und mögliche Engpässe einzuordnen.

Die entscheidende Rechnung: Wie viel Zeit steckt wirklich im Netzwerk?

Diese Zahlen erklären den Nutzen eines CDN besser als jede Feature-Liste. Ihr Shop läuft auf einem Server in Deutschland. TCP- und TLS-Handshake benötigen zusammen rund drei bis vier Roundtrips:

• Besucher aus München: etwa 10 bis 15 Millisekunden pro Roundtrip, macht 40 bis 60 Millisekunden Netzwerkanteil.
• Besucher aus New York: 90 bis 110 Millisekunden pro Roundtrip, macht 300 bis 450 Millisekunden bevor Ihr Server eine Zeile Code ausgeführt hat.

Daraus folgt alles Weitere: Bei deutscher Kundschaft holt ein CDN bestenfalls 30 bis 40 Millisekunden aus der TTFB, bei internationalem Traffic mehrere hundert. Liegt Ihre TTFB bei 1,2 Sekunden und Ihre Kunden sitzen in der DACH-Region, stecken über 90 Prozent dieser Zeit im Backend und dort ändert ein CDN nichts.

Was ein CDN wirklich bringt

Ein CDN verteilt Inhalte auf Server-Standorte in der Nähe Ihrer Besucher. Häufig angefragte Inhalte werden im Cache gespeichert und direkt vom nächstgelegenen Standort ausgeliefert für schnellere Ladezeiten weltweit, bei gleichzeitiger Entlastung der Hosting-Server. Konkret wirkt das auf:

• Kürzere Handshakes: TCP- und TLS-Verbindung entstehen am nächstgelegenen Edge-Standort statt über die volle Distanz. Bei internationalen Zugriffen der größte Einzelhebel, siehe Rechnung oben.
• Auslieferung statischer Inhalte: Bilder, CSS, JavaScript und Fonts kommen vom Edge. Das verkürzt nicht die TTFB des HTML-Dokuments, aber Gesamtladezeit und LCP deutlich.
• Full-Page-Caching für anonyme Besucher: Liegen Kategorie- und Produktseiten komplett am Edge, entfällt der Backend-Anteil vollständig die TTFB fällt von mehreren hundert Millisekunden auf wenige Dutzend.
• Origin-Entlastung und Peak-Stabilität: Jede Anfrage, die der Edge beantwortet, erreicht Ihren Server nie. Das zählt bei Sale-Aktionen, Newsletter-Versand und Black Friday: Was bei 200 Besuchern pro Stunde läuft, kollabiert bei 2.000.
• Sicherheit: SSL-Verschlüsselung und stabile Infrastruktur halten Projekte geschützt und wartungsarm.

Was ein CDN nicht bringt 

Hier entscheidet sich, ob Ihr Investment Wirkung zeigt. 

• Es macht Ihr Backend nicht schneller. Braucht Ihre Kategorieseite 700 Millisekunden PHP-Zeit, weil eine Datenbankabfrage ohne Index läuft, braucht sie diese 700 Millisekunden auch mit CDN bei jedem Cache-Miss. Der Edge kann weiterleiten, nicht rechnen. 
• Es hilft nicht bei personalisierten Seiten. Warenkorb, Checkout, Kundenkonto, eingeloggte B2B-Preise: Diese Antworten unterscheiden sich pro Nutzer und sind damit nicht cachebar. Genau dort ist Ihr Shop am langsamsten. 
• Es rettet keine schlechte Cache-Konfiguration. Falsch gesetzte Cache-Control-Header, Session-Cookies auf jeder Anfrage oder zu viele Cache-Varianten drücken die Trefferquote gegen null. Das Netzwerk steht, der Nutzen bleibt aus. 
• Es löst keine Redirect-Ketten auf. Ein CDN liefert Weiterleitungen zwar am Edge aus und macht sie dadurch schneller, aber drei aufeinanderfolgende Redirects bleiben drei Roundtrips. Auflösen schlägt beschleunigen. 

Und der Checkout? Was für dynamische Seiten wirklich hilft

Dass ein CDN bei personalisierten Seiten nicht greift, heißt nicht, dass dort nichts zu holen ist. Drei Ansätze für dynamische Inhalte:

• Fragment-Caching (ESI). Die Seite wird in Bausteine zerlegt: Header, Navigation und Produktdaten kommen aus dem Cache, nur der Warenkorb wird pro Nutzer generiert. Der Backend-Anteil sinkt erheblich, ohne dass die Personalisierung leidet.
• stale-while-revalidate. Der Edge liefert eine leicht veraltete Version sofort aus und aktualisiert im Hintergrund. Für Kategorieseiten mit wechselnden Beständen ein wirksamer Kompromiss.
• Early Hints (HTTP 103). Der Server nennt dem Browser kritische Ressourcen, während er die Antwort noch berechnet. Die TTFB bleibt gleich, aber der Browser lädt bereits CSS und Fonts auf LCP und wahrgenommene Geschwindigkeit wirkt das spürbar.

Die häufigsten echten TTFB-Bremsen im Shop

In der Praxis liegt hier der Großteil der verlorenen Zeit meist in der Datenbank. Fehlende Indizes, teure Joins und zu viele Einzelabfragen pro Seitenaufruf sind der häufigste Einzelbefund. Ein Redis Object-Cache entlastet die Datenbank spürbar; bei größeren Katalogen ist zusätzlich eine Volltextsuche über Elasticsearch statt über die Datenbank ein deutlicher Sprung.

Danach kommen die üblichen Verdächtigen: synchron eingebundene externe API-Calls (ERP, Lagerbestände, Bewertungs-Widgets), bei denen Ihr Server auf fremde Systeme wartet. Plugins und Extensions, die nach jedem Update neu geprüft gehören. Eine veraltete PHP-Version oder ein fehlender OPcache ein Versionssprung bringt oft zweistellige Prozentgewinne ohne eine Zeile Codeänderung. Und schlicht unterdimensionierte Ressourcen: RAM, CPU und I/O müssen zu Katalog und Traffic passen.

Ihr Vorgehen in fünf Schritten

1. Prüfen Sie zunächst, wo die Ladezeit entsteht. Mit curl können Sie erkennen, wie viel Zeit für Verbindung, TLS und Backend benötigt wird. Ist die Backend-Zeit besonders hoch, liegt die Ursache wahrscheinlich nicht beim CDN.
2. Erheben Sie Feldwerte, nicht nur Laborwerte. Ein Testlauf aus Frankfurt sagt wenig darüber, was Ihre Kunden erleben. Nutzen Sie CrUX-Daten über PageSpeed Insights oder ein RUM-Monitoring.
3. Schlüsseln Sie nach Seitentyp auf. Startseite, Kategorie, Produktdetail, Warenkorb, Checkout die Werte unterscheiden sich meist erheblich, und die Maßnahmen ebenso.
4. Profilen Sie das Backend. Mit einem PHP-Profiling-Werkzeug wie Tideways sehen Sie, welche Funktion und welche Abfrage die Zeit verbraucht statt zu raten. Prüfen Sie parallel, welcher Anteil Ihrer Seitenaufrufe auf anonyme Besucher entfällt: Das ist Ihr realistisches CDN-Potenzial für die HTML-TTFB.
5. Erst dann entscheiden und einzeln umsetzen. Backend-Problem zuerst lösen, dann das CDN aufsetzen. Wer beides in derselben Woche deployt, weiß hinterher nicht, was gewirkt hat.

Kurz zusammengefasst: Wann lohnt sich ein CDN?

Ein CDN ist der richtige nächste Schritt, wenn Sie international verkaufen, Ihr Shop medienlastig ist, ein großer Teil Ihres Traffics auf cachebare Seiten für anonyme Besucher entfällt, oder wenn Sie Lastspitzen abfedern und Ihren Origin entlasten wollen.

Es ist nicht Ihr erster Schritt, wenn Ihre Zielgruppe rein regional ist, Ihre Backend-Zeiten hoch sind und Ihre kritischen Seiten überwiegend personalisiert ausgeliefert werden. Dann bringen Datenbank-Optimierung, Object-Caching und passende Ressourcen deutlich mehr.

Managed CDN von profihost

Ein CDN wirkt nur so gut, wie es konfiguriert ist. Genau hier setzt unser Managed CDN an: Wir richten es passend zu Ihrer Shop-Architektur ein, definieren die Caching-Regeln gemeinsam mit Ihnen und stimmen sie auf Ihre personalisierten Bereiche ab damit Warenkorb und Checkout korrekt funktionieren und cachebare Seiten tatsächlich vom Edge kommen.

Websites und Shops laden schneller, was Conversion und Einkaufserlebnis verbessert. Die optimierte Performance wirkt sich zudem positiv auf Rankings und Sichtbarkeit aus.

Weil ein CDN selten allein die Antwort ist, betrachten wir es als einen Baustein von mehreren: Redis Caching zur Entlastung Ihrer Datenbank, Elasticsearch für eine performante Volltextsuche, Tideways PHP-Profiling für die gezielte Suche nach Engpässen im Code. Welche Kombination in Ihrem Projekt sinnvoll ist, klären wir vorher anhand Ihrer Messwerte, nicht anhand einer Produktliste.

Mehr zum Managed CDN