Unter Pagespeed-Optimierung versteht man das systematische Verbessern von Performance-Kennzahlen wie Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Diese Core Web Vitals sind direkte Ranking-Faktoren und maßgeblich für die User Experience. Eine schnelle Seite reduziert Absprungraten, erhöht die Conversion-Rate und stärkt die SEO-Sichtbarkeit.
Wesentliche Kennzahlen
| Metrik | Sollwert | Bedeutung |
|---|---|---|
| LCP | ≤ 2,5 s | Zeit, bis das größte sichtbare Element lädt |
| INP | ≤ 200 ms | Reaktionszeit auf Nutzer-Eingaben |
| CLS | ≤ 0,10 | Visuelle Stabilität während des Ladevorgangs |
| Time to First Byte (TTFB) | ≤ 0,8 s | Server-Antwortgeschwindigkeit |
| First Input Delay (FID) | ≤ 100 ms | Erstes Interaktions-Delay (bis 2024) |
Haupthebel der Pagespeed-Optimierung
- Server-Performance
- HTTP/2 oder HTTP/3 aktivieren
- Caching-Layer (Varnish, Redis) einführen
- Datenübertragung
- Gzip/Brotli-Kompression nutzen
- Unnötige Redirect-Ketten eliminieren
- Ressourcen-Management
- Critical CSS inline, restliches CSS via media=“print” und onload nachladen
- JavaScript per defer oder import() splitten
- Tree-Shaking & Code-Splitting in Build-Tools (Webpack, Vite) aktivieren
- Bild-Optimierung
- Moderne Formate (WebP, AVIF) verwenden
- Responsive Images mit
srcset/sizes - Lazy-Loading via
loading="lazy"
- Third-Party-Skripte
- Tags asynchron laden, nur notwendige Dienste zulassen
- Self-Hosting von Schriften & Icons
- Delivery-Strategien
- Content Delivery Network (CDN) nutzen
- Edge Caching für dynamische Inhalte (z. B. Next.js Middleware)
Schritt-für-Schritt-Vorgehen
- Audit & Messung
- Lighthouse, WebPageTest oder PageSpeed Insights ausführen
- Reale Nutzerdaten aus CrUX oder RUM-Tooling (e.g. SpeedCurve) analysieren
- Priorisierung (Impact × Aufwand)
- LCP-Blocker an erster Stelle: unkomprimierte Hero-Bilder, Render-Blocking-CSS
- INP-Verzögerer: schweres Third-Party-JavaScript, unoptimierte Event-Handler
- Optimierung umsetzen
- Code-Splitting: nur seitenspezifische Skripte laden
- Preload für Above-the-Fold-Assets
- Server Push (HTTP/2) gezielt einsetzen
- Testing & Monitoring
- Nach Deploy: Lab-Tools + RUM vergleichen
- Performance-Budgets in CI/CD Pipeline integrieren (z. B.
budgets.json)
Beispiel-Optimierung eines Blog-Articles
| Ausgangszustand | Maßnahme | Ergebnis |
|---|---|---|
| LCP 4,2 s, 1,8 MB Hero-Bild (JPG) | WebP 380 kB + preload | LCP 1,7 s |
| 300 kB gebloatetes CSS | Critical CSS extrahiert, Rest deferred | CLS 0,05 |
| 97 KB Analytics-Snippet synchron | Async + Consent-Delay | INP ↓ 130 ms |
Häufige Fehler & Gegenmaßnahmen
- Alles auf einmal optimieren → erst die größten Blocker anpacken, sonst Ressourcenverschwendung.
- Optimierung nur im Labor → reale Nutzerdaten übersehen; immer Field Data prüfen.
- Images vergessen → Bilder machen meist > 50 % der Payload aus; automatisierte Bild-Pipelines einrichten.
- Keine Regression-Kontrolle → neue Features können Performance ruinieren; Budgets in Pull Requests enforce-n.
Fazit: Pagespeed-Optimierung ist kein einmaliges Projekt, sondern ein kontinuierlicher Prozess. Wer einen Performance-First-Mindset pflegt, technische Schulden abbaut und Verbesserungen automatisiert überprüft, erreicht schneller ladende, suchmaschinenfreundliche und Conversion-starke Websites.
