TTFB-Optimierung: Server-Antwortzeit auf unter 200 ms senken
Ein hoher Time to First Byte verzögert alles Weitere — LCP, FCP, INP. Wir analysieren Ihre gesamte Auslieferungskette vom Hosting bis zur Datenbankabfrage und senken die Server-Antwortzeit auf ein Niveau, das Google als exzellent einstuft.
< 2,5s
Ziel-LCP
94ms
medianer TTFB nach Optimierung (Projekterfahrung)
78%
typische TTFB-Reduktion im ersten Schritt (Projekterfahrung)
50+
TTFB-Projekte abgeschlossen
Die Time to First Byte (TTFB) misst die Zeitspanne vom Absenden der HTTP-Anfrage bis zum Eintreffen des ersten Antwort-Bytes im Browser. Google empfiehlt Werte unter 800 Millisekunden als akzeptabel und unter 200 Millisekunden als exzellent (web.dev, 2024). Ein hoher TTFB ist keine Kleinigkeit: Er verzögert den Largest Contentful Paint, reduziert die Crawling-Effizienz von Suchmaschinen und beeinträchtigt das Nutzererlebnis spürbar — besonders auf mobilen Verbindungen. Wir betrachten TTFB als eigenständige Disziplin und behandeln alle Ursachen systematisch: Hosting-Infrastruktur, PHP-Laufzeitumgebung, Caching-Architektur, Datenbankabfragen und den Render-Pfad der Anwendung.
Einstieg in die TTFB-Optimierung
- Messung der Server-Antwortzeit auf mehreren Seitentypen
- Priorisierter Maßnahmenplan mit erwartetem TTFB-Hebel
- Klare Empfehlung: Konfiguration optimieren oder Hosting wechseln
- Optionales Core-Web-Vitals-Monitoring ab 59 € pro Monat netto
Kostenlose Ersteinschätzung zum Einstieg: Sie schildern Ihr System, wir prüfen Ihren aktuellen TTFB und nennen die größten Hebel — unverbindlich. Der Performance-Quick-Check (ab 349 € netto) liefert anschließend einen dokumentierten Kurzbericht, der Full-Performance-Audit (ab 1.490 € netto) die vollständige Analyse mehrerer Seitentypen.
Was die Time to First Byte beeinflusst
Der TTFB ist kein einzelner Wert, sondern die Summe mehrerer Teilzeiten. Jede Station auf dem Weg vom Browser zum Server und zurück trägt dazu bei. Nur wer alle Stationen kennt und misst, kann gezielt dort eingreifen, wo der größte Hebel sitzt. In unseren Analyse-Projekten messen wir TTFB mit synthetischen Tests von mehreren Standorten und unterscheiden dabei konsequent zwischen Netzwerklatenz, Protokoll-Overhead und tatsächlicher Server-Verarbeitungszeit. Letztere ist in der Regel der einzige Teil, den eine Optimierung direkt beeinflussen kann.
Netzwerklatenz und DNS
Die DNS-Auflösung und die physische Distanz zwischen Nutzer und Server erzeugen eine unvermeidliche Grundlatenz. Wir minimieren sie durch schnelle DNS-Provider mit Anycast-Netzwerken, niedrige TTL-Werte für dynamische Records und CDN-Integration für statische Inhalte.
TLS-Handshake-Overhead
TLS 1.2 benötigt zwei Roundtrips für den Verbindungsaufbau, TLS 1.3 reduziert dies auf einen. Mit Session Tickets und 0-RTT-Wiederverbindungen sinkt der TLS-Overhead bei Folgebesuchen auf nahezu null. OCSP Stapling verhindert zusätzliche Roundtrips zur Zertifizierungsstelle.
PHP-Verarbeitungszeit
Von allen Faktoren hat die PHP-Verarbeitungszeit das größte Optimierungspotenzial. OPcache, JIT-Kompilierung, PHP Preloading und ein korrekt dimensionierter PHP-FPM-Pool senken die reine Rechenzeit um 50 bis 70 Prozent (Projekterfahrung).
Datenbankabfragezeit
Fehlende Indizes, N+1-Queries und nicht zwischengespeicherte Abfragen sind die häufigste Ursache für TTFB-Werte über einer Sekunde. Schon wenige gezielte Optimierungen an den häufigsten Queries senken die Datenbankzeit um 80 bis 95 Prozent (Projekterfahrung).
Caching-Trefferquote
Jeder Cache-Treffer ersetzt eine vollständige PHP-Ausführung durch eine Speicheroperation von unter einer Millisekunde. Eine hohe Trefferquote auf der richtigen Cache-Ebene — OPcache, Application Cache, Reverse Proxy — ist der wirksamste Einzelhebel für einen niedrigen TTFB.
Hosting-Infrastruktur
Shared Hosting mit überlasteten Servern, limitiertem RAM oder veralteten PHP-Versionen setzt eine Obergrenze für jede Optimierung. Wir bewerten Ihre aktuelle Infrastruktur und empfehlen bei Bedarf Migration auf besser geeignete Hosting-Varianten.
Hosting-Wahl als Grundlage des TTFB
Die Hosting-Infrastruktur definiert den Rahmen, innerhalb dessen alle anderen Optimierungen wirken. Shared Hosting mit überlasteten CPU-Slots, stark limitiertem Arbeitsspeicher und langsamen I/O-Systemen lässt sich durch keine Konfigurationsänderung auf TTFB-Werte unter 200 Millisekunden trimmen. Wir analysieren Ihre aktuelle Hosting-Umgebung und identifizieren, ob und wo ein Infrastruktur-Upgrade sinnvoll ist. Das bedeutet nicht zwingend teuerere Angebote — häufig ist ein Wechsel zu einem spezialisierten VPS oder Managed Server bei ähnlichen Kosten die bessere Wahl.
- Shared Hosting: Geeignet für statische Seiten mit wenig Traffic. PHP-Verarbeitungszeit variiert je nach Server-Auslastung stark und entzieht sich der Kontrolle. TTFB-Ziele unter 500 ms sind oft unrealistisch.
- Managed VPS / Cloud VPS: Dedizierte CPU-Ressourcen und eigener Arbeitsspeicher schaffen die Grundlage für OPcache, PHP-FPM-Tuning und Reverse Proxy. Für die meisten mittelgroßen WordPress-, TYPO3- und Shopware-Projekte die empfohlene Basis.
- Dedizierter Server: Maximale Kontrolle über alle Parameter. PHP-FPM-Pools, MariaDB-Konfiguration und Caching-Layer können ohne Einschränkungen optimiert werden. Sinnvoll ab mittlerem Traffic oder hoher Gleichzeitigkeit.
- Serverstandort: Die physische Distanz zum Nutzer schlägt sich direkt im TTFB nieder. Für ein deutsches Publikum empfehlen wir Rechenzentren in Frankfurt, Düsseldorf oder Hamburg mit typischen Round-Trip-Zeiten unter 10 Millisekunden.
- NVMe-Speicher: Datenbankzugriffe und PHP-Dateioperationen profitieren stark von NVMe-Speicher gegenüber SATA-SSD. Wir prüfen, ob die I/O-Performance Ihrer Umgebung ein Engpass ist.
PHP-Laufzeitumgebung: OPcache, FPM und Preloading
Die PHP-Laufzeitumgebung ist in den meisten Webanwendungen der größte Einzelhebel für den TTFB. Ohne OPcache liest PHP bei jedem Seitenaufruf alle beteiligten Dateien vom Dateisystem, parst sie und kompiliert sie in Bytecode — ein Prozess, der je nach Anwendungsgröße 100 bis 400 Millisekunden kostet. Mit OPcache wird der kompilierte Bytecode im geteilten Arbeitsspeicher vorgehalten und steht sofort bereit. Für große Frameworks wie Symfony, Laravel oder den Shopware-Core reduziert OPcache die PHP-Initialisierungszeit um 60 bis 80 Prozent (php.net, 2024). Wir konfigurieren OPcache mit ausreichend Speicher für alle PHP-Dateien Ihrer Anwendung und aktivieren PHP Preloading, das häufig genutzte Klassen bereits beim Start des PHP-FPM-Prozesses in den Speicher lädt.
Praxiswert: OPcache-Speicher richtig dimensionieren
OPcache und PHP-FPM: der größte Einzelhebel
Die PHP-Laufzeitumgebung entscheidet über den Großteil der Server-Verarbeitungszeit. Mit korrekt dimensioniertem OPcache, PHP Preloading und einem an das Lastprofil angepassten Worker-Pool bearbeitet der Server jeden Request ohne wiederholtes Kompilieren — die reine PHP-Zeit sinkt spürbar.
- OPcache mit Speicherpuffer für alle PHP-Dateien der Anwendung
- PHP Preloading lädt Framework-Kernklassen beim Prozessstart
- Worker-Pool nach realem Speicherbedarf statt nach Faustregel
PHP-FPM: Worker-Dimensionierung und Pool-Konfiguration
PHP-FPM verwaltet den Pool der PHP-Worker-Prozesse, die eingehende Requests abarbeiten. Zu wenige Worker führen unter Last zu Warteschlangen und erhöhtem TTFB. Zu viele Worker erschöpfen den verfügbaren Arbeitsspeicher und lösen Swapping aus — was den TTFB ebenfalls massiv erhöht. Wir dimensionieren die Worker-Anzahl anhand des tatsächlichen Speicherverbrauchs pro PHP-Prozess, des verfügbaren RAM abzüglich Reserven für Datenbank und Caches sowie des erwarteten Parallelitätsniveaus. Typische Anwendungen benötigen 30 bis 80 Megabyte pro Worker — ein Server mit 4 GB RAM kann nach Abzug aller anderen Dienste etwa 30 bis 60 PHP-Worker zuverlässig betreiben.
Process Manager: dynamic
Im Dynamic-Modus startet PHP-FPM neue Worker bei Bedarf und gibt sie bei Inaktivität frei. Das spart Ressourcen bei niedrigem Traffic und skaliert bei Lastspitzen. Wir konfigurieren pm.min_spare_servers, pm.max_spare_servers und pm.max_children für Ihr Lastprofil.
Request Timeout
request_terminate_timeout begrenzt die maximale Ausführungszeit eines einzelnen PHP-Requests. Das verhindert, dass hängende Anfragen Worker dauerhaft blockieren und den TTFB für alle anderen Nutzer erhöhen. Wir setzen konservative Timeouts und überwachen abgebrochene Requests.
Slow Log Analyse
Das PHP-FPM Slow Log protokolliert alle Requests über einer definierten Schwelle inklusive vollständigem Stacktrace. Diese Daten sind die zuverlässigste Quelle für langsame Code-Pfade und ergänzen den Blick, den ein Lighthouse-Audit auf das Frontend bietet.
Wo steht Ihr TTFB gerade?
Wir messen Ihre Server-Antwortzeit auf allen wichtigen Seitentypen und zeigen die größten Hebel — kostenlos und unverbindlich, bevor Sie sich für eine Optimierung entscheiden.
Datenbankoptimierung: Queries, Indizes und Connection Pooling
Die Datenbank ist in den meisten dynamischen Webanwendungen der primäre TTFB-Treiber. Eine einzelne Seite in WordPress, TYPO3 oder Shopware CE kann 50 bis 250 Datenbankabfragen auslösen. Jede Abfrage ohne passenden Index führt zu einem Full Table Scan — bei Tabellen mit Hunderttausenden Einträgen kann das einzelne Queries auf mehrere hundert Millisekunden strecken. Wir aktivieren das Slow Query Log, analysieren die häufigsten und langsamsten Abfragen mit EXPLAIN ANALYZE und implementieren gezielte Indizes und Query-Rewrites. In unseren Projekten reduzieren wir die Datenbankabfragezeit pro Seitenaufruf typischerweise um 70 bis 90 Prozent, was sich direkt im TTFB widerspiegelt (Projekterfahrung).
Slow Query Log
Alle Abfragen über einer konfigurierbaren Schwelle werden mit Ausführungszeit, Tabellenanzahl und betroffenen Zeilen protokolliert. Die häufigsten Muster zeigen, wo ein einziger Index den größten Effekt hat.
Index-Strategie
Zusammengesetzte Indizes für typische WHERE-Kombinationen, Covering Indexes für SELECT-Heavy-Queries und Partial Indexes für selektive Filter-Kriterien. Kein Index ohne vorherigen Test mit realen Datenmengen.
N+1-Problem beheben
N+1-Queries entstehen, wenn eine Schleife für jeden Datensatz eine separate Abfrage ausführt. Wir identifizieren diese Muster im ORM-Code und lösen sie durch Eager Loading oder dedizierte Batch-Queries.
InnoDB Buffer Pool
Der InnoDB Buffer Pool hält häufig abgerufene Daten- und Index-Seiten im RAM. Ein auf 70 bis 80 Prozent des verfügbaren RAM dimensionierter Buffer Pool eliminiert Disk-I/O für die meisten Lesezugriffe nahezu vollständig.
Connection Pooling
Jeder neue Verbindungsaufbau kostet 1 bis 5 Millisekunden. Connection Pooling hält eine definierte Anzahl Verbindungen offen und weist sie eingehenden Requests sofort zu. Bei hoher Parallelität summiert sich die Ersparnis erheblich.
Query Cache via Redis
Häufig abgerufene, selten ändernde Datensätze — Navigationsbäume, Konfigurationen, Kategorielisten — werden in Redis zwischengespeichert. Cache-Treffer liefern Antworten in unter einer Millisekunde statt in 20 bis 50 Millisekunden.
Caching-Architektur für maximale TTFB-Reduktion
Ein einziges Caching-Tool zu aktivieren reicht selten aus. Wirkungsvolle TTFB-Reduktion erfordert eine mehrstufige Caching-Architektur, in der jede Schicht die darunter liegende entlastet. Die oberste Schicht — Reverse Proxy oder Full-Page Cache — fängt den Großteil aller Anfragen ab, bevor PHP überhaupt gestartet wird. Die mittlere Schicht — Application Cache in Redis oder Memcached — beschleunigt die verbleibenden dynamischen Requests. Die unterste Schicht — OPcache — sorgt dafür, dass selbst Cache-Fehltreffer so schnell wie möglich bearbeitet werden. Wir entwerfen diese Architektur als Einheit und stimmen Caching-Strategien, Invalidierungsregeln und TTL-Werte aufeinander ab.
Schicht 1: Reverse Proxy Cache
nginx oder Varnish hält fertig gerenderte HTML-Seiten im Arbeitsspeicher und liefert sie in unter 5 Millisekunden aus. Für Websites mit vielen anonymen Besuchern ist dies der wirksamste Einzelhebel: Cache-Trefferquoten von 85 bis 95 Prozent sind in der Praxis erreichbar (Projekterfahrung). Wir konfigurieren Cache-Keys, Cookie-Ausschlüsse für eingeloggte Nutzer und tag-basierte Invalidierung für gezieltes Cache-Busting bei Content-Änderungen.
Schicht 2: Full-Page Cache der Anwendung
CMS-eigene Full-Page-Cache-Systeme wie der Shopware HTTP Cache, der TYPO3 Page Cache oder der WordPress-Seiten-Cache arbeiten innerhalb der Anwendung und können anmeldungsabhängige Inhalte differenzierter handhaben als ein vorgelagerter Proxy. Wir konfigurieren Cache-Warmup-Routinen, die nach Deployments die wichtigsten Seiten vorab befüllen, sodass Nutzer keinen leeren Cache erleben.
Schicht 3: Object Cache / Application Cache
Datenbankabfragen, API-Aufrufe und aufwändige Berechnungen werden in Redis zwischengespeichert. Auch wenn eine Seite nicht vollständig gecacht werden kann — etwa bei personalisierten Inhalten — reduziert der Object Cache die Datenbankabfragezeit auf ein Minimum. Wir konfigurieren Redis-Datenbankpartitionen, TTL-Strategien und Eviction-Policies passend zur Arbeitslast.
Schicht 4: OPcache und Preloading
Als unterste Schicht stellt OPcache sicher, dass PHP-Code nicht bei jedem Request neu kompiliert werden muss. PHP Preloading lädt Framework-Kernklassen bereits beim Start des PHP-FPM-Prozesses, sodass keine Initialisierungszeit pro Request anfällt. Diese Schicht wirkt bei jedem einzelnen PHP-Request, auch wenn alle oberen Schichten einen Cache-Fehltreffer verzeichnen.
Mehrstufiges Caching: jede Schicht entlastet die nächste
Ein einzelnes Cache-Plugin genügt selten. Wir schichten Reverse Proxy, Full-Page-Cache, Object-Cache und OPcache so übereinander, dass der Großteil aller Anfragen beantwortet wird, bevor PHP überhaupt startet — und selbst Cache-Fehltreffer schnell bleiben.
- Reverse Proxy liefert gecachte Seiten in unter 5 Millisekunden
- Object-Cache in Redis senkt die Datenbankzeit auf ein Minimum
- Abgestimmte Invalidierung statt pauschalem Cache-Leeren
TTFB-Optimierung in der Praxis
Anonymisierte, illustrative Projektverläufe (Projekterfahrung). Konkrete Ergebnisse besprechen wir für Ihre Konfiguration.
TTFB bei CMS-Plattformen: WordPress, TYPO3 und Shopware
Jede Plattform bringt eigene TTFB-Charakteristika mit. WordPress lädt bei jedem Request alle aktiven Plugins, was bei schlecht konfigurierten Installationen 80 bis 200 aktive Datenbankabfragen pro Seite bedeutet. TYPO3 bietet einen leistungsfähigen integrierten Page Cache, der bei korrekter Konfiguration nahezu alle Frontend-Requests ohne Datenbankzugriff beantwortet. Shopware CE besitzt einen HTTP-Cache auf Symfony-Basis, der zusammen mit dem ESI-Mechanismus personalisierte und anonyme Inhalte effizient trennt. Wir kennen die plattformspezifischen Stellschrauben und wenden sie gezielt an, ohne die Stabilität der Anwendung zu gefährden.
WordPress TTFB-Optimierung
Object-Cache mit Redis über einen Redis-Adapter, Query-Profiling zur Abfrageanalyse, WP-Cron auf echten Cron-Job umleiten, transientes Option-Autoloading bereinigen und unnötige Plugin-Hooks entfernen. Ergänzend unsere WordPress-Performance-Leistung für eine vollständige Optimierung.
TYPO3 TTFB-Optimierung
Page Cache korrekt konfigurieren (Cache-Identifier, Tags, Lifetime), Extbase-Query-Caching aktivieren, DataProcessor-Aufrufe reduzieren, TypoScript-Conditions vereinfachen und den cacheflush-Hook gezielt nutzen, um nur betroffene Cache-Bereiche zu invalidieren.
Shopware CE TTFB-Optimierung
HTTP-Cache aktivieren und korrekt konfigurieren, ESI-Tags für Warenkorb-Widget und Login-Bereich setzen, Produktlisten-API per Elasticsearch beschleunigen, Message-Queue-Consumer auf dedizierten Worker auslagern und Twig-Template-Caching aktivieren. Mehr dazu in unserer Shopware-Performance-Leistung.
Messung und Diagnose: So ermitteln wir den TTFB-Engpass
Bevor wir optimieren, messen wir präzise. Ein hoher TTFB kann viele Ursachen haben, und jede Maßnahme, die am falschen Ort ansetzt, ist verschwendete Ressource. Unser Diagnose-Prozess beginnt mit synthetischen Tests von mehreren Standorten aus — das isoliert die tatsächliche Server-Verarbeitungszeit von der Netzwerklatenz. Anschließend profilieren wir die Anwendung im laufenden Betrieb und messen auf jeder Ebene: PHP-Ausführungszeit, Datenbankabfragezeit, Cache-Trefferquote und Queue-Wartezeit. Das Ergebnis ist eine priorisierte Liste der Maßnahmen mit erwartetem TTFB-Hebel und geschätztem Aufwand.
Synthetische Tests vs. Feld-Daten
Der TTFB-Optimierungsprozess im Überblick
Baseline-Messung und Infrastruktur-Audit
Wir messen den TTFB von mehreren Standorten aus und auf mehreren Seitentypen (Startseite, Kategorie, Produktdetail, API-Endpoints). Gleichzeitig erfassen wir die vollständige Infrastruktur-Konfiguration: PHP-Version und OPcache-Einstellungen, PHP-FPM-Konfiguration, Datenbankversion und -konfiguration, vorhandene Caching-Schichten, Hosting-Umgebung und aktuelle Ressourcenauslastung. Ergebnis: klares Bild des Ist-Zustands und erste Hypothesen zu den Hauptursachen.
Profiling und Ursachenanalyse
Mit Profiling-Tools analysieren wir den zeitintensivsten Code-Pfad pro Seitentyp. Das Slow Query Log liefert die langsamsten Datenbankabfragen inklusive Ausführungsplan. Server-Metriken zeigen, ob CPU, RAM oder I/O der limitierende Faktor ist. Am Ende dieses Schritts kennen wir die drei bis fünf Maßnahmen mit dem höchsten TTFB-Hebel.
Umsetzung der Maßnahmen
Wir setzen die Maßnahmen in der Reihenfolge ihres erwarteten Hebels um und messen nach jeder Änderung den aktuellen TTFB. So erkennen wir schnell, wenn eine Maßnahme nicht den erhofften Effekt hat, und können gegensteuern. Typische Maßnahmen: OPcache-Dimensionierung, PHP-FPM-Tuning, Datenbankindizes, Redis-Integration, Reverse-Proxy-Setup, TLS-Optimierung.
Validierung unter Last
Nach den Konfigurationsänderungen simulieren wir realistische Lastszenarien und prüfen, ob der optimierte TTFB unter Produktionsbedingungen stabil bleibt. Wir testen insbesondere Cold-Cache-Szenarien nach Deployments und prüfen, ob Cache-Warmup-Routinen korrekt funktionieren.
Dokumentation und Monitoring
Jede Maßnahme wird dokumentiert: vorher/nachher-TTFB, Konfigurationsänderung, Begründung. Wir richten Monitoring mit automatischen Alerts ein, damit ein TTFB-Anstieg durch neue Features oder Traffic-Spitzen frühzeitig erkannt wird. Die Dokumentation dient auch als Grundlage für Ihre Entwickler bei künftigen Änderungen.
Typische Ergebnisse: Was eine TTFB-Optimierung bewirkt
Die folgenden Werte zeigen typische Verbesserungen aus unseren TTFB-Projekten. Konkrete Ergebnisse hängen von der Ausgangssituation, der Anwendungskomplexität und der Hosting-Umgebung ab (Projekterfahrung). Auf Anfrage besprechen wir realistische Zielwerte für Ihre spezifische Konfiguration.
Vom Flaschenhals zur exzellenten Antwortzeit
Die größten Sprünge entstehen dort, wo mehrere Ursachen zusammenkommen: schwaches Hosting, fehlender OPcache und ungünstige Datenbankabfragen. Werden sie in der richtigen Reihenfolge behoben, fällt der TTFB von mehreren Sekunden auf einen zweistelligen Millisekundenwert (Projekterfahrung).
- Ausgangswerte über 2 Sekunden sind bei ungetuntem PHP normal
- Reverse Proxy und OPcache liefern den größten Einzelsprung
- Jede Maßnahme wird vorher/nachher gemessen und dokumentiert
| Metrik | Typischer Ausgangswert | Nach TTFB-Optimierung |
|---|---|---|
| TTFB (gecachte Seite, Reverse Proxy) | keine (kein Proxy vorhanden) | unter 10 ms |
| TTFB (dynamische Seite, PHP) | 800 – 3.500 ms | 80 – 250 ms |
| PHP-Ausführungszeit pro Request | 350 – 1.200 ms | 50 – 180 ms |
| Datenbankabfragen pro Seitenaufruf | 60 – 250 | 10 – 40 |
| OPcache-Trefferquote | 0 % oder schlecht konfiguriert | 98 – 99,5 % |
| Google LCP (Feld-Daten) | schlecht / verbesserungswürdig | gut / exzellent |
TTFB und Core Web Vitals sind direkt verknüpft
TTFB-Optimierung für internationale Websites
Für Websites, die Nutzer in mehreren Ländern bedienen, ist die Netzwerklatenz ein eigenständiger TTFB-Faktor. Während ein Nutzer in Deutschland mit einem Server in Frankfurt unter 5 Millisekunden Roundtrip-Zeit rechnen darf, erlebt derselbe Nutzer von einem australischen Standort aus 260 bis 300 Millisekunden allein durch die physische Distanz. CDN-Edge-Caching und die Auslagerung statischer Assets auf geografisch verteilte Netzwerke sind in diesem Fall die wichtigste TTFB-Maßnahme. Wir planen CDN-Strategien, die über einfaches Asset-Caching hinausgehen und auch HTML-Seiten am Edge zwischenspeichern, wo dies ohne Korrektheitsverlust möglich ist. In Verbindung mit unserer Server-Optimierung und effizienter Caching-Architektur erzielen wir für internationale Projekte TTFB-Werte, die auch aus dem Ausland als exzellent eingestuft werden. Zum Weiterlesen empfehlen wir unsere Beiträge zu TTFB und Server-Antwortzeit und Brotli und Zstandard.
Das Wichtigste zur TTFB-Optimierung
- Google stuft einen TTFB unter 200 ms als exzellent ein (web.dev, 2024) — dynamische Seiten erreichen das mit OPcache, Datenbankindizes und mehrstufigem Caching
- Der größte Einzelhebel ist meist die PHP-Laufzeit: OPcache und Preloading senken die reine Rechenzeit deutlich
- Ein Reverse-Proxy-Cache liefert gecachte Seiten in unter 5 Millisekunden und fängt den Großteil anonymer Anfragen ab
- Ohne Optimierung liegt der TTFB dynamischer Seiten oft über 2 Sekunden — nach der Optimierung im zweistelligen bis niedrigen dreistelligen Millisekundenbereich (Projekterfahrung)
- Einstieg über die kostenlose Ersteinschätzung; Performance-Quick-Check ab 349 € netto, Full-Performance-Audit ab 1.490 € netto, optionales Monitoring ab 59 € pro Monat (netto)