Die kurze Antwort

WordPress PageSpeed wird nicht durch ein einzelnes Plugin gut. Messen Sie zuerst die langsamste Seitengruppe auf Mobilgeräten, identifizieren Sie das konkrete LCP-Element und prüfen Sie danach Serverantwort, Bildauslieferung, blockierende Styles, JavaScript und Schriftarten. Beheben Sie immer den größten gemessenen Engpass und testen Sie dieselbe URL erneut.

Für Nutzer zählen die Core Web Vitals im Feld. Ein guter Lighthouse-Labortest hilft bei der Diagnose, beweist aber allein keine schnelle Website für echte Besucher. Google bewertet LCP, INP und CLS am 75. Perzentil getrennt für Mobilgeräte und Desktop. Die Zielwerte sind höchstens 2,5 Sekunden für LCP, höchstens 200 Millisekunden für INP und höchstens 0,1 für CLS.

Wenn Updates, Cache, Backups und Performance dauerhaft kontrolliert werden sollen, gehört das in eine planbare WordPress Wartung.

Vor der Optimierung richtig messen

Prüfen Sie nicht nur die Startseite. Messen Sie mindestens eine typische Inhaltsseite, eine wichtige Landingpage und bei WooCommerce eine Kategorie oder Produktseite. Nutzen Sie jeweils die öffentliche URL ohne Anmeldung. Ein Admin-Toolbar, ein Consent-Testmodus oder eine leere Staging-Datenbank verfälscht das Ergebnis.

PageSpeed Insights verbindet Felddaten aus dem Chrome User Experience Report mit einem Lighthouse-Labortest. Felddaten zeigen reale Nutzung der letzten 28 Tage, sofern genügend Daten vorliegen. Der Labortest liefert eine reproduzierbare Momentaufnahme und nennt konkrete Ressourcen. Beide Perspektiven beantworten unterschiedliche Fragen.

  • URL und Gerätetyp dokumentieren.
  • Feldwerte und Labordaten getrennt notieren.
  • LCP-Element, lange Aufgaben und Layoutverschiebungen konkret benennen.
  • Ersten Aufruf und warmen Cache unterscheiden.
  • Nach jeder Änderung dieselbe URL unter vergleichbaren Bedingungen prüfen.

LCP verbessern: Das größte sichtbare Element zuerst

Beim Largest Contentful Paint ist häufig das Hero-Bild, ein Beitragsbild oder ein großer Textblock betroffen. Prüfen Sie in Lighthouse, welches Element tatsächlich als LCP erkannt wurde. Ein kleines WebP kann trotzdem spät erscheinen, wenn der Browser es erst nach Styles oder JavaScript entdeckt.

Ein sichtbares Hero-Bild sollte nicht per Lazy Loading verzögert werden. Liefern Sie passende Abmessungen über srcset und sizes aus, setzen Sie width und height und priorisieren Sie nur das tatsächliche LCP-Bild. Ein CSS-Hintergrund wird später entdeckt als ein Bild im HTML. Wechseln Sie nicht blind die Technik, sondern prüfen Sie die Wasserfallansicht.

  • Bild auf die maximale Darstellungsgröße zuschneiden.
  • WebP oder AVIF anbieten und die sichtbare Qualität kontrollieren.
  • Das LCP-Bild nicht lazy laden.
  • Nur das wichtigste Bild mit hoher Priorität laden.
  • Cache und CDN erst nach korrekter Bildauslieferung bewerten.

Devvibe-Praxischeck: Bildgewicht reproduzierbar senken

Für diesen Beitrag haben wir am 1. Oktober 2026 das erzeugte Hero-Original mit einer festen, reproduzierbaren Pipeline verarbeitet. Das PNG hatte 2688 mal 1520 Pixel und 3.480.093 Byte. Die Web-Kopie wurde zentral auf 1920 mal 1086 Pixel zugeschnitten und als WebP mit Qualitätsstufe 82 gespeichert. Das Ergebnis hat 67.352 Byte.

Dieser Vergleich belegt nur die Dateiverarbeitung dieses konkreten Bildes. Er ist kein allgemeines Einsparversprechen und kein Nachweis für einen bestimmten LCP-Wert. Vor der Freigabe haben wir Original und Web-Kopie visuell auf Artefakte, unerwünschte Schrift sowie den zentralen Mobilzuschnitt geprüft.

Reproduzierbarer Bildschritt mit Sharp
sharp('hero-original.png')
  .resize(1920, 1086, { fit: 'cover', position: 'centre' })
  .webp({ quality: 82, effort: 6 })
  .toFile('hero-ki-generiert.webp');
  • Testumgebung: Linux, Node.js 24, Sharp aus dem Projekt-Lockfile.
  • Original: PNG, 2688 mal 1520 Pixel, 3.480.093 Byte.
  • Web-Kopie: WebP, 1920 mal 1086 Pixel, 67.352 Byte.
  • Sichtprüfung: keine Schrift, Logos, Personen oder auffälligen Kompressionsartefakte.

