Warum die Installation eines Caching-Plugins es nicht behoben hat
Ein Page-Cache speichert fertiges HTML und liefert es dem nächsten anonymen Besucher aus, ohne WordPress überhaupt zu starten. Das ist ein echter Gewinn für öffentlichen Traffic - aber die gecachte Seite ist das Ergebnis, nicht die Arbeit. Was die Seite langsam gemacht hat, läuft jedes Mal weiter, wenn der Cache nicht liefern kann.
Der Speedtest wird für ausgeloggte Besucher grün. Ihre eigenen Klicks - eingeloggt, im wp-admin, im Warenkorb - fühlen sich genauso langsam an wie vorher, weil für Sie nichts gecacht ist. Das Plugin macht seinen Job. Der Job ist nur enger gefasst als das Problem.
Der Cache kann also perfekt funktionieren und die Website fühlt sich überall dort, wo es für Sie zählt, trotzdem langsam an. Die Frage ist nicht mehr „funktioniert der Cache", sondern „was läuft darunter immer noch."
Was ein Page-Cache nicht anfassen kann
Caching-Plugins sind in ihrer Doku ehrlich damit - sie fangen nur mit den Benchmarks an. Dies sind die Stellen, an denen ein Page-Cache nie greift, und die Arbeit, die darin weiterläuft:
| Was langsam ist | Warum der Cache es verfehlt | Welches Modul es sieht |
|---|---|---|
| wp-admin-Screens | Das Backend wird nie gecacht - jeder Klick startet WordPress und führt die Admin-Hooks jedes Plugins aus | Slow Query Analyzer, Find Slow Callbacks |
| Eingeloggtes Frontend | Personalisierte Seiten umgehen den Cache für jeden angemeldeten Nutzer - Mitglieder, Kunden, Redakteure | Find Slow Callbacks |
| Warenkorb, Checkout, Mein Konto | Von vornherein ausgeschlossen - sie zu cachen würde die Daten eines Kunden auf der Seite eines anderen landen lassen. | Find Slow Callbacks, Slow Query Analyzer |
| Langsame Datenbank-Queries | Der Cache speichert das Ergebnis; die Query läuft bei jedem Miss und jeder ungecachten Seite weiter | Slow Query Analyzer |
| Automatisch geladene Optionen | Das Autoload-Set aus wp_options lädt, bevor WordPress irgendetwas rendert - gecacht oder nicht | Autoloader Optimizer |
| Langsame Plugin-Callbacks | Ein 800-ms-admin_init-Hook feuert bei jedem ungecachten Request, den die PHP-App erzeugt | Find Slow Callbacks |
| Externe HTTP-Calls | Update-Checks, Lizenz-Pings und Telemetrie feuern innerhalb des Requests, hinter dem Cache | Modul External Call Optimizer |
Zuerst: Funktioniert der Cache überhaupt?
Bevor Sie den Code darunter beschuldigen, prüfen Sie, ob der Cache überhaupt cacht. Site Doctor feuert einen Loopback-Request auf Ihre eigene Website und liest den echten Cache-Header, den der Server zurücksendet - HIT, MISS oder BYPASS - statt der Einstellungsseite des Plugins zu vertrauen. Eine Homepage, die mit BYPASS antwortet, wird als Info gemeldet, nicht als Fehler, weil die Homepage die Seite ist, die am häufigsten absichtlich ausgeschlossen wird.
Er liest auch die Einstellungen Ihrer anderen aktiven Optimizer und listet nur, was an beiden Stellen eingeschaltet ist - die klassische Situation „zwei Plugins minifizieren dasselbe" - damit Sie einen Verantwortlichen pro Aufgabe wählen können, statt die Arbeit doppelt zu bezahlen.
Was nach dem Cachen des HTML langsam bleibt
- Langsame Datenbank-Queries. Slow Query Analyzer protokolliert die Queries, die seinen Schwellenwert überschreiten, führt MySQL EXPLAIN auf dem Request aus, der sie geloggt hat, und schlägt fertige Index-Fixes vor
- Autoload-Ballast. Autoloader Optimizer sortiert Ihre größten automatisch geladenen Optionen und deaktiviert Autoload bei den Übeltätern - auf Websites mit echtem Object Cache schrumpft der Gewinn, und das sagt es auch
- Langsame Plugin-Callbacks. Find Slow Callbacks profiliert eine URL pro Request und sortiert jeden Callback über 10 Millisekunden nach Zeit, mit Hook und der Quelldatei, die ihn registriert hat
- Externe HTTP-Calls. Modul External Call Optimizer begrenzt nachweislich gesprächige Drittanbieter-Hosts auf ein sinnvolles Timeout und cacht wiederholte GET/HEAD-Polls kurz - Zahlungs- und Checkout-Calls werden nie angefasst
Klarstellung: WP Multitool liefert keinen Page-Cache
Es übernimmt den Teil für anonyme Besucher. WP Multitool übernimmt den ungecachten Teil darunter - die Queries, Autoload, Callbacks und ausgehenden Calls, die darüber entscheiden, wie schnell der ungecachte Render ist. Der Overlap-Check von Site Doctor existiert genau, weil die beiden Jobs verschieden sind; er listet reine Page-Cache-Plugins sogar als konfliktfrei.
Wo Sie anfangen
- Führen Sie Site Doctor aus. Ein Scan: der Page-Cache-Probe, Redis-Checks, Konfiguration, Datenbank-Ballast, Autoload und überlappende Optimizer. Read-only - nichts ändert sich, bis Sie es sagen.
- Prüfen Sie die Queries. Öffnen Sie Slow Query Analyzer und führen Sie EXPLAIN auf den schlimmsten Übeltätern aus, die er erfasst hat.
- Auditieren Sie den Autoload. Wenn der Scan ein aufgeblähtes Autoload-Set in wp_options zeigt, lassen Sie Autoloader Optimizer es sortieren.
- Profilieren Sie den Rest. Richten Sie Find Slow Callbacks auf die immer noch langsame URL und lesen Sie den Namen der Funktion, die Sie ausbremst.
- Begrenzen Sie die Heimrufe. Wenn die Callbacks externes HTTP zeigen, lassen Sie External Call Optimizer die gesprächigen Hosts auf ein Timeout setzen.
FAQ: Caching hat es nicht behoben
Ich habe ein Caching-Plugin installiert - warum ist meine WordPress-Website immer noch langsam?
Ein Page-Cache beschleunigt nur wiederholte Aufrufe anonymer Besucher. wp-admin, eingeloggte Sessions, Warenkorb und Checkout und jeder Cache-Miss laufen weiterhin mit vollem PHP - und was diesen Render langsam macht (Queries, Autoload, Callbacks, externe Calls), läuft unter dem Cache weiter.
Ersetzt WP Multitool mein Caching-Plugin?
Nein - es liefert überhaupt keinen Page-Cache. Behalten Sie Ihren Cache für anonymen Traffic; WP Multitool diagnostiziert und behebt die ungecachte Arbeit darunter. Site Doctor prüft sogar, ob zwei Plugins dieselbe Optimierung gleichzeitig machen.
Warum ist meine Website nur langsam, wenn ich eingeloggt bin?
Weil der Page-Cache Sie bewusst überspringt. Jeder angemeldete Nutzer bekommt einen frischen PHP-Render, also spüren Sie die echte Geschwindigkeit der Website - die Queries, automatisch geladene Optionen und Plugin-Callbacks, auf die anonyme Besucher nie warten.
Warum ist der WooCommerce-Checkout trotz Caching langsam?
Warenkorb, Checkout und Mein Konto sind vom Page-Cache von vornherein ausgeschlossen - sie zu cachen würde die Daten eines Kunden an einen anderen ausliefern. Ihre Geschwindigkeit ist die Geschwindigkeit des ungecachten Renders: die Queries und Plugin-Callbacks, die auf diesen Requests laufen.
Woher weiß ich, ob mein Caching-Plugin wirklich funktioniert?
Site Doctor feuert einen Loopback-Request auf Ihre eigene Website und liest den Cache- Header, den der Server wirklich sendet - HIT, MISS oder BYPASS - statt dem Dashboard des Plugins zu vertrauen. Ein BYPASS auf einer Seite, die Sie cachen wollten, sagt Ihnen, dass die Regel falsch ist, nicht dass der Cache kaputt ist.
Können zwei Optimierungs-Plugins miteinander kollidieren?
Ja - zwei Plugins, die dieselben Dateien minifizieren oder dieselben Bilder optimieren, sind ein üblicher Weg, es schlimmer zu machen. Site Doctor liest die Einstellungen Ihrer anderen aktiven Optimizer und meldet nur, was an beiden Stellen eingeschaltet ist, damit Sie einen Verantwortlichen pro Aufgabe wählen können.
Finden Sie, was der Cache nicht beheben kann
Site Doctor ist der Startpunkt mit einem Scan; die Pro-Module gehen dort den Queries, dem Autoload, den Callbacks und den ausgehenden Calls auf den Grund. Pro startet bei $79/Jahr für eine Website - jeder bezahlte Plan enthält alle 19 Module.
Pro kaufen – ab $79/Jahr Site Doctor Alle Tarife auf der Preisseite →