Zusammenfassung: Eine langsame WordPress-Seite liegt fast nie an „zu wenig Server”, sondern an zu viel Ballast: unkomprimierte Bilder, ein überladener Page-Builder, render-blockierende Skripte, Fonts von Fremdhosts und fehlendes Caching. Der entscheidende Schritt kommt vor jeder Maßnahme: messen. Erst die Diagnose (Lighthouse mobil, PageSpeed Insights, echte Server-Antwortzeit) zeigt den wahren Engpass — danach behebt man ihn gezielt statt nach Checkliste. Dieser Artikel zeigt die Reihenfolge, die wirklich wirkt, mit echten Vorher/Nachher-Zahlen aus Kundenprojekten.
Inhaltsverzeichnis
- Zuerst messen, dann optimieren
- Die wichtigsten Performance-Hebel
- Ein echtes Beispiel
- Brauche ich ein Performance-Plugin?
- Was sind Core Web Vitals?
- FAQ
Zuerst messen, dann optimieren
Der häufigste Fehler bei WordPress-Performance ist Raten: irgendein Cache-Plugin installieren, irgendein Bild kleiner machen, und hoffen. Das behebt selten den echten Engpass — und manchmal macht es die Seite sogar langsamer.
Miss deshalb vor der ersten Änderung eine Baseline:
- PageSpeed Insights (mobil): der Referenzwert, den auch Google sieht. Achte nicht nur auf den Score, sondern auf die einzelnen Werte — vor allem Largest Contentful Paint (LCP) und Total Blocking Time.
- Lighthouse (in Chrome, Tab „Lighthouse”, mobil, gedrosselt): dieselbe Engine lokal, gut für schnelle Wiederholungsmessungen nach jedem Schritt.
- Server-Antwortzeit (TTFB): die Zeit bis zum ersten Byte. Ist sie hoch und schwankt stark, liegt das Problem am Hosting oder am Cache — nicht an Bildern.
Miss auf mehreren Seitentypen (Startseite, eine Inhaltsseite, ggf. eine Shop-Seite). Ohne Baseline ist „schneller” nur ein Gefühl.
Die wichtigsten Performance-Hebel
Die folgenden Hebel bringen bei WordPress erfahrungsgemäß am meisten — grob nach Wirkung geordnet.
1. Bilder. Der mit Abstand häufigste Ballast. Bilder skalieren (nicht ein 4000-px-Foto in einen 800-px-Slot laden), modern komprimieren (WebP/AVIF), natives loading="lazy" für alles unterhalb des sichtbaren Bereichs — und für das Hero-Bild ein gezieltes Preload, damit der LCP früh startet.
2. Caching. Ein Page-Cache liefert fertiges HTML aus, statt es bei jedem Aufruf neu zu bauen. Dazu Browser-Cache-Header für statische Dateien. Wichtig ist eine saubere Architektur mit automatischem Purgen bei Änderungen — sonst zeigt die Seite alte Inhalte (siehe WordPress Cache leeren).
3. Theme- und Page-Builder-Ballast. Page-Builder wie Divi oder Elementor laden pro Seite viele Stylesheets und Skripte. Divi 5 ist hier deutlich schlanker als Divi 4 — allein der Umstieg bringt oft spürbar bessere Werte (siehe Divi 5 Performance optimieren). Prüfe außerdem, ob dein Theme Funktionen lädt, die du gar nicht nutzt.
4. Render-Blocking & Fremdhosts. Jedes CSS/JS von einer fremden Domain kostet einen zusätzlichen Verbindungsaufbau im kritischen Pfad. Ressourcen (z. B. Icon-Bibliotheken) auf die eigene Domain holen und nicht benötigtes CSS/JS gar nicht erst laden.
5. Font-Strategie. Google Fonts direkt von Google einzubinden ist doppelt schlecht — langsam und ein DSGVO-Problem. Selbst hosten, nur die tatsächlich genutzten Schnitte, font-display: swap. So bleibt der kritische Renderpfad Same-Origin.
6. Skript-Diät. Jedes Plugin, das ein Skript auf jeder Seite lädt (Kontaktformular, Slider, Analytics), summiert sich. Drittanbieter-Skripte verzögert laden (erst bei Interaktion oder Sichtbarkeit), ungenutzte Plugins deaktivieren, WooCommerce-Assets auf Nicht-Shop-Seiten dequeuen.
7. Server & Kompression. Gzip/Brotli für HTML aktivieren (greift bei PHP-Seiten nicht immer automatisch), HTTP/2, und bei hoher/schwankender TTFB die Cache- und Hosting-Frage klären.
Ein echtes Beispiel
Wie sehr das wirkt, zeigt ein B2B-Kunde (WordPress/Divi + WooCommerce + WPML): Der erste Verdacht war „zu schwacher Server”. Die Messung zeigte etwas anderes — eine bimodale Server-Antwortzeit (Cache-Treffer 0,2 s, Cache-Neuaufbau bis 8 s) und über 40 render-blockierende Skripte pro Seite durch den Page-Builder.
Nach gezielter Cache-Architektur, HTML-Kompression und Asset-Diät — ohne Serverwechsel:
| Messwert | Vorher | Nachher |
|---|---|---|
| Server-Antwortzeit (TTFB) | bis 8 s | ~0,2 s |
| Erste Inhaltsanzeige (Inhaltsseiten, mobil) | ~10 s | 1,7 s |
Die ganze Geschichte inkl. Diagnose steht in der Case Study zur Microsensys-Performance. Merksatz: Diagnose statt Raten — der Server war unschuldig, das Theme war es.
Brauche ich ein Performance-Plugin?
Ein gutes Caching-/Optimierungs-Plugin (z. B. WP Rocket, LiteSpeed Cache, FlyingPress) nimmt dir viel Handarbeit ab — Page-Cache, Lazy Loading, CSS/JS-Verwaltung. Aber: Ein Plugin ersetzt die Diagnose nicht. Zwei Fehler sind häufig:
- Zu viele Optimierungs-Plugins parallel — sie greifen sich ins Gehege und machen die Seite langsamer statt schneller.
- Aggressive Optionen blind aktivieren (CSS „combine”, JS defer für alles) — das bricht oft das Layout oder Funktionen. Nach jeder Option neu messen und sichtprüfen.
Ein Plugin ist Werkzeug, kein Autopilot. Der größte Hebel bleibt fast immer die Bild- und Skript-Last der konkreten Seite.
Was sind Core Web Vitals?
Core Web Vitals sind Googles Nutzererlebnis-Kennzahlen:
- LCP (Largest Contentful Paint): wie schnell der Hauptinhalt sichtbar ist. Ziel: unter 2,5 s.
- INP (Interaction to Next Paint): wie schnell die Seite auf Eingaben reagiert. Ziel: unter 200 ms.
- CLS (Cumulative Layout Shift): wie stabil das Layout beim Laden bleibt. Ziel: unter 0,1.
Sie sind ein bestätigter Google-Ranking-Faktor und fließen zusätzlich in den Quality Score von Google Ads ein — schnelle Seiten ranken tendenziell besser und kosten pro Klick weniger. Performance ist damit kein reines Technik-Thema, sondern zahlt direkt auf Sichtbarkeit und Werbekosten ein.
Wenn du die Optimierung lieber abgibst: Wir machen bestehende Seiten diagnosegetrieben schneller — mit dokumentiertem Vorher/Nachher und meist ohne Redesign. Details auf der Leistungsseite Performance-Optimierung; der erste Performance-Check ist kostenlos.
FAQ
Warum ist meine WordPress-Seite so langsam?
Meist an zu viel Ballast, nicht an zu wenig Server: unkomprimierte, zu große Bilder, ein überladener Page-Builder mit vielen Skripten pro Seite, Fonts und Skripte von Fremdhosts sowie fehlendes oder falsch konfiguriertes Caching. Was genau bei dir bremst, zeigt erst eine Messung mit PageSpeed Insights und einer TTFB-Prüfung.
Wie mache ich meine WordPress-Seite schneller?
In dieser Reihenfolge: erst messen (Baseline), dann die größten Hebel angehen — Bilder komprimieren und lazy laden, Page-Cache einrichten, Theme-/Plugin-Ballast reduzieren, render-blockierende Fremdhosts entfernen, Fonts selbst hosten, Skripte verzögert laden und HTML-Kompression aktivieren. Nach jedem Schritt neu messen, damit du siehst, was wirklich wirkt.
Welches ist das beste WordPress-Performance-Plugin?
Es gibt kein „bestes” für alle. Etablierte Caching-Plugins wie WP Rocket, LiteSpeed Cache oder FlyingPress nehmen viel Handarbeit ab. Wichtiger als die Wahl ist: nur eines verwenden, Optionen einzeln aktivieren und nach jeder Änderung messen und sichtprüfen — sonst bricht schnell das Layout.
Verbessert Caching allein die Ladezeit genug?
Caching senkt vor allem die Server-Antwortzeit (TTFB) und hilft bei wiederkehrenden Aufrufen enorm. Wenn aber die Seite selbst 8 MB Bilder lädt, bleibt sie trotz Cache langsam. Caching ist ein wichtiger Baustein, ersetzt aber Bild- und Skript-Optimierung nicht.
Muss ich für bessere Core Web Vitals meine Seite neu bauen?
In den meisten Fällen nicht. Bild-, Cache-, Font- und Skript-Optimierung finden am Bestand statt, das Aussehen bleibt unverändert. Ein Neubau lohnt nur, wenn Theme oder Page-Builder grundlegend zu schwer sind — dann ist oft ein Umstieg auf ein schlankeres Setup (z. B. Divi 4 auf Divi 5) der bessere Hebel.
Quellen
- Google — PageSpeed Insights
- Google Web.dev — Core Web Vitals
- Adfera — Case Study: Microsensys-Performance (dokumentierte Vorher/Nachher-Messungen)