Server & Netzwerk 14 Min. Lesezeit

TTFB optimieren: So reduzieren Sie Ihre Server Response Time

TTFB ist der unterschätzte Performance-Killer. So reduzieren Sie Ihre Server Response Time mit CDN, Caching, HTTP/3 und Brotli-Kompression – mit konkreten Code-Beispielen und einer priorisierten Checkliste.

Editorial Team

Warum TTFB der unterschätzte Performance-Killer ist

Wenn's um Web-Performance geht, dreht sich die Diskussion meistens um clientseitige Metriken: Wie groß ist das JavaScript-Bundle? Sind die Bilder optimiert? Wird Lazy Loading eingesetzt? Alles wichtig – keine Frage. Aber es gibt eine Metrik, die chronisch unterschätzt wird und gleichzeitig alles andere beeinflusst: die Time to First Byte (TTFB).

TTFB misst die Zeitspanne zwischen dem Absenden einer HTTP-Anfrage durch den Browser und dem Empfang des ersten Bytes der Server-Antwort. Sie umfasst die DNS-Auflösung, den TCP-Verbindungsaufbau, die TLS-Aushandlung und – das ist der entscheidende Teil – die Server-Verarbeitungszeit.

Eine langsame TTFB verschiebt buchstäblich alles nach hinten. Jede CSS-Datei, jedes Bild, jedes Script kann erst geladen werden, nachdem das initiale HTML-Dokument eingetroffen ist. Das klingt offensichtlich, wird aber erstaunlich oft ignoriert.

Google definiert folgende Schwellenwerte für TTFB:

  • Gut: unter 800 Millisekunden
  • Verbesserungsbedürftig: 800 ms bis 1.800 ms
  • Schlecht: über 1.800 ms

In der Praxis sollten Sie aber deutlich ambitionierter sein. Eine TTFB unter 200 ms für statische Inhalte und unter 500 ms für dynamische Seiten ist ein realistisches Ziel. Laut dem HTTP Archive Web Almanac 2025 liegt die mediane TTFB für Desktop-Seiten bei rund 940 ms – mehr als die Hälfte aller Websites kratzt also bereits am „Verbesserungsbedürftig"-Bereich. Mal ehrlich: Da liegt enormes Optimierungspotenzial brach.

In unserem Leitfaden zu den Core Web Vitals 2026 haben wir gezeigt, dass LCP (Largest Contentful Paint) die wichtigste Lademetrik darstellt. Was dabei oft unter den Tisch fällt: TTFB ist der Startschuss für LCP. Wenn Ihr Server schon 1.200 ms braucht, um das erste Byte zu liefern, bleiben für die gesamte LCP-Berechnung (Ziel: unter 2.500 ms) nur noch 1.300 ms – für HTML-Parsing, CSS-Laden, Schriften, Rendering des LCP-Elements und alles andere. Das wird verdammt eng.

TTFB messen und verstehen: Diagnose vor Therapie

Bevor Sie optimieren, müssen Sie messen. Und vor allem müssen Sie verstehen, wo genau die Zeit verloren geht. TTFB ist nämlich keine einzelne Zahl, sondern die Summe mehrerer Phasen.

Die Anatomie einer HTTP-Anfrage

Jede HTTP-Anfrage durchläuft diese Phasen, die zusammen die TTFB bilden:

  1. DNS-Lookup (typisch 20–120 ms): Auflösung des Domainnamens zur IP-Adresse
  2. TCP-Verbindungsaufbau (typisch 20–100 ms): Three-Way-Handshake zwischen Browser und Server
  3. TLS-Aushandlung (typisch 30–150 ms): Verschlüsselungsparameter und Zertifikatsvalidierung
  4. Server-Verarbeitungszeit (variabel, oft 100–2.000+ ms): Hier passiert die eigentliche Arbeit – Datenbankabfragen, Template-Rendering, API-Aufrufe, Geschäftslogik
  5. Netzwerk-Latenz (variabel): Die physische Übertragungszeit des ersten Response-Bytes vom Server zum Client

Die Server-Verarbeitungszeit (Phase 4) ist fast immer der größte Hebel. Hier können Sie durch Caching, Datenbankoptimierung und effizientere Anwendungslogik oft Hunderte von Millisekunden einsparen.

TTFB mit den Chrome DevTools messen

