TTFB: Warum Time To First Byte sowohl für SEO als auch für LLMs wichtig ist

Time To First Byte (TTFB) ist eine der kritischsten, aber am häufigsten übersehenen Performance-Metriken für Websites. Während sich die meisten auf die Ladezeit der Seite oder das visuelle Rendering konzentrieren, ist die TTFB der erste Indikator dafür, wie responsive Ihre Seite ist – und das ist sowohl für Suchmaschinen als auch für AI-Crawler von Bedeutung. Eine langsame TTFB kann dazu führen, dass AI-Systeme weniger Seiten crawlen, Ihre Inhalte niedriger priorisieren oder das Crawlen Ihrer Seite komplett abbrechen. Dieser Guide erklärt, was TTFB ist, warum es wichtig ist und wie Sie es optimieren.

Was ist TTFB?

Time To First Byte (TTFB) ist die Zeit vom Absenden einer HTTP-Anfrage durch einen Browser/Crawler bis zum Empfang des ersten Datenbytes vom Server.

Bestandteile der TTFB:

1. DNS-Lookup – Zeit für die Auflösung des Domainnamens in eine IP-Adresse

2. Verbindungsaufbau – Zeit für den Aufbau der TCP-Verbindung

3. SSL/TLS-Handshake – Zeit für den Aufbau der HTTPS-Verbindung (falls zutreffend)

4. Server-Verarbeitungszeit – Zeit, die der Server benötigt, um die Response zu generieren

5. Netzwerklatenz – Zeit, die das erste Byte für den Rückweg benötigt

Formel:

TTFB im Vergleich zu anderen Metriken

TTFB misst die Responsiveness des Servers, bevor Inhalte gesendet werden.

FCP (First Contentful Paint) misst, wann der erste visuelle Inhalt gerendert wird.

LCP (Largest Contentful Paint) misst, wann das Hauptelement geladen ist.

TTFB passiert zuerst – es ist das Fundament für alle anderen Performance-Metriken.

Warum TTFB für AI-Crawler wichtig ist

1. Crawler-Budgets

AI-Crawler (und Suchmaschinen) haben eine begrenzte Zeit pro Website. Wenn Ihre TTFB langsam ist, crawlen sie weniger Seiten, bevor ihr Zeitbudget abgelaufen ist.

Beispiel:

• Website A: TTFB = 200ms → Crawler kann 500 Seiten in 5 Minuten crawlen

• Website B: TTFB = 2000ms → Crawler kann nur 150 Seiten in 5 Minuten crawlen

Website A erhält 3x mehr Crawl-Abdeckung.

2. Crawl-Priorisierung

Crawler priorisieren schnelle Seiten. Wenn Ihre TTFB dauerhaft langsam ist, werden Crawler:

• Seltener wiederkehren

• Weniger Seiten pro Visit crawlen

• Die Websites von Mitbewerbern priorisieren

3. Datenqualität

Eine lange TTFB kann zu Timeouts führen. Die AI erhält unvollständige Daten oder bricht den Vorgang komplett ab.

Googles Richtlinien:

• Gute TTFB: < 600ms

• Akzeptable TTFB: 600ms - 1200ms

• Schlechte TTFB: > 1200ms

Das Gleiche gilt für AI-Crawler.

Warum TTFB auch für SEO wichtig ist

Google hat bestätigt, dass die TTFB indirekt über die Core Web Vitals (da sie den LCP beeinflusst) ein Ranking-Faktor ist.

Impact:

• Langsame TTFB → Langsamer LCP → Schlechteres Ranking

• Schnelle TTFB → Schneller LCP → Besseres Ranking

Messen Sie Ihre aktuelle TTFB

Browser DevTools (Chrome)

1. Öffnen Sie die Chrome DevTools (F12)

2. Gehen Sie zum Reiter Network

3. Laden Sie die Seite neu

4. Klicken Sie auf den ersten Request (normalerweise Ihr HTML-Dokument)

5. Prüfen Sie den Reiter Timing

Sie sehen Folgendes:

PageSpeed Insights

1. Gehen Sie auf https://pagespeed.web.dev/

2. Geben Sie Ihre URL ein

3. Prüfen Sie die "Antwortzeit des Servers" unter Diagnose

WebPageTest

1. Gehen Sie auf https://www.webpagetest.org/

2. Geben Sie Ihre URL ein und wählen Sie den Test-Standort

