WooCommerce-Shop wird langsam: Warenkorb-Fragmente, Sessions und Datenbank in der richtigen Reihenfolge prüfen
Ein WooCommerce-Shop wird mit der Zeit zäh: So prüfe ich Warenkorb-Fragmente, Sessions und die Datenbanktabellen in der richtigen Reihenfolge.


Ein WooCommerce-Shop, der am Anfang flott war und nach ein, zwei Jahren spürbar zäh wirkt, hat selten ein einziges Problem. Meist kommen drei Dinge zusammen: die Warenkorb-Fragmente, die bei jedem Seitenaufruf nachladen, aufgeblähte Sessions in der Datenbank und Tabellen, die seit der Installation nie aufgeräumt wurden. Ich gehe bei einem trägen Shop immer in derselben Reihenfolge vor, weil die Reihenfolge darüber entscheidet, ob ich das eigentliche Problem finde oder nur Symptome bekämpfe.
Das Symptom: Seiten laden langsam, aber nur eingeloggt oder im Shop
Typisch: Startseite und Blogbeiträge sind schnell, aber Produktseiten, Warenkorb und Kasse brauchen deutlich länger. Im PageSpeed-Test sieht alles unauffällig aus, weil dort meist ein nicht eingeloggter Besucher ohne Warenkorbinhalt gemessen wird. Für echte Kunden mit gefülltem Warenkorb sieht die Zeit bis zur ersten Reaktion ganz anders aus – ein Hinweis darauf, dass das Problem nicht im Theme oder in den Bildern steckt, sondern in dem, was WooCommerce bei jedem Aufruf im Hintergrund nachlädt.
Ursache 1: Warenkorb-Fragmente laufen bei jedem Seitenaufruf mit
WooCommerce hält den Warenkorb-Hinweis im Header (Anzahl Artikel, Zwischensumme) per AJAX-Aufruf aktuell, dem sogenannten Cart-Fragments-Request. Das ist nötig, weil die Seite selbst oft aus dem Cache kommt und sonst einen veralteten Warenkorbstand zeigen würde. Das Problem: Dieser Aufruf läuft bei jedem einzelnen Seitenaufruf, auch wenn sich am Warenkorb nichts geändert hat, und er umgeht dabei jedes Seiten-Caching, weil er dynamisch sein muss. Bei vielen gleichzeitigen Besuchern erzeugt das spürbar Last auf dem Server, unabhängig davon, wie schnell die restliche Seite ausgeliefert wird.
Ich prüfe das über die Entwicklertools im Browser, Reiter Netzwerk: Taucht bei jedem Seitenwechsel ein Aufruf auf ?wc-ajax=get_refreshed_fragments auf, der mehrere hundert Millisekunden braucht, ist das ein klarer Kandidat. Abschalten sollte man den Mechanismus nicht einfach, sonst zeigt der Warenkorb falsche Stände. Sinnvoller: ihn gezielt entschärfen, sodass er nur dort lädt, wo der Warenkorb-Hinweis tatsächlich sichtbar ist, und nicht auf jeder Blogseite.
Ursache 2: Sessions wachsen in der Datenbank und werden nie aufgeräumt
Jeder Besucher mit Artikeln im Warenkorb bekommt eine Session, die WooCommerce in der Tabelle wp_woocommerce_sessions speichert. Bei Shops mit viel Traffic und wenig Kaufabschluss sammeln sich dort schnell zehntausende Zeilen an, weil Sessions standardmäßig erst nach 48 Stunden abgelaufen gelten und auch dann nicht sofort gelöscht werden. Eine Tabelle mit mehreren hunderttausend Zeilen macht jede Abfrage, die WooCommerce auf sie absetzt, messbar langsamer, und das betrifft praktisch jeden Aufruf einer Shopseite.
Ich sehe mir diese Tabelle über phpMyAdmin oder Adminer an der Zeilenanzahl an. Mehr als 20.000 bis 30.000 Einträge sind ein Warnsignal. Abgelaufene Sessions räumt WooCommerce über einen eigenen Cronjob auf, der nur läuft, wenn die Seite auch aufgerufen wird – bei wenig Besucherverkehr oder deaktiviertem WP-Cron bleibt die Aufräumfunktion stehen. Ein serverseitiger Cronjob, der wp-cron.php zuverlässig anstößt, löst das dauerhaft; ein einmaliges Löschen der abgelaufenen Zeilen schafft nur kurzfristig Luft.
Ursache 3: Die Datenbank selbst ist seit Jahren nicht gepflegt
Neben Sessions sammeln sich weitere Altlasten an: verwaiste Postmeta-Einträge gelöschter Produkte, Entwürfe, Revisionen, Protokolleinträge von Zahlungs-Plugins ohne Aufbewahrungsfrist. Solche Tabellen werden bei normalen WooCommerce-Abfragen mitgelesen, selbst wenn die Daten längst irrelevant sind – das zeigt sich nicht als einzelner langsamer Vorgang, sondern als generelle Trägheit, die mit dem Alter des Shops zunimmt.
Vor jeder Bereinigung steht ein vollständiges Datenbank-Backup, denn gelöschte Metadaten lassen sich nicht zurückholen. Danach prüfe ich mit einem Plugin wie WP-Optimize oder Advanced Database Cleaner die Tabellengrößen und lösche gezielt verwaiste Einträge statt pauschal „alles bereinigen" anzuklicken – manche Zahlungsanbieter brauchen bestimmte Protokolle für Rückbuchungen.
Was danach zu prüfen ist
Nach den drei Schritten lohnt ein Blick auf den technischen Unterbau: Ein persistenter Objekt-Cache mit Redis oder Memcached nimmt WooCommerce einen großen Teil der wiederholten Datenbankabfragen ab, auch bei eingeloggten Nutzern und AJAX-Aufrufen, wo klassisches Seiten-Caching nicht greift. Ich prüfe außerdem, ob ein Sicherheits-Plugin den Cart-Fragments-Aufruf blockiert – dann zeigt der Warenkorb falsche Stände, ein neues, eigenes Problem.
Wie man es künftig vermeidet
Ein Shop, der von Anfang an einen funktionierenden WP-Cron-Mechanismus hat und in dem etwa vierteljährlich ein Blick auf die Tabellengrößen fällt, gerät selten in den Zustand, in dem sich Monate an Altlasten angesammelt haben. Wer auf ein größeres Sortiment umstellt oder deutlich mehr Besucher erwartet, sollte das Thema Hosting-Umfang und Betreuung vorher klären, statt erst bei den ersten Aussetzern zu reagieren. Wer unsicher ist, wo die eigene Installation steht, lässt sich Datenbank und Cron-Einstellungen einmal von außen ansehen – das genügt meist, um die größten Bremsen zu finden. Dazu passt auch ein Blick in mein Wissensangebot zu laufender Website-Betreuung.
Kurz beantwortet
Macht ein Caching-Plugin einen langsamen WooCommerce-Shop automatisch schnell?
Nein. Seiten-Caching hilft nicht eingeloggten Besuchern ohne Warenkorb, aber die Cart-Fragments-Aufrufe und Datenbankabfragen für Kunden mit Warenkorbinhalt laufen trotzdem bei jedem Aufruf neu.
Wie groß darf die Tabelle wp_woocommerce_sessions werden, ohne dass es auffällt?
Eine feste Grenze gibt es nicht, aber ab einigen zehntausend Zeilen wird der Effekt auf die Ladezeit in der Regel messbar. Entscheidend ist, dass abgelaufene Sessions überhaupt automatisch gelöscht werden.
Reicht es, einmal die Datenbank zu bereinigen?
Nein. Ohne funktionierenden Cronjob für die Session-Bereinigung und eine regelmäßige Kontrolle wachsen die Tabellen einfach wieder an, meist schneller, als man denkt.
Sie möchten das Thema für Ihr Unternehmen umsetzen? Mehr zu unseren Leistungen: Webdesign, SEO, GEO & AEO.
Konrad Griesser
Webdesigner & SEO-Experte aus Augsburg — seit 1999