Wenn eine Seite langsam lädt, liegt das Problem oft nicht bei den Bildern oder JavaScript — sondern beim Server selbst. Der TTFB (Time to First Byte) misst, wie lange es dauert, bis dein Browser das erste Datenbyte vom Server empfängt. Und genau dieser Wert ist einer der am häufigsten unterschätzten Faktoren bei der Website-Optimierung.
Google listet TTFB explizit als Ursache für schlechte Core Web Vitals — vor allem für einen hohen LCP (Largest Contentful Paint). Wer seinen LCP verbessern will, muss zuerst den TTFB in den Griff bekommen. In diesem Artikel zeige ich dir, was TTFB genau ist, wie du ihn misst und mit welchen Maßnahmen du ihn drastisch reduzierst.
Was ist TTFB?
Der Time to First Byte (TTFB) ist die Zeit vom ersten HTTP-Request des Browsers bis zum Empfang des ersten Bytes der Serverantwort. Er umfasst drei Phasen:
- DNS-Lookup: Der Browser ermittelt die IP-Adresse der Domain (z. B. shift07.ai → 185.45.x.x)
- TCP-Verbindung + TLS-Handshake: Browser und Server bauen eine gesicherte HTTPS-Verbindung auf
- Server-Verarbeitungszeit: Der Server empfängt die Anfrage, verarbeitet sie (PHP, Datenbankabfrage etc.) und sendet die erste Antwort
Von diesen drei Phasen ist die Server-Verarbeitungszeit diejenige, die du am meisten beeinflussen kannst. DNS-Lookup und TCP-Verbindung sind schnell — aber ein träger Server kann die TTFB auf mehrere Sekunden treiben.
Was ist ein guter TTFB-Wert?
Google definiert in der Web Vitals-Dokumentation konkrete Schwellenwerte:
Das klingt nach viel Spielraum — aber wirklich schnelle Websites liegen unter 200 ms. Ein TTFB von 1.500 ms bedeutet: Bevor auch nur ein einziges Bild geladen wird, hat der Nutzer bereits anderthalb Sekunden gewartet. Für viele Besucher — besonders auf dem Smartphone — ist das der Moment, an dem sie abspringen.
Wichtig: TTFB ist der erste Schritt beim Laden. Alles danach (HTML parsen, CSS laden, JavaScript ausführen, Bilder rendern) kommt on top. Ein schlechter TTFB schiebt das komplette Rendering nach hinten.
TTFB messen: Diese Tools helfen
1. Chrome DevTools
Das präziseste Werkzeug für TTFB-Messung. Öffne DevTools (F12 → Network), lade die Seite neu und klicke auf die HTML-Datei ganz oben in der Netzwerk-Tabelle. Im Reiter "Timing" siehst du:
- Queued / Stalled: Warten im Browser-Queue
- DNS Lookup: Namensauflösung
- Initial connection / SSL: TCP + TLS
- Waiting (TTFB): Das ist der eigentliche TTFB — Server-Verarbeitungszeit
- Content Download: Übertragung der HTML-Datei
2. PageSpeed Insights
Unter pagespeed.web.dev zeigt Google unter "Lab Data" den TTFB an. Außerdem bekommst du Hinweise, falls der TTFB in den "Field Data" (echte Nutzer) schlecht ist — das ist der Wert, der ins Ranking einfließt.
3. GTmetrix und WebPageTest
GTmetrix gibt den TTFB direkt in der Zusammenfassung aus und zeigt ihn im Wasserfall-Diagramm. WebPageTest (webpagetest.org) ist besonders nützlich, um TTFB von verschiedenen Standorten aus zu testen — so erkennst du, ob ein CDN helfen würde.
4. Unsere kostenlose SEO-Analyse
Die kostenlose SEO-Analyse auf shift07.ai prüft neben klassischen SEO-Faktoren auch Performance-Probleme — darunter langsame Server-Antwortzeiten und fehlende Performance-Optimierungen.
Die 7 häufigsten Ursachen für hohen TTFB
1. Billiges Shared Hosting
Auf einem Shared-Hosting-Server teilen sich hunderte von Websites dieselbe CPU und denselben RAM. Wenn ein Nachbar-Server plötzlich viel Traffic bekommt, leidet deine Website. Das ist der Hauptgrund für einen hohen TTFB bei kleinen Websites.
2. Kein Server-seitiges Caching
Dynamische Websites (WordPress, Joomla, Typo3) bauen jede Seite bei jedem Aufruf neu zusammen: PHP startet, fragt die Datenbank ab, generiert HTML, schickt es zurück. Ohne Caching passiert das bei jedem einzelnen Besucher — und das kostet Zeit.
3. Langsame Datenbankabfragen
Eine WordPress-Seite mit vielen Plugins kann bei einem einzelnen Seitenaufruf 50–100 Datenbankabfragen auslösen. Jede Query kostet Millisekunden — die sich schnell zu Sekunden summieren.
4. Kein CDN (Content Delivery Network)
Wenn dein Server in Frankfurt steht und ein Besucher aus München kommt, ist das kein Problem. Aber wenn jemand aus Wien oder Zürich auf deine Website zugreift, kostet allein die physische Distanz bereits 20–40 ms extra. Ohne CDN antwortet immer derselbe Server, egal wo der Besucher sitzt.
5. Nicht optimierte PHP-Konfiguration
PHP-Skripte werden bei jedem Aufruf neu kompiliert, wenn kein OPcache aktiv ist. OPcache speichert den kompilierten Bytecode und spart bei jedem Aufruf die Kompilierungszeit — oft 20–50 ms pro Request.
6. HTTP/1.1 statt HTTP/2 oder HTTP/3
HTTP/1.1 kann pro Verbindung nur eine Anfrage gleichzeitig verarbeiten. HTTP/2 führt Multiplexing ein — mehrere Anfragen laufen parallel über eine einzige Verbindung. HTTP/3 nutzt QUIC statt TCP und reduziert die Verbindungsaufbauzeit weiter. Viele ältere Hosting-Pakete nutzen noch HTTP/1.1.
7. Kein aktiviertes Gzip/Brotli
Wenn der Server HTML, CSS und JavaScript unkomprimiert sendet, ist das Transfer-Volumen deutlich größer. Gzip reduziert HTML typischerweise auf 20–30% der ursprünglichen Größe, Brotli sogar noch mehr. Das senkt zwar nicht direkt die Server-Verarbeitungszeit, aber die Zeit bis zum vollständigen Empfang.
TTFB verbessern: 8 konkrete Maßnahmen
Maßnahme 1: Server-Caching aktivieren
Das ist die wirkungsvollste Einzelmaßnahme für dynamische Websites. Statt die Seite bei jedem Aufruf neu zu generieren, wird das fertige HTML gecacht und direkt ausgeliefert. Der TTFB sinkt von mehreren hundert Millisekunden auf unter 50 ms.
WordPress: WP Rocket, W3 Total Cache oder LiteSpeed Cache (wenn dein Server LiteSpeed nutzt). Aktiviere mindestens Page Caching und Browser Caching.
Apache/Nginx allgemein: Für Nginx gibt es FastCGI Cache, für Apache mod_cache. Wer mehr über Caching-Strategien erfahren möchte, findet in unserem Artikel Caching richtig einrichten eine vollständige Anleitung.
# Nginx: FastCGI Cache aktivieren
fastcgi_cache_path /tmp/nginx-cache levels=1:2 keys_zone=my_cache:100m max_size=10g inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
# Im Server-Block:
fastcgi_cache my_cache;
fastcgi_cache_valid 200 60m;
fastcgi_cache_bypass $no_cache;
fastcgi_no_cache $no_cache;Maßnahme 2: PHP OPcache aktivieren
OPcache ist in modernen PHP-Versionen (ab PHP 5.5) eingebaut und muss nur aktiviert werden. Bei vielen günstigen Hosting-Paketen ist er standardmäßig deaktiviert.
; php.ini
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.revalidate_freq=2
opcache.save_comments=1Prüfe in deinem Hosting-Control-Panel (cPanel, Plesk) ob OPcache aktiviert ist. Viele Provider bieten es als einfachen Toggle an. Mit aktiviertem OPcache sinkt die PHP-Ausführungszeit oft um 30–50%.
Maßnahme 3: CDN einsetzen
Ein CDN (Content Delivery Network) stellt deine Website von Servern aus, die geografisch nah beim Besucher liegen. Cloudflare bietet einen kostenlosen Plan, der als Reverse Proxy fungiert: Anfragen gehen zuerst zum Cloudflare-Rechenzentrum, das gecachte Inhalte direkt ausliefert — ohne deinen Origin-Server überhaupt zu kontaktieren.
So richtest du Cloudflare ein:
- Account auf cloudflare.com erstellen
- Domain hinzufügen, Cloudflare scannt deine bestehenden DNS-Einträge
- DNS-Server bei deinem Domain-Registrar auf die Cloudflare-Nameserver umstellen
- Im Cloudflare-Dashboard: Speed → Optimization → Auto Minify aktivieren
- Caching → Configuration → Browser Cache TTL auf 4 Stunden setzen
Das Ergebnis: Besucher aus Österreich, der Schweiz oder anderen europäischen Ländern werden vom nächstgelegenen Cloudflare-Rechenzentrum bedient. Der TTFB für diese Besucher sinkt drastisch — oft von 300 ms auf unter 50 ms.
Maßnahme 4: Hosting upgraden
Shared Hosting hat systembedingte Limits. Wenn du mit Caching und Optimierungen schon alles ausgereizt hast, ist ein Wechsel auf VPS- oder Cloud-Hosting der nächste Schritt. Anbieter wie Hetzner (Deutschland, DSGVO-konform) bieten VPS-Server ab 4–5 € pro Monat mit garantierten CPU-Ressourcen.
Wechsle zu Nginx statt Apache: Nginx ist für statischen Content und hohe gleichzeitige Verbindungen deutlich effizienter als Apache. Viele moderne Hosting-Stacks (wie LEMP: Linux, Nginx, MySQL, PHP) nutzen Nginx als Standard.
Maßnahme 5: Datenbankabfragen optimieren
Installiere das Plugin Query Monitor (WordPress) um langsame Datenbankabfragen zu identifizieren. Queries die länger als 50 ms dauern, sind Kandidaten für Optimierungen.
Häufige Ursachen für langsame Queries:
- Fehlende Datenbank-Indizes: Abfragen ohne Index scannen die gesamte Tabelle
- Zu viele WordPress-Plugins: Jedes Plugin kann zusätzliche Queries auslösen — weniger Plugins, schnellere Seite
- Autoloaded Options: WordPress lädt beim Start alle "autoloaded" Optionen aus der Datenbank. Mehr als 1 MB autoloaded data ist ein Problem
- Post Revisions: WordPress speichert standardmäßig unbegrenzt viele Revisionen — das bläht die Datenbank auf
// wp-config.php: Revisionen begrenzen
define('WP_POST_REVISIONS', 3);
// Autoloaded Optionen prüfen (SQL):
SELECT option_name, length(option_value) AS size
FROM wp_options WHERE autoload = 'yes'
ORDER BY size DESC LIMIT 20;Maßnahme 6: HTTP/2 oder HTTP/3 aktivieren
Prüfe zunächst, ob deine Website bereits HTTP/2 nutzt. Gib deine URL unter tools.keycdn.com/http2-test ein. HTTP/2 wird von allen modernen Hosting-Anbietern unterstützt — oft reicht ein einfaches Aktivieren im Control-Panel.
Nginx: HTTP/2 ist standardmäßig aktiviert wenn SSL konfiguriert ist:
server {
listen 443 ssl http2;
# ...
}Cloudflare: HTTP/2 und HTTP/3 (QUIC) sind in allen Plänen automatisch aktiv.
Maßnahme 7: Kompression aktivieren
Gzip sollte auf jedem Server aktiv sein. Brotli bietet noch bessere Kompressionsraten, wird aber nicht von allen Hostern angeboten.
# Nginx: Gzip aktivieren
gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css text/xml text/javascript application/javascript application/xml+rss application/json;
gzip_disable "MSIE [1-6]\.";
# Apache: Gzip in .htaccess
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/json
</IfModule>Prüfe ob Gzip aktiv ist: Lade deine Seite in Chrome DevTools (Network → HTML-Datei → Response Headers) und suche nach Content-Encoding: gzip oder Content-Encoding: br (Brotli).
Maßnahme 8: DNS-Lookup-Zeit reduzieren
Lange DNS-Lookup-Zeiten erhöhen den TTFB vor allem beim ersten Besuch. Wechsle zu einem schnellen DNS-Anbieter wie Cloudflare DNS (1.1.1.1) oder Google DNS (8.8.8.8). Der Unterschied kann 20–100 ms betragen.
Nutze außerdem dns-prefetch für externe Domains, die deine Seite lädt:
<!-- Im <head> deiner HTML-Seite -->
<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="dns-prefetch" href="//www.googletagmanager.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>Der komplette Optimierungs-Workflow: Wo anfangen?
Die beste Reihenfolge, um TTFB effektiv zu senken:
- Messen: Chrome DevTools → Timing-Tab → "Waiting (TTFB)" notieren
- Caching aktivieren (größte Wirkung, schnellster Gewinn)
- OPcache prüfen und aktivieren (falls PHP-basiert)
- Cloudflare einrichten (CDN + kostenloser SSL + HTTP/2)
- Gzip/Brotli prüfen
- Datenbank-Performance prüfen (Query Monitor / slow query log)
- Hosting upgraden wenn alle anderen Maßnahmen ausgeschöpft sind
TTFB im Zusammenhang mit anderen Performance-Metriken
TTFB ist der Startpunkt — aber nicht das Ende der Optimierungsreise. Wenn der TTFB unter Kontrolle ist, schaue dir als nächstes an:
- Render-Blocking-Ressourcen: CSS und JavaScript, die das Rendering blockieren — unser Artikel Render-Blocking-Ressourcen entfernen erklärt alle Techniken
- Bildoptimierung: Große Bilder sind oft der zweitgrößte Faktor nach TTFB — lies unseren Artikel über Bilder für das Web optimieren
- Browser Caching: Wie du Caching für wiederkehrende Besucher optimierst, erklärt unser Artikel Caching richtig einrichten
Checkliste: TTFB-Optimierung
- ✅ TTFB gemessen (Ziel: < 200 ms für Seitentypen mit Caching, < 800 ms gesamt)
- ✅ Server-seitiges Caching aktiviert (Page Cache bei WordPress)
- ✅ PHP OPcache aktiv (im Hosting-Control-Panel prüfen)
- ✅ Gzip oder Brotli-Kompression aktiv
- ✅ HTTP/2 aktiviert (im Hosting oder via Cloudflare)
- ✅ CDN genutzt (Cloudflare Free reicht für die meisten Websites)
- ✅ DNS-Lookup-Zeit geprüft (< 50 ms ideal)
- ✅ Langsame Datenbankabfragen identifiziert und behoben
- ✅ Hosting-Paket passt zur erwarteten Last
- ✅ Ergebnis verifiziert mit PageSpeed Insights (Field Data!)
Fazit
Ein hoher TTFB ist oft das am leichtesten zu behebende Performance-Problem — wenn man weiß, wo man suchen muss. Server-Caching hat das größte Potenzial: Aus einer dynamischen WordPress-Seite mit 800 ms TTFB kann mit Page Caching eine in 30 ms antwortende Seite werden. Cloudflare als CDN obendrauf, und du erreichst Werte, die selbst für Webentwickler beeindruckend sind.
Prüfe jetzt mit der kostenlosen SEO-Analyse auf shift07.ai, ob deine Website Performance-Probleme hat — und welche Maßnahmen den größten Hebel bringen. Und mit dem kompletten Performance-SEO-Paket aus Core Web Vitals, Bildoptimierung, Caching, Render-Blocking und einem optimierten TTFB hast du alles in der Hand, um in den Rankings nach oben zu klettern.