Öffnen Sie die Chrome DevTools (F12), wechseln Sie zum Network-Tab und laden Sie Ihre Seite neu. Klicken Sie auf die initiale HTML-Anfrage und dann auf den Timing-Tab. Dort sehen Sie die einzelnen Phasen aufgeschlüsselt:

  • Stalled/Queueing: Wartezeit in der Browser-Queue
  • DNS Lookup: DNS-Auflösung
  • Initial Connection: TCP-Verbindungsaufbau
  • SSL: TLS-Aushandlung
  • Waiting for server response (TTFB): Die eigentliche Server-Verarbeitungszeit
  • Content Download: Download der Response

Der Wert „Waiting for server response" ist Ihre reine Server-TTFB. Ist dieser Wert hoch, liegt das Problem auf dem Server. Ist er niedrig, aber die Gesamtzeit trotzdem hoch, schauen Sie sich DNS, Netzwerk oder TLS genauer an.

TTFB mit der Navigation Timing API messen

Für automatisiertes Monitoring können Sie die Navigation Timing API nutzen:

// TTFB über die Navigation Timing API messen
const [entry] = performance.getEntriesByType('navigation');

if (entry) {
  // Gesamte TTFB (inkl. DNS, TCP, TLS)
  const ttfb = entry.responseStart - entry.startTime;
  console.log(`Gesamt-TTFB: ${ttfb.toFixed(0)} ms`);

  // Aufschlüsselung der einzelnen Phasen
  const dns = entry.domainLookupEnd - entry.domainLookupStart;
  const tcp = entry.connectEnd - entry.connectStart;
  const tls = entry.secureConnectionStart > 0
    ? entry.connectEnd - entry.secureConnectionStart
    : 0;
  const serverTime = entry.responseStart - entry.requestStart;

  console.log(`DNS-Lookup: ${dns.toFixed(0)} ms`);
  console.log(`TCP-Verbindung: ${tcp.toFixed(0)} ms`);
  console.log(`TLS-Aushandlung: ${tls.toFixed(0)} ms`);
  console.log(`Server-Verarbeitung: ${serverTime.toFixed(0)} ms`);
}

// Als PerformanceObserver für Real User Monitoring
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    const ttfb = entry.responseStart - entry.startTime;
    // An Analytics-Dienst senden
    sendToAnalytics('ttfb', ttfb);
  }
});
observer.observe({ type: 'navigation', buffered: true });

Lighthouse und WebPageTest

Lighthouse zeigt in seinem Performance-Audit den Punkt „Reduce initial server response time", wenn die TTFB über 600 ms liegt. Für tiefergehende Analysen ist WebPageTest (webpagetest.org) Gold wert – dort können Sie die TTFB von verschiedenen Standorten weltweit messen und die Waterfall-Ansicht für jede Phase inspizieren.

Ein Tipp aus der Praxis: Testen Sie immer von mehreren Standorten. Ihre TTFB aus Frankfurt kann hervorragend sein, während Nutzer aus Singapur eine völlig andere Erfahrung machen.

Server-seitige Optimierungen: Wo die meiste Zeit verloren geht

Die Server-Verarbeitungszeit ist typischerweise der größte Anteil der TTFB. Schauen wir uns die wirksamsten Stellschrauben an.

Datenbankabfragen optimieren

Langsame Datenbankabfragen sind der häufigste Grund für hohe Server-Verarbeitungszeiten. Ich hab schon Projekte gesehen, wo eine einzige schlecht indexierte Query die TTFB um über eine Sekunde nach oben getrieben hat. Hier ein systematischer Ansatz zur Diagnose:

