Ein Plugin wurde aktualisiert, ein Video ergänzt oder eine Optimierung eingeschaltet. Seitdem fühlt sich deine WordPress-Website langsamer an. Der Cache ist aktiv, trotzdem bleibt das Problem. Jetzt hilft eine saubere Spurensuche: Was wurde geändert, welche Besucher sind betroffen und an welcher Stelle entsteht die Verzögerung? Dieser Beitrag behandelt genau diese Verschlechterung. Die Grundlagen zu Messwerten findest du im Beitrag über Ladezeiten und Nutzererlebnis.
1. Sichere den Ausgangspunkt statt sofort alles umzuschalten
Schreibe auf, seit wann das Problem auffällt. Sammle die Änderungen kurz davor: Plugin- oder Theme-Updates, neue Bilder, externe Einbindungen, Schriften, Cookie-Einstellungen und Änderungen am Hosting. Eine zeitliche Nähe ist eine Spur, noch kein Beweis.
Wähle drei repräsentative Seiten: Startseite, wichtige Leistungsseite und Kontaktseite. Notiere, was du beobachtest: lange weiße Fläche, verspätetes Titelbild, stockendes Menü oder springendes Layout. Speichere vorhandene Vergleichsmessungen und die aktuellen Einstellungen. Fehlen frühere Werte, behaupte keine gemessene Verschlechterung; halte die jetzige Beobachtung als Ausgangspunkt fest.
Vor Eingriffen brauchst du eine aktuelle Sicherung und einen bekannten Rückweg. Konflikttests gehören möglichst auf eine geschützte Testkopie. Schalte auf der Live-Website nicht wahllos Plugins aus, während darüber Anfragen oder Bestellungen laufen.
2. Vergleiche dieselbe Seite unter denselben Bedingungen
Deine eingeloggte WordPress-Ansicht ist nicht automatisch die Ansicht eines Interessenten. Prüfe die öffentliche Seite ausgeloggt und getrennt davon die Admin-Ansicht. Verwende für Vergleiche dieselbe URL, denselben Gerätetyp und dieselbe Einstellung zur Einwilligung. Dokumentiere auch, ob du einen Erstbesuch oder einen erneuten Aufruf prüfst.
Wiederhole einen Labortest mehrfach, statt den besten Einzelwert herauszugreifen. Felddaten beschreiben Erfahrungen echter Besuche; Labortests untersuchen definierte Bedingungen. Beides kann deshalb voneinander abweichen. web.dev erklärt die Unterschiede zwischen Labor- und Felddaten.
Prüffall: Nur dein eingeloggter Aufruf ist langsam, die öffentliche Seite reagiert zügig. Dann untersuchst du diesen Zustand gesondert. Ein zusätzlicher Bildkompressor ist daraus noch nicht als Lösung abgeleitet.
3. Welcher Cache arbeitet hier überhaupt?
Ein Seiten-Cache hält fertige Seiten bereit und reduziert damit die erneute Verarbeitung durch WordPress. Der Browser-Cache speichert beispielsweise Bilder, CSS und JavaScript auf dem Gerät. Ein Object Cache kann wiederholte Datenbankzugriffe verringern. Diese Ebenen erfüllen unterschiedliche Aufgaben. Das WordPress-Handbuch beschreibt die Cache-Arten.
Deshalb beweist „Caching eingeschaltet“ noch nicht, dass dein konkreter Aufruf aus dem Seiten-Cache beantwortet wurde. Und ein schneller HTML-Abruf bedeutet nicht, dass ein schweres Video oder aufwendiger JavaScript-Code ebenfalls schnell verarbeitet wird.
Zeigt dein Hoster oder CDN einen Cache-Status wie HIT, MISS oder BYPASS, notiere ihn zusammen mit der getesteten URL. Prüfe die Bedeutung beim jeweiligen Anbieter: Ein Treffer auf dieser Ebene beweist nicht, dass jede andere Cache-Ebene oder die komplette Seite fehlerfrei arbeitet.
4. Weise den Cache für den betroffenen Aufruf nach
Nutze die dokumentierte Prüfmethode deines Cache-Systems. Bei WP Rocket nennt die offizielle Anleitung unter anderem den Hinweis im Seitenquelltext mit Cache-Zeitstempel und die erzeugten Cache-Dateien. Sie erklärt auch Besonderheiten, wenn das Hosting den Seiten-Cache übernimmt. Ein Generator-Meta-Tag zeigt die Verarbeitung durch WP Rocket, ist aber nicht allein der Nachweis für die konkrete Cache-Auslieferung. WP Rocket: Caching überprüfen.
Prüffall: Der erste Besuch nach einer Leerung ist langsam, weitere Aufrufe derselben öffentlichen Seite sind zügiger. Untersuche Cache-Aufbau und Leerungszeitpunkte. Bleibt nur eine bestimmte Seite langsam, prüfe deren Ausschlüsse und Funktionen. Frage auch, ob ein Login, Cookie oder URL-Parameter die behandelte Variante verändert. Lösche nicht vor jeder Messung sämtliche Caches; sonst vergleichst du womöglich ständig einen anderen Ausgangszustand.
5. Trenne Wartezeit auf die Antwort vom Aufbau im Browser
Die Time to First Byte, kurz TTFB, beschreibt die Zeit bis zum ersten Byte der Antwort. Sie hilft, die frühe Auslieferung zu untersuchen, ist aber selbst kein Core Web Vital. Eine hohe TTFB kann nachfolgende Ladezeiten verlängern; niedrige TTFB garantiert umgekehrt noch keinen schnellen sichtbaren Inhalt. web.dev: TTFB gezielt untersuchen.
Kommt schon das HTML spät an, gehören Cache-Verhalten, Weiterleitungen und Serververarbeitung in die Prüfung. Dein Hoster kann bei auffälligen Ressourcenlimits oder Serverprotokollen helfen. Ist die Antwort zügig, das Hauptbild erscheint aber spät, schaue im Netzwerkverlauf auf genau dieses Bild und seine Abhängigkeiten.
Erfasse dabei Dateigröße, Beginn und Dauer des Abrufs sowie Fehlermeldungen. „Seit dem neuen Titelbild“ ist eine prüfbare Vermutung. „WordPress ist eben langsam“ liefert dir dagegen keinen nächsten Arbeitsschritt.
6. Wenn die Seite da ist, aber das Menü hängt
Ein sichtbarer Seitenaufbau und eine schnelle Reaktion auf Eingaben sind verschiedene Dinge. Die Interaction to Next Paint, kurz INP, betrachtet die Verzögerung zwischen einer Interaktion und der nächsten sichtbaren Darstellung. Bei auffälligen Interaktionen empfiehlt web.dev, die konkrete Aktion zu reproduzieren und Wartezeit, Verarbeitung und anschließende Darstellung getrennt zu untersuchen. web.dev: langsame Interaktionen eingrenzen.
Prüffall: Das mobile Menü reagiert erst nach dem zweiten Tippen oder nach einer Wartezeit. Prüfe, ob dies seit einer Änderung an verzögertem JavaScript auftritt. Teste auf der Kopie gezielt diese Einstellung oder das betroffene Skript. Bestätigt sich der Zusammenhang, suche die kleinste nötige Korrektur.
Kontrolliere anschließend auch Formular, Cookie-Auswahl und eingebettete Dienste. Eine höhere Testpunktzahl wäre kein Fortschritt, wenn dein Kontaktformular dabei seine Funktion verliert.
7. Ändere eine Ursache und prüfe den ganzen Kontaktweg
Deine Testnotiz sollte enthalten: vermutete Ursache, genaue Änderung, getestete URL, Besucherzustand und Ergebnis. Prüfe zuerst die jüngste plausible Änderung. Ist kein Unterschied reproduzierbar, stelle den Ausgangszustand wieder her und untersuche die nächste Spur. So bleiben die Ergebnisse verständlich.
Nach einer erfolgreichen Korrektur überprüfst du erneut dieselben drei Seiten. Öffne das mobile Menü direkt nach dem Laden, nutze die Tastatur, kontrolliere Bilder und sende eine gekennzeichnete Testanfrage. Prüfe deren Eingang. Bei einem Shop kommen Warenkorb und Bestellablauf hinzu. Vergleiche danach die Messwerte unter denselben Bedingungen; echte Nutzungsdaten brauchen Zeit, um eine Änderung abzubilden.
Der praktische Maßstab ist eine zuverlässig nutzbare Website. Ein PageSpeed-Wert von 100 ist weder für jeden Aufbau realistisch noch eine Garantie für einen funktionierenden Kontaktweg.