TTFB diagnostizieren, bevor am Frontend geschraubt wird

Cookbook: Ziel und Ergebnis

Du zerlegst die erste Serverantwort in Netzwerk, Weiterleitungen, Cache und dynamische WordPress-Arbeit. Erst danach wird an PHP, Datenbank oder Plugins gearbeitet.

Rezept: Schritt für Schritt

1. Miss dieselbe kanonische HTTPS-URL aus einer passenden Region ohne Weiterleitung.
2. Rufe sie zweimal anonym ab und notiere Cache-Header, TTFB und Gesamtzeit. Der erste Abruf ist meist Miss, der zweite sollte Hit sein.
3. Erzeuge kontrolliert einen Cache-Miss, etwa nach gezieltem Purge, und vergleiche ihn mit eingeloggter Ansicht.
4. Nur wenn dynamische Antworten langsam sind: PHP-Slowlog, Query-Profiling und externe HTTP-Aufrufe untersuchen.

Rechenweg oder Entscheidungsregel

TTFB ≈ DNS + TCP/TLS + Weiterleitungen + Queue + Serververarbeitung + Netzrückweg\nCache-Nutzen = TTFB(Miss) − TTFB(Hit)

Richtwerte sind Diagnosehilfen: Ein stabiler Cache-Hit unter etwa 200 ms ist häufig gut; geografische Distanz kann mehr verursachen. Entscheidend sind Vergleich und Streuung, nicht eine universelle Zahl.

Praxisbeispiel

Miss: 1.180 ms, Hit: 170 ms, eingeloggter Aufruf: 1.260 ms. Der Page Cache spart rund 1.010 ms; das Frontend ist nicht die Ursache der dynamischen TTFB. Nächster Schritt: Slowlog und Datenbank der nicht gecachten Pfade. Sind Miss und Hit beide bei 900 ms, zuerst Netzwerk, Reverse Proxy und tatsächlichen Hit-Status prüfen.

Prüfen, ob es funktioniert

• Header wie x-litespeed-cache: hit, age oder den Host-spezifischen Status belegen.
• Mindestens zehn Wiederholungen; Median und P95 statt Bestwert vergleichen.
• Keine 5xx-, Timeout- oder Queue-Zunahme unter Last.

Rollback

Diagnosewerkzeuge lassen sich ohne Änderung entfernen. Wurde ein Cache oder Profiler aktiviert, vorherige Einstellung wiederherstellen, temporäre Logs sicher entfernen und einen normalen sowie eingeloggten Abruf prüfen.

Das Problem

TTFB enthält DNS, Verbindung, TLS, Weiterleitungen und Serververarbeitung. Eine hohe Zahl beweist daher nicht automatisch eine langsame Datenbank. Gleichzeitig kann eine langsame HTML-Antwort selbst ein perfekt optimiertes LCP-Bild ausbremsen.

Diagnose in Reihenfolge

1. Prüfe unnötige Weiterleitungen und miss aus einer passenden Region.
2. Vergleiche einen anonymen Cache-Hit mit einem absichtlichen Cache-Miss.
3. Prüfe Antwortheader des Page Caches und wiederhole mehrere Abrufe.
4. Nur bei langsamen dynamischen Antworten: PHP, Datenbankabfragen, externe HTTP-Aufrufe und Plugins profilieren.

Interpretation

Ist nur der erste Abruf langsam, sind Cache-Warmup oder Ursprungslatenz Kandidaten. Bleiben Cache-Hits langsam, liegen Netzwerk-, Server- oder Cache-Konfigurationsprobleme nahe. Ist nur die eingeloggte Ansicht langsam, helfen Full-Page-Caches meist nicht; dann sind Object Cache und Anwendungsprofiling wichtiger.

Erfolgskontrolle

Miss gleiche URL, Region und Cache-Situation. Dokumentiere Median und Streuung. Ein kleiner Laborgewinn ist wertlos, wenn der Ursprung unter Last Fehler produziert.

Quellen und Prüfstand

• Google: LCP und TTFB-Zusammenhang
• WordPress: Caching

Inhalt fachlich geprüft am 17. August 2026. Konkrete Werte sind Ausgangspunkte, keine Universaldosierung.