Die wichtigste Erkenntnis: Ein niedriger PageSpeed-Insights-Score bei WordPress hat fast immer dieselben Ursachen — unoptimierte Bilder, render-blockierende Skripte und fehlendes Caching. Behebe sie in dieser Reihenfolge und teste nach jeder Änderung erneut; die meisten Websites wechseln so von Rot auf Grün, ganz ohne Hosting-Upgrade oder Theme-Neubau.
Warum WordPress-Websites bei PageSpeed Insights schlecht abschneiden
WordPress macht es einfach, Plugins, Page-Builder und Drittanbieter-Skripte hinzuzufügen — jedes davon bringt eigenes CSS, JavaScript und manchmal externe Anfragen mit. Eine Standardinstallation mit Page-Builder, ein paar Marketing-Plugins und unoptimierten Medien kann leicht 3-4MB Assets für eine einzige Seite ausliefern.
PageSpeed Insights führt bei jeder getesteten URL zwei separate Analysen durch:
- Labordaten: ein simulierter Lighthouse-Test, sofort auf Googles Servern unter festen Netzwerk- und Gerätebedingungen ausgeführt. Nützlich, um konkrete Probleme zu finden, aber eine Momentaufnahme, kein echtes Nutzerverhalten.
- Felddaten: echte Messungen von tatsächlichen Chrome-Nutzern, die deine Website in den letzten 28 Tagen besucht haben, aus dem Chrome User Experience Report (CrUX). Diese erscheinen nur, wenn deine Website genug Chrome-Traffic hat.
Eine Website kann im Labor 95 erzielen und in den Felddaten trotzdem "poor" (schlecht) abschneiden — meist weil echte Nutzer langsamere Verbindungen oder ältere Geräte haben, als die Laborsimulation annimmt. Beide Zahlen zählen, aber der Core-Web-Vitals-Bericht der Search Console nutzt Felddaten — das ist also die Zahl, die mit den Ranking-Signalen verknüpft ist.
Die Reihenfolge, die den Score wirklich verändert
Arbeite diese Punkte der Reihe nach ab — jeder hat tendenziell einen größeren Effekt als der nächste, daher verschwendet man bei falscher Reihenfolge Zeit mit kleineren Gewinnen zuerst.
1. Zuerst die Bilder beheben
Auf einer durchschnittlichen WordPress-Seite machen Bilder 50-80% des gesamten Seitengewichts aus. Das ist fast immer die wirkungsvollste Einzelmaßnahme und meist die Ursache für einen roten Largest Contentful Paint (LCP)-Score, da das LCP-Element auf den meisten Seiten ein Hero-Bild, Beitragsbild oder Produktfoto oberhalb des sichtbaren Bereichs ist.
Drei Dinge, die bei jedem Bild oberhalb des Falzes zu prüfen sind:
- Format — ist es noch rohes JPEG oder PNG? WebP ist bei gleicher Qualität etwa 25-35% kleiner, AVIF reduziert die Größe gegenüber JPEG oft um die Hälfte.
- Abmessungen — wird ein 4000px breites Foto in einen 800px-Container gequetscht? Der Browser lädt trotzdem die volle Datei, bevor er sie verkleinert.
- Ladepriorität — ist das LCP-Bild versehentlich mit
loading="lazy"markiert? Das ist einer der häufigsten Fehler: ein "Performance"-Plugin lädt alle Bilder der Seite lazy, einschließlich des Bildes, das der Browser zuerst braucht.
Wir behandeln das ausführlicher in unserer Core-Web-Vitals-Bild-Checkliste und WebP-Konvertierungsanleitung. Erdo Image Optimizer übernimmt die Formatkonvertierung und Lazy-Loading-Korrektur automatisch, über die serverseitige GD- oder Imagick-Bibliothek — ohne externe API oder monatliches Kontingent.
2. Render-blockierendes CSS und JavaScript eliminieren
Jedes <script> und <link rel="stylesheet"> im <head> ohne async, defer oder eine Media Query blockiert das Rendern der Seite, bis es heruntergeladen und (bei Skripten) ausgeführt wurde. Page-Builder und Multi-Purpose-Themes sind hier häufige Übeltäter und laden oft eine komplette Icon-Bibliothek oder ein Animations-Framework, selbst auf Seiten, die sie nicht nutzen.
Die Lösung ist nicht immer "Plugin entfernen" — oft reicht es, nicht-kritische Skripte zu verzögern und das wenige CSS, das für den ersten Bildschirm nötig ist, inline einzubinden. Die meisten Caching- und Performance-Plugins haben dafür eine Einstellung; teste danach sorgfältig, da aggressives Verzögern gelegentlich ein Skript brechen kann, das von der Ladereihenfolge abhängt.
3. Server- und Browser-Caching aktivieren
Eine Seite, die bei jeder einzelnen Anfrage von PHP und MySQL neu aufgebaut werden muss, fügt der Time to First Byte (TTFB) mehrere hundert Millisekunden hinzu, was alles Nachfolgende verzögert, einschließlich LCP. Seiten-Caching (wiederkehrenden Besuchern eine vorgefertigte statische HTML-Datei ausliefern) und Objekt-Caching (wiederholte Datenbankabfragen vermeiden) sind beide sinnvoll, und die meisten Caching-Plugins konfigurieren beides mit vernünftigen Standardwerten.
Dieser Schritt zählt, ist aber selten der größte Score-Treiber — eine gut gecachte Seite mit einem 2MB großen, unkomprimierten Hero-Bild scheitert trotzdem bei LCP.
4. Plugin-Anzahl und -Qualität prüfen
Die Anzahl der Plugins selbst ist kein grundsätzliches Performance-Problem — ein gut programmiertes Plugin, das seine Assets nur bei Bedarf lädt, kostet sehr wenig. Das eigentliche Problem sind Plugins, die CSS/JS website-weit laden, unabhängig davon, ob die aktuelle Seite sie nutzt. Zehn schlanke, gut abgegrenzte Plugins sind weniger problematisch als zwei schlecht programmierte.
Eine praktische Prüfung: Chrome DevTools öffnen → Network-Tab, eine langsame Seite neu laden und nach Größe sortieren. Alles unerwartet Große ist eine Untersuchung wert — verfolge es zurück zum Plugin oder Theme-Bestandteil, der es lädt.
Kurzreferenz: Core-Web-Vitals-Schwellenwerte
| Metrik | Gut | Verbesserungsbedürftig | Schlecht |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Unter 2,5s | 2,5s – 4s | Über 4s |
| INP (Interaction to Next Paint) | Unter 200ms | 200ms – 500ms | Über 500ms |
| CLS (Cumulative Layout Shift) | Unter 0,1 | 0,1 – 0,25 | Über 0,25 |
Das sind Googles veröffentlichte Schwellenwerte, gemessen am 75. Perzentil echter Besuche — das heißt, drei von vier deiner Besucher müssen im Bereich "Gut" liegen, damit die Metrik besteht.
Ein durchgerechnetes Beispiel
Bei einem kürzlichen Audit eines WooCommerce-Shops mit recht typischer Ausstattung (Page-Builder, 3 Marketing-Plugins, unoptimierte Produktfotografie) sah die Entwicklung vor und nach der Behebung von Bildern und render-blockierenden Skripten so aus:
| Änderung | LCP vorher | LCP nachher |
|---|---|---|
| Hero- und Produktbilder in WebP konvertieren | 4,8s | 3,6s |
| Übergroße Bildabmessungen korrigieren | 3,6s | 2,9s |
loading="lazy" vom Hero-Bild entfernen |
2,9s | 2,1s |
Keine dieser drei Änderungen betraf Hosting, Caching-Konfiguration oder Theme-Code — sie brachten LCP allein durch Bildbehandlung von "schlecht" auf "gut". Das deckt sich mit dem, was wir bei den meisten WordPress-Audits sehen: Bilder sind die erste Stelle, an der man nachsehen sollte, nicht die letzte.
Der Fehler, den man vermeiden sollte
Ein häufiger Reflex, wenn PageSpeed Insights rot anzeigt, ist, Plugins nacheinander zu deaktivieren, in der Hoffnung, "den" Übeltäter zu finden. Das ist langsam und oft ergebnislos, weil der eigentliche Engpass häufig gar kein Plugin ist, sondern ein einzelnes übergroßes Bild. Schau zuerst in den Abschnitt "Diagnose" des PageSpeed-Insights-Berichts — er benennt das tatsächliche LCP-Element und listet die konkreten Ressourcen, die das Rendern blockieren. Das ist ein deutlich schnellerer Ausgangspunkt als Trial-and-Error-Deaktivierung.
Fazit
Ein roter PageSpeed-Insights-Score bei WordPress fühlt sich an, als bräuchte er ein Hosting-Upgrade oder einen kompletten Theme-Umbau, aber in der Praxis ist die Lösung fast immer enger gefasst: Bilder in ein modernes Format mit der richtigen Größe bringen, das Rendern nicht mit unnötigen Skripten blockieren, cachen, was sich cachen lässt, und Plugins ausdünnen, die Assets laden, die sie nicht brauchen. Arbeite diese vier Punkte der Reihe nach ab und teste nach jedem erneut — meist weißt du schon nach dem ersten oder zweiten Schritt, welche Maßnahme die eigentliche Arbeit leistet.
Falls Bilder sich als dein größtes Problem herausstellen (das ist meistens so), automatisiert Erdo Image Optimizer die oben beschriebene Formatkonvertierung, Größenwarnung und Lazy-Loading-Prüfung — aus einer wiederkehrenden manuellen Kontrolle wird so eine einmalige Einrichtung.