Zusammenfassung
Eine langsame Website ist wie ein Geschäft mit klemmender Eingangstür. Die Kunden geben auf, bevor sie überhaupt reinkommen.
53%
Bounce bei >3s
24%
Weniger Bounces mit CWV
47%
Sites bestehen CWV
2 Sek
Optimale Ladezeit
Die harten Fakten 2025:
- 53% der mobilen Nutzer verlassen Seiten, die länger als 3 Sekunden laden
- Nur 47% aller Websites erfüllen Googles Core Web Vitals - ein enormes Verbesserungspotenzial
- Sites die alle drei Core Web Vitals bestehen, haben bis zu 24% niedrigere Bounce-Rates
- E-Commerce: 1 Sek Ladezeit = 3,05% Conversion vs. 1,08% bei 5 Sekunden
Update Dezember 2025: INP (Interaction to Next Paint) hat FID seit März 2024 vollständig ersetzt und ist nun kein Beta-Feature mehr. Die mobile-first Indexierung bedeutet: Google bewertet primär die mobile Performance - Desktop-Werte sind zweitrangig.
Die gute Nachricht: Mit Bricks Builder 2.0 brauchst du für 95+ PageSpeed-Punkte oft nicht mal mehr Optimierungs-Plugins. Der Code ist von Grund auf performant.
Google PageSpeed Insights mit Score 95+
Warum Pagespeed wichtig ist
PageSpeed beeinflusst zwei kritische Bereiche: Nutzererfahrung und Google-Rankings. Und 2025 ist beides wichtiger denn je.
Nutzererfahrung
Menschen haben keine Geduld. Der Konsens unter Experten: 2 Sekunden oder weniger ist die optimale Ladezeit, besonders für E-Commerce. Bei 3 Sekunden sind 53% bereits weg.
3,05%
Conversion bei 1 Sek
1,08%
Conversion bei 5 Sek
Das ist besonders kritisch auf Mobilgeräten, wo die Verbindung oft langsamer und die Aufmerksamkeitsspanne kürzer ist.
Google Rankings
Google hat 2021 Core Web Vitals als offizielles Ranking-Signal eingeführt. In 2025 ist diese Wichtigkeit nur noch gestiegen. Websites die alle Vitals erfüllen haben deutlich bessere Chancen auf Top-Platzierungen.
Die Realität:
Content-Relevanz ist nach wie vor Faktor #1. Aber bei vielen Suchanfragen gibt es reichlich guten Content - hier kann Page Experience der entscheidende Differenzierungsfaktor sein.
Dazu kommt Mobile-First Indexierung: Google bewertet primär die mobile Version deiner Seite. Ein hoher INP oder LCP auf Desktop nützt nichts, wenn die mobile Erfahrung lahmt.
Wirtschaftliche Auswirkungen
Die Zahlen sind eindeutig: Schlechte Core Web Vitals kosten Unternehmen 8-35% an Umsatz, Rankings und Conversions. Angesichts dessen, dass nur 47% der Websites Googles Anforderungen erfüllen, liegt hier enormes Potenzial.
Core Web Vitals 2025
Google hat im März 2024 FID (First Input Delay) durch INP (Interaction to Next Paint) ersetzt. 2025 ist INP vollständig ausgereift - kein Beta-Status mehr. Hier sind die drei aktuellen Metriken:
Core Web Vitals Übersicht - LCP, INP, CLS
Bestehens-Anforderung:
Um Core Web Vitals zu "bestehen", müssen 75% aller Seitenaufrufe die jeweiligen Schwellenwerte einhalten. Das 75. Perzentil ist der Maßstab - nicht der Durchschnitt.
LCP - Largest Contentful Paint
Misst, wie lange es dauert, bis das größte sichtbare Element (meist Hero-Bild oder Headline) geladen ist. Der wichtigste Indikator für wahrgenommene Ladegeschwindigkeit.
| Bewertung | LCP Zeit | Bedeutung |
|---|---|---|
| Gut | ≤ 2,5 Sek | Optimale Nutzererfahrung |
| Verbesserungswürdig | 2,5 - 4,0 Sek | Kann Rankings kosten |
| Schlecht | > 4,0 Sek | Dringend optimieren |
INP - Interaction to Next Paint
Ersetzt FID seit März 2024. Misst die Reaktionszeit auf Nutzerinteraktionen (Klicks, Tippen, Tastatureingaben) über die gesamte Sitzung - nicht nur die erste Interaktion.
INP beinhaltet drei Komponenten: Input Delay, Processing Time und Presentation Delay.
| Bewertung | INP Zeit | Bedeutung |
|---|---|---|
| Gut | ≤ 200ms | Schnelle Reaktion |
| Verbesserungswürdig | 200 - 500ms | Spürbare Verzögerung |
| Schlecht | > 500ms | Frustrierend für Nutzer |
CLS - Cumulative Layout Shift
Misst visuelle Stabilität. Wenn Elemente während des Ladens springen, ist das frustrierend und führt zu versehentlichen Klicks - ein Klassiker bei schlecht optimierten Seiten.
| Bewertung | CLS Score | Bedeutung |
|---|---|---|
| Gut | ≤ 0,1 | Stabile Darstellung |
| Verbesserungswürdig | 0,1 - 0,25 | Gelegentliche Sprünge |
| Schlecht | > 0,25 | Chaotisches Layout |
INP verstehen - Die wichtigste Änderung
INP ist der Game-Changer der Core Web Vitals. Während FID nur die erste Interaktion gemessen hat, betrachtet INP die längste Interaktionsverzögerung während des gesamten Besuchs.
Warum INP strenger ist als FID:
- Misst alle Interaktionen, nicht nur die erste
- Schlechte Erfahrungen später im Besuch werden erfasst
- Schwere JavaScript-Verarbeitung wird sichtbar
- Realistische Abbildung der tatsächlichen Nutzererfahrung
Was INP beeinflusst
INP ist primär ein JavaScript-Problem. Diese Faktoren verschlechtern deinen INP:
- Lange JavaScript-Ausführung im Main Thread
- Zu viele Event Listener
- Komplexe DOM-Operationen bei Interaktionen
- Third-Party Scripts (Analytics, Chat-Widgets)
- Frameworks mit hohem Hydration-Overhead
INP verbessern
| Problem | Lösung |
|---|---|
| Lange Tasks | Code Splitting, Task-Aufteilung |
| Main Thread blockiert | Web Workers für schwere Berechnungen |
| Zu viele Scripts | Third-Party Scripts auditieren |
| Framework-Overhead | Partial Hydration, Islands Architecture |
Performance messen
Du kannst nicht verbessern, was du nicht misst. Diese Tools helfen dir dabei:
Google PageSpeed Insights
Google PageSpeed Insights Interface
Das offizielle Tool von Google. Zeigt Core Web Vitals, Lab-Daten und konkrete Optimierungsvorschläge. Immer mit mobiler Messung beginnen.
GTmetrix
Detaillierte Waterfall-Diagramme zeigen genau, welche Ressourcen wie lange laden. Ideal um Bottlenecks zu identifizieren.
Browser DevTools
F12 drücken, "Network"-Tab öffnen. Hier siehst du in Echtzeit, was dein Browser lädt. Throttling aktivieren um mobile Verbindungen zu simulieren.
Wichtig:
Führe mehrere Messungen durch. PageSpeed variiert je nach Serverauslastung, Tageszeit und Testserver-Standort.
Das Fundament: Hosting
Ohne gutes Hosting ist alles andere Symptombekämpfung. Ein langsamer Server macht jede Optimierung zunichte.
- SSD-Speicher (kein HDD)
- PHP 8.2/8.3 Support
- HTTP/3 Unterstützung
- Server-Standort in der Nähe deiner Zielgruppe
- Guter Support bei technischen Fragen
- Automatische Backups
Shared Hosting reicht für die meisten WordPress-Seiten. Erst bei hohem Traffic oder rechenintensiven Funktionen lohnt sich Managed WordPress Hosting.
Caching-Strategie
Caching speichert generierte Seiten, sodass sie nicht bei jedem Aufruf neu erstellt werden müssen.
300%
schneller laden gecachte Websites im Durchschnitt.
Arten von Caching
- Page CacheSpeichert fertig gerenderte HTML-Seiten
- Browser CacheSpeichert Ressourcen im Browser des Besuchers
- Object CacheSpeichert Datenbankabfragen (Redis/Memcached)
- CDN CacheSpeichert Inhalte auf weltweit verteilten Servern
Cache-Invalidierung
Der Cache muss bei Änderungen geleert werden, sonst sehen Besucher veraltete Inhalte. Die meisten Cache-Plugins machen das automatisch bei Aktualisierungen.
CDN einrichten
Ein Content Delivery Network verteilt deine Inhalte auf Server weltweit. Besucher laden von dem Server, der ihnen geografisch am nächsten ist.
CDN Weltkarte - Serverstandorte
Cloudflare (empfohlen)
Cloudflare bietet einen großzügigen kostenlosen Plan mit:
- CDN mit weltweitem Edge-Netzwerk
- DDoS-Schutz inklusive
- Auto Minify (CSS, JS, HTML)
- Brotli-Komprimierung
- Kostenlose SSL-Zertifikate
Empfohlene Cloudflare-Einstellungen
- →Auto Minify: CSS, JavaScript, HTML aktivieren
- →Brotli: Aktivieren
- →Browser Cache TTL: 1 Jahr
- →Always Use HTTPS: Aktivieren
- →Page Rules: Cache Everything für statische Seiten
Bildoptimierung
Bilder machen oft 50-70% der Seitengröße aus. Hier liegt das größte Optimierungspotenzial.
Richtige Größe
Lade keine 4000px breiten Bilder hoch, wenn sie maximal 1920px breit angezeigt werden. Skaliere vor dem Upload auf die maximal benötigte Größe.
Komprimierung
Moderne Komprimierung reduziert die Dateigröße um 60-80% ohne sichtbaren Qualitätsverlust. Tools wie ShortPixel oder TinyPNG erledigen das automatisch.
Moderne Formate
WebP und AVIF sind deutlich effizienter als JPEG oder PNG:
| Format | Ersparnis vs. JPEG |
|---|---|
| WebP | 25-35% kleiner, breite Browser-Unterstützung |
| AVIF | 50% kleiner, noch nicht überall unterstützt |
Width/Height Attribute
Setze immer explizite Breiten und Höhen bei Bildern. Das verhindert Layout Shifts (CLS), weil der Browser den Platz schon vor dem Laden reserviert.
<img src="bild.webp" width="800" height="600" alt="Beschreibung">
Web Fonts optimieren
Externe Fonts (Google Fonts) können die Ladezeit erheblich verlängern und FOUT (Flash of Unstyled Text) verursachen. Außerdem: DSGVO!
Lokal hosten
Lade Fonts herunter und hoste sie selbst. Das spart DNS-Lookups und Verbindungen zu externen Servern. Und es ist DSGVO-konform - Google Fonts einbinden ohne lokales Hosting kann abgemahnt werden.
WOFF2 Format
WOFF2 ist das optimale Font-Format - 30%+ kleiner als TTF oder WOFF. Alle modernen Browser unterstützen es.
/* Nur WOFF2 reicht heute aus */
@font-face {
font-family: 'Inter';
src: url('/fonts/inter.woff2') format('woff2');
font-display: swap;
}
Font-Familien limitieren
Jede Font-Familie und jeder Weight benötigt eine separate Datei. 5 verschiedene Fonts mit jeweils 6 Weights = 30 Font-Dateien. Beschränke dich auf das Nötigste:
- 1-2 Font-Familien maximal
- Nur benötigte Weights (Regular, Medium, Bold)
- Variable Fonts für mehr Flexibilität
Preload kritischer Fonts
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>
Lade nur die kritischsten 1-2 Fonts vor. Zu viele Preloads sind kontraproduktiv.
JavaScript optimieren
JavaScript ist der größte Feind der Performance - besonders für INP. Hier sind die wichtigsten Optimierungstechniken:
Render-Blocking vermeiden
Render-blocking Ressourcen (JavaScript oder CSS, die vor dem Rendering geladen werden müssen) sind Performance-Killer #1.
/* Nicht-kritisches JS deferred laden */
<script src="app.js" defer></script>
/* Oder async für unabhängige Scripts */
<script src="analytics.js" async></script>
Code Splitting
Lade nur den JavaScript-Code, der tatsächlich benötigt wird. Moderne Bundler wie Webpack, Rollup oder Vite machen das automatisch.
- Route-basiertes Splitting: Jede Seite lädt nur ihren Code
- Component-Level Splitting: Große Komponenten lazy laden
- Third-Party Code separieren: Vendor Bundle separat
Minifizierung
Minifizierung entfernt Whitespace, Zeilenumbrüche und Kommentare - die Datei wird kleiner ohne Funktionsänderung. Sollte für Produktion immer aktiviert sein.
Third-Party Scripts auditieren
Die üblichen Verdächtigen:
- —Chat-Widgets (Intercom, Crisp, etc.)
- —Analytics-Scripts (übermäßiges Tracking)
- —Social Media Embeds
- —A/B Testing Tools
Frage bei jedem Script: Brauchen wir das wirklich? Wenn ja, kann es delayed oder nur auf bestimmten Seiten geladen werden?
Empfohlene Plugins
Weniger ist mehr. Jedes Plugin erhöht die Ladezeit. Hier sind die, die sich wirklich lohnen:
Bildoptimierung
- ShortPixel - Automatische Komprimierung und WebP/AVIF-Konvertierung
- EWWW Image Optimizer - Lokale Optimierung ohne Cloud-Abhängigkeit
- Imagify - Von WP Rocket, gute Integration
Alle drei konvertieren automatisch zu WebP. AVIF-Support ist 2025 ebenfalls universell - alle Browser unterstützen es.
Caching & Performance
Meine Empfehlung: Swift Performance
Seit Jahren mein Go-to für alle WordPress-Projekte. Top Support, hervorragendes Preis-Leistungs-Verhältnis, und funktioniert einfach ohne Probleme. Die KI-gestützte Optimierung ist ein echter Mehrwert.
| Plugin | Stärke | Preis |
|---|---|---|
| Swift Performance | KI-Optimierung, zuverlässig | Ab $49/Jahr |
| WP Rocket | Bekannte Allround-Lösung | Ab $59/Jahr |
| FlyingPress | Leichtgewicht, modern | Ab $60/Jahr |
| LiteSpeed Cache | Kostenlos, wenn LiteSpeed-Server | Gratis |
| Perfmatters | Script Manager für INP | Ab $24/Jahr |
Tipp: Perfmatters ist kein Caching-Plugin, aber ideal um Third-Party Scripts pro Seite zu steuern - wichtig für INP.
Theme-Empfehlung
Bricks Builder produziert von Haus aus schnellen Code. Kein zusätzliches Theme nötig, minimale Optimierungs-Plugins erforderlich für 90+ PageSpeed-Werte.
Warum das Theme so wichtig ist:
Der erste Schritt zur PageSpeed-Optimierung findet immer im HTML statt. Ein aufgeblähtes Theme wie Elementor oder Divi produziert 5-10x mehr Code als nötig. Kein Plugin kann das vollständig kompensieren.
Testing-Empfehlung
Teste regelmäßig: Vor dem Optimieren, nach jeder größeren Änderung, und dann alle 1-2 Monate um sicherzustellen, dass nichts degradiert ist.
- →Google PageSpeed Insights - Offizielle Core Web Vitals
- →GTmetrix - Detaillierte Waterfall-Analysen
- →DebugBear - Kontinuierliches Performance Monitoring
- →WebPageTest - Tiefe technische Analysen
Fazit 2025
PageSpeed-Optimierung ist keine einmalige Aufgabe, sondern ein fortlaufender Prozess. Mit INP als neuem Core Web Vital ist JavaScript-Optimierung wichtiger denn je.
Beginne mit dem Fundament (Hosting, Theme-Wahl), optimiere Bilder und Fonts, dann JavaScript und Caching. Regelmäßiges Testen ist Pflicht - 90+ mobile PageSpeed-Punkte sind mit den richtigen Tools erreichbar.
Die Belohnung: Bis zu 24% weniger Bounces und bis zu 35% mehr Conversions. Das ist kein Luxus - das ist ROI.