WooCommerce schneller machen: Was im Shop wirklich zählt

Ein WooCommerce-Shop ist kein normaler WordPress-Blog – und genau deshalb greifen viele generische Performance-Tipps zu kurz. Shops haben dynamische, nutzerspezifische Bereiche, die sich nicht einfach statisch cachen lassen. Wer weiß, wo WooCommerce typisch bremst, optimiert gezielt statt mit der Gießkanne. Dieser Beitrag zeigt die shop-spezifischen Bremsen, wie du sie löst – und in welcher Reihenfolge.

Warum ein Shop anders ist als ein Blog

Bei einem Blog kannst du fast jede Seite einmal vorbauen und als fertiges HTML ausliefern. Ein Shop kann das nicht: Warenkorb, Kasse und „Mein Konto” sehen für jeden Besucher anders aus und ändern sich in Echtzeit. Genau diese dynamischen Bereiche sind der Grund, warum ein einfacher Page-Cache im Shop nicht reicht – und warum WooCommerce eigene Optimierungen braucht.

Die WooCommerce-spezifischen Bremsen

1. Cart Fragments (AJAX-Warenkorb)

Ältere WooCommerce-Versionen (vor 7.8) luden den Warenkorb-Status per AJAX bei jedem Seitenaufruf nach – auch auf Seiten, die gar keinen Warenkorb zeigen. Seit Version 7.8 geschieht das laut WooCommerce-Entwicklerblog nur noch, wenn ein Mini-Cart-Widget ausgegeben wird; Themes wie Storefront, die das Widget fest einbauen, laden das Skript aber weiterhin überall. Jeder dieser Aufrufe geht am Page-Cache vorbei direkt auf den Server. Auf traffic-starken Shops summiert sich das zu spürbarer Last.

Die Lösung ist nicht, das Skript pauschal zu killen (dann aktualisiert sich der Warenkorb-Zähler nicht mehr), sondern es nur dort zu laden, wo ein Warenkorb sichtbar ist:

// In functions.php des Child-Themes oder einem eigenen Plugin
add_action( 'wp_enqueue_scripts', function () {
    // Auf Warenkorb, Kasse und Konto aktiv lassen
    if ( is_cart() || is_checkout() || is_account_page() ) {
        return;
    }
    wp_dequeue_script( 'wc-cart-fragments' );
}, 99 );

Auf reinen Inhaltsseiten – Blog, Über uns, Kontakt – braucht niemand den Live-Warenkorb. Dort spart das Deaktivieren pro Aufruf einen Server-Request – sofern das Skript bei dir dort überhaupt geladen wird, was sich im Netzwerk-Tab des Browsers prüfen lässt.

2. Nicht cachebare Seiten

Warenkorb, Kasse und „Mein Konto” sind pro Nutzer unterschiedlich und dürfen nicht statisch gecacht werden – sonst sieht Kunde B den Warenkorb von Kunde A. Ein guter Cache schließt diese Seiten deshalb bewusst aus. Damit sie trotzdem schnell bleiben, setzt der Object-Cache an (dazu gleich mehr).

3. Query-Last durch Produkte und Filter

Große Kataloge mit Attributen, Varianten und Filtern erzeugen schwere Datenbankabfragen. Ein Layered-Nav-Filter, der bei jedem Klick den gesamten Katalog neu durchsucht, bringt auch schnelle Server ins Schwitzen. Hier helfen ein sauberer Object-Cache, schlanke Filter-Lösungen und das Vermeiden von Plugins, die auf jeder Seite den gesamten Katalog abfragen.

Object-Cache: der wichtigste Hebel für Shops

Der Object-Cache ist die Zutat, die im Shop den größten Unterschied macht – und die auf günstigem Hosting oft fehlt. Er speichert die Ergebnisse von Datenbankabfragen im Arbeitsspeicher (per Redis oder Memcached), sodass WooCommerce dieselbe Abfrage nicht bei jedem Aufruf neu an die Datenbank schickt. Gerade an den dynamischen Seiten, die kein Page-Cache abfängt, ist das der spürbarste Beschleuniger.

In der Praxis heißt das: Redis auf dem Server installieren (oder ein Hosting wählen, das es mitbringt), das passende Plugin aktivieren und in der wp-config.php verbinden. Viele gute Managed-WordPress-Hoster liefern Redis fertig konfiguriert – ein Kriterium, auf das sich bei der Hosting-Wahl zu achten lohnt. Die Grundlagen zum Zusammenspiel von Page- und Object-Cache haben wir in Caching richtig einrichten beschrieben.

Die Basics, die auch hier gelten

• Server-Caching für alle nicht-dynamischen Seiten (Startseite, Kategorien, Produktseiten ohne personalisierten Inhalt).
• Bilder in WebP oder AVIF, korrekt dimensioniert – Produktbilder sind oft die größten LCP-Treiber im Shop.
• Aufgeräumte Datenbank – Shops sammeln besonders viele Transients und verwaiste Metadaten → Datenbank optimieren.
• Schlanke Plugin-Auswahl – jedes Shop-Plugin, das im Frontend lädt, kostet INP.

Hosting: der Unterbau entscheidet

Kein Optimierungstrick rettet einen Shop auf zu schwachem Hosting. WooCommerce braucht mehr als ein Blog: genug Arbeitsspeicher (PHP memory_limit realistisch 256 MB oder mehr), eine aktuelle PHP-Version, Object-Cache-Unterstützung und eine Datenbank, die auch unter Last antwortet. Billiges Shared Hosting, das sich zehn Nachbarn teilen, ist im Verkauf der falsche Sparposten – die langsame Kasse kostet mehr, als das bessere Hosting im Jahr ausmacht.

Reihenfolge fürs Optimieren

1. Felddaten messen – vor allem INP, weil Shops interaktiv sind und hier am ehesten schwächeln.
2. Cart Fragments dort deaktivieren, wo kein Warenkorb gebraucht wird.
3. Object-Cache für Warenkorb, Kasse und Konto einrichten.
4. Server-Caching für statische Shop-Seiten.
5. Produktbilder und Datenbank angehen.
6. Nach jeder Änderung erneut messen – nicht alles auf einmal umbauen.

Das Ziel sind dieselben Core Web Vitals wie bei jeder WordPress-Seite – nur mit Rücksicht auf die dynamischen Shop-Bereiche.

---

Dein Shop ist langsam, aber du willst Warenkorb und Checkout nicht riskieren? Schreib uns kurz – wir beschleunigen WooCommerce gezielt, ohne den Kaufprozess zu stören.