Deine WordPress-Seite lädt langsam, und du vermutest die Plugins. Vermutlich hast du recht. Aber solange du nicht weißt, welches Plugin bremst, bleibt jede Änderung ein Ratespiel. Dieser Artikel zeigt die vier Zahlen, an denen deine Seite gemessen wird, und das Verfahren, mit dem du den Verursacher findest.
Wie verbreitet das Problem ist, lässt sich beziffern: Im Juli 2024 haben 41 Prozent der WordPress-Ursprünge die Core Web Vitals bestanden, gegenüber weniger als 15 Prozent im Januar 2020 (HTTP Archive Web Almanac 2024). Es geht also aufwärts, und trotzdem fällt weiterhin die Mehrheit durch.
Plugins laden mehr, als deine Seite braucht
Jedes aktive Plugin kann beim Seitenaufruf eigene PHP-Dateien, Stylesheets und JavaScript mitladen. Der entscheidende Punkt steckt in dem Wort „kann". Ein sauber gebautes Plugin lädt seine Dateien nur dort, wo sie gebraucht werden. Die WordPress-Entwicklerdokumentation sagt das ausdrücklich: „Use this information to only enqueue your script on pages where it is needed", also binde dein Skript nur auf den Seiten ein, auf denen es gebraucht wird (WordPress Developer Resources).
Die Bremse ist deshalb nicht die Zahl deiner Plugins, sondern die Zahl derer, die diese Empfehlung ignorieren. Ein Slider-Plugin, das seinen Code auf jeder Unterseite mitlädt, obwohl der Slider nur auf der Startseite steht, kostet dich überall sonst Ladezeit für nichts. Die pauschale Aussage „zu viele Plugins machen die Seite langsam" ist damit nur halb richtig: fünf schlecht gebaute Plugins bremsen stärker als zwanzig sparsame.
Deaktiviert ist nicht deinstalliert
Ein deaktiviertes Plugin führt keinen Code mehr aus. Seine Dateien und seine Datenbankeinträge bleiben aber liegen, und bei jeder Sicherung wandern sie mit. Wenn du ein Plugin nicht brauchst, deinstalliere es, statt es nur abzuschalten. Wie du vorher sauber sicherst, damit dir dabei nichts verloren geht, steht im Artikel über ein zuverlässiges Backup deiner Website.
Die vier Zahlen, an denen deine Seite gemessen wird
Bevor du ein Plugin anfasst, brauchst du einen Messwert. Google nennt für drei Kennzahlen konkrete Schwellen, ab denen eine Seite als gut gilt, und gemessen wird nicht der Durchschnitt, sondern das 75. Perzentil der Seitenaufrufe, getrennt für Mobilgeräte und Desktop (web.dev, Stand Oktober 2024). Drei von vier Aufrufen müssen den Wert also schaffen.
| Kennzahl | Was sie misst | Gut laut Google |
|---|---|---|
| Largest Contentful Paint (LCP) | wann der größte sichtbare Inhalt steht | unter 2,5 Sekunden |
| Interaction to Next Paint (INP) | wie schnell die Seite auf einen Klick reagiert | unter 200 Millisekunden |
| Cumulative Layout Shift (CLS) | wie stark das Layout beim Laden springt | unter 0,1 |
| Time to First Byte (TTFB) | wann der Server das erste Byte sendet | unter 0,8 Sekunden |
Die vierte Zeile trägt eine Einschränkung, die oft untergeht: TTFB ist kein Core Web Vital. Google schreibt dazu wörtlich „Because TTFB isn't a Core Web Vitals metric, it's not absolutely necessary that sites meet the 'good' TTFB threshold" und nennt den Wert selbst nur einen groben Anhaltspunkt. Schlecht sind laut derselben Quelle Werte über 1,8 Sekunden (web.dev, Stand November 2025). TTFB sagt dir also, ob das Problem am Server liegt, nicht ob deine Seite Googles Prüfung besteht.
PageSpeed Insights misst nicht, was deine Besucher erleben
Der häufigste Messfehler steckt nicht im Werkzeug, sondern im Verständnis dessen, was es anzeigt. PageSpeed Insights liefert zwei Sorten Daten gleichzeitig, und die messen verschiedene Dinge.
- Labordaten entstehen, indem die Seite in einer festgelegten Umgebung mit vorgegebenen Geräte- und Netzwerkeinstellungen geladen wird. Immer gleich, immer wiederholbar.
- Felddaten kommen von echten Besuchern und spiegeln deren tatsächliche Geräte, Verbindungen und Standorte.
Google beschreibt ausdrücklich, dass Labor- und Felddaten sich bei allen Core Web Vitals unterscheiden können, und nennt das eine verständliche Quelle der Verwirrung (web.dev). Praktisch heißt das: Wenn dein Testwert gut aussieht und die Search Console trotzdem eine schlechte Bewertung meldet, ist keines von beiden kaputt. Die Felddaten zeigen, was deine Besucher erleben, und darauf kommt es an.
Was das für deine Messung bedeutet
Miss nie nur einmal und nie nur mit einem Werkzeug. Ein Labortest direkt nach einer Änderung zeigt dir sofort, ob die Änderung technisch gewirkt hat. Ob sie bei deinen Besuchern ankommt, zeigt sich erst in den Felddaten, und die brauchen Zeit, weil sie über einen längeren Zeitraum gesammelt werden. Wer nach zwei Tagen in der Search Console nachsieht und nichts findet, hat nicht das Gegenteil bewiesen, sondern zu früh gemessen.
So findest du das Plugin, das wirklich bremst
Jetzt wird es konkret. Du hast einen Messwert, jetzt suchst du den Verursacher. Das ist ein Ausschlussverfahren, und es braucht Disziplin, keine besonderen Werkzeuge.
Schritt für Schritt zum Verursacher
- Ausgangswert festhalten: Miss vor jeder Änderung und schreib die Zahl auf. Ohne diesen Wert kannst du hinterher nichts belegen, weder dir selbst noch jemand anderem.
- Verbrauch je Plugin sichtbar machen: Das kostenlose Query Monitor zeigt dir direkt im Dashboard, welche Datenbankabfragen, Skripte und Stylesheets ein Plugin erzeugt. Das ist aufschlussreicher als jede Produktbeschreibung im Plugin-Verzeichnis.
- Einzeln abschalten, einzeln messen: Ein Plugin deaktivieren, neu messen, wieder aktivieren. Nur so weißt du, welches den Unterschied macht. Zwei gleichzeitig abgeschaltet heißt zwei mögliche Ursachen und keine Antwort.
- Auf einer Kopie arbeiten: Dieses Verfahren gehört nicht auf die Live-Seite. Sonst erlebt ein Besucher deine Messung, und im schlechtesten Fall mitten im Kaufvorgang.
Bei diesem Durchgang stellt sich oft eine Frage anderer Art: Brauche ich dieses Plugin überhaupt, und wäre eine eigene Lösung nicht schlanker? Das ist keine Messfrage mehr, sondern eine strategische. Sie steht in einem eigenen Artikel über den Plugin-Zoo und eigene Plugins.
Caching verdeckt das Problem, es löst es nicht
Ein Caching-Plugin speichert die fertig gebaute Seite als statische Datei und liefert diese aus. Das wirkt sofort und deutlich, vor allem auf den Server-Zeitwert. Nur behebt es die Ursache nicht: Die Plugins laufen weiter, sie laufen nur seltener. Sobald eine Seite nicht aus dem Zwischenspeicher kommt, etwa im Warenkorb, im Checkout oder in einem Mitgliederbereich, ist die volle Last zurück.
Bewährt sind WP Rocket, W3 Total Cache und LiteSpeed Cache, letzteres nur auf Servern mit LiteSpeed. Welches davon zu dir passt, hängt von deinem Hosting ab und nicht von einem Testbericht.
Was neben dem Caching wirklich trägt
- Bilder in ein modernes Format bringen und Lazy Loading aktivieren, damit nur geladen wird, was der Besucher auch sieht
- CSS und JavaScript verkleinern lassen, also überflüssige Leerzeichen und Kommentare entfernen
- Die Datenbank regelmäßig von alten Revisionen, Spam-Kommentaren und abgelaufenen Zwischenspeicher-Einträgen befreien
- Nach jeder einzelnen Maßnahme neu messen, sonst weißt du am Ende nicht, welche davon gewirkt hat
Und ein Hinweis, der schon vielen Stunden gekostet hat: Zwei Plugins können sich gegenseitig blockieren. Ein Sicherheits-Plugin, das den Zwischenspeicher nicht durchlässt, macht das Caching-Plugin wirkungslos, ohne dass irgendwo eine Fehlermeldung auftaucht. Auch hier gilt: messen statt annehmen.
Eine Messung ohne Wiederholung ist wertlos
Eine WordPress-Seite, die über Jahre wächst, sammelt Altlasten. Das Plugin für eine einmalige Aktion, das nie entfernt wurde. Die Funktion, die zweimal installiert ist, weil niemand mehr den Überblick hatte. Das Theme, das ein halbes Dutzend eigener Plugins mitbringt, die alle parallel laufen. Jede dieser Altlasten kostet jeden Tag ein wenig Ladezeit, und keine davon meldet sich von selbst.
Dagegen hilft kein einmaliger Kraftakt, sondern ein Termin. Einmal im Quartal eine Stunde: Updates prüfen, Plugin-Liste durchgehen, Datenbank aufräumen, messen. Und die Zahl aus dem Vorquartal daneben legen. Genau dieser Vergleich ist der Grund, warum der Ausgangswert so wichtig ist.
Dass sich die Arbeit lohnt, zeigt der Gesamtbestand: Bei WordPress-Seiten stieg der Anteil, der die LCP-Schwelle schafft, von 28 Prozent im Jahr 2023 auf 40 Prozent im Jahr 2024. Andere Systeme liegen dabei deutlich höher, etwa TYPO3 mit 71 und Duda mit 73 Prozent (HTTP Archive Web Almanac 2024). WordPress holt also auf und hat den Abstand noch nicht geschlossen.
Kurz zusammengefasst
Plugins zu optimieren heißt zuerst messen und dann handeln, nicht umgekehrt. Die wichtigsten Punkte:
- Nicht die Anzahl der Plugins entscheidet, sondern wie viele davon ihre Dateien überall mitladen, obwohl sie es nicht müssten
- Die Zielwerte sind LCP unter 2,5 Sekunden, INP unter 200 Millisekunden und CLS unter 0,1, gemessen am 75. Perzentil deiner Seitenaufrufe
- TTFB unter 0,8 Sekunden ist ein Richtwert für die Server-Seite, aber kein Core Web Vital
- Labordaten und Felddaten messen verschiedene Dinge. Ein guter Testwert und eine schlechte Bewertung in der Search Console sind kein Widerspruch
- Den Verursacher findest du nur einzeln: ein Plugin abschalten, messen, wieder einschalten, und das auf einer Kopie statt live
- Caching verdeckt die Last, es entfernt sie nicht. Auf Seiten, die nicht zwischengespeichert werden, ist sie vollständig zurück
- Einmal im Quartal messen und die Zahl mit dem Vorquartal vergleichen
Worauf sich das stützt
Was du noch wissen solltest
Die Anzahl ist die falsche Messgröße. Entscheidend ist, wie viele deiner Plugins ihre Dateien auf jeder Seite mitladen, obwohl sie dort nicht gebraucht werden. Die WordPress-Entwicklerdokumentation empfiehlt ausdrücklich, ein Skript nur auf den Seiten einzubinden, auf denen es gebraucht wird (WordPress Developer Resources). Fünf Plugins, die das ignorieren, bremsen stärker als zwanzig, die sich daran halten.
Google nennt als Schwelle für eine gute Bewertung: Largest Contentful Paint unter 2,5 Sekunden, Interaction to Next Paint unter 200 Millisekunden und Cumulative Layout Shift unter 0,1. Gemessen wird nicht der Durchschnitt, sondern das 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgeräten und Desktop (web.dev, Stand Oktober 2024).
Weil beide verschiedene Dinge messen. Labordaten entstehen beim Laden der Seite in einer festgelegten Umgebung mit vorgegebenen Geräte- und Netzwerkeinstellungen, Felddaten stammen von echten Besuchern mit ihren tatsächlichen Geräten und Verbindungen. Google beschreibt ausdrücklich, dass sich beide bei allen Core Web Vitals unterscheiden können (web.dev). Keiner der Werte ist falsch, aber nur die Felddaten sagen dir, was deine Besucher wirklich erleben.