# MySQL/MariaDB: Slow Query Log aktivieren
# In my.cnf oder my.ini
[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.5  # Alle Queries > 500ms loggen

# PostgreSQL: Query-Statistiken aktivieren
# In postgresql.conf
shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.track = all

Die häufigsten Problemfälle und ihre Lösungen:

  • Fehlende Indizes: Analysieren Sie Ihre häufigsten Queries mit EXPLAIN ANALYZE und erstellen Sie gezielte Indizes. Ein fehlender Index auf einer WHERE-Klausel kann den Unterschied zwischen 2 ms und 2.000 ms ausmachen – kein Scherz.
  • N+1-Query-Problem: Statt in einer Schleife für jedes Element eine einzelne Abfrage zu feuern, nutzen Sie JOINs oder Batch-Queries. In ORMs wie Eloquent, Django ORM oder Prisma gibt es dafür Eager Loading (with(), select_related(), include).
  • Überdimensionierte SELECT-Abfragen: Holen Sie nur die Spalten, die Sie tatsächlich brauchen. SELECT * auf einer Tabelle mit 50 Spalten, wenn Sie nur 3 davon benötigen, verschwendet Bandbreite und Speicher.
  • Fehlende Connection Pools: Jede neue Datenbankverbindung kostet 50–100 ms. Nutzen Sie Connection Pooling (PgBouncer für PostgreSQL, ProxySQL für MySQL), um bestehende Verbindungen wiederzuverwenden.

Server-seitiges Caching implementieren

Caching ist – und das sage ich ohne Übertreibung – der mächtigste Hebel zur TTFB-Reduktion. Statt dieselbe teure Datenbankabfrage bei jedem Request auszuführen, speichern Sie das Ergebnis und liefern es direkt aus dem Cache:

# Beispiel: Redis-Caching in einer Node.js/Express-Anwendung
import Redis from 'ioredis';
const redis = new Redis({
  host: process.env.REDIS_HOST || 'localhost',
  port: 6379,
  maxRetriesPerRequest: 3
});

// Cache-Middleware für Express
function cacheMiddleware(ttlSeconds = 300) {
  return async (req, res, next) => {
    // Nur GET-Anfragen cachen
    if (req.method !== 'GET') return next();

    const cacheKey = `page:${req.originalUrl}`;

    try {
      const cached = await redis.get(cacheKey);
      if (cached) {
        const data = JSON.parse(cached);
        res.set('X-Cache', 'HIT');
        return res.send(data.body);
      }
    } catch (err) {
      console.error('Cache-Fehler:', err);
    }

    // Original send() überschreiben, um Response zu cachen
    const originalSend = res.send.bind(res);
    res.send = (body) => {
      redis.setex(cacheKey, ttlSeconds, JSON.stringify({ body }))
        .catch(console.error);
      res.set('X-Cache', 'MISS');
      return originalSend(body);
    };

    next();
  };
}

// Anwendung
app.get('/api/produkte', cacheMiddleware(600), async (req, res) => {
  const produkte = await db.query('SELECT * FROM produkte WHERE aktiv = true');
  res.json(produkte);
});

Typische Cache-Strategien und wann Sie welche einsetzen:

  • Page Cache (TTL: 5–60 Minuten): Komplette HTML-Seiten für anonyme Besucher. Drückt die TTFB auf unter 50 ms, da der Server nur aus dem Cache liest – keine Datenbankzugriffe, kein Template-Rendering.
  • Fragment Cache (TTL: 1–30 Minuten): Einzelne Seitenbereiche wie Navigation, Sidebar oder Footer, die sich selten ändern. Besonders praktisch bei personalisierten Seiten, wo ein Full-Page-Cache nicht möglich ist.
  • Query Cache (TTL: 1–10 Minuten): Ergebnisse teurer Datenbankabfragen. Der Klassiker für E-Commerce-Kategorie-Seiten oder Blog-Archive.
  • Object Cache (TTL: variabel): Einzelne Datenobjekte wie Benutzerprofile, Konfigurationen oder Produkt-Stammdaten.

PHP- und WordPress-spezifische Optimierungen

Da ein großer Teil des Webs auf PHP und WordPress läuft, verdienen diese Plattformen besondere Aufmerksamkeit:

# PHP OPcache aktivieren und optimieren (php.ini)
opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=10000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.jit=1255
opcache.jit_buffer_size=128M

In PHP 8.3+ bringt der JIT-Compiler spürbare Performance-Verbesserungen, besonders bei rechenintensiven Operationen. Für WordPress-Sites empfehle ich zusätzlich:

  • Object Cache mit Redis: Das Plugin „Redis Object Cache" eliminiert wiederholte Datenbankabfragen für Optionen, Transients und Queries.
  • Full-Page-Cache: Plugins wie WP Super Cache oder W3 Total Cache generieren statische HTML-Dateien. Noch besser: Nginx FastCGI Cache oder Varnish vor WordPress – das kann die TTFB auf unter 20 ms drücken.
  • Datenbankbereinigung: Autoload-Optionen, Post-Revisionen und Transients wachsen mit der Zeit und verlangsamen jeden einzelnen Request. Regelmäßiges Aufräumen ist hier Pflicht, nicht Kür.

Streaming und Early Hints

Zwei moderne Techniken können die wahrgenommene TTFB drastisch verbessern. Und mit „drastisch" meine ich wirklich deutlich spürbar.

HTTP Streaming (Chunked Transfer Encoding): Statt die gesamte HTML-Seite auf dem Server fertig zu generieren und erst dann zu senden, können Sie den HTML-Stream bereits beginnen, während der Server noch rechnet. Der Browser erhält den <head>-Bereich sofort und kann CSS und kritische Ressourcen laden, während der <body> noch generiert wird.

// Node.js: Streaming-Response mit Express
app.get('/', async (req, res) => {
  res.setHeader('Content-Type', 'text/html; charset=utf-8');
  res.setHeader('Transfer-Encoding', 'chunked');

  // Head sofort senden – Browser beginnt CSS/JS zu laden
  res.write(`<!DOCTYPE html>
<html lang="de">
<head>
  <meta charset="utf-8">
  <title>Meine Seite</title>
  <link rel="stylesheet" href="/styles.css">
  <link rel="preload" href="/fonts/inter.woff2" as="font"
        type="font/woff2" crossorigin>
</head>
<body>
  <header>Navigation...</header>
  <main>`);

  // Teure Datenbankabfrage – dauert 300ms
  const produkte = await db.getProdukte();

  // Dynamischen Content senden
  res.write(renderProduktListe(produkte));

  // Seite abschließen
  res.end(`</main>
  <footer>Footer...</footer>
</body></html>`);
});

103 Early Hints: Eine relativ neue HTTP-Funktion (seit 2023 in Chrome, Firefox und Edge), bei der der Server vorab signalisiert, welche Ressourcen der Browser laden soll – bevor die eigentliche Response fertig ist:

# Nginx-Konfiguration für 103 Early Hints
location / {
    # Early Hints für kritische Ressourcen senden
    add_header Link "</styles/critical.css>; rel=preload; as=style" early;
    add_header Link "</fonts/inter-var.woff2>; rel=preload; as=font; type=font/woff2; crossorigin" early;
    add_header Link "</js/app.js>; rel=preload; as=script" early;

    proxy_pass http://backend;
}

# Apache-Konfiguration
H2EarlyHints on
Header add Link "</styles/critical.css>;rel=preload;as=style" 103

So läuft das ab: Der Client sendet eine Anfrage → der Server antwortet sofort mit einem 103-Status und den Link-Headers → der Browser fängt an, die verlinkten Ressourcen herunterzuladen → der Server schickt die eigentliche 200-Response, sobald sie fertig ist. Das spart die gesamte Server-Verarbeitungszeit für das Laden kritischer Ressourcen.

Cloudflare berichtet, dass Early Hints den LCP im Median um 30 Prozent verbessern kann. Das ist schon beachtlich.

CDN-Strategien: Inhalte näher zum Nutzer bringen

Ein Content Delivery Network (CDN) verteilt Ihre Inhalte auf Edge-Server weltweit. Statt dass ein Nutzer aus Tokio Ihr HTML von einem Server in Frankfurt abruft (150–250 ms Netzwerklatenz), erhält er es vom nächstgelegenen Edge-Server (20–50 ms).

Für die TTFB ist das ein absoluter Game-Changer.

Statisches vs. dynamisches CDN-Caching

Die einfachste CDN-Nutzung betrifft statische Assets (CSS, JavaScript, Bilder, Schriften). Hier konfigurieren Sie lange Cache-Zeiten mit Content-Hashing für Cache-Busting:

# Nginx: Cache-Header für statische Assets
location ~* \.(css|js|woff2|png|jpg|webp|avif|svg)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    add_header Vary "Accept-Encoding";
}

