TTFB
TTFB (Time to First Byte) misst, wie lange der Server braucht, bis das erste Zeichen der Seite ankommt. Es ist die reinste Server-Geschwindigkeit — vor jedem Bild, vor jedem Skript. Ziel: unter 800 ms, ideal unter 400 ms.
Warum Google das bewertet
Der TTFB ist der Grundpreis jeder Ladezeit: Alles Weitere wartet darauf. Google misst ihn als Core Web Vital und Nutzer springen bei langsamem Start sofort ab (nach 3 Sekunden Ladezeit verliert man die Hälfte der Besucher). Langsamer Server = langsamere Seite = schlechtere Rankings, unabhängig vom Inhalt.
So behebst du es
1) Caching aktivieren: Bei WordPress ein Caching-Plugin (LiteSpeed Cache, WP Super Cache), beim Hoster oft ein Schalter. 2) PHP-Version aktualisieren (8.x ist doppelt so schnell wie 7.x). 3) Ein CDN wie Cloudflare (Free-Plan reicht) vor die Seite schalten — das weltweit nächste Kopie antwortet dann. 4) Danach erneut messen: PageSpeed Insights zeigt den Wert.
Die Server-Antwortzeit liegt im gelben Bereich
Die Server-Antwortzeit liegt im gelben Bereich (800 bis 1500 ms). Nicht kritisch, aber messbar langsamer als nötig — Besucher merken das als „die Seite hängt kurz“.
Warum Google das bewertet
Zwischen 800 und 1500 ms TTFB verliert man schon messbare Besucher und verpasst den Core-Web-Vitals-Bereich, in dem Google Bonus gibt. Die Fixe sind meist billig: Caching und ein CDN reichen in 80 Prozent der Fälle.
So behebst du es
1) Caching aktivieren (Plugin oder Hoster-Schalter) — der größte Einzelhebel. 2) Cloudflare free vor die Seite schalten. 3) Bei WordPress: Plugin-Anzahl prüfen, jedes trägt bei. 4) Nach einer Woche erneut scannen und vergleichen.
Gzip
Gzip (oder Brotli) komprimiert die HTML-Datei vor der Auslieferung — der Browser entpackt sie in Millisekunden. Eine 40-KB-Seite wird so zu rund 10 KB Übertragung.
Warum Google das bewertet
Ohne Komprimierung überträgst du jede Seite 3- bis 5-fach so groß wie nötig. Auf Mobilfunk (dein typischer Besucher!) sind das spürbare Sekunden. Google bewertet die Übertragungsgröße in den Core Web Vitals. Die Komprimierung kostet einmal 5 Minuten Einrichtung — danach dauerhaft schnellere Seiten ohne jeden Nachteil.
So behebst du es
1) nginx: gzip on; + gzip_types text/css application/javascript … in der Server-Konfiguration. 2) Apache: mod_deflate aktivieren (in .htaccess). 3) Bei managed Hostern ist es meist ein Schalter im Panel. 4) Teste mit checkgzip.com oder den Browser-DevTools (Netzwerk-Tab: Spalte „Größe“ vs. „Transfer“).
# nginx:
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;
gzip_min_length 1000;
Das HTML der Seite ist sehr groß
Das HTML der Seite ist sehr groß (über 250 KB komprimiert oder unkomprimiert auffällig). Meist stecken Plugin-Reste, Inline-Stile, eingebettete SVG-Bilder oder Page-Builder-Müll darin.
Warum Google das bewertet
Großes HTML verlängert jede Ladezeit — es muss heruntergeladen, geparst und ausgeführt werden, bevor der Besucher etwas sieht. Ab 500 KB HTML leidet die Nutzererfahrung messbar. Und: Was im HTML steckt, muss der Browser alles verarbeiten — auch auf schwachen Handy-Prozessoren.
So behebst du es
1) Öffne die DevTools (F12 → Netzwerk) und schau, was die 250 KB ausmacht. 2) Page-Builder: Elemente löschen, die nicht mehr genutzt werden; Builder-CSS aufräumen. 3) Inline-SVGs und riesige Inline-Stile in externe Dateien auslagern. 4) Bei WordPress: ungenutzte Widgets/Shortcodes entfernen.
Im <head> der Seite stehen mehrere JavaScript-Dateien ohne defer oder async. Jede davon hält den Seitenaufbau an: Erst m
Im <head> der Seite stehen mehrere JavaScript-Dateien ohne defer oder async. Jede davon hält den Seitenaufbau an: Erst muss die Datei geladen und ausgeführt sein, dann erst zeichnet der Browser weiter.
Warum Google das bewertet
Blockierende Scripts sind die häufigste Ursache für das Gefühl „die Seite ist weiß, dann springt alles rein“. Jede Sekunde Weiß = Besucher-Verlust. Google misst genau diesen Moment als FCP (First Contentful Paint).
So behebst du es
1) Liste die Scripts im <head> auf. 2) Bei jedem, das nicht sofort beim Rendern gebraucht wird (Analytics, Chat-Widgets, schöne Effekte): attribute defer hinzufügen. 3) Absolute Blocker (Chat-Widget!) ans Ende des <body> verschieben. 4) Danach erneut messen: PageSpeed Insights → FCP sollte springen.
<script src="/analytics.js" defer></script> <!-- blockiert nicht mehr -->
WebP und AVIF sind moderne Bildformate: gleiches Bild, 30 bis 80 Prozent kleinere Datei als JPG/PNG. Alle modernen Brows
WebP und AVIF sind moderne Bildformate: gleiches Bild, 30 bis 80 Prozent kleinere Datei als JPG/PNG. Alle modernen Browser beherrschen sie — es gibt keinen Grund mehr für JPG.
Warum Google das bewertet
Bilder sind meist der größte Teil einer Seite. Alte Formate kosten Besucher Sekunden Ladezeit auf Mobilfunk und verderben die Core Web Vitals (LCP misst das größte Bild). Konvertierung ist der schnellste Speed-Gewinn ohne Design-Änderung.
So behebst du es
1) Einzeln: squoosh.app (kostenlos, im Browser) — Bild rein, WebP herunter, Quelle ersetzen. 2) Batch: cwebp-Tool oder Plugin (bei WordPress: „Imagify“/„ShortPixel“ konvertiert automatisch). 3) Referenzen umschreiben oder <picture>-Fallback für alte Browser. 4) Danach erneut scannen — die LCP-Zahl fällt spürbar.
<picture>
<source srcset="bild.webp" type="image/webp">
<img src="bild.jpg" alt="Beschreibung" loading="lazy">
</picture>
Lazy-loading lädt Bilder erst dann, wenn sie in den sichtbaren Bereich scrollen. Ein einziges HTML-Attribut: loading="la
Lazy-loading lädt Bilder erst dann, wenn sie in den sichtbaren Bereich scrollen. Ein einziges HTML-Attribut: loading="lazy". Alles unter dem ersten Bildschirm wird so erst geladen, wenn es gebraucht wird.
Warum Google das bewertet
Ohne lazy lädt ein Besucher sofort ALLE Bilder — auch die 10 Bilder ganz unten, die er nie sieht. Das verschwendet Daten und Zeit auf Kosten der oberen Seite. Mit lazy startet die Seite sichtbar schneller, besonders auf Mobilfunk. Der erste Bildschirm bleibt unangetastet.
So behebst du es
1) Alle Bilder unterhalb des ersten Bildschirms bekommen loading="lazy" im img-Tag. 2) Das Hero-Bild (ganz oben) NIEMALS lazy — im Gegenteil: fetchpriority="high" fürs LCP-Bild. 3) Fertig. Test: DevTools → Netzwerk → scrollen und beobachten, wie Bilder nachladen.
<img src="bild.jpg" alt="Beschreibung" loading="lazy">
Cache-Control-Header sagen dem Browser: „Dieses Bild/CSS/JS darfst du X Tage behalten und nicht erneut herunterladen“. W
Cache-Control-Header sagen dem Browser: „Dieses Bild/CSS/JS darfst du X Tage behalten und nicht erneut herunterladen“. Wiederkehrende Besucher laden dann nur die Seite selbst neu — alles andere kommt aus dem Cache.
Warum Google das bewertet
Ohne Cache-Headers lädt ein zweiter Besucher ALLES neu herunter — Bilder, Schriften, Skripte. MitCache-Headers ist der zweite Besuch fast sofort da. Google belohnt wiederkehrende Schnelligkeit, und du sparst Transfer-Kosten beim Hoster.
So behebst du es
1) nginx: location ~* \.(jpg|png|css|js)$ { expires 1y; add_header Cache-Control "public, immutable"; } 2) Apache: mod_expires in .htaccess. 3) Achtung: Nur statische Dateien (Bilder, CSS, JS) lange cachen — HTML kurz oder gar nicht, sonst sehen Besucher Änderungen erst zu spät. 4) Test: DevTools → Netzwerk → zweiter Reload: Dateien mit „(from disk cache)“.
# nginx: statische Dateien 1 Jahr cachen
location ~* \.(jpg|jpeg|png|webp|css|js|woff2)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}