# TTFB in der AI-Search-Optimierung: Warum wir messen & optimieren (GEO Case Study) > URL: https://4eck-media.de/blog/ttfb-ai-search-optimierung-geo-case-study/ > Language: de > Description: Von 1,2 Sekunden auf 184 Millisekunden: Warum die kursierende 600-Millisekunden-Grenze ein Mythos ist und wir sie trotzdem beachten. In der GEO-Szene kursiert eine Zahl. Bei einer… --- Von 1,2 Sekunden auf 184 Millisekunden: Warum die kursierende 600-Millisekunden-Grenze ein Mythos ist und wir sie trotzdem beachten. In der GEO-Szene kursiert eine Zahl. Bei einer Time to First Byte (TTFB) zwischen 500 und 700 Millisekunden, so heißt es, würden KI-Bots beim Live-Retrieval verstärkt abbrechen. Die Seite falle aus dem Antwortbudget, der Inhalt lande nicht im Kontext, die Zitierung bleibe aus. Wir haben uns die Quellenlage angesehen und Ergebnis ist ernüchternd: es gibt keine wirklichen Quellen dazu. ## Was sich belegen lässt und was nicht Eine Primärquelle für die 500-bis-700-Millisekunden-Schwelle existiert nicht. Weder OpenAI noch Anthropic, Perplexity oder Google dokumentieren die Fetch-Timeouts ihrer Retrieval-Bots öffentlich. Was existiert, sind Blogbeiträge, die sich gegenseitig zitieren, und deren Zahlen sich dabei widersprechen: - Mal heißt es, unter 200 ms sei sehr gut, 200 bis 500 ms akzeptabel, ab konsistent 600 ms bestehe akuter Handlungsbedarf. - Mal wird 200 ms als Goldstandard gesetzt und behauptet, oberhalb von 800 ms sinke die Zitierrate signifikant. - Als tatsächliche Timeouts pro Seite werden in denselben Texten wiederum 1 bis 5 Sekunden genannt, also das Fünf- bis Fünfundzwanzigfache der angeblichen Abbruchschwelle. Auffällig ist, wo die Zahl 500 bis 700 ms tatsächlich gut belegt ist: in der Sprach-KI. Dort gilt ein medianes Time to First Token von rund 500 ms als praktischer Zielwert für Echtzeit-Dialoge, abgeleitet aus der Turn-Taking-Forschung, und für Enterprise-Voice werden unter 400 ms im p50 und unter 700 ms im p95 angesetzt. Unsere Vermutung: Die Zahl ist aus diesem Kontext ins GEO-Vokabular gewandert. Technisch ist ein harter Abbruch bei 600 ms ohnehin unplausibel. Ein HTTP-Client, der so früh aufgibt, wäre absurd aggressiv. Übliche Library-Defaults liegen im Sekundenbereich. ## Warum TTFB trotzdem zählt: das Rennen um die Kontextberücksichtigung Dass die Zahl falsch ist, heißt nicht, dass die Sorge unbegründet wäre. Sie ist nur falsch gerahmt. Beim Live-Retrieval passiert kein Timeout, sondern ein **Rennen**. Das System holt mehrere Quellen parallel, und das **Antwortbudget ist endlich.** Wer zu spät liefert, fliegt nicht mit einer Fehlermeldung raus, sondern kommt schlicht nicht mehr in den Kontext, aus dem die Antwort gebaut wird. Das ist ein weicher, gleitender Effekt, keine Klippe bei einem bestimmten Millisekundenwert. Und maßgeblich ist dabei nicht die TTFB allein, sondern die Zeit bis zum letzten Byte des HTML-Dokuments, also auch Payload-Größe und Kompression. Dazu kommt die Crawl-Frequenz. Wer langsam antwortet, wird seltener abgeholt, ist im Index seltener aktuell und damit seltener zitierfähig. Das gilt für Googlebot seit jeher und für Retrieval-Bots erst recht, weil deren Ressourcenbudget pro Domain enger kalkuliert ist. Die häufigsten Ursachen für gescheiterte Grounding-Fetches sind gar nicht Latenz, sondern 403 durch WAF und Bot-Management, JavaScript-Challenges, Rate-Limiting mit 429 und clientseitig gerendertes Markup. Unsere Position dazu ist klar: Wir sind eh besessen von PageSpeed: TTFB ist eine Qualifikationsschwelle, kein Rankingfaktor. Man muss sie überspringen, dann konkurriert man über Inhalte. Wir arbeiten deshalb mit einer schlichten Arbeitsregel statt mit einer erfundenen Grenze. Unter 200 ms ist das Ziel, alles über 700 ms ist ein echtes Problem, und relevant sind p95 und p99 unter Last, nicht der Median. Retrieval findet zu beliebigen Zeitpunkten statt, und der schlechteste Fall entscheidet, nicht der Durchschnitt. ## Der Fall goldmichi.de Wie sich das in der Praxis auswirkt, zeigt ein aktuelles Projekt. Ausgangslage: ein Kunde auf einem leistungsschwachen Server, mit entsprechenden Werten. Der Core-Web-Vitals-Test von PageSpeed Insights fällt durch. LCP bei 2,6 Sekunden im gelben Bereich, INP und CLS dagegen unauffällig. ![Core Web Vitals Vorher](https://4eck-media.de/wp-content/uploads/2026/08/core-web-vitals-vorher.avif "Core Web Vitals Vorher") Die Ursache zeigt der TTFB-Test derselben Woche. Durchschnittlich 1,2 Sekunden über die europäischen Messpunkte, Grade F, Score 32 Prozent. Selbst Frankfurt, also der geografisch nächste Messpunkt, liegt bei 1,1 Sekunden. Kein Caching, keine Entlastung nach außen. ![TTFB vorher](https://4eck-media.de/wp-content/uploads/2026/08/ttfb-vorher-goldmichi.avif "TTFB vorher") Bemerkenswert ist die Gleichverteilung. Zwischen bestem und schlechtestem Messpunkt liegen nur 200 Millisekunden. Das ist die Signatur eines Origin-Problems, nicht eines Distanzproblems. Ein CDN allein hätte hier wenig geholfen, weil die Zeit nicht auf der Leitung, sondern im Server verging. Nach der Optimierung liegt der europäische Durchschnitt bei 184 Millisekunden. Grade A, Score 95 Prozent. Frankfurt bei 128 ms, der schlechteste Messpunkt in Finnland bei 265 ms, also immer noch besser als das Vierfache dessen, was der beste Messpunkt vorher erreichte. ![TTFB Nachher, 1. August 2026](https://4eck-media.de/wp-content/uploads/2026/08/ttfb-nachher.avif "TTFB Nachher, 1. August 2026") Das ist eine Reduktion um rund 85 Prozent. Und weil die TTFB die erste Phase des LCP ist, schlägt sie direkt durch: Der Core-Web-Vitals-Test ist bestanden, LCP steht bei 2,2 Sekunden im grünen Bereich. ![Core Web Vitals nachher](https://4eck-media.de/wp-content/uploads/2026/08/core-web-vitals-nachher.avif "Core Web Vitals nachher") ## Einordnung der Zahlen Wer genau rechnet, stellt fest: Die TTFB ist um etwa eine Sekunde gesunken, der LCP aber nur um 0,4 Sekunden. Das ist kein Widerspruch, sondern eine Eigenschaft der Datenquelle. Die Werte in PageSpeed Insights unter „Discover what your real users are experiencing“ stammen aus dem Chrome User Experience Report und sind ein rollierender 75. Perzentilwert über 28 Tage. Sie enthalten also noch anteilig Messungen aus der Zeit vor der Optimierung. Der Effekt ist in den Felddaten noch nicht vollständig angekommen, der LCP wird in den kommenden Wochen weiter sinken. Wir halten das für erwähnenswert, weil in Case Studies gern der maximale Delta-Wert plakatiert wird. Die verlässliche Aussage lautet: Der Schwellenwert ist übersprungen, der Trend ist stabil, und die Restverbesserung kommt automatisch nach. ## Was wir konkret machen bei der TTFB-Optimierung Bei Goldmichi haben wir den Spezialfall, dass alle paar Minuten Live-Börsewerte für Gold, Silber und Co. abgerufen werden, die direkt auf die Preise im Shop Einfluss haben. Daher ost ein Edge-Caching hier nicht aktiv. Aber grundsätzlich führen wir folgende Maßnahmen zut TTFB-Verbesserung bei der AI-Search-Optimierung durch: - Server-seitiges Full-Page-Caching statt Auslieferung pro Request - Object-Cache für wiederkehrende Datenbankabfragen - Reduktion blockierender Backend-Aufrufe im Request-Pfad - Aktuelle PHP- oder Runtime-Version, OPcache-Konfiguration - Vorgelagertes CDN mit Edge-Caching für die HTML-Antwort - Bereinigung von Redirect-Ketten, insbesondere www und Protokoll TTFB ist bei uns fester Bestandteil des technischen AI-Search-Audits, gleichrangig neben Crawler-Zugang und Rendering. Konkret erfassen wir: - TTFB über mehrere Regionen, getrennt nach Origin und Edge, um Origin-Probleme von Distanzproblemen zu unterscheiden. - p95 und p99 unter Last, nicht den Median. Der schlechteste Fall entscheidet über das Rennen. - Time to last byte des HTML-Dokuments, weil Retrieval-Bots das vollständige Markup brauchen und kein JavaScript ausführen. - Logfile-Auswertung nach User-Agent, getrennt nach Retrieval-Bots wie OAI-SearchBot, ChatGPT-User, PerplexityBot und Claude-Web gegenüber Training-Bots, mit Statuscode und Request-Dauer je Zugriff. - Zugangsprüfung vor Latenzprüfung, also robots.txt, WAF-Regeln, Bot-Score, Challenges. Eine schnelle Seite, die 403 ausliefert, ist wertlos. Punkt 4 ist dabei der einzige Weg, die eingangs erwähnte Frage empirisch zu beantworten. Wenn es eine Abbruchschwelle gäbe, müsste sie sich als Knick in der Verteilung abgebrochener Verbindungen zeigen. Wir haben bisher keinen veröffentlichten Datensatz gesehen, der so etwas zeigt, und werten deshalb selbst aus. Hier ist beispielsweise ein AI Bot Log aus einem besucherstarken Kundenprojekt von uns. Bei Abbrüchen, weil der Server zu langsam geantwortet hat, müssten Fehler mit Statuscode 499 auftauchen, die wir bei uns nicht haben: ![AI Bot Logs](https://4eck-media.de/wp-content/uploads/2026/08/ai-bot-logs-4eck.avif "AI Bot Logs") ## Fazit zur Schwellwert-Grenze bei TTFB und AI-Search (GEO) Die 500-bis-700-Millisekunden-Grenze geben wir nicht als Fakt weiter. Sie ist nirgends belegt und technisch falsch gerahmt. Es wäre dennoch falsch, es als unwichtig abzutun. Stellen wir TTFB-Werte über 500 ms fest, optimieren wir im Interesse des Kunden. Was bleibt, ist aus unserer Sicht ein weiteres Argument für TTFB-Optimierung, nur mit der richtigen Begründung: schnellere Auslieferung bedeutet häufigeres Crawling, bessere Chancen im parallelen Wettlauf um den Antwortkontext und, wie dieser Fall zeigt, als willkommener Nebeneffekt bestandene Core Web Vitals. Der Kunde hat für dasselbe Geld beides bekommen, ohne den Server zu wechseln. Wer wissen will, wo die eigene Seite steht, sollte nicht auf den Durchschnittswert schauen, sondern auf das p95 unter Last. Dort entscheidet sich, ob man überhaupt im Rennen ist.