WP Rocket ist eines der beliebtesten Caching-Plugins, um die Ladezeiten von WordPress-Seiten zu optimieren. Bei ressourcenintensiven Websites – wie zum Beispiel großen WooCommerce-Shops oder Portalen mit vielen dynamischen Inhalten – kann das Plugin in den Standardeinstellungen jedoch zu starken Lastspitzen führen. In einigen Fällen äußert sich dies durch CPU-Limits oder 503-Fehler (Service Unavailable).
Warum WP Rocket den Server beanspruchen kann
Ursächlich für hohe Serverlasten ist meist das ungedrosselte Zusammenspiel von zwei Hintergrundprozessen:
Der Preload-Bot (Vorladen): Der reguläre Preload-Prozess übergibt in der Standardeinstellung mitunter sehr viele URLs gleichzeitig an den Cache. Wenn der Bot zu schnell zu viele Seiten vorlädt, kann dies die CPU des Servers an die Belastungsgrenze bringen.
Der RUCSS-Stau (Remove Unused CSS): Die RUCSS-Funktion nutzt eine externe SaaS-API von WP Rocket, um das CSS für jede einzelne Seite auszulagern und zu berechnen. Fehlt das "Used CSS" für eine Seite, pausiert der Preload-Bot oft und reiht die URL wieder hinten ein. Laufen beide Prozesse zeitgleich, können sie sich aufstauen und sehr viele parallele Anfragen abfeuern, was technisch wie eine hohe Zugriffswelle (DDoS) auf den Server wirkt.
👉 Hinweis zum Support-Umfang: Als Managed WordPress Hoster ist unsere Serverstruktur bereits stark auf Performance ausgelegt. Bitte habe Verständnis dafür, dass wir keinen direkten Support oder Konfigurationseinstellungen für Drittanbieter-Plugins wie WP Rocket übernehmen können. Die folgenden Best Practices basieren auf unseren Erfahrungen und Analysen und helfen oft dabei, die Stabilität deiner Website eigenverantwortlich zu sichern.
💡 Best Practices: Der optimale Caching-Workflow mit WP Rocket
Oftmals lassen sich Lastspitzen bereits durch eine kleine Anpassung im täglichen Umgang mit dem Caching-Plugin vermeiden. Folgende Herangehensweisen können hier sehr gut helfen:
Der Automatik vertrauen: Es ist meist nicht notwendig, den gesamten Cache nach jeder kleinen inhaltlichen Änderung (z. B. bei neuen Texten oder Produkten) manuell zu leeren. WP Rocket z.B. löscht den Cache für bearbeitete Einzelseiten in der Regel vollautomatisch. Den Rest erledigt das eingestellte Intervall der "Cache-Lebensdauer" (Cache Lifespan) geräuschlos im Hintergrund.
"Used CSS" (RUCSS) als Notfallknopf: Der Cache für das ungenutzte CSS sollte im Idealfall nur dann geleert werden, wenn tiefgreifende Design- oder Theme-Änderungen (z. B. globale Elementor-Anpassungen) vorgenommen wurden. Ein manueller Klick auf diesen Button zwingt den Shop sonst häufig in eine langwierige Neuberechnung.
Mobilen Cache deaktivieren: Bei modernen, responsiven Themes bringt ein separater mobiler Cache oft keinen spürbaren Vorteil, verdoppelt aber die Rechenlast beim Preloading. Hier hilft es, diesen über das offizielle WP Rocket Helper-Plugin dauerhaft zu deaktivieren.
⚙️ WP Rocket Parameter drosseln (Helper Plugin)
Um die Standardwerte von WP Rocket etwas zu drosseln, empfehlen wir, das offizielle WPR Helper-Plugin "Change Parameters" zu installieren und mit serverseitig schonenderen Werten zu bestücken.
💡 Wichtig: Finde deinen Sweetspot: Die passenden Werte hängen immer stark vom individuellen Setup deiner Website ab (aktive Plugins, Theme, Datenbankgröße, Anzahl der Beiträge, etc.). Die folgenden Werte haben sich in Testreihen jedoch als äußerst stabil erwiesen und dienen als sehr guter Startwert.
So kann der angepasste PHP-Code innerhalb der Helper-Plugin-Datei aussehen:
<?php
/**
* Plugin Name: WP Rocket Helper - Change Parameters (Optimized)
* Description: Drosselt den WP Rocket Preload und RUCSS Prozess, um Lastspitzen auf aufwendigen Seiten abzufangen.
*/
// 1. Preload Batch Size (Standard: 25 -> Reduziert auf 20)
add_filter( 'rocket_preload_cache_pending_jobs_cron_rows_count', function() {
return 20;
} );
// 2. Preload Delay zwischen den Anfragen (Standard: 0 -> Setzt 1 Sekunde Pause)
add_filter( 'rocket_preload_delay_between_requests', function() {
return 1000000; // Wert in Mikrosekunden (1.000.000 = 1 Sekunde)
} );
// 3. Preload Cron Intervall (Standard: variabel -> Fest auf 60 Sekunden)
add_filter( 'rocket_preload_cron_interval', function() {
return 60; // Wert in Sekunden
} );
// 4. RUCSS Batch Size (Standard: 25 -> Reduziert auf 15)
add_filter( 'rocket_rucss_pending_jobs_cron_rows_count', function() {
return 15;
} );
// 5. RUCSS Cron Intervall (Standard: variabel -> Fest auf 60 Sekunden)
add_filter( 'rocket_rucss_cron_interval', function() {
return 60; // Wert in Sekunden
} );
(Hinweis: Ein expliziter Filter für die "Minimum Batch Size" ist in der WPR-API oft nicht mehr direkt verfügbar, die obenstehenden Parameter drosseln die Last in den meisten Fällen aber bereits zuverlässig).
🛠️ Alternative Lösung, falls die Parameter ignoriert werden: Der 9999-Trick
Falls du bemerkst, dass das Helper-Plugin aktiv ist, WP Rocket die drosselnden Parameter aber scheinbar ignoriert (manchmal überschreiben Themes oder andere Plugins die Hook-Prioritäten), kann die Ausführung erzwungen werden. Füge dazu die Priorität , 9999 am Ende jeder add_filter-Funktion hinzu.
Beispiel für die Eskalation beim Preload Delay:
add_filter( 'rocket_preload_delay_between_requests', function() {
return 1000000;
}, 9999 ); // <- Höchste Priorität erzwingt die Ausführung
🔗 Offizielle WP Rocket Hilfe Artikel & Helper Plugins
Für den direkten Download der benötigten Helper-Plugins und vertiefende Erklärungen kannst du direkt die offizielle englischsprachige Dokumentation von WP Rocket heranziehen:
Official WPR Helper Plugin: Change Parameters (edit parameters in PHP*)
Official WPR Helper Plugin: Deactivate Mobile Cache (just install)
Official WPR HelpCenter Article: Disable Mobile Cache
Official WPR HelpCenter Article: High CPU Usage
Official WPR HelpCenter Article: Remove Unused CSS