Was ist ein guter TTFB-Zielwert?

Unter 200ms gilt für die meisten Websites als gut, 200-500ms braucht Verbesserung, und alles über 500ms ist ein echtes Problem. Anders als LCP oder CLS ist TTFB kein offizieller Core Web Vital, aber ein harter Boden unter allen dreien - nichts Nachfolgendes kann starten, bevor das erste Byte ankommt.

Behebt ein CDN die TTFB auch für dynamische Seiten?

Nur teilweise. Ein CDN beschleunigt statische Assets und kann vollständige HTML-Antworten für Seiten cachen, die sich nicht pro Anfrage ändern, aber eine wirklich dynamische Seite (personalisierter Inhalt, Live-Daten) muss weiterhin Ihren Ursprungsserver treffen - dafür liegt die Lösung serverseitig (Abfragegeschwindigkeit, Funktions-Cold-Starts, Regionsplatzierung), nicht im Caching.

Warum ist die TTFB bei meiner allerersten Anfrage nach einem Deploy langsam, danach aber schnell?

Das ist fast immer ein Cold Start auf Serverless-Infrastruktur - die Funktion muss sich initialisieren, bevor sie die Anfrage bearbeiten kann. Nachfolgende Anfragen treffen eine warme Instanz. Ist Ihr Traffic-Muster stoßweise, können Cold Starts stärker ins Gewicht fallen, als Ihre durchschnittliche TTFB vermuten lässt.

Misst Scanverra TTFB getrennt von LCP?

Ja. Es ist eine eigenständige Metrik, erfasst im selben Lighthouse-Lauf, der auch für LCP und CLS verwendet wird, sodass Sie erkennen können, ob ein langsamer LCP eigentlich ein verkapptes Server-Problem ist oder ein wirklich eigenständiges Rendering-Problem.

Langsame Time to First Byte (TTFB) beheben

Warum Ihr Server langsam antwortet

TTFB ist fast ausschließlich ein Backend- und Netzwerkproblem, kein Frontend-Problem. Häufige Ursachen:

Cold Starts. Serverless-Funktionen, die erst eine Ausführungsumgebung hochfahren müssen, bevor sie die erste Anfrage nach einer Weile bearbeiten können.
Ungecachtes dynamisches Rendering. Jede Anfrage führt erneut Datenbankabfragen und serverseitiges Rendering aus, die stattdessen gecacht oder einmalig berechnet werden könnten.
Langsame Datenbankabfragen. Eine einzelne nicht indexierte Abfrage oder ein N+1-Muster kann Hunderte Millisekunden hinzufügen, bevor der Server überhaupt anfangen kann, eine Antwort zu schreiben.
Große physische Entfernung zum Ursprungsserver. Ein Besucher in Singapur, der einen Server in Virginia anfragt, zahlt bei jeder Anfrage für diesen Umweg, unabhängig davon, wie schnell der Server selbst antwortet.
Weiterleitungsketten. Jeder Sprung (http → https → www → finale URL) ist ein voller Umweg, bevor die eigentliche Antwort überhaupt beginnt.

So findet man, was wirklich langsam ist

Scanverras Performance-Checks erfassen TTFB als Teil desselben Lighthouse-Laufs, der auch für LCP und CLS verwendet wird, gegen Ihre Live-URL - Sie erhalten also die echte Server-Antwortzeit, keinen Näherungswert dafür. Das ist wichtig, denn ein langsamer LCP bei schneller TTFB weist auf Bild-/Render-Fixes hin, während ein langsamer LCP bei langsamer TTFB bedeutet, dass zuerst der Server repariert werden muss.

Um einzugrenzen, wo die Zeit tatsächlich verloren geht, prüfen Sie die serverseitige Timing-Aufschlüsselung Ihres Hosting- oder APM-Anbieters (die meisten Plattformen melden Zeit für Funktionsinitialisierung, Datenbankaufrufe und Antwort-Serialisierung getrennt), statt von außen zu raten.

So behebt man es

1. Cachen, was nicht pro Anfrage neu erzeugt werden muss

Alles, was für jeden Besucher - oder jeden Besucher in einem bestimmten Segment - gleich ist, ist ein Kandidat fürs Caching. Setzen Sie eine explizite Cache-Lebensdauer am CDN-Edge, statt jede Anfrage Ihren Ursprungsserver treffen zu lassen:

Am Edge cachen, aber im Hintergrund revalidieren, damit Inhalt nicht veraltettypescript

1Cache-Control: public, max-age=60, stale-while-revalidate=300

2. Ihren Ursprungsserver (oder zumindest eine Cache-Schicht) nah an Ihre Nutzer bringen

Deployen Sie in eine Region nahe Ihrem tatsächlichen Traffic, oder stellen Sie einem entfernten Ursprungsserver einen Edge-Cache/CDN vor, damit die meisten Anfragen den langen Umweg gar nicht erst machen müssen.

3. Die langsame Abfrage beheben, nicht das Symptom

Zeigt Ihr APM, dass Datenbankzeit die TTFB dominiert, liegt das meist an einem fehlenden Index, einem N+1-Abfragemuster oder einer Abfrage, die mehr leistet, als die Seite eigentlich braucht - profilieren Sie die konkrete Abfrage, bevor Sie zu Caching als Umweg greifen.

4. Die Häufigkeit von Cold Starts bei Serverless-Funktionen reduzieren

Halten Sie Funktionen für latenzsensible Routen warm, minimieren Sie Code und Abhängigkeiten, die vor der Ausführung des Handlers initialisiert werden müssen, und ziehen Sie einen dauerhaften Server für Traffic-Muster in Betracht, bei denen Cold Starts ständig auftreten.

5. Weiterleitungsketten verkürzen

Jeder Sprung zwischen der von einem Nutzer angefragten URL und der URL, die den Inhalt tatsächlich ausliefert, ist ein voller Umweg, der der TTFB hinzugefügt wird, bevor das Rendering überhaupt starten kann - richten Sie Links und Canonical-URLs direkt auf das finale Ziel.

Wie Scanverra TTFB-Probleme erkennt

TTFB wird direkt aus demselben echten Lighthouse-Lauf erfasst, den Scanverra für jeden Performance-Check durchführt - sowohl auf einem Desktop-Profil als auch auf einem 375px-Mobile-Viewport -, gemessen also gegen Ihre tatsächliche live Server-Antwort, nicht simuliert.