3. Prüfen Sie "Time to First Byte" in den Ergebnissen

WebPageTest zeigt außerdem:

• TTFB pro Request (nicht nur für das erste HTML)

• Detaillierte Aufschlüsselung von DNS, Connect, SSL, Wait

Command-Line-Test mit curl

# TTFB messen
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nSSL: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://ditwebsite.dk/

# Output:
# DNS: 0.015s
# Connect: 0.045s
# SSL: 0.132s
# TTFB: 0.456s
# Total: 0.612s

# TTFB messen
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nSSL: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://ditwebsite.dk/

# Output:
# DNS: 0.015s
# Connect: 0.045s
# SSL: 0.132s
# TTFB: 0.456s
# Total: 0.612s

# TTFB messen
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nSSL: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://ditwebsite.dk/

# Output:
# DNS: 0.015s
# Connect: 0.045s
# SSL: 0.132s
# TTFB: 0.456s
# Total: 0.612s

Python-Script für Bulk-Testing

import requests
import time

def measure_ttfb(url):
    start = time.time()
    r = requests.get(url, stream=True)
    ttfb = time.time() - start
    return ttfb * 1000  # In Millisekunden umrechnen

urls = [
    "https://ditwebsite.dk/",
    "https://ditwebsite.dk/products/",
    "https://ditwebsite.dk/blog/"
]

for url in urls:
    ttfb = measure_ttfb(url)
    print(f"{url}: {ttfb:.2f}ms")

import requests
import time

def measure_ttfb(url):
    start = time.time()
    r = requests.get(url, stream=True)
    ttfb = time.time() - start
    return ttfb * 1000  # In Millisekunden umrechnen

urls = [
    "https://ditwebsite.dk/",
    "https://ditwebsite.dk/products/",
    "https://ditwebsite.dk/blog/"
]

for url in urls:
    ttfb = measure_ttfb(url)
    print(f"{url}: {ttfb:.2f}ms")

import requests
import time

def measure_ttfb(url):
    start = time.time()
    r = requests.get(url, stream=True)
    ttfb = time.time() - start
    return ttfb * 1000  # In Millisekunden umrechnen

urls = [
    "https://ditwebsite.dk/",
    "https://ditwebsite.dk/products/",
    "https://ditwebsite.dk/blog/"
]

for url in urls:
    ttfb = measure_ttfb(url)
    print(f"{url}: {ttfb:.2f}ms")

Identifizieren Sie die Ursachen für eine langsame TTFB

Die TTFB gliedert sich in verschiedene Komponenten. Identifizieren Sie Engpässe:

1. DNS-Lookup (sollte < 20ms sein)

Problem: Langsamer DNS-Resolver.

Test:

Lösung:

• Schnellen DNS-Provider nutzen (Cloudflare DNS, Google DNS)

• DNS-Prefetching aktivieren:

<link rel="dns-prefetch" href="//ditwebsite.dk">

<link rel="dns-prefetch" href="//ditwebsite.dk">

<link rel="dns-prefetch" href="//ditwebsite.dk">

2. Verbindungsaufbau (sollte < 50ms sein)

Problem: Geografische Distanz zum Server oder langsames Netzwerk.

Lösung:

• Content Delivery Network (CDN) nutzen, um näher an Usern/Crawlern zu sein

• Anzahl der Verbindungen reduzieren (HTTP/2 hilft hierbei)

3. SSL/TLS-Handshake (sollte < 100ms sein)

Problem: Langsame SSL-Verhandlung.

Test:

openssl s_time -connect ditwebsite.dk:443 -www

openssl s_time -connect ditwebsite.dk:443 -www

openssl s_time -connect ditwebsite.dk:443 -www

Lösung:

• TLS 1.3 aktivieren (schnellerer Handshake)

• OCSP Stapling nutzen

• HTTP/2 oder HTTP/3 aktivieren

4. Server-Verarbeitungszeit (sollte < 200ms sein)

Problem: Langsames Backend oder langsame Datenbankabfragen.

Dies ist in der Regel der größte Engpass.

Identifizierung:

• Server-Logs auf langsame Requests prüfen

• APM-Tools verwenden (New Relic, Datadog)

• Datenbankabfragen profilen

Server-Verarbeitungszeit optimieren

Hier erzielen Sie den größten Hebel.

1. Caching implementieren

Serverseitiges Caching:

Nutzen Sie Redis oder Memcached, um Datenbankergebnisse zu cachen.

Beispiel (PHP mit Redis):

<?php
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);

$cache_key = 'homepage_data';
$data = $redis->get($cache_key);

if (!$data) {
    // Daten nicht im Cache, aus Datenbank laden
    $data = fetch_from_database();
    $redis->setex($cache_key, 3600, serialize($data));  // Für 1 Stunde cachen
} else {
    $data = unserialize($data);
}

echo json_encode($data);

<?php
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);

$cache_key = 'homepage_data';
$data = $redis->get($cache_key);

if (!$data) {
    // Daten nicht im Cache, aus Datenbank laden
    $data = fetch_from_database();
    $redis->setex($cache_key, 3600, serialize($data));  // Für 1 Stunde cachen
} else {
    $data = unserialize($data);
}

echo json_encode($data);

<?php
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);

$cache_key = 'homepage_data';
$data = $redis->get($cache_key);

if (!$data) {
    // Daten nicht im Cache, aus Datenbank laden
    $data = fetch_from_database();
    $redis->setex($cache_key, 3600, serialize($data));  // Für 1 Stunde cachen
} else {
    $data = unserialize($data);
}

echo json_encode($data);

Full-Page Caching:

Cachen Sie komplette HTML-Responses.

Nginx-Beispiel:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;

server {
    location / {
        proxy_cache my_cache;
        proxy_cache_valid 200 60m;
        proxy_cache_key "$scheme$request_method$host$request_uri";
        proxy_pass http

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;

server {
    location / {
        proxy_cache my_cache;
        proxy_cache_valid 200 60m;
        proxy_cache_key "$scheme$request_method$host$request_uri";
        proxy_pass http

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m;

server {
    location / {
        proxy_cache my_cache;
        proxy_cache_valid 200 60m;
        proxy_cache_key "$scheme$request_method$host$request_uri";
        proxy_pass http

2. Datenbankabfragen optimieren

Problem: N+1-Abfragen oder nicht indizierte Abfragen.

Langsame Abfragen identifizieren (MySQL):

-- Slow-Query-Log aktivieren
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;  -- Abfragen über 1 Sekunde

-- Langsame Abfragen anzeigen
SELECT * FROM

-- Slow-Query-Log aktivieren
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;  -- Abfragen über 1 Sekunde

-- Langsame Abfragen anzeigen
SELECT * FROM

-- Slow-Query-Log aktivieren
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;  -- Abfragen über 1 Sekunde

-- Langsame Abfragen anzeigen
SELECT * FROM

Lösungen:

• Indizes hinzufügen:

-- Vorher: Full Table Scan
SELECT * FROM products WHERE category = 'electronics';

-- Nachher: Index erstellen
CREATE INDEX idx_category ON products(category)

-- Vorher: Full Table Scan
SELECT * FROM products WHERE category = 'electronics';

-- Nachher: Index erstellen
CREATE INDEX idx_category ON products(category)

-- Vorher: Full Table Scan
SELECT * FROM products WHERE category = 'electronics';

-- Nachher: Index erstellen
CREATE INDEX idx_category ON products(category)

• Query Caching nutzen:

-- Query Cache aktivieren (MySQL 5.7)
SET GLOBAL query_cache_size = 67108864;  -- 64MB
SET GLOBAL query_cache_type = ON

-- Query Cache aktivieren (MySQL 5.7)
SET GLOBAL query_cache_size = 67108864;  -- 64MB
SET GLOBAL query_cache_type = ON

-- Query Cache aktivieren (MySQL 5.7)
SET GLOBAL query_cache_size = 67108864;  -- 64MB
SET GLOBAL query_cache_type = ON

• JOINs optimieren:

-- Schlecht: Mehrere Joins ohne passende Indizes
SELECT * FROM orders
JOIN users ON orders.user_id = users.id
JOIN products ON orders.product_id = products.id
WHERE users.country = 'DK';

-- Gut: Composite-Indizes hinzufügen
CREATE INDEX idx_user_country ON users(country, id);
CREATE INDEX idx_product_id ON products(id)

-- Schlecht: Mehrere Joins ohne passende Indizes
SELECT * FROM orders
JOIN users ON orders.user_id = users.id
JOIN products ON orders.product_id = products.id
WHERE users.country = 'DK';

-- Gut: Composite-Indizes hinzufügen
CREATE INDEX idx_user_country ON users(country, id);
CREATE INDEX idx_product_id ON products(id)

-- Schlecht: Mehrere Joins ohne passende Indizes
SELECT * FROM orders
JOIN users ON orders.user_id = users.id
JOIN products ON orders.product_id = products.id
WHERE users.country = 'DK';

-- Gut: Composite-Indizes hinzufügen
CREATE INDEX idx_user_country ON users(country, id);
CREATE INDEX idx_product_id ON products(id)

3. Server-Ressourcen upgraden

Server-Auslastung prüfen:

top
# CPU- und Memory-Auslastung anzeigen

htop
# Benutzerfreundlichere Alternative

top
# CPU- und Memory-Auslastung anzeigen

htop
# Benutzerfreundlichere Alternative

top
# CPU- und Memory-Auslastung anzeigen

htop
# Benutzerfreundlichere Alternative

Bei dauerhaft hoher Auslastung (>80% CPU):

• CPU upgraden

• Mehr RAM hinzufügen

• Load Balancing einsetzen

4. Ein CDN nutzen

Content Delivery Networks cachen Inhalte geografisch nah an Ihren Usern und Crawlern.

Bekannte CDNs:

• Cloudflare – Kostenloser Tarif verfügbar, hervorragend für kleine bis mittlere Seiten

• AWS CloudFront – Extrem skalierbar

• Fastly – Starke Performance, technischer Fokus

• BunnyCDN – Sehr budgetfreundlich

Wie ein CDN die TTFB verbessert:

Ohne CDN:

• Ein User in den USA ruft eine in Europa gehostete Seite auf

• TTFB = 500ms (200ms Netzwerklatenz + 300ms Server-Verarbeitung)

Mit CDN:

• User in den USA sendet Request → CDN-Edge-Server in den USA antwortet

• TTFB = 150ms (20ms Netzwerklatenz + 130ms Cache-Hit)

5. Gzip/Brotli-Komprimierung aktivieren

Komprimierung reduziert die Response-Größe und beschleunigt so die Transferzeit.

Nginx-Konfiguration:

gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
gzip_min_length 256;
gzip_comp_level 6;

# Noch besser: Brotli
brotli on;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text

gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
gzip_min_length 256;
gzip_comp_level 6;

# Noch besser: Brotli
brotli on;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text

gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
gzip_min_length 256;
gzip_comp_level 6;

# Noch besser: Brotli
brotli on;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text

Apache-Konfiguration:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/json
</IfModule>

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/json
</IfModule>

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/json
</IfModule>

6. Serverseitige Verarbeitung reduzieren

Minimieren Sie:

• Aufwendige Berechnungen bei jedem Request

• Externe API-Calls

• Datei-I/O-Operationen

Beispiel (Python Flask):

from flask import Flask, render_template
from functools import lru_cache
import requests

app = Flask(__name__)

# Schlecht: Externer API-Call bei jedem Request
@app.route('/weather')
def weather_bad():
    response = requests.get('https://api.weather.com/data')
    return render_template('weather.html', data=response.json())

# Gut: Externen API-Call cachen
@lru_cache(maxsize=128)
def fetch_weather_cached():
    response = requests.get('https://api.weather.com/data')
    return response.json()

@app.route('/weather')
def weather_good():
    data = fetch_weather_cached()
    return render_template('weather.html', data=data)

from flask import Flask, render_template
from functools import lru_cache
import requests

app = Flask(__name__)

# Schlecht: Externer API-Call bei jedem Request
@app.route('/weather')
def weather_bad():
    response = requests.get('https://api.weather.com/data')
    return render_template('weather.html', data=response.json())

# Gut: Externen API-Call cachen
@lru_cache(maxsize=128)
def fetch_weather_cached():
    response = requests.get('https://api.weather.com/data')
    return response.json()

@app.route('/weather')
def weather_good():
    data = fetch_weather_cached()
    return render_template('weather.html', data=data)

from flask import Flask, render_template
from functools import lru_cache
import requests

app = Flask(__name__)

# Schlecht: Externer API-Call bei jedem Request
@app.route('/weather')
def weather_bad():
    response = requests.get('https://api.weather.com/data')
    return render_template('weather.html', data=response.json())

# Gut: Externen API-Call cachen
@lru_cache(maxsize=128)
def fetch_weather_cached():
    response = requests.get('https://api.weather.com/data')
    return response.json()

@app.route('/weather')
def weather_good():
    data = fetch_weather_cached()
    return render_template('weather.html', data=data)

7. HTTP/2 oder HTTP/3 nutzen

HTTP/2 ermöglicht Multiplexing, was den Verbindungs-Overhead deutlich reduziert.

HTTP/2 aktivieren (Nginx):

server {
    listen 443 ssl http2;
    server_name ditwebsite.dk;
    # ... rest of config

server {
    listen 443 ssl http2;
    server_name ditwebsite.dk;
    # ... rest of config

server {
    listen 443 ssl http2;
    server_name ditwebsite.dk;
    # ... rest of config

Prüfen, ob HTTP/2 aktiv ist:

curl -I --http2 https://ditwebsite.dk/
# Suchen Sie nach "HTTP/2 200" in der Response

curl -I --http2 https://ditwebsite.dk/
# Suchen Sie nach "HTTP/2 200" in der Response

curl -I --http2 https://ditwebsite.dk/
# Suchen Sie nach "HTTP/2 200" in der Response

Speziell für AI-Crawler optimieren

1. Wichtige Seiten priorisieren

Stellen Sie sicher, dass Ihre wichtigsten Seiten (Homepage, Key-Products, Top-Artikel) die schnellste TTFB haben.

Nginx: Separater Cache für Key-Pages:

location = / {
    proxy_cache_valid 200 120m;  # Homepage für 2 Stunden cachen
    proxy_pass http://backend;
}

location /products/ {
    proxy_cache_valid 200 60m;  # Produkte für 1 Stunde cachen
    proxy_pass http

location = / {
    proxy_cache_valid 200 120m;  # Homepage für 2 Stunden cachen
    proxy_pass http://backend;
}

location /products/ {
    proxy_cache_valid 200 60m;  # Produkte für 1 Stunde cachen
    proxy_pass http

location = / {
    proxy_cache_valid 200 120m;  # Homepage für 2 Stunden cachen
    proxy_pass http://backend;
}

location /products/ {
    proxy_cache_valid 200 60m;  # Produkte für 1 Stunde cachen
    proxy_pass http

2. Crawler erkennen und gezielt optimieren

Gecachte Version direkt an Crawler ausliefern:

<?php
$user_agent = $_SERVER['HTTP_USER_AGENT'];

$is_crawler = preg_match('/GPTBot|ClaudeBot|CCBot|Googlebot|bingbot/i', $user_agent);

if ($is_crawler) {
    // Statisch gecachtes HTML ausliefern
    echo file_get_contents('/cache/static_page.html');
} else {
    // Dynamische Inhalte ausliefern
    include('dynamic_page.php');
}

<?php
$user_agent = $_SERVER['HTTP_USER_AGENT'];

$is_crawler = preg_match('/GPTBot|ClaudeBot|CCBot|Googlebot|bingbot/i', $user_agent);

if ($is_crawler) {
    // Statisch gecachtes HTML ausliefern
    echo file_get_contents('/cache/static_page.html');
} else {
    // Dynamische Inhalte ausliefern
    include('dynamic_page.php');
}

<?php
$user_agent = $_SERVER['HTTP_USER_AGENT'];

$is_crawler = preg_match('/GPTBot|ClaudeBot|CCBot|Googlebot|bingbot/i', $user_agent);

if ($is_crawler) {
    // Statisch gecachtes HTML ausliefern
    echo file_get_contents('/cache/static_page.html');
} else {
    // Dynamische Inhalte ausliefern
    include('dynamic_page.php');
}

3. Cache vor Crawler-Besuchen vorwärmen (Pre-warming)

Wenn Sie wissen, wann Crawler Ihre Seite besuchen (z. B. nach dem Einreichen einer Sitemap), können Sie den Cache vorwärmen:

#!/bin/bash
# Cache vorwärmen durch Request aller URLs
while read url; do
  curl -s "$url" > /dev/null
done

#!/bin/bash
# Cache vorwärmen durch Request aller URLs
while read url; do
  curl -s "$url" > /dev/null
done

#!/bin/bash
# Cache vorwärmen durch Request aller URLs
while read url; do
  curl -s "$url" > /dev/null
done

TTFB kontinuierlich monitoren

Automatisches Monitoring einrichten

Pingdom:

1. Erstellen Sie einen Account unter pingdom.com

2. Fügen Sie URL-Checks hinzu

3. Definieren Sie einen Alert-Schwellenwert (z. B. "alert if TTFB > 800ms")

UptimeRobot:

1. Kostenloses Monitoring alle 5 Minuten

2. E-Mail-Alerts bei Ausfällen oder Verzögerungen

Eigenes Script (Cronjob):

#!/bin/bash
# TTFB prüfen und alarmieren, wenn > 1000ms
TTFB=$(curl -o /dev/null -s -w '%{time_starttransfer}' https://ditwebsite.dk/)
TTFB_MS=$(echo "$TTFB * 1000" | bc)

if (( $(echo "$TTFB_MS > 1000" | bc -l) )); then
  echo "TTFB too high: ${TTFB_MS}ms" | mail -s "TTFB Alert" admin@ditwebsite.dk
fi

#!/bin/bash
# TTFB prüfen und alarmieren, wenn > 1000ms
TTFB=$(curl -o /dev/null -s -w '%{time_starttransfer}' https://ditwebsite.dk/)
TTFB_MS=$(echo "$TTFB * 1000" | bc)

if (( $(echo "$TTFB_MS > 1000" | bc -l) )); then
  echo "TTFB too high: ${TTFB_MS}ms" | mail -s "TTFB Alert" admin@ditwebsite.dk
fi

#!/bin/bash
# TTFB prüfen und alarmieren, wenn > 1000ms
TTFB=$(curl -o /dev/null -s -w '%{time_starttransfer}' https://ditwebsite.dk/)
TTFB_MS=$(echo "$TTFB * 1000" | bc)

if (( $(echo "$TTFB_MS > 1000" | bc -l) )); then
  echo "TTFB too high: ${TTFB_MS}ms" | mail -s "TTFB Alert" admin@ditwebsite.dk
fi

Stündlich ausführen:

crontab -e
# Hinzufügen:
0

crontab -e
# Hinzufügen:
0

crontab -e
# Hinzufügen:
0

TTFB-Zielwerte

Googles Empfehlungen

• Gut: < 600ms

• Verbesserungswürdig: 600ms - 1200ms

• Schlecht: > 1200ms

Für AI-Crawler (Empfehlungen)

• Exzellent: < 300ms (erhält höchste Crawl-Priorität)

• Gut: 300ms - 600ms (normale Crawl-Rate)

• Akzeptabel: 600ms - 1000ms (niedrigere Crawl-Rate)

• Schlecht: > 1000ms (Risiko von unvollständigen Crawls)

Häufige TTFB-Probleme und Lösungen

Implementierungs-Checkliste

Nutzen Sie diese Checkliste zur Verbesserung Ihrer TTFB:

1. Ausgangswert (Baseline) messen – Nutzen Sie PageSpeed Insights oder WebPageTest

2. Engpässe identifizieren – DNS, Verbindung, SSL oder Server-Verarbeitung?

3. Serverseitiges Caching implementieren – Redis/Memcached für Datenbankergebnisse nutzen

4. Full-Page Caching aktivieren – Für statische oder semi-statische Seiten

5. Datenbankabfragen optimieren – Indizes hinzufügen, N+1-Abfragen eliminieren

6. Gzip/Brotli aktivieren – Responses komprimieren

7. CDN nutzen – Cloudflare, AWS CloudFront oder BunnyCDN einrichten

8. HTTP/2 aktivieren – Verbindungs-Overhead minimieren

9. TTFB überwachen – Pingdom oder eigenes Monitoring einrichten

10. Mit curl testen – Verbesserungen verifizieren

Fazit

Die TTFB ist eine kritische Metrik sowohl für SEO als auch für die Sichtbarkeit in AI-Systemen. Eine langsame TTFB führt zu weniger gecrawlten Seiten, einer niedrigeren Priorisierung und potenziell unvollständigen Daten für Large Language Models. Die meisten Websites können ihre TTFB durch Caching (serverseitig und Full-Page), Datenbankoptimierung und den Einsatz eines CDNs drastisch verbessern.

Messen Sie zunächst Ihre aktuelle TTFB, identifizieren Sie den größten Bottleneck (meist die Server-Verarbeitungszeit) und implementieren Sie Caching. Für die meisten Seiten ist es möglich, mit grundlegenden Optimierungen unter 600ms zu kommen – und mit einem CDN sowie aggressivem Caching sogar unter 300ms.

Denken Sie daran: Die TTFB ist das Fundament – alle anderen Performance-Metriken bauen darauf auf. Optimieren Sie zuerst die TTFB, danach FCP und LCP.