Ein WooCommerce-Shop wird am häufigsten langsam durch fehlenden Seiten-Cache, zu wenige PHP-Worker in der Spitze, große Autoload-Optionen in der Datenbank, liegengebliebene Hintergrundaufgaben und Plugins, die externe Dienste abfragen. Beginnen Sie mit der Messung der Zeit bis zum ersten Byte (TTFB): Gut sind bis 0,8 s; in einem Shop mit funktionierendem Cache kann sie von 0,78 s auf 0,11 s sinken.
Erst messen, dann reparieren
TTFB von Produktseite und Warenkorb
In den Entwicklertools des Browsers (Tab Netzwerk) oder in PageSpeed Insights. Ein Produkt aus dem Cache sollte in Bruchteilen einer Sekunde antworten; der Warenkorb wird immer neu berechnet.
Cache-Header
Prüfen Sie auf LiteSpeed den Header
X-LiteSpeed-Cache.hitbedeutet eine Seite aus dem Cache,missoder kein Header – eine von Grund auf berechnete Seite.Query Monitor
Das Plugin Query Monitor zeigt die langsamsten Datenbankabfragen, HTTP-Anfragen an andere Dienste und das Plugin, das sie auslöst.
Ressourcenverbrauch im Panel
Treten in der Spitze Fehler 508 oder 503 auf, liegt das Problem bei den Prozesslimits, nicht im Code.
10 Ursachen, von der häufigsten an
| Ursache | Woran Sie sie erkennen | Was zu tun ist |
|---|---|---|
| 1. Kein Seiten-Cache | Kein X-LiteSpeed-Cache: hit auf Produktseiten | LSCache oder einen anderen Seiten-Cache aktivieren |
| 2. Kein Object Cache | Warenkorb und Dashboard langsam trotz Seiten-Cache | Redis als Object Cache – so prüfen Sie ihn |
| 3. Zu wenige PHP-Worker | Fehler 508/503 oder Warteschlange in der Spitze | Benötigte Zahl berechnen |
4. Großes Autoload in wp_options | Summe der automatisch geladenen Optionen über ca. 800 KB (Warnschwelle im Website-Zustand) | Autoload für große Optionen verwaister Plugins abschalten |
| 5. Liegengebliebene Hintergrundaufgaben | Tausende Aufgaben unter WooCommerce → Status → Geplante Aktionen | Abgeschlossene löschen, sich wiederholende reparieren |
| 6. WP-Cron, ausgelöst durch Besucher | Sprünge der Antwortzeit alle paar Minuten | In den System-Cron verlagern |
| 7. Plugin fragt einen externen Dienst ab | Query Monitor: langsame HTTP-Anfragen | Ergebnisse zwischenspeichern oder anderes Plugin |
| 8. Cart Fragments auf jeder Seite | wc-ajax=get_refreshed_fragments bei jedem Seitenaufruf | Auf Seiten beschränken, die den Mini-Warenkorb zeigen |
| 9. Alte PHP-Version | PHP 7.x im Panel | Nach Prüfung der Plugin-Kompatibilität auf PHP 8.x wechseln |
| 10. Schwere Bilder und Skripte | Schlechter LCP bei schnellem TTFB | WebP/AVIF, Lazy Loading, weniger externe Skripte |
Die Größe des Autoloads prüfen Sie in der Datenbank mit folgender Abfrage (seit WordPress 6.6 haben automatisch geladene Optionen die Werte yes, on, auto-on oder auto):
SELECT ROUND(SUM(LENGTH(option_value)) / 1024) AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');Wann das Hosting schuld ist
Antwortet eine Seite aus dem Cache schnell, Warenkorb und Dashboard sind aber trotz Object Cache und sauberer Datenbank langsam, liegt die Grenze meist in der Leistung des Tarifs: Zahl der PHP-Worker, Prozessor oder Festplatte. Beim Hosting von Aderlo Cloud sind LiteSpeed Enterprise, LSCache und eine eigene Redis-Instanz für jedes Konto ab dem ersten Tag eingerichtet; in einem unserer Shops sind das 0,78 s bis zum ersten Byte ohne Cache und 0,11 s mit Cache.
Tarife von Aderlo Cloud vergleichen →Häufige Fragen
- Welcher TTFB ist für einen WooCommerce-Shop gut?
- Google wertet bis 0,8 s als gut. Produktseiten aus dem Cache sollten deutlich darunter liegen; Warenkorb und Bestellung werden immer neu berechnet, dort zählen Serverleistung und Object Cache.
- Macht mehr RAM den Shop schneller?
- Nur wenn dem Shop Speicher fehlt. Häufiger liegt die Grenze bei den PHP-Workern, bei langsamen Datenbankabfragen oder bei fehlendem Cache – das sollten Sie vor einem Tarifwechsel messen.