# Für HTML-Dokumente: Kurze oder keine Cache-Zeit
location ~* \.html$ {
    expires 5m;
    add_header Cache-Control "public, no-cache";
}

Der eigentliche Durchbruch kommt aber durch das Caching dynamischer Inhalte am CDN-Edge. Moderne CDNs wie Cloudflare, Fastly und AWS CloudFront können HTML-Seiten cachen und bei Änderungen gezielt invalidieren:

# Cloudflare: Cache-Control für dynamische HTML-Seiten
# (via Page Rules oder Cache Rules konfigurierbar)

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

# Variante 2: CDN-spezifischer Cache mit Surrogate-Key
Cache-Control: public, max-age=0, must-revalidate
Surrogate-Control: max-age=3600
Surrogate-Key: homepage produkte-liste

# Gezielte Invalidierung über Surrogate-Key (Fastly-Beispiel)
# curl -X POST -H "Fastly-Key: YOUR_API_KEY" \
#   https://api.fastly.com/service/SERVICE_ID/purge/produkte-liste

Das stale-while-revalidate-Pattern ist besonders elegant (und ehrlich gesagt mein persönlicher Favorit): Der CDN-Edge liefert die gecachte Version sofort aus – TTFB unter 50 ms – und holt sich im Hintergrund eine frische Version vom Origin-Server. Nutzer erhalten immer eine schnelle Antwort, und die Inhalte sind höchstens 60 Sekunden veraltet. Für die meisten Websites ist das ein völlig akzeptabler Kompromiss.

