Server-Antwortzeit

Was diese Prüfung macht

Misst, wie lange der Server braucht, um das erste Byte des HTML-Dokuments zurückzugeben — TTFB. Die Uhr läuft, sobald MetricSpots Crawler die Anfrage sendet, und stoppt, wenn das erste Antwort-Byte ankommt. DNS, TCP, TLS und Server-Verarbeitung sind alle enthalten.

Die Prüfung besteht unter 800 ms (web.devs “gute” Schwelle) und warnt über 1,8 s.

Warum es zählt

TTFB ist eine Obergrenze für jeden anderen Core Web Vital. Largest Contentful Paint (LCP) kann TTFB + Render-Zeit nicht unterbieten — wenn dein Server 2 Sekunden zum Antworten braucht, liegt dein LCP mathematisch bei mindestens 2 Sekunden, egal wie schnell dein CSS oder wie aggressiv deine Bildoptimierung ist. Googles “guter LCP”-Schwellenwert liegt bei 2,5 s; ein TTFB von 2 s lässt dir 500 ms für alles andere.

Langsames TTFB deutet meist auf eines von vier Dingen hin: eine kalte Serverless-Funktion, eine Datenbankabfrage im Request-Pfad, kein Edge-Caching oder ein CMS, das Arbeit macht, die es nicht müsste (WordPress ohne Object Cache ist der Klassiker).

So behebst du es

Finde zuerst den Engpass. Füge Server-Timing-Header hinzu, damit du siehst, wohin die Zeit fließt:

Server-Timing: db;dur=420, render;dur=180, total;dur=620

Dann greif die Stufe an, die am größten ist.

Cache das HTML am Edge. Eine statische oder seiten-gecachte Antwort sollte in 20–100 ms vom nächsten POP ausgeliefert werden, nicht in 800 ms vom Origin.

# nginx — Mikro-Cache für dynamische Seiten, 60s
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=html:50m max_size=1g inactive=10m;

location / {
  proxy_cache html;
  proxy_cache_valid 200 60s;
  proxy_cache_use_stale updating error timeout;
  proxy_cache_lock on;
  proxy_pass http://app;
}

Cloudflare: Aktiviere “Cache Everything” über eine Cache Rule für HTML und setze dann Cache-Control: s-maxage=60, stale-while-revalidate=600 vom Origin. Das stale-while-revalidate ist der Trick — Cloudflare liefert die veraltete Kopie sofort und aktualisiert im Hintergrund.

Caddy:

example.com {
  reverse_proxy localhost:3000
  header Cache-Control "public, max-age=0, s-maxage=60, stale-while-revalidate=600"
}

Next.js (App Router): Bevorzuge statische Generierung. Ist eine Seite dynamisch, setze die Route-Segment-Konfig:

export const revalidate = 60; // ISR
export const dynamic = "force-static"; // wenn möglich

Für Server-Komponenten, die eine DB ansprechen, wickle den Fetch in unstable_cache oder nutze fetch(url, { next: { revalidate: 60 } }).

Bun / Node: Die üblichen Gewinne sind (a) deine DB in einen Connection-Pool stecken (pg.Pool, nicht ein frischer Client pro Request), (b) N+1-Queries vermeiden — ein JOIN schlägt 50 Round-Trips, (c) alles vorberechnen, was zur Build-Zeit geht, (d) die Antwort mit gzip/brotli komprimieren.

WordPress: Installiere einen persistenten Object Cache (Redis über das Redis Object Cache-Plugin) und einen Page Cache (WP Super Cache, W3 Total Cache oder LiteSpeed Cache). Eine nackte WP-Installation ohne Caching braucht routinemäßig 1–3 s pro Request; mit beiden Caches aktiv fällt das unter 200 ms.

Datenbank: Den fehlenden Index hinzufügen. Lass EXPLAIN ANALYZE auf der langsamsten Abfrage in deinem Request-Pfad laufen; sagt es Seq Scan, brauchst du einen Index. Ein einziger fehlender Index kann das gesamte TTFB-Problem sein.

Geografische Latenz: Wenn dein Origin in Frankfurt steht und deine Besucher:innen in Singapur sitzen, behebt keine Server-Optimierung den 180-ms-Round-Trip. Stell ein CDN vor das HTML (nicht nur vor die Bilder).

Sobald TTFB gesund ist, arbeite an Largest Contentful Paint und Interaction to Next Paint — die liegen stromabwärts von TTFB und zeigen Client-seitige Probleme auf.

Häufig gestellte Fragen

Ist TTFB ein Core Web Vital?

Nein. TTFB ist eine vorgelagerte Metrik — Google nutzt sie nicht direkt als Ranking-Signal. Aber sie ist die Untergrenze für LCP, und LCP ist ein Ranking-Signal. Schlechtes TTFB garantiert schlechtes LCP.

Warum misst MetricSpot ein anderes TTFB als PageSpeed Insights?

Unterschiedliche Messpunkte. MetricSpot misst aus unserem Crawler in einem einzelnen Rechenzentrum. PSI nutzt Felddaten (Chrome User Experience Report), wenn verfügbar — das sind echte Nutzer:innen weltweit in echten Netzen. Felddaten sind die Wahrheit; Labordaten sind die Diagnose.

Mein TTFB ist okay für die Startseite, aber schlecht für Produktseiten — warum?

Die Startseite ist wahrscheinlich gecacht, Produktseiten nicht. Erweitere entweder das Page-Caching auf Produkt-URLs (mit kurzer TTL und Cache-Bust bei Bestandsänderung) oder berechne Produktseiten zur Build-Zeit via ISR / On-Demand-Revalidation vor.