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

Time To First Byte (TTFB) ist einer 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 wichtig. Eine langsame TTFB kann dazu führen, dass AI-Systeme weniger Seiten crawlen, Ihre Inhalte niedriger priorisieren oder das Crawling Ihrer Seite komplett abbrechen. Dieser Guide erklärt, was die TTFB ist, warum sie wichtig ist und wie Sie sie optimieren.

Was ist die TTFB?

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

Komponenten der TTFB:

1. DNS-Lookup — Zeit zur Übersetzung des Domainnamens in eine IP-Adresse

2. Verbindungsaufbau (Connection time) — Zeit zum Aufbau der TCP-Verbindung

3. SSL/TLS-Handshake — Zeit zum Aufbau einer HTTPS-Verbindung (falls zutreffend)

4. Server-Processing-Time — Zeit, die der Server zur Generierung der Antwort benötigt

5. Netzwerklatenz — Zeit, die das erste Byte benötigt, um zurückzureisen

Formel:

TTFB vs. andere Metriken

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

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

Der LCP (Largest Contentful Paint) misst, wann das Haupt-Element geladen ist.

Die TTFB passiert zuerst – sie ist das Fundament für alle anderen Ladezeit-Metriken.

Warum die 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:

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

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

Site A erzielt eine 3x höhere Crawl-Coverage.

2. Crawl-Priorisierung

Crawler priorisieren schnelle Websites. 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 das Crawling komplett ab.

Googles Empfehlung:

• Gute TTFB: < 600 ms

• Akzeptable TTFB: 600 ms - 1200 ms

• Schlechte TTFB: > 1200 ms

Dasselbe gilt für AI Crawler.

Warum die TTFB auch für SEO wichtig ist

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

Auswirkung:

• 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 (Netzwerk)

3. Laden Sie die Seite neu

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

5. Öffnen 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" (Server response time) unter Diagnostik

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 die "Time to First Byte" in den Ergebnissen

WebPageTest zeigt außerdem:

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

• Das Breakdown von DNS, Connect, SSL, Wait

Kommandozeilen-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-Skript für Bulk-Tests

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, was Ihre TTFB verlangsamt

Die TTFB unterteilt sich in mehrere Komponenten. Identifizieren Sie Bottlenecks:

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

Problem: Langsamer DNS-Resolver.

Test:

Lösung:

• Nutzen Sie einen schnellen DNS-Anbieter (Cloudflare DNS, Google DNS)

• Aktivieren Sie DNS-Prefetching:

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

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

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

2. Verbindungszeit (sollte < 50 ms sein)

Problem: Geografische Entfernung zum Server oder langsames Netzwerk.

Lösung:

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

• Reduzieren Sie die Anzahl der Verbindungen (HTTP/2 hilft hierbei)