Edge Computing und Edge SSR

Der neueste Trend geht über reines Caching hinaus: Edge Computing führt Ihre Anwendungslogik direkt auf den CDN-Edge-Servern aus. Plattformen wie Cloudflare Workers, Vercel Edge Functions und Deno Deploy ermöglichen serverseitiges Rendering in unter 50 ms – weltweit.

// Cloudflare Worker: Edge-SSR mit HTML-Streaming
export default {
  async fetch(request, env) {
    const url = new URL(request.url);

    // Cache-Check
    const cache = caches.default;
    const cached = await cache.match(request);
    if (cached) return cached;

    // Daten von der API abrufen (KV-Store oder D1-Datenbank)
    const produkte = await env.DB
      .prepare('SELECT * FROM produkte WHERE aktiv = 1 LIMIT 20')
      .all();

    // HTML am Edge rendern
    const html = renderPage(produkte.results);

    const response = new Response(html, {
      headers: {
        'Content-Type': 'text/html;charset=utf-8',
        'Cache-Control': 'public, max-age=300, stale-while-revalidate=600'
      }
    });

    // Response im CDN-Cache speichern
    request.method === 'GET' && cache.put(request, response.clone());

    return response;
  }
};

Der Vorteil liegt auf der Hand: Statt eines einzigen Origin-Servers in einer Region führen hunderte Edge-Nodes weltweit Ihre Logik aus. Die TTFB sinkt auf 20–80 ms – egal, wo sich der Nutzer gerade befindet.

HTTP/2 und HTTP/3: Protokoll-Optimierungen

Das Transportprotokoll hat erheblichen Einfluss auf die TTFB, besonders beim Verbindungsaufbau. Und hier hat sich in den letzten Jahren einiges getan.

HTTP/2: Multiplexing und Server Push

HTTP/2 sollte 2026 der absolute Mindeststandard sein. Es bietet:

  • Multiplexing: Mehrere Requests über eine einzelne TCP-Verbindung, ohne Head-of-Line-Blocking auf HTTP-Ebene
  • Header-Kompression (HPACK): Reduziert die Größe von HTTP-Headern um bis zu 85 Prozent
  • Priorisierung: Der Browser kann signalisieren, welche Ressourcen zuerst geladen werden sollen
# Nginx: HTTP/2 aktivieren
server {
    listen 443 ssl;
    http2 on;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Moderne TLS-Konfiguration für minimale Handshake-Zeit
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # OCSP Stapling – spart einen zusätzlichen DNS-Lookup
    ssl_stapling on;
    ssl_stapling_verify on;
}

HTTP/3 mit QUIC: Der nächste Sprung

HTTP/3 basiert auf dem QUIC-Protokoll und löst fundamentale Probleme von TCP. Der größte Vorteil für die TTFB: 0-RTT-Verbindungsaufbau. Bei einer Erstverbindung spart QUIC einen Round-Trip gegenüber TCP+TLS (1 RTT statt 2–3 RTTs). Bei Wiederverbindungen ermöglicht 0-RTT das Senden von Daten bereits im ersten Paket – die Verbindungsaufbauzeit fällt damit praktisch weg.

# Nginx: HTTP/3 aktivieren (ab Nginx 1.25+)
server {
    listen 443 ssl;
    http2 on;

    # HTTP/3 über QUIC
    listen 443 quic reuseport;
    http3 on;

    # Alt-Svc Header, damit Browser HTTP/3 entdecken
    add_header Alt-Svc 'h3=":443"; ma=86400';

    # QUIC-spezifische Optimierungen
    quic_retry on;
    ssl_early_data on;
}

# Apache: HTTP/3 mit mod_http2 und mod_quic
Protocols h2 h3 http/1.1
H3MaxSessionAge 86400

Laut Cloudflare-Messungen reduziert HTTP/3 die Verbindungsaufbauzeit um 30 bis 40 Prozent gegenüber HTTP/2 – auf mobilen Verbindungen mit höherer Latenz sogar noch mehr. Alle modernen Browser unterstützen HTTP/3, und die Server-Unterstützung in Nginx, Caddy und Litespeed ist stabil.

Es gibt 2026 ehrlich gesagt keinen guten Grund mehr, HTTP/3 nicht zu aktivieren.