INP verbessern: Lange Aufgaben und unnötiges JavaScript reduzieren

Interaction to Next Paint misst, wie schnell eine Seite nach einer Interaktion sichtbar reagiert. Bei WordPress entstehen Verzögerungen oft durch umfangreiche Themes, Page Builder, Slider, Tracking oder mehrere Erweiterungen mit ähnlicher Aufgabe. Eine gute Startzeit allein löst dieses Problem nicht.

Prüfen Sie lange Aufgaben im Performance-Profil und ordnen Sie Skripte ihrem Ursprung zu. Entfernen Sie ungenutzte Funktionen, laden Sie nicht kritische Skripte später und testen Sie Formulare, Navigation und Consent-Dialog nach jeder Änderung. Verzögern Sie kein Skript, das für die erste Interaktion benötigt wird.

Wenn die Last aus individueller Pluginlogik stammt, sollte sie mit Profiling, klaren Hooks und gezielten Abfragen in der WordPress Plugin Entwicklung behoben werden.

CLS verbessern: Platz reservieren und späte Sprünge vermeiden

Cumulative Layout Shift steigt, wenn sichtbare Elemente nachträglich ihren Platz verändern. Typische Ursachen sind Bilder ohne Abmessungen, eingebettete Inhalte, nachgeladene Schriftarten, Banner und dynamische Blöcke oberhalb des Inhalts.

Geben Sie Bildern und Videos feste Seitenverhältnisse. Reservieren Sie Platz für Banner und Einbettungen. Bei Webfonts helfen passende Fallback-Metriken und eine begrenzte Zahl benötigter Schnitte. Prüfen Sie die Seite außerdem mit eingeblendeter Cookie-Einwilligung, Fehlerhinweisen und geöffnetem Menü.

Server, Cache und Datenbank in der richtigen Reihenfolge prüfen

Eine langsame Serverantwort verschiebt jede weitere Ressource. Prüfen Sie deshalb Time to First Byte, Full-Page-Cache und PHP-Ausführung, bevor Sie mehrere Frontend-Plugins kombinieren. Zwei konkurrierende Cache-Lösungen machen das Verhalten schwerer reproduzierbar.

Bereinigen Sie nicht pauschal die Datenbank. Finden Sie langsame Abfragen, große Autoload-Optionen und wiederkehrende Hintergrundjobs mit Messdaten. Testen Sie Änderungen in Staging und sichern Sie den vorherigen Zustand. Ein schneller Cache darf Fehler nur nicht schneller ausliefern.

Für API-Fehler, Rewrite-Probleme und geschützte Routen gibt es den ergänzenden Leitfaden WordPress REST API aktivieren und Fehler beheben.

Was Sie nicht blind tun sollten

Installieren Sie nicht mehrere Optimierungsplugins auf Verdacht. Kombinieren, Verzögern und Entfernen von CSS oder JavaScript kann Navigation, Formulare, Checkout und Tracking beschädigen. Ein hoher Score ist wertlos, wenn eine wichtige Funktion nicht mehr arbeitet.

Optimieren Sie auch nicht nur für einen einzelnen Testlauf. Lighthouse-Werte schwanken. Dokumentieren Sie mehrere vergleichbare Läufe, beobachten Sie reale Core Web Vitals und kontrollieren Sie nach Updates erneut. Bei kleinen Websites ohne ausreichende Felddaten bleibt der Labortest wichtig, muss aber als Labordaten gekennzeichnet werden.

Priorisierte Checkliste für WordPress PageSpeed

Die folgende Reihenfolge hält Änderungen klein und überprüfbar. Beginnen Sie mit der langsamsten relevanten Vorlage und wechseln Sie erst nach einem bestätigten Ergebnis zum nächsten Punkt.

  • Core Web Vitals und Lighthouse für Mobilgeräte erfassen.
  • LCP-Element sowie Server-, Lade- und Renderverzögerung bestimmen.
  • Hero-Bild korrekt dimensionieren, priorisieren und sichtbar prüfen.
  • Lange JavaScript-Aufgaben und doppelte Funktionen reduzieren.
  • Platz für Medien, Banner und Einbettungen reservieren.
  • Page Cache, Objekt-Cache und Datenbank nur mit Messdaten ändern.
  • Navigation, Formulare, Consent und Checkout als Regressionstest prüfen.
  • Felddaten nach dem nächsten 28-Tage-Fenster erneut bewerten.

Weitere technische Problemlösungen und Entscheidungshilfen finden Sie im Devvibe Magazin.

Offizielle Quellen

Die Zielwerte und Diagnoseprinzipien stammen aus den offiziellen Dokumentationen von WordPress und Chrome. Prüfen Sie zusätzlich die Dokumentation Ihres Themes, Ihrer Erweiterungen und Ihrer Hosting-Umgebung.

WordPress Developer Resources: Optimization im Advanced Administration Handbook

web.dev: Web Vitals

web.dev: LCP optimieren

web.dev: INP optimieren

web.dev: CLS optimieren