Pagespeed-Optimierung ist die Gesamtheit aller Maßnahmen, die dazu beitragen, eine Website schneller zu laden und eine bessere Nutzererfahrung zu liefern. Sie ist sowohl ein direkter SEO-Rankingfaktor als auch einer der stärksten Hebel für Conversion-Rate-Optimierung.
In einer Welt, in der 53 % der mobilen Nutzer eine Website verlassen, wenn sie länger als 3 Sekunden zum Laden braucht (Google-Studie), ist Pagespeed kein Nice-to-Have. Es ist ein wirtschaftlicher Imperativ.
Ladezeit-Faktoren: Was eine Website langsam macht
1. Server Response Time (TTFB)
Time to First Byte (TTFB) ist die Zeit, bis der Browser das erste Byte vom Server erhält. Eine hohe TTFB deutet auf:
- Langsamen Webhosting-Server
- Fehlende oder ineffiziente Caching-Konfiguration
- Nicht optimierte Datenbankabfragen (bei CMS wie WordPress)
- Fehlende CDN-Integration
Zielwert: TTFB < 200ms (Google-Empfehlung: < 600ms)
2. Render-Blocking Resources
JavaScript und CSS im <head> blockieren das Rendering der Seite, bis sie vollständig geladen sind. Jede blockierende Ressource verzögert sichtbaren Content.
Häufige Ursachen:
- Externe JavaScript-Libraries (jQuery, Bootstrap, Font-Libraries)
- CSS-Dateien ohne asynchrones Laden
- Google Fonts ohne Font-Display-Optimierung
- Third-Party-Scripts (Chat-Widgets, Tracking-Pixel)
Lösung: Nicht-kritisches JavaScript defer oder async laden; kritisches CSS inline einbetten; Google Fonts mit font-display: swap laden.
3. Bildgröße und -format
Bilder sind meist der größte Einzelfaktor für Seitengewicht.
Typische Probleme:
- Bilder in Originalgröße (5MB DSLR-Fotos statt optimierter 100KB-Version)
- JPEG/PNG statt moderner Formate (WebP, AVIF)
- Fehlende responsive Images (riesiges Bild für Mobile geladen)
- Keine Lazy Loading für Below-the-Fold-Bilder
4. JavaScript-Bundle-Größe
Zu großes JavaScript-Bundle verzögert den Time to Interactive (TTI) – den Moment, ab dem die Seite voll bedienbar ist.
Häufig bei:
- Ungenutzten npm-Packages (tree-shaking fehlt)
- Zu großen Frameworks für einfache Anforderungen
- Third-Party-Scripts ohne Bedarf
- Fehlender Code-Splitting (gesamtes Bundle auf einmal geladen)
5. Fehlende Caching-Konfiguration
Ohne Browser-Caching wird jede Ressource bei jedem Besuch neu geladen. Mit richtigem Caching werden statische Assets (Bilder, CSS, JavaScript) beim Folgebesuch aus dem Cache geladen.
6. Fehlende Komprimierung
Ohne GZIP oder Brotli-Komprimierung werden HTML, CSS und JavaScript in voller Größe übertragen. Komprimierung reduziert Textdateien um 60–80 %.
Google PageSpeed Insights: Scores verstehen
Google PageSpeed Insights (PSI) zeigt zwei Arten von Daten:
Lab-Daten (Lighthouse-Simulation)
- Gemessen unter kontrollierten Bedingungen (simuliertes Device, Netzwerk)
- Performance Score (0–100): Zusammenfassung der Lighthouse-Metriken
- Grün (90–100): Gut
- Gelb (50–89): Verbesserungswürdig
- Rot (0–49): Kritisch
Field-Daten (Chrome User Experience Report, CrUX)
- Echte Nutzerdaten aus Chrome-Browsern
- Repräsentiert die tatsächliche Erfahrung realer Besucher
- Für Google-Ranking-Zwecke relevanter als Lab-Daten
Wichtig: Ein hoher PSI-Score ist gut, aber nicht das einzige Ziel. Verbessern Sie die tatsächlichen Core Web Vitals Ihrer echten Nutzer.
Core Web Vitals: Die drei Schlüsselmetriken
Core Web Vitals sind Googles definierte Schlüsselmetriken für Seitenqualität und direkter Rankingfaktor seit 2021.
| Metrik | Beschreibung | Gut | Verbesserung nötig | Schlecht |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Ladezeit des größten sichtbaren Elements | < 2,5s | 2,5–4,0s | > 4,0s |
| INP (Interaction to Next Paint) | Reaktionszeit auf Nutzereingaben | < 200ms | 200–500ms | > 500ms |
| CLS (Cumulative Layout Shift) | Visuelle Stabilität (kein Spring-Effekt) | < 0,1 | 0,1–0,25 | > 0,25 |
Detaillierte Informationen zu den Core Web Vitals: Core Web Vitals
Optimierungstechniken im Detail
WebP und AVIF: Moderne Bildformate
WebP bietet bei gleicher visueller Qualität 25–35 % kleinere Dateigrößen als JPEG und 26 % kleiner als PNG. AVIF ist noch effizienter (ca. 50 % kleiner als JPEG), wird aber noch nicht von allen Browsern unterstützt.
Implementierung mit HTML Picture-Element:
<picture>
<source srcset="bild.avif" type="image/avif">
<source srcset="bild.webp" type="image/webp">
<img src="bild.jpg" alt="Beschreibung" loading="lazy">
</picture>
In Next.js: Die <Image>-Komponente konvertiert automatisch zu WebP/AVIF und generiert responsive Srcsets.
Lazy Loading
<!-- Native Browser Lazy Loading -->
<img src="bild.jpg" alt="Produkt" loading="lazy" width="800" height="600">
<!-- Nicht lazy laden: Hero-Bilder, LCP-Element -->
<img src="hero.jpg" alt="Hero" loading="eager" fetchpriority="high">
Wichtig: Das LCP-Element (Largest Contentful Paint, meist das Hero-Bild) darf nicht lazy geladen werden. Es sollte stattdessen mit fetchpriority="high" priorisiert werden.
Minification und Komprimierung
Minification entfernt Whitespace, Kommentare und unnötige Zeichen aus CSS, JavaScript und HTML. Komprimierung (GZIP oder Brotli) komprimiert Textdateien auf Server-Ebene.
Typische Einsparungen durch GZIP:
- HTML: 70–80 % kleiner
- CSS: 60–70 % kleiner
- JavaScript: 70–80 % kleiner
Content Delivery Network (CDN)
Ein CDN verteilt statische Assets (Bilder, CSS, JavaScript) auf Server weltweit. Nutzer laden diese Ressourcen vom nächstgelegenen Server – das reduziert Latenz erheblich.
Populäre CDN-Lösungen:
- Cloudflare (kostenloser Einstieg): DNS-basiert, einfache Einrichtung
- Vercel Edge Network: Für Next.js-Projekte automatisch integriert
- AWS CloudFront: Enterprise-Lösung
- BunnyCDN: Kostengünstige Alternative
Caching-Strategie
# .htaccess (Apache) - Caching-Header
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType text/html "access plus 1 hour"
</IfModule>
Critical CSS inline
CSS, das für den sichtbaren Seitenbereich (above the fold) benötigt wird, sollte inline im <head> stehen, um das erste Rendering nicht zu blockieren:
<head>
<style>
/* Critical CSS: Nur Styles für sichtbaren Bereich */
body { margin: 0; font-family: Poppins, sans-serif; }
.hero { background: #075CE1; padding: 80px 20px; }
</style>
<!-- Restliches CSS async laden -->
<link rel="preload" href="/styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
</head>
Pagespeed für WordPress optimieren
WordPress-Seiten haben spezifische Optimierungsherausforderungen. Die wichtigsten Plugins:
| Lösung | Funktion | Empfehlung |
|---|---|---|
| WP Rocket | Caching, Minification, Lazy Loading | Beste All-in-One-Lösung |
| LiteSpeed Cache | Caching (nur LiteSpeed-Server) | Sehr schnell auf LiteSpeed |
| Imagify / ShortPixel | Bildoptimierung und WebP-Konvertierung | Standard-Empfehlung |
| Cloudflare | CDN + Brotli-Komprimierung | Kostenloser Einstieg |
| W3 Total Cache | Caching (kostenlos) | Alternative zu WP Rocket |
Messtools für Pagespeed
| Tool | Was es misst | URL |
|---|---|---|
| Google PageSpeed Insights | PSI-Score + CrUX + Lab-Daten | pagespeed.web.dev |
| Google Search Console | Core Web Vitals (Field Data) | search.google.com/search-console |
| GTmetrix | Wasserfall-Diagramm, Video-Replay | gtmetrix.com |
| WebPageTest | Detailliertes Waterfall, Multi-Location | webpagetest.org |
| Lighthouse (Chrome DevTools) | Umfassender Lab-Test | Chrome DevTools > Lighthouse |