Kompression: Jedes Byte zählt

Effiziente Kompression reduziert nicht nur die Übertragungszeit, sondern wirkt sich indirekt auch auf die TTFB aus – besonders bei der stale-while-revalidate-Strategie, wo kleinere Responses schneller validiert werden.

Brotli als Standard in 2026

Brotli (br) sollte 2026 Ihre primäre Kompressionsmethode sein. Es liefert 15 bis 25 Prozent bessere Kompression als Gzip bei vergleichbarer Dekompressionsgeschwindigkeit. Alle modernen Browser unterstützen Brotli seit Jahren – hier gibt es keine Ausreden mehr.

# Nginx: Brotli-Kompression konfigurieren
# (erfordert ngx_brotli-Modul)
brotli on;
brotli_comp_level 6;  # 1-11, 6 ist ein guter Kompromiss
brotli_types
  text/html
  text/css
  text/javascript
  application/javascript
  application/json
  application/xml
  image/svg+xml
  font/woff2;

# Gzip als Fallback
gzip on;
gzip_comp_level 5;
gzip_types text/html text/css application/javascript application/json;
gzip_vary on;

Ein wichtiger Praxis-Tipp: Für statische Assets sollten Sie Brotli-Dateien zur Build-Zeit vorkomprimieren (Kompressionslevel 11). Für dynamische Responses nutzen Sie Level 4–6, weil die höheren Level schlicht zu CPU-intensiv für Echtzeit-Kompression sind.

# Statische Assets zur Build-Zeit vorkomprimieren
# Im Build-Skript oder via Vite-Plugin
npx brotli-cli compress --quality 11 dist/**/*.{js,css,html,svg}

# Vite: Vorkomprimierung mit vite-plugin-compression
// vite.config.js
import viteCompression from 'vite-plugin-compression';

export default defineConfig({
  plugins: [
    viteCompression({
      algorithm: 'brotliCompress',
      ext: '.br',
      threshold: 1024
    }),
    viteCompression({
      algorithm: 'gzip',
      ext: '.gz',
      threshold: 1024
    })
  ]
});

Zstandard (zstd): Der Newcomer

Zstandard ist ein neueres Kompressionsformat von Meta, das 2024 in Chrome und 2025 in Firefox und Safari Einzug gehalten hat. Es bietet eine interessante Kombination: Kompressionsverhältnisse ähnlich wie Brotli bei Dekompressionsgeschwindigkeiten vergleichbar mit LZ4. Für Server mit hohem Traffic kann Zstandard die CPU-Last bei dynamischer Kompression spürbar senken.

Behalten Sie dieses Format im Auge – es etabliert sich gerade als dritte Option neben Gzip und Brotli.

DNS- und Netzwerk-Optimierungen

Die Netzwerkphasen der TTFB werden oft übersehen, können aber in Summe 200–400 ms ausmachen. Das ist nicht nichts.

DNS-Latenz minimieren

  • Premium-DNS-Anbieter nutzen: Cloudflare DNS, AWS Route 53 oder Google Cloud DNS bieten Anycast-DNS mit globaler Verteilung und Antwortzeiten unter 20 ms. Günstige DNS-Anbieter können dagegen 80–150 ms pro Lookup kosten.
  • DNS-Prefetching für Drittanbieter: Wenn Ihre Seite Ressourcen von externen Domains lädt, lösen Sie die DNS-Adresse vorab auf:
<!-- DNS-Prefetch für externe Domains -->
<link rel="dns-prefetch" href="https://fonts.googleapis.com">
<link rel="dns-prefetch" href="https://cdn.analytics-tool.com">

<!-- Preconnect: DNS + TCP + TLS vorab aufbauen -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preconnect" href="https://api.mein-service.de">

preconnect ist stärker als dns-prefetch: Es baut die komplette Verbindung auf (DNS + TCP + TLS). Nutzen Sie preconnect für die 2–3 wichtigsten externen Domains und dns-prefetch für weniger kritische. Aber übertreiben Sie es nicht – jeder Preconnect verbraucht Ressourcen, und mehr als 4–6 gleichzeitige Preconnects können tatsächlich kontraproduktiv sein.

TLS-Optimierung

TLS 1.3 reduziert den Handshake von zwei auf einen Round-Trip. Mit Session Resumption und 0-RTT kann die TLS-Aushandlung bei Wiederverbindungen sogar ohne zusätzlichen Round-Trip erfolgen:

# Nginx: Optimale TLS-Konfiguration
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