3. SSL/TLS-Handshake (sollte < 100 ms 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:

• Aktivieren Sie TLS 1.3 (schnellerer Handshake)

• Nutzen Sie OCSP-Stapling

• Aktivieren Sie HTTP/2 oder HTTP/3

4. Server-Processing-Time (sollte < 200 ms sein)

Problem: Langsames Backend oder langsame Datenbankabfragen.

Dies ist in den meisten Fällen das größte Bottleneck.

Identifizieren:

• Prüfen Sie die Server-Logs auf langsame Requests

• Nutzen Sie APM-Tools (New Relic, Datadog)

• Profile von Datenbankabfragen erstellen

Server-Processing-Time optimieren

Hier erzielen Sie die größte Wirkung.

1. Caching implementieren

Serverseitiges Caching:

Nutzen Sie Redis oder Memcached, um DB-Ergebnisse 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 Cache:

Cachen Sie vollständige HTML-Antworten.

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 Cache aktivieren:

-- 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: Multiple Joins ohne richtige 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: Multiple Joins ohne richtige 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: Multiple Joins ohne richtige 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-Load prüfen:

top
# CPU- und Memory-Auslastung prüfen

htop
# Benutzerfreundlichere Alternative

top
# CPU- und Memory-Auslastung prüfen

htop
# Benutzerfreundlichere Alternative

top
# CPU- und Memory-Auslastung prüfen

htop
# Benutzerfreundlichere Alternative

Bei dauerhaft hoher Auslastung (>80% CPU):

• CPU upgraden

• Mehr RAM hinzufügen

• Load Balancing einrichten

4. Ein CDN nutzen

Content Delivery Networks cachen Inhalte geografisch nah am User bzw. Crawler.

Beliebte CDNs:

• Cloudflare — Kostenloser Tarif verfügbar, hervorragend für kleine bis mittlere Websites

• AWS CloudFront — Hochgradig skalierbar

• Fastly — Spitzen-Performance, technischerer Ansatz

• BunnyCDN — Budgetfreundlich

Wie ein CDN die TTFB verbessert:

Ohne CDN:

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

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

Mit CDN:

• User in den USA fragt an → CDN-Edge-Server in den USA antwortet

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

5. Gzip/Brotli-Komprimierung aktivieren

Komprimierung reduziert die Antwortgröße und beschleunigt die Übertragungszeit.

Nginx-Config:

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-Config:

<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. Serverseitiges Processing reduzieren

Minimieren Sie:

• Aufwendige Berechnungen pro 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 reduziert.

HTTP/2 aktivieren (Nginx):

server {
    listen 443 ssl http2;
    server_name ditwebsite.dk;
    # ... restliche Config

server {
    listen 443 ssl http2;
    server_name ditwebsite.dk;
    # ... restliche Config

server {
    listen 443 ssl http2;
    server_name ditwebsite.dk;
    # ... restliche Config

Testen, ob HTTP/2 aktiviert ist:

curl -I --http2 https://ditwebsite.dk/
# Nach "HTTP/2 200" in der Antwort suchen

curl -I --http2 https://ditwebsite.dk/
# Nach "HTTP/2 200" in der Antwort suchen

curl -I --http2 https://ditwebsite.dk/
# Nach "HTTP/2 200" in der Antwort suchen

Speziell für AI Crawler optimieren

1. Wichtige Seiten priorisieren

Stellen Sie sicher, dass Ihre wichtigsten Seiten (Homepage, Bestseller-Produkte, Top-Artikel) die schnellste TTFB aufweisen.

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 für sie optimieren

Gecachte Version 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) {
    // Statisches, gecachtes HTML ausliefern
    echo file_get_contents('/cache/static_page.html');
} else {
    // Dynamischen Content 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) {
    // Statisches, gecachtes HTML ausliefern
    echo file_get_contents('/cache/static_page.html');
} else {
    // Dynamischen Content 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) {
    // Statisches, gecachtes HTML ausliefern
    echo file_get_contents('/cache/static_page.html');
} else {
    // Dynamischen Content ausliefern
    include('dynamic_page.php');
}

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

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

#!/bin/bash
# Cache aufwärmen, indem alle URLs angefragt werden
while read url; do
  curl -s "$url" > /dev/null
done

#!/bin/bash
# Cache aufwärmen, indem alle URLs angefragt werden
while read url; do
  curl -s "$url" > /dev/null
done

#!/bin/bash
# Cache aufwärmen, indem alle URLs angefragt werden
while read url; do
  curl -s "$url" > /dev/null
done

TTFB kontinuierlich überwachen

Automatisiertes Monitoring einrichten

Pingdom:

1. Erstellen Sie einen Account auf pingdom.com

2. Fügen Sie URL-Checks hinzu

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

UptimeRobot:

1. Kostenloses Monitoring alle 5 Minuten

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

Eigenes Skript (Cronjob):

#!/bin/bash
# TTFB prüfen und alerten, 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 alerten, 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 alerten, 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

Jede Stunde ausführen:

crontab -e
# Hinzufügen:
0

crontab -e
# Hinzufügen:
0

crontab -e
# Hinzufügen:
0

TTFB-Zielwerte

Googles Empfehlungen

• Gut: < 600 ms

• Verbesserungswürdig: 600 ms - 1200 ms

• Schlecht: > 1200 ms

Für AI Crawler (Empfehlungen)

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

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

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

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

Häufige TTFB-Probleme und Fixes

Implementation Checklist

Nutzen Sie diese Checklist, um Ihre TTFB zu verbessern:

1. Baseline-TTFB messen — Nutzen Sie PageSpeed Insights oder WebPageTest

2. Bottlenecks identifizieren — DNS, Verbindung, SSL oder Server-Processing?

3. Serverseitiges Caching einrichten — Redis/Memcached für Datenbank-Ergebnisse

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 — Antworten komprimieren

7. CDN nutzen — Cloudflare, AWS CloudFront oder BunnyCDN

8. HTTP/2 aktivieren — Verbindungs-Overhead reduzieren

9. TTFB überwachen — Pingdom oder eigenes Monitoring aufsetzen

10. Mit curl testen — Verbesserungen verifizieren

Fazit

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

Messen Sie als Erstes Ihre aktuelle TTFB, identifizieren Sie das größte Bottleneck (meist das Server-Processing) und implementieren Sie Caching. Für die meisten Websites ist es möglich, mit grundlegender Optimierung unter 600 ms und mit einem CDN sowie aggressivem Caching unter 300 ms zu kommen.

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