Der umfassende Leitfaden zur WooCommerce-Performance (Edition 2026)

Standard-WooCommerce gerät ins Stocken, bevor der Katalog interessant wird. Eine frische Installation mit einigen hundert Produkten wirkt auf Staging schnell, dasselbe Template mit zehntausenden Produkten und Bestellungen bekommt eine lange TTFB, Cart Fragments stauen sich auf dem Shop-Archiv, und die Tabelle wp_options wächst unbemerkt.

Das Problem ist nicht die Plattform, sondern die Konfiguration und jahrelang angesammelte Plugins. Ein schneller WooCommerce-Shop entsteht durch Arbeit an genau diesen Stellen.

Dieser Text ist ein Praxisleitfaden, um WooCommerce gegen echte Last abzusichern. Er setzt Shell-Zugang, WP-CLI und die Bereitschaft voraus, das Slow Query Log zu lesen.

#Wie die HPOS-Migration in WooCommerce funktioniert

Ein Jahrzehnt lang speicherte WooCommerce Bestellungen als Beiträge vom Typ shop_order in wp_posts (dieselbe Tabelle wie Ihre Blog-Artikel) und zerlegte jede Position, jede Adresse und jedes Metadatenfeld in Zeilen in wp_postmeta. Eine Abfrage wie “Bestellungen aus dem Mai” bedeutete, eine Tabelle voller Revisionen, Autosaves und Seitenentwürfe zu scannen und danach drei- oder viermal mit postmeta zu joinen, um jede Bestellung zusammenzusetzen.

High Performance Order Storage verschiebt Bestellungen in wc_orders, wc_order_addresses, wc_order_operational_data und wc_orders_meta. Bestelllisten treffen direkt auf indexierte Spalten, statt jede Zeile aus postmeta zu rekonstruieren.

HPOS ist laut HPOS-Dokumentation seit WooCommerce 8.2, erschienen im Oktober 2023, der Standard für neue Installationen. Shops, die vor dieser Version gestartet sind, laufen oft noch mit der Speicherung in Beiträgen, deshalb steht die Migration in den meisten Audits weiterhin ganz oben.

Was HPOS allein nicht behebt:

• Eigene Plugins, die weiterhin in postmeta-Schlüssel schreiben statt über die Bestell-API, laufen nach dem Abschalten des Kompatibilitätsmodus still auseinander
• Plugins, die Bestelldaten mit get_post_meta($order_id, ...) statt $order->get_meta() lesen, liefern leere Werte, sobald die alte Tabelle nicht mehr maßgeblich ist
• Reports auf Basis von WP_Query gegen shop_order müssen neu geschrieben werden

Ablauf:

1. WooCommerce -> Einstellungen -> Erweitert -> Funktionen, High Performance Order Storage mit aktivem Kompatibilitätsmodus einschalten
2. Die Synchronisierung außerhalb der Spitzenzeiten laufen lassen; in einem großen Shop kann sie mehrere Stunden dauern
3. Mit wp wc hpos verify_data prüfen
4. Eine Woche lang alle Plugins testen, die Bestellungen berühren, während der Kompatibilitätsmodus weiter nach postmeta schreibt
5. Den Kompatibilitätsmodus erst abschalten, wenn jedes dieser Plugins nachweislich aus HPOS liest

wp wc hpos status
wp wc hpos sync --batch-size=500
wp wc hpos verify_data

#HPOS-Befehle in WP-CLI seit WooCommerce 8.9

Ältere Anleitungen nutzen den Namensraum wp wc cot. WooCommerce 8.9.0 hat ihn als veraltet markiert: Die alten Befehle laufen weiter, geben aber jeweils eine Warnung mit dem Nachfolger unter wp wc hpos aus, und verify_cot_data heißt jetzt verify_data (CLIRunner.php). Die Dokumentation der HPOS-CLI-Werkzeuge und die Docblocks der Befehle nennen den aktuellen Satz:

• wp wc hpos status zeigt die HPOS-Einstellungen und den Stand der Synchronisierung
• wp wc hpos count_unmigrated zählt Bestellungen, die noch auf die Synchronisierung warten
• wp wc hpos sync migriert Bestellungen in Stapeln, --batch-size steht standardmäßig auf 500
• wp wc hpos verify_data vergleicht beide Datenspeicher; das Flag --re-migrate synchronisiert abweichende Bestellungen erneut und kann eine Bestellung überschreiben, also zuerst auf Staging testen
• wp wc hpos diff 123 zeigt die Unterschiede einer einzelnen Bestellung
• wp wc hpos compatibility-mode enable und disable schalten die Synchronisierung ohne Admin-Oberfläche
• wp wc hpos cleanup entfernt alte Beitragsdaten migrierter Bestellungen. Die Dokumentation nennt den Befehl destruktiv, ohne Argumente tut er nichts; wp wc hpos cleanup all verarbeitet alle Bestellungen

Führen Sie cleanup erst aus, wenn der Kompatibilitätsmodus lange genug abgeschaltet ist, dass kein Plugin mehr die alte Kopie liest, und immer nach einem Datenbank-Backup.

#Wie ein eigenes Plugin HPOS-kompatibel wird

WooCommerce warnt Shop-Betreiber, wenn sie HPOS aktivieren wollen, während ein als inkompatibel deklariertes Plugin aktiv ist, und zeigt dieselbe Warnung auf der Plugin-Seite. Bei Plugins, die keine WooCommerce-Erweiterungen sind, erscheint die Warnung nur, wenn der Plugin-Header eine Zeile WC tested up to enthält. Ein eigenes Plugin deklariert seinen Status in der Hauptdatei, wie das HPOS-Rezeptbuch zeigt:

add_action( 'before_woocommerce_init', function() {
    \Automattic\WooCommerce\Utilities\FeaturesUtil::declare_compatibility( 'custom_order_tables', __FILE__, true );
} );

Die Deklaration ist ein Versprechen, keine Reparatur. Der Code dahinter muss Bestellungen mit wc_get_order() statt get_post() laden und Metadaten über das Bestellobjekt schreiben (update_meta_data(), add_meta_data(), delete_meta_data(), danach save()) statt mit update_post_meta(). Dann entscheidet WooCommerce, welche Tabellen den Schreibzugriff erhalten. Das Rezeptbuch weist darauf hin, dass save() relativ teuer ist; eine Schleife, die nach jeder einzelnen Metadaten-Änderung speichert, ist deshalb selbst ein Performance-Problem. Code, der nach Speicher-Engine unterscheiden muss, kann OrderUtil::custom_orders_table_usage_is_enabled() aufrufen.

#Wie man Cart Fragments in WooCommerce deaktiviert

Ein älterer WooCommerce-Shop oder einer mit Warenkorb-Widget im Header zeigt in GTmetrix oder WebPageTest die Anfrage ?wc-ajax=get_refreshed_fragments auf jeder Seite. Das ist WooCommerce, das PHP fragt, ob sich das Warenkorb-Symbol im Header geändert hat: auf der Startseite, im Blog, in Kategorie-Archiven, auf der Seite “Über uns”. Auch bei leerem Warenkorb.

Die einfachste Regel für den Geltungsbereich:

add_action( 'wp_enqueue_scripts', function() {
    if ( is_cart() || is_checkout() || is_product() ) {
        return;
    }
    wp_dequeue_script( 'wc-cart-fragments' );
}, 11 );

Plugins wie Perfmatters und Asset CleanUp bieten das als Schalter in der Oberfläche. Beide Wege führen zum selben Ziel: Cart Fragments sollen nur dort laufen, wo ein Warenkorb-Symbol live aktualisiert werden muss.

Wenn Sie den Zähler im Header wirklich auf jeder Seite brauchen, speichern Sie ihn in localStorage und aktualisieren Sie ihn per JavaScript bei Add-to-Cart-Ereignissen, statt den Server abzufragen.

#Wann WooCommerce Cart Fragments seit Version 7.8 noch lädt

WooCommerce 7.8 hat das Standardverhalten geändert. Laut dem Beitrag im WooCommerce-Entwicklerblog Best practices for the use of the “cart fragments” API (16. Juni 2023) wird das Skript nicht mehr auf jeder Route des Shops eingebunden. Es lädt weiterhin in drei Fällen: auf Seiten, auf denen das Warenkorb-Widget gerendert wird, wenn ein Drittanbieter-Skript das Cart-Fragments-Skript als Abhängigkeit registriert, und wenn Code es explizit einbindet. Derselbe Beitrag merkt an, dass manche Themes, darunter Storefront, das Widget fest in ihre Templates einbauen.

In einem aktuellen Shop ist die Anfrage im Wasserfall also ein Symptom mit auffindbarer Ursache. Suchen Sie im Seitenquelltext nach dem Handle wc-cart-fragments und verfolgen Sie, welches Theme-Template oder Plugin es nachlädt. Das Skript ohne diese Prüfung zu entfernen, kann einen Header-Warenkorb zerstören, den das Theme noch über Fragments aktualisiert, und ein Plugin, das das Skript als Abhängigkeit führt, bindet es ohnehin wieder ein.

#Object Cache oder Transients in der Datenbank

WooCommerce nutzt Transients intensiv: Preisspannen von Varianten, Abfragen von Attribut-Begriffen, Versandkostenberechnungen. Ohne Object Cache landen Transients in wp_options. Ob sie bei jeder Anfrage geladen werden, hängt vom Ablaufdatum ab: set_transient() speichert ein Transient ohne Ablauf mit Autoload und eines mit Ablauf ohne Autoload, plus eine eigene Zeile _transient_timeout_. WooCommerce speichert seine Transients für Variantenpreise und Kind-Varianten mit 30 Tagen Ablauf (Datenspeicher für variable Produkte), sie blähen also vor allem die Zeilenzahl von wp_options auf. Das Autoload-Gewicht kommt von Optionen, die Plugins ohne Ablauf schreiben.

Entscheiden Sie sich für ein Cache-Backend und bleiben Sie dabei. Entweder Redis oder Memcached als echter Object Cache, oder Transients in der Datenbank. Beides zu mischen erzeugt Invalidierungsfehler, die schwer zu diagnostizieren sind.

# Autoload-Größe in wp_options
wp db query "SELECT SUM(LENGTH(option_value)) AS bytes, COUNT(*) AS rows FROM wp_options WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');"

# Die größten Autoload-Optionen
wp db query "SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload IN ('yes', 'on', 'auto-on', 'auto') ORDER BY bytes DESC LIMIT 20;"

WordPress führt viele Abfragen aus, um eine einzelne Produktseite aufzubauen: Varianten, Preise, Lagerbestand. Redis hält die Ergebnisse dieser Abfragen im RAM. Ist Redis auf Serverebene eingerichtet, beim Hoster als verwalteter Dienst oder als eigene redis-server-Instanz, und liegt object-cache.php im Verzeichnis, schreibt set_transient() in den Object Cache statt in wp_options, Transients wandern in den RAM und der Druck auf Autoload sinkt.

#Autoload-Werte in WordPress 6.6 und die 800-KB-Grenze

WordPress 6.6 hat die Speicherung von Autoload geändert. Der Entwicklerhinweis des Core-Teams Options API: disabling autoload for large options führt die Datenbankwerte on, off, auto, auto-on und auto-off ein; on und off sind explizite Entscheidungen, auto-on und auto-off setzt WordPress selbst. Die Funktion wp_autoload_values_to_autoload() liefert yes, on, auto-on und auto, deshalb filtern die Audit-Abfragen oben auf genau diese Liste. Eine Abfrage, die nur autoload = 'yes' prüft, übersieht jede nach dem Update gespeicherte Option und lässt den Shop sauberer aussehen, als er ist.

Mit der Änderung kamen zwei Schwellen. Eine Option über 150 000 Bytes wird nicht automatisch geladen, außer der Code verlangt es ausdrücklich, und der Filter wp_max_autoloaded_option_size verschiebt diese Grenze. Website-Zustand meldet ein Problem, wenn die Gesamtgröße der Autoload-Optionen 800 KB übersteigt. Diese Prüfung ist der günstigste erste Test in einem unbekannten Shop, weil sie keinen Shell-Zugang braucht und das Problem benennt, bevor jemand einen Datenbank-Client öffnet.

#Was im WooCommerce-Shop nie gecacht werden darf

Statisches Caching hilft Archiven, Produktseiten und Blog-Beiträgen. Es zerstört alles, was von der Sitzung des Nutzers abhängt, weil jeder Kunde seinen eigenen Warenkorb hat.

Pflicht-Ausnahmen für jeden Seiten-Cache und jede Cloudflare-Regel:

• /warenkorb/ oder /cart/
• /kasse/ oder /checkout/
• /mein-konto/ oder /my-account/
• Jede URL mit ?wc-ajax=
• Jede Anfrage mit dem Cookie woocommerce_items_in_cart
• Die REST-Endpunkte unter /wp-json/wc/

Statische Inhalte (Bilder, CSS, JS) cachen Sie am Edge. Cloudflare APO für WordPress kann auch HTML für ausgeloggte Nutzer cachen und respektiert die Session-Cookies von WooCommerce, wenn es richtig konfiguriert ist. Prüfen Sie trotzdem mit curl -I auf Warenkorb und Kasse, ob cf-cache-status: BYPASS zurückkommt. Ein falsch konfigurierter Cache, der den Warenkorb eines anderen Kunden ausliefert, ist ein DSGVO-Vorfall und kein Performance-Gewinn.

#Abfragen variabler Produkte und der Filter woocommerce_variable_children_args

Variable Produkte mit jeweils dutzenden Varianten vervielfachen JOINs. Das Archiv eines Modeshops mit 200 variablen Produkten zu je 30 Varianten joint bei jedem Aufruf gegen wp_posts für 6000 Kind-Produkte.

Zwei praktische Korrekturen:

• Laden Sie für das Dropdown nur Varianten, die vorrätig und sichtbar sind
• Schließen Sie mit woocommerce_variable_children_args private und nicht vorrätige Varianten auf Archivseiten vom ersten Laden aus

add_filter( 'woocommerce_variable_children_args', function( $args ) {
    if ( is_shop() || is_product_category() ) {
        $args['post_status'] = 'publish';
        $args['meta_query'][] = array(
            'key'     => '_stock_status',
            'value'   => 'instock',
        );
    }
    return $args;
} );

#Wie man das Wachstum der Action-Scheduler-Tabellen bremst

Jede WooCommerce-Erweiterung, die im Hintergrund arbeitet, nutzt Action Scheduler. Abonnements, Folge-E-Mails, Wiederherstellung abgebrochener Warenkörbe, Lagerabgleich, ERP-Anbindungen: Alles landet in wp_actionscheduler_actions und wp_actionscheduler_logs.

In einem Shop mit aktiven Abonnements und Warenkorb-Wiederherstellung sammeln diese Tabellen innerhalb eines Jahres eine große Zahl abgeschlossener und fehlgeschlagener Aktionen an. Der Admin-Bereich fragt sie bei jedem Seitenaufruf ab, um den Zähler der Warteschlange anzuzeigen.

Wartungsskript:

# Abgeschlossene und abgebrochene Aktionen älter als 31 Tage löschen
wp action-scheduler clean --before="31 days ago" --pause=1

# Größe der Warteschlange prüfen
wp db query "SELECT status, COUNT(*) FROM wp_actionscheduler_actions GROUP BY status;"

# Indizes auf status und scheduled_date_gmt prüfen
wp db query "SHOW INDEX FROM wp_actionscheduler_actions;"

#Wie lange Action Scheduler abgeschlossene und fehlgeschlagene Aktionen behält

Action Scheduler räumt während der Queue-Läufe selbst auf. Sein Queue Cleaner löscht abgeschlossene und abgebrochene Aktionen, sobald sie älter als 31 Tage sind; der Filter action_scheduler_retention_period ändert dieses Fenster. Seit Action Scheduler 4.0 werden auch fehlgeschlagene Aktionen gelöscht, standardmäßig nach drei Monaten (action_scheduler_retention_period_for_failed); der Kommentar im Code verknüpft diesen Zeitraum mit dem Quartalsabschluss in der Buchhaltung.

Die Bereinigung läuft innerhalb des Queue Runners. In einem Shop, der WP-Cron abschaltet und keinen System-Cron hat, der wp-cron.php oder wp action-scheduler run aufruft, bleibt die Warteschlange stehen und die Bereinigung mit ihr, ohne sichtbare Fehlermeldung. Den Rückstand aus so einer Lücke räumen Sie von Hand mit wp action-scheduler clean auf, das laut WP-CLI-Referenz von Action Scheduler die Optionen --status (Standard canceled,complete), --before (Standard 31 Tage), --batch-size (Standard 20) und --pause für eine Pause zwischen Stapeln auf einer ausgelasteten Datenbank kennt.

#Wie man Produktbilder in WooCommerce optimiert

Produktbilder sind meist der schwerste Teil jedes Shops. Drei Regeln:

1. AVIF für Hauptbilder und Galerien, mit WebP als Rückfallebene für ältere Safari-Versionen, die noch im Traffic auftauchen
2. Keine rohen 4000-px-Exporte hochladen. Begrenzen Sie den Upload auf 2000 px an der langen Kante
3. Natives loading="lazy" reicht; entfernen Sie alte JavaScript-Lazy-Loader, die damit kollidieren

Verkleinern Sie Bilder vor dem Upload, statt WordPress Vorschaubilder im laufenden Betrieb erzeugen zu lassen, denn das schreibt nach wp_postmeta und bläht die Datenbank auf.

#Wie man die WooCommerce-Datenbank mit WP-CLI bereinigt

Führen Sie das monatlich aus, häufiger in Shops mit vielen abgebrochenen Warenkörben:

# Abgelaufene Sessions löschen (nur nötig, wenn die geplante Bereinigung steht)
wp db query "DELETE FROM wp_woocommerce_sessions WHERE session_expiry < UNIX_TIMESTAMP();"

# WooCommerce-Transients leeren
wp wc tool run clear_transients --user=1

# Tabellen optimieren
wp db optimize

# Tiefe der Action-Scheduler-Warteschlange prüfen
wp action-scheduler status

Planen Sie das per System-Cron statt über wp-cron.php, das nur bei Traffic auslöst. Das Flag --user bei wp wc tool run stammt aus den WooCommerce-CLI-Beispielen; setzen Sie die ID eines Administratorkontos Ihrer Installation ein. Wer lieber in der Oberfläche arbeitet, kann WP-Optimize verwenden.

#Wie WooCommerce Kunden-Sessions bereinigt

WooCommerce kürzt seine Session-Tabelle selbst. Es registriert eine wiederkehrende Action-Scheduler-Aktion woocommerce_cleanup_sessions, die alle 12 Stunden läuft (class-woocommerce.php), und der Session-Handler löscht abgelaufene Zeilen in Stapeln zu 100 mit einer kurzen Pause dazwischen. Eine Gast-Session läuft nach zwei Tagen ab, die eines eingeloggten Kunden nach sieben; die Filter wc_session_expiration und wc_session_expiring ändern beide Werte. Laufzeiten über 30 Tage erzeugen eine Warnung im WooCommerce-Log, weil längere Sessions die Tabelle wachsen lassen.

Daraus folgen zwei Dinge. Eine Session-Tabelle im Gigabyte-Bereich bedeutet meist, dass die Action-Scheduler-Warteschlange nicht läuft oder ein Plugin die Session-Laufzeit erhöht hat; prüfen Sie also wp action-scheduler status und diese Filter, bevor Sie etwas löschen. Und führen Sie auf einem Live-Shop nie TRUNCATE auf wp_woocommerce_sessions aus: Das leert jeden aktiven Warenkorb, während das DELETE ... WHERE session_expiry < UNIX_TIMESTAMP() oben nur bereits abgelaufene Zeilen entfernt.

#Welche WooCommerce-Performance-Kennzahlen man verfolgen sollte

Wer blind optimiert, optimiert das Falsche. Wählen Sie einige Signale und prüfen Sie sie wöchentlich:

• TTFB bei kaltem Cache auf dem Shop-Archiv und einer Produktseite
• Time to First Byte auf Warenkorb und Kasse mit einem und mit vier Artikeln im Warenkorb
• Zeilenzahl und Gesamtgröße der Autoload-Optionen in wp_options
• Tiefe der Action-Scheduler-Warteschlange und älteste ausstehende Aktion

Query Monitor auf Staging zeigt, welche Abfragen dominieren. New Relic oder Datadog APM in Produktion zeigen die echte Verteilung. PageSpeed Insights ist ein Rauchtest, keine Diagnose.

#Letzte Aktualisierung

2026-10-14. Wenn Ihr Shop zu keinem dieser Muster passt, liegt das Problem nicht in den Mustern. Lesen Sie zuerst das Slow Query Log. Für HPOS, Redis und Datenbankpflege im laufenden Shop hilft ein erfahrener WooCommerce-Entwickler.