# Session-Resumption für schnellere Wiederverbindungen
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;

# TLS 1.3 0-RTT aktivieren (mit Vorsicht!)
ssl_early_data on;
# Schutz vor Replay-Attacken
proxy_set_header Early-Data $ssl_early_data;

# ECDSA-Zertifikat statt RSA: Kleinere Zertifikate, schnellerer Handshake
# (Bei Let's Encrypt: certbot --key-type ecdsa)

Ein ECDSA-Zertifikat ist deutlich kleiner als ein RSA-Zertifikat (ca. 300 Bytes vs. 2–4 KB), was den TLS-Handshake beschleunigt. In Kombination mit OCSP Stapling und TLS 1.3 können Sie die TLS-Phase auf unter 30 ms drücken.

Monitoring und kontinuierliche Optimierung

TTFB-Optimierung ist kein einmaliges Projekt – es ist ein fortlaufender Prozess. Server-Konfigurationen ändern sich, Code wächst, Datenbanken werden größer. All das kann die TTFB schleichend verschlechtern, ohne dass es jemand merkt.

Real User Monitoring (RUM) einrichten

Synthetische Tests (Lighthouse, WebPageTest) sind wichtig, zeigen aber nur einen Bruchteil der Realität. Real User Monitoring erfasst die tatsächliche TTFB Ihrer echten Nutzer – mit deren realen Netzwerkverbindungen, Standorten und Geräten.

// Einfaches TTFB-Monitoring mit der web-vitals-Bibliothek
import { onTTFB } from 'web-vitals';

onTTFB((metric) => {
  console.log('TTFB:', metric.value, 'ms');
  console.log('Rating:', metric.rating); // 'good', 'needs-improvement', 'poor'

  // An Ihren Analytics-Dienst senden
  fetch('/api/analytics', {
    method: 'POST',
    body: JSON.stringify({
      name: metric.name,
      value: metric.value,
      rating: metric.rating,
      navigationType: metric.navigationType,
      // Aufschlüsselung der Phasen (wenn verfügbar)
      entries: metric.entries.map(e => ({
        dns: e.domainLookupEnd - e.domainLookupStart,
        tcp: e.connectEnd - e.connectStart,
        tls: e.secureConnectionStart > 0
          ? e.connectEnd - e.secureConnectionStart : 0,
        server: e.responseStart - e.requestStart
      }))
    }),
    keepalive: true
  });
});

TTFB-Budget definieren

Definieren Sie ein klares Performance-Budget für Ihre TTFB und integrieren Sie es in Ihre CI/CD-Pipeline:

# Lighthouse CI: TTFB-Budget in lighthouserc.js
module.exports = {
  ci: {
    assert: {
      assertions: {
        'server-response-time': ['error', { maxNumericValue: 600 }],
        'largest-contentful-paint': ['warn', { maxNumericValue: 2500 }]
      }
    },
    collect: {
      url: ['https://meine-website.de/', 'https://meine-website.de/produkte'],
      numberOfRuns: 3
    }
  }
};

Wenn die TTFB das Budget überschreitet, schlägt der Build fehl. So stellen Sie sicher, dass Performance-Regressionen nicht unbemerkt in die Produktion gelangen. Und glauben Sie mir: Das passiert schneller als man denkt.

Praxis-Checkliste: TTFB-Optimierung Schritt für Schritt

Zum Abschluss hier Ihre priorisierte Checkliste – geordnet nach dem typischen Impact-zu-Aufwand-Verhältnis. Fangen Sie oben an und arbeiten Sie sich durch:

  1. CDN aktivieren (Impact: sehr hoch, Aufwand: gering): Cloudflare Free Tier reicht für den Anfang. Sofortige TTFB-Reduktion um 50–80 Prozent für Nutzer außerhalb Ihrer Server-Region.
  2. HTTP/2 und HTTP/3 aktivieren (Impact: hoch, Aufwand: gering): Nginx-Konfiguration anpassen, QUIC freischalten. 30–40 Prozent schnellerer Verbindungsaufbau.
  3. Brotli-Kompression aktivieren (Impact: mittel-hoch, Aufwand: gering): 15–25 Prozent kleinere Responses gegenüber Gzip.
  4. Server-seitiges Caching (Impact: sehr hoch, Aufwand: mittel): Redis/Memcached für Datenbank-Queries und Full-Page-Cache. Kann die Server-Verarbeitungszeit um 90+ Prozent reduzieren.
  5. Datenbankabfragen optimieren (Impact: hoch, Aufwand: mittel): Slow Query Log analysieren, Indizes erstellen, N+1-Probleme beheben.
  6. TLS-Konfiguration optimieren (Impact: mittel, Aufwand: gering): TLS 1.3, OCSP Stapling, Session Resumption, ECDSA-Zertifikat.
  7. DNS-Prefetch und Preconnect (Impact: mittel, Aufwand: gering): Zwei HTML-Zeilen, die 100–200 ms für externe Ressourcen sparen können.
  8. 103 Early Hints (Impact: hoch, Aufwand: mittel): Kritische Ressourcen vorab signalisieren. Erfordert CDN- oder Serverunterstützung.
  9. Edge Computing evaluieren (Impact: sehr hoch, Aufwand: hoch): Bei globaler Zielgruppe und dynamischen Inhalten – Cloudflare Workers oder Vercel Edge Functions in Betracht ziehen.
  10. RUM-Monitoring einrichten (Impact: indirekt, Aufwand: gering): Ohne Monitoring optimieren Sie im Blindflug. Die web-vitals-Bibliothek ist in fünf Minuten integriert.

Häufig gestellte Fragen (FAQ)

Was ist ein guter TTFB-Wert und wie wird er gemessen?

Google definiert eine TTFB unter 800 ms als „gut". In der Praxis sollten Sie aber unter 200 ms für statische und unter 500 ms für dynamische Seiten anstreben. Messen können Sie die TTFB über die Chrome DevTools (Network-Tab → Timing), die Navigation Timing API, Lighthouse oder WebPageTest. Für wirklich verlässliche Daten empfiehlt sich Real User Monitoring (RUM), das die tatsächliche TTFB Ihrer echten Nutzer erfasst – nicht nur synthetische Laborwerte.

Wie beeinflusst TTFB die Core Web Vitals?

TTFB ist zwar kein offizieller Core Web Vital, beeinflusst aber direkt den Largest Contentful Paint (LCP). Da LCP die Zeit bis zur Anzeige des größten sichtbaren Elements misst, verschiebt eine langsame TTFB den gesamten Rendering-Prozess nach hinten. Wenn Ihr Server 1.200 ms für das erste Byte braucht, bleiben für LCP (Ziel: unter 2.500 ms) nur noch 1.300 ms – das reicht oft nicht. Indirekt beeinflusst TTFB auch INP, da lange Server-Zeiten bei Navigation-Requests die wahrgenommene Responsiveness verschlechtern.

Welche Maßnahme verbessert die TTFB am schnellsten?

Die schnellste Verbesserung erzielen Sie typischerweise mit einem CDN. Die Aktivierung eines CDN wie Cloudflare (bereits im Free-Tier effektiv) kann die TTFB für internationale Nutzer um 50 bis 80 Prozent reduzieren – und das innerhalb weniger Minuten, ganz ohne Codeänderungen. Der zweite große Hebel ist Server-seitiges Caching mit Redis oder Varnish, das die Server-Verarbeitungszeit um 90+ Prozent senken kann. Das braucht etwas mehr Implementierungsaufwand, lohnt sich aber fast immer.

Warum ist meine TTFB auf Mobilgeräten so viel schlechter als auf Desktop?

Mobile Verbindungen haben typischerweise eine höhere Latenz (40–100 ms vs. 5–20 ms bei Kabel/Glasfaser), häufigere Verbindungsabbrüche und langsamere DNS-Auflösung. Dazu kommt, dass Mobilfunknetze DNS-Anfragen über eigene Resolver leiten können, was weitere Verzögerungen verursacht. Die wirksamsten Gegenmaßnahmen: CDN-Nutzung (kürzere physische Distanz), HTTP/3 mit QUIC (schnellerer Verbindungsaufbau, bessere Handhabung von Paketverlust) und Preconnect-Hints für kritische Domains.

Wie unterscheidet sich TTFB von der Server Response Time in Lighthouse?

Die Server Response Time in Lighthouse misst speziell die Zeit, die der Server für die Verarbeitung der Hauptdokument-Anfrage braucht. TTFB umfasst zusätzlich die Netzwerkphasen (DNS, TCP, TLS). Lighthouse markiert die Server Response Time als problematisch ab 600 ms. Beide Metriken sind verwandt, aber TTFB gibt Ihnen das vollständigere Bild, da sie auch Netzwerk- und DNS-Probleme aufdeckt, die außerhalb der reinen Server-Verarbeitung liegen.

Über den Autor Editorial Team

Our team of expert writers and editors.