- Cart-Fragmente (wc-ajax) feuern bei jedem Seitenaufruf einen unkachebaren PHP-Request, auch für Besucher mit leerem Warenkorb. Das ist der häufigste unsichtbare Performance-Fresser in WooCommerce-Shops.
- Ein Objekt-Cache (Redis oder Memcached) halbiert die Datenbankabfragen auf dynamischen Seiten wie Warenkorb und Checkout, weil Abfrageergebnisse im RAM statt in MySQL gehalten werden.
- Veraltete WooCommerce-Stores lagern oft Gigabytes an Session-Daten und toten Transients in
wp_options. Das verlangsamt jede einzelne Seite, weil WordPress die autogeladenen Zeilen bei jedem Request komplett einliest. - High Performance Order Storage (HPOS) ist seit WooCommerce 8.2 der Standard für neue Shops. Wer HPOS noch nicht aktiviert hat, lässt bis zu 40x schnellere Bestellabfragen liegen.
- Das erste sichtbare Produktbild darf nicht lazy geladen werden. Das kostet laut web.dev bis zu 15 % beim LCP.
Ein WooCommerce-Shop, der langsam lädt, verliert Kunden, bevor die erste Produktseite fertig sichtbar ist. Laut Google Web Vitals-Daten beginnt ab 2,5 Sekunden LCP der messbare Rückgang der Abschlussquote. WooCommerce stellt dabei besondere Anforderungen: Eine Produktseite mit Galerie, Variantenauswahl und Warenkorb-Logik erzeugt deutlich mehr Datenbankabfragen und größere JavaScript-Pakete als eine statische Informationsseite. Wer nur generische WordPress-Performance-Tipps anwendet, erzielt selten eine messbare Verbesserung. Dieser Artikel nennt die sechs Hebel, die in WooCommerce-Shops konkret wirken, und zeigt, wie man sie ansetzt.
Warum WooCommerce anders ist als ein normales Blog
WordPress-Performance-Artikel raten zu Caching, Bildoptimierung und einem schnellen Hoster. Das stimmt, greift für WooCommerce aber zu kurz. Ein Shop hat Seiten, die nicht gecacht werden dürfen: Warenkorb, Checkout und Kundenkonto enthalten nutzerspezifische Inhalte. Sobald ein Besucher ein Produkt in den Warenkorb legt, muss die PHP-Schicht aktiv werden, und hier zeigen generische Caching-Lösungen schnell Nebenwirkungen. Im schlimmsten Fall sieht ein Kunde den Warenkorb eines anderen.
Dazu kommt der Umfang: Ein mittelgroßer Shop mit 500 Produkten, Variantenkombinationen und Bestellhistorie hat eine deutlich schwerere Datenbank als ein Blog mit 100 Artikeln. WooCommerce nutzt den Action Scheduler intensiv für Hintergrundprozesse, schreibt Session-Daten und Transients in wp_options, und erzeugt pro Bestellung mehrere Dutzend Datenbankzeilen, sofern HPOS nicht aktiv ist. Wer das ignoriert und einfach ein Caching-Plugin installiert, hat eine Seite, die im Messwerkzeug besser aussieht, beim Checkout aber falsch funktioniert oder sogar Kundendaten vermischt.
Die sechs Hebel unten sind auf genau diese WooCommerce-Eigenheiten ausgerichtet. Allgemeine WordPress-Performance wie Render-Blocking-Ressourcen oder Core Web Vitals Grundlagen behandeln die Ratgeber Core Web Vitals einfach erklärt und Caching verständlich erklärt.
Bevor es an die einzelnen Hebel geht, eine eigene Messung, die die Richtung weist.
der geprüften deutschen Shops überschreiten Googles Ladezeit-Schwelle von 2,5 Sekunden (LCP), obwohl der Server die erste Antwort meist schnell ausliefert.
Warum das zählt: Ab 2,5 Sekunden gilt der LCP für Google nicht mehr als „gut“ (Core Web Vitals), und Käufer springen messbar häufiger ab. Der Verlust passiert fast immer im Frontend, bei Bildern, Skripten und Rendering, nicht am Server.
Methodik: Eigene Render-Erhebung mit einem echten Browser über 341 deutsche Onlineshops, gemessen wurde der Largest Contentful Paint. LCP-Median 1,56 Sekunden. Stand: Juni 2026. Keine amtliche Grundgesamtheit.
Genau deshalb drehen sich die folgenden Hebel fast alle um das Frontend und die dynamischen Anfragen, nicht um einen schnelleren Server. Der erste sitzt direkt im WooCommerce-Kern.
Bevor es an die Technik geht, lohnt der Blick auf den Euro-Hebel. Das Tool schätzt aus Ihren Besucherzahlen, der Ladezeit und dem Warenkorbwert, wie viel Umsatz eine zu langsame Seite pro Monat kostet.
Cart-Fragmente (wc-ajax): der unsichtbare Performance-Fresser
/wp-admin/admin-ajax.php, um die Warenkorb-Anzeige aktuell zu halten. Das betrifft auch Besucher mit leerem Warenkorb und blockiert das Seitenladen, weil die Anfrage nicht aus dem Cache bedient werden kann.Das Skript wc-cart-fragments.js ist standardmäßig auf jeder Shop-Seite aktiv. Es sendet beim Laden der Seite eine Ajax-Anfrage an ?wc-ajax=get_refreshed_fragments. WordPress bootet dafür vollständig hoch, lädt WooCommerce, prüft die Session und liefert die aktuelle Warenkorb-Anzahl zurück. Bei einem Shop mit hohem Traffic laufen so tausende dieser Anfragen parallel, ohne dass ein einziger davon einen vollen Warenkorb liefert.
Das drückt den TTFB, weil PHP-FPM-Worker gebunden sind, solange die Admin-Ajax-Requests abgearbeitet werden. Daneben blockiert die Ajax-Antwort im Browser manche UI-Interaktionen, bis sie eingetroffen ist. WP Rocket löst das mit einer eigenen Cart-Fragment-Optimierung: Der Request wird verzögert, bis der Nutzer tatsächlich eine Interaktion auslöst. Alternativ lässt sich das Fragment-Update auf Warenkorb- und Checkout-Seiten beschränken, wo es wirklich gebraucht wird.
Wer das Verhalten manuell kontrollieren will, kann das Skript per PHP-Hook deregistrieren und nur auf den relevanten Seiten wieder einbinden. Achtung: Zeigt Ihr Theme einen Warenkorb-Zähler im Header (bei vielen Themes, auch Divi, Standard), wird dieser danach nicht mehr automatisch aktualisiert. Prüfen Sie das zuerst, sonst sieht der Kunde eine veraltete Warenkorb-Anzahl.
add_action( 'wp_enqueue_scripts', function() {
if ( ! is_cart() && ! is_checkout() ) {
wp_dequeue_script( 'wc-cart-fragments' );
}
}, 11 );Bei Shops ohne dauerhaft sichtbaren Header-Warenkorb ist das die einfachste Lösung mit der stärksten Wirkung. Wer den Header-Zähler braucht, nutzt stattdessen die verzögerte Variante von WP Rocket oder lädt die Fragmente erst bei der ersten Nutzer-Interaktion.
Objekt-Cache und Redis: Datenbankabfragen aus dem RAM beantworten
WordPress hat einen eingebauten Objekt-Cache, der aber nur innerhalb eines einzelnen PHP-Requests vorhält. Sobald der nächste Besucher die Seite aufruft, werden dieselben Datenbankabfragen neu ausgeführt. Ein persistenter Objekt-Cache via Redis oder Memcached hält die Ergebnisse über Requests hinweg im RAM und gibt sie sofort zurück.
Für WooCommerce ist das besonders relevant, weil Warenkorb- und Checkout-Seiten nicht seitengecacht werden können, aber trotzdem schnell sein müssen. Abfragen auf Produktdaten, Versandregeln und globale Shop-Optionen werden bei aktivem Redis-Cache aus dem Speicher beantwortet, nicht aus der Datenbank. Das nimmt der Datenbank genau die wiederkehrenden Abfragen ab, die sonst jeden einzelnen Request treffen.
Das empfohlene Plugin ist Redis Object Cache von Till Krüss. Es installiert ein Objekt-Cache-Drop-in (object-cache.php) und benötigt einen Redis-Dienst auf dem Server. Viele Managed-WordPress-Hoster bieten Redis als Zusatzmodul an. Die Konfiguration in wp-config.php beschränkt sich auf zwei Zeilen:
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );Wichtig: Redis zuerst einrichten, nachdem die Datenbank aufgeräumt ist, nicht davor. Ein Redis-Cache, der veraltete Transients und überdimensionierte wp_options-Daten cached, bringt keine Verbesserung, sondern konserviert das Problem im RAM.
Datenbank aufräumen: wp_options, Transients, Sessions, HPOS
wp_options komplett ein. Mehr als 500 Zeilen oder über 1 MB autogeladene Daten gelten laut WooCommerce-Dokumentation als problematisch. In älteren Shops sind es oft mehrere Tausend Zeilen.Der Datenbankbremsen-Klassiker in WooCommerce-Shops: Die Tabelle wp_options hat nach Jahren des Betriebs tausende Zeilen, davon viele mit autoload = yes. Das bedeutet, die Datenbank muss bei jedem einzelnen PHP-Request alle autogeladenen Zeilen lesen und das komplette Ergebnis an PHP übergeben. WordPress hat seit Version 6.1 zwar einen Index auf dem autoload-Feld, der bei der geringen Zahl möglicher Werte aber kaum greift. Der eigentliche Kostentreiber ist nicht die Suche, sondern die Datenmenge: Alle autogeladenen Zeilen werden bei jedem Request eingelesen, an PHP übertragen und dort deserialisiert. Je mehr und je größer sie sind, desto teurer wird jeder Seitenaufbau.
Die häufigsten Quellen für autogeladene Überreste: Plugins, die nach der Deinstallation ihre Optionen nicht bereinigen, veraltete WooCommerce-Transients und Session-Einträge für längst abgebrochene Warenkörbe. Ein SQL-Schnellcheck zeigt den aktuellen Zustand:
SELECT SUM(LENGTH(option_value)) AS total_bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');Der IN-Filter ist wichtig: Seit WordPress 6.6 gibt es mehrere autoload-Werte (yes, on, auto-on, auto) statt nur yes/no. Eine Abfrage auf autoload = 'yes' allein unterschätzt die wirklich geladene Datenmenge auf aktuellen Installationen deutlich oder liefert sogar null. Ein Ergebnis über 1.000.000 Bytes (1 MB) ist ein klares Signal zum Aufräumen. WP-Optimize oder die WooCommerce-eigene Tool-Seite unter WooCommerce > Status > Tools bieten eine geführte Bereinigung von veralteten Transients, Kundensitzungen und orphaned Variationen.
HPOS: der strukturelle Datenbanksprung für wachsende Shops
Bevor WooCommerce 8.2 im Oktober 2023 High Performance Order Storage (HPOS) einführte, wurden Bestelldaten in den WordPress-Standard-Tabellen wp_posts und wp_postmeta gespeichert, denselben Tabellen, die auch Seiten, Artikel und Mediendaten enthalten. Das bedeutete: Jede Bestellabfrage konkurrierte mit allen anderen WordPress-Abfragen um dieselben Tabellen-Locks.
HPOS verschiebt Bestelldaten in vier eigene Tabellen: wc_orders, wc_order_addresses, wc_order_operational_data und wc_orders_meta. Dedizierte Indizes auf diesen Tabellen sorgen dafür, dass Bestellabfragen nicht mehr mit Seiten, Artikeln und Mediendaten um dieselben Locks konkurrieren. Laut WooCommerce-Plattform-Update sind Bestellabfragen in WooCommerces eigenen Tests damit bis zu 40-mal schneller, der Checkout läuft bis zu 1,5-mal schneller, jeweils für Shops mit großem Bestellvolumen. Dass der Checkout weniger stark zulegt als die reine Abfrage, liegt daran, dass die Datenbankabfragen nur ein Teil des gesamten Checkout-Ablaufs sind. Für neue Shops ist HPOS seit WooCommerce 8.2 der Standard. Bestehende Shops aktivieren es unter WooCommerce > Einstellungen > Erweitert > Features, nachdem die Kompatibilität der installierten Plugins geprüft wurde.
Zu viele Plugins: was ein schlechtes Plugin wirklich kostet
Ein WooCommerce-Shop mit 25 Plugins muss nicht langsam sein. Ein Shop mit 12 Plugins, von denen eines schlecht programmiert ist, kann es trotzdem sein. Was zählt, ist, was jedes Plugin bei jedem Seitenaufruf tatsächlich tut.
Typische Plugin-Kostenstellen: Marketing-Pixel und Tracking-Tags, die synchron laden, Slider-Plugins mit unnötigem JavaScript auf Produktseiten, veraltete SEO-Plugins mit redundanten Datenbankabfragen oder Sicherheits-Plugins, die jeden Request vollständig scannen. Query Monitor listet für jeden Seitenaufruf alle Datenbankabfragen, sortiert nach Dauer, und zeigt, welche Datei oder welches Plugin sie ausgelöst hat. So lässt sich in Minuten feststellen, ob ein Plugin 50 Abfragen pro Seite auslöst, die eigentlich unnötig wären.
Der Audit-Ablauf ist einfach: Query Monitor installieren, Produktseite und Checkout aufrufen, die langsamsten Abfragen identifizieren, zum zugehörigen Plugin zurückverfolgen. Wer nicht weiterkommt, findet im Ratgeber Warum Ihre Website langsam ist weitere Diagnosewege.
JavaScript auf Seiten dequeue-n, wo es nicht gebraucht wird
WooCommerce selbst lädt standardmäßig mehrere Skripte global, darunter wc-cart-fragments.js (bereits behandelt), aber auch Checkout-Bibliotheken auf der Startseite. Per wp_dequeue_script lassen sich diese auf die Seiten beschränken, wo sie tatsächlich gebraucht werden. Das ist kein Plugin-Thema, sondern ein Konfigurationsthema, das ein gutes Child-Theme oder ein Funktions-Plugin löst.
Produktbilder optimieren: WebP, Lazy Loading, LCP-Falle
WooCommerce erzeugt beim Upload automatisch mehrere Bildgrößen: Thumbnail, Medium, Shop-Thumbnail und weitere je nach Theme. Das ist gut, funktioniert aber nur, wenn das Theme auch wirklich die passende Größe einbindet. Wenn ein Theme das Vollformat lädt und der Browser es auf Listengröße schrumpft, bezahlt der Nutzer für Pixel, die er nie sieht.
Seit WooCommerce 10.6 (ausgerollt im Februar 2026) sind Produktbilder standardmäßig lazy geladen. Das verbessert die Ladezeit für Bilder unterhalb des sichtbaren Bereichs, birgt aber eine Falle: Das erste sichtbare Hauptproduktbild auf einer Produktseite oder die erste Bildzeile im Shop-Archiv sind häufig das LCP-Element. Ist dieses Bild lazy geladen, fordert der Browser es bewusst verzögert an, statt sofort beim Seitenaufbau. Bei einem Bild, das ohnehin schon im sichtbaren Bereich liegt, schiebt das genau den wichtigsten Ladevorgang nach hinten und verschlechtert den LCP.
Die Lösung ab WooCommerce 10.6: Den Filter woocommerce_product_image_loading_attr nutzen, um für das erste Produktbild eager und ein <link rel="preload"> im Head zu setzen. WooCommerce liefert dafür seit 10.6 eine saubere Filter-Schnittstelle. Wer noch eine ältere Version fährt, hat das Standard-Lazy-Loading von WooCommerce zwar nicht, sollte aber prüfen, ob Theme oder ein Performance-Plugin die Bilder verzögert lädt: Dort entsteht dieselbe LCP-Falle, und sie wird dann im Theme beziehungsweise im Plugin entschärft.
Bildformat: WebP als Standard, AVIF wo unterstützt
WebP wird von allen modernen Browsern unterstützt und spart gegenüber JPEG bei vergleichbarer Qualität 25-35 % Dateigröße. AVIF ist kompakter, wird aber noch nicht überall unterstützt. Für die Praxis heißt das: WebP als Standard einsetzen und AVIF dort ergänzen, wo die Browser-Unterstützung schon trägt. Das Marketplace-Plugin GP Images Optimizer (von GrandPlugins) konvertiert hochgeladene Bilder serverseitig in WebP oder AVIF, ohne externe Dienste. Cloudflare Images und Bunny.net Optimizer erledigen das alternativ auf CDN-Ebene, sobald ein Bild angefordert wird.
Hosting für Shops: PHP 8.3, OPcache, Memory-Limit
Das Hosting ist der erste Flaschenhals, an dem alle anderen Optimierungen scheitern können. Ein günstiger Shared-Hoster mit zu vielen Projekten auf derselben Maschine liefert schlechte TTFB-Werte (mehr als 600 ms), egal wie gut der Shop sonst konfiguriert ist. Ein guter Richtwert für TTFB ist unter 200 ms, messbar mit WebPageTest.
PHP-Version und OPcache
PHP 8.3 ist die aktuell von WooCommerce empfohlene Version laut offizieller Serverdokumentation. Der Unterschied zu PHP 7.4 ist groß: PHP 8 verarbeitet objektintensiven Code wie WooCommerce schneller, weil die Zend-Engine ab Version 8 deutlich effizienter arbeitet. Verbreiteter Mythos: Der oft genannte JIT-Compiler von PHP 8 mache WooCommerce schneller. In der Praxis hilft JIT vor allem bei rechenintensiven Batch-Berechnungen, im typischen, I/O-lastigen Web-Request eines Shops dagegen kaum. PHP 7.4 hat zudem seit Dezember 2022 keine Sicherheitsupdates mehr erhalten und sollte in keiner Produktivumgebung mehr betrieben werden.
OPcache hält den kompilierten PHP-Bytecode im Arbeitsspeicher. Ohne OPcache muss PHP bei jedem Aufruf alle PHP-Dateien von WooCommerce (mehrere Hundert) neu parsen und kompilieren. Mit OPcache geschieht das einmalig beim ersten Aufruf. Ein realistischer Startwert für opcache.memory_consumption sind 128 MB, für große Shops mit vielen Plugins 256 MB.
Managed Hosting und WooCommerce-spezifische Optionen
Der Ratgeber WordPress-Hosting: Worauf es bei Tempo und Sicherheit ankommt vergleicht Hosting-Optionen im Detail. Für WooCommerce gelten zusätzliche Anforderungen: Redis muss als Dienst verfügbar sein, wenn ein Objekt-Cache geplant ist. Die Datenbank sollte idealerweise auf demselben Server oder im selben Rechenzentrum laufen, da jede Netzwerklatenz zwischen Webserver und Datenbankserver bei mehreren Dutzend Abfragen pro Seite direkt in der Gesamtladezeit ankommt. PHP-FPM mit separatem Pool für WooCommerce verhindert außerdem, dass ein langsamer Request die gesamte PHP-Verfügbarkeit blockiert.
Vergleich: Hebel, Wirkung, Aufwand
| Hebel | Wirkung | Aufwand | Priorität |
|---|---|---|---|
| Cart-Fragmente einschränken oder verzögern | Hoch: jeder Seitenaufruf profitiert, TTFB sinkt | Niedrig bis mittel (WP Rocket oder PHP-Hook) | Sehr hoch |
| Objekt-Cache via Redis | Hoch: Datenbankabfragen auf dynamischen Seiten halbiert | Mittel (Redis auf Server + Plugin) | Sehr hoch |
| wp_options aufräumen (autoload, Transients) | Mittel bis hoch: Seitenaufbau-Bottleneck beseitigt | Niedrig (WP-Optimize oder WC-Tools) | Hoch, vor Redis-Einrichtung |
| HPOS aktivieren | Sehr hoch für große Shops: bis zu 40x schnellere Bestellabfragen | Niedrig bis mittel (Plugin-Kompatibilität prüfen) | Hoch für Shops mit 1.000+ Bestellungen |
| Plugin-Audit mit Query Monitor | Variabel: bis zu mehrere Sekunden bei einem schlechten Plugin | Niedrig (Analyse) bis mittel (Plugin austauschen) | Hoch |
| Bilder: WebP + LCP-eager | Hoch: größtes Datenvolumen reduziert, LCP-Falle entschärft | Niedrig bis mittel (Plugin oder CDN) | Hoch |
| Hosting-Upgrade: PHP 8.3, OPcache, Redis | Sehr hoch als Basis: alle anderen Optimierungen bauen darauf auf | Mittel bis hoch (Hosting-Wechsel) | Hoch wenn TTFB über 600 ms |
Schritt für Schritt: WooCommerce-Performance analysieren und verbessern
- Ausgangsmessung: Google PageSpeed Insights für Startseite, Produktseite, eine Produktkategorie-Seite und die Checkout-Seite aufrufen. TTFB, LCP, INP und Total Blocking Time notieren. Das ist die Basis für die spätere Erfolgsbewertung.
- TTFB prüfen: Liegt der TTFB über 600 ms, ist das Hosting der Engpass. PHP-Version, OPcache und Memory-Limit beim Hoster prüfen. Wenn das Hosting nicht aufgerüstet werden kann, lohnt sich eine Migration auf ein Managed-WordPress-Hosting mit WooCommerce-Unterstützung.
- wp_options-Größe messen: Per SQL (siehe Abschnitt oben) oder WP-Optimize prüfen, wie viele autogeladene Bytes vorhanden sind. Über 1 MB: aufräumen. Veraltete Transients und WooCommerce-Sessions löschen.
- Plugin-Audit mit Query Monitor: Plugin installieren, Produktseite aufrufen, Abfragen nach Dauer sortieren. Jedes Plugin mit mehr als 20 Abfragen pro Seite oder mehr als 100 ms Datenbankzeit untersuchen.
- Cart-Fragmente einschränken: Entweder über WP Rocket (WooCommerce-Modus) oder manuell per PHP-Hook (siehe Abschnitt oben). Nach der Änderung messen.
- Redis einrichten: Wenn der Hoster Redis anbietet, Plugin installieren, Verbindung konfigurieren, Objekt-Cache aktivieren. Danach erneut Checkout-Seite messen.
- HPOS aktivieren: Unter WooCommerce > Einstellungen > Erweitert > Features die Plugin-Kompatibilität prüfen (WooCommerce zeigt nicht-kompatible Plugins an) und HPOS dann aktivieren.
- Bilder nachziehen: Bildformat und LCP-Eager für das erste Produktbild einrichten. WebP-Konvertierung über Plugin oder CDN aktivieren.
- Abschlussmessung: Dieselben vier Seiten nochmals mit PageSpeed Insights messen. Alle Werte mit der Ausgangsmessung vergleichen.
Praxisbeispiel
Nehmen wir einen Onlineshop mit rund 800 Produkten, der seit Jahren auf demselben Hoster läuft. Der LCP auf der Startseite liegt über 4 Sekunden, der Checkout bei knapp 4 Sekunden. Der Checkout ist nie gecacht und reagiert trotzdem zäh.
Die Analyse mit Query Monitor zeigt oft das gleiche Bild: weit über hundert Datenbankabfragen auf der Produktlisten-Seite, ein großer Teil davon durch ein Bewertungs-Aggregations-Plugin, das jeden Seitenaufruf vollständig neu berechnet, statt Ergebnisse zu cachen. Der zweite typische Fund: wp_options mit tausenden autogeladenen Zeilen, mehrere MB groß, überwiegend veraltete Transients aus zuvor deinstallierten Plugins.
Die Maßnahmen sind dann meist dieselben: wp_options bereinigen, das Bewertungs-Plugin durch eine schlanke Alternative ersetzen, einen Objekt-Cache wie Redis aktivieren, die PHP-Version aktualisieren und Cart-Fragmente auf Warenkorb- und Checkout-Seiten beschränken. Ein Hoster-Wechsel ist dafür oft nicht nötig, viele Hoster bieten Redis als optionalen Dienst an. Das Ergebnis: Startseiten-LCP und Checkout fallen deutlich unter 2 Sekunden. Der größte Sprung passiert meist am Checkout, weil der Objekt-Cache dort die Abfragen auf Versandregeln, Steuerklassen und Kundendaten aus dem RAM beantwortet statt aus der Datenbank.
Diese Analyse mit Query Monitor, SQL-Checks und PageSpeed setzt einiges an Zeit und Technik voraus. Wer sie nicht selbst fahren will: Wir übernehmen den Performance-Audit für Ihren WooCommerce-Shop, von der Messung über die Ursachensuche bis zur priorisierten Maßnahmenliste. Zu den Leistungen.
Sofort-Checkliste
- TTFB unter 200 ms? (Messung mit WebPageTest)
- PHP 8.3 oder höher aktiv?
- OPcache auf dem Server aktiviert (mindestens 128 MB)?
- Memory-Limit auf mindestens 256 MB gesetzt?
- wp_options autogeladene Daten unter 1 MB?
- Veraltete WooCommerce-Transients und Sessions bereinigt?
- HPOS aktiviert oder Plugin-Kompatibilität geprüft?
- Redis-Objekt-Cache eingerichtet?
- Cart-Fragmente auf Cart/Checkout beschränkt?
- Query Monitor laufen lassen und Abfragen auswerten?
- Produktbilder im WebP-Format?
- LCP-Hauptbild nicht lazy geladen (loading=“eager“ + preload)?
- Caching-Plugin mit WooCommerce-Modus aktiv?
- Cart-Fragmente und ein überladenes
wp_optionssind die häufigsten unsichtbaren Performance-Bremsen in gewachsenen WooCommerce-Shops, oft wichtiger als das Hosting. - Ein Objekt-Cache via Redis ist der wirksamste Einzelhebel für Warenkorb- und Checkout-Geschwindigkeit, weil diese Seiten nicht seitengecacht werden können.
- HPOS bringt für Shops mit mehr als 1.000 Bestellungen einen strukturellen Datenbanksprung. Vor der Aktivierung Plugins auf Kompatibilität prüfen.
- Das erste sichtbare Produktbild muss mit
loading="eager"und einem Preload-Link im Head ausgeliefert werden, alles andere kostet LCP-Punkte.
Häufige Fragen
Macht ein Caching-Plugin den WooCommerce-Shop allein schnell?
Nein. Seitencaching hilft für statische Seiten wie Produktlisten und die Startseite, greift aber auf Warenkorb, Checkout und Kundenkonto nicht, weil diese Seiten nutzerspezifische Inhalte enthalten. Caching ist ein wichtiger Baustein, ersetzt aber keine Datenbankbereinigung, keinen Objekt-Cache und kein Bild-Management. Mehr zum Thema Caching erklärt der Ratgeber Caching verständlich erklärt.
Was ist der Unterschied zwischen Seiten-Cache und Objekt-Cache?
Ein Seiten-Cache speichert die fertig gerenderte HTML-Seite und liefert sie ohne PHP-Verarbeitung aus. Ein Objekt-Cache speichert Datenbankabfrage-Ergebnisse im RAM und gibt sie an PHP zurück, das dann trotzdem noch rendert. Für WooCommerce braucht man beides: Seiten-Cache für statische Seiten, Objekt-Cache für dynamische Seiten. Eine Ausnahme sind Produktlisten mit individualisierten Preisen (etwa Kundengruppen im B2B) oder mit Echtzeit-Lagerbeständen: Sie sind nicht ohne Weiteres seitencachebar, hier muss das Caching-Plugin entsprechend konfiguriert werden.
Kann ich HPOS nachträglich aktivieren, wenn der Shop schon läuft?
Ja. WooCommerce bietet einen geführten Migrationsprozess mit einem Kompatibilitätsmodus: Alte und neue Tabellen können parallel betrieben werden, bis alle Plugins kompatibel sind. WooCommerce zeigt bei der Aktivierung an, welche installierten Plugins noch nicht kompatibel sind. Eine Migration auf einem Testsystem vorab ist dennoch empfohlen.
Welches Bildformat soll ich für Produktbilder nehmen?
WebP ist der sichere Standard: breite Browser-Unterstützung, 25-35 % kleiner als JPEG. AVIF ist kompakter, läuft aber noch nicht auf allen Geräten. Beide Formate lassen sich serverseitig automatisch konvertieren, entweder über ein Plugin wie GP Images Optimizer oder auf CDN-Ebene über Cloudflare Images oder Bunny.net. Das Originalformat spielt dann keine Rolle mehr, weil der Browser das optimale Format erhält.
Ab wie vielen Produkten muss ich über Datenbankoptimierung nachdenken?
Die Produktanzahl ist weniger entscheidend als das Bestellvolumen und die Laufzeit des Shops. Ein Shop mit 200 Produkten und drei Jahren Betrieb hat oft mehr Datenbankprobleme als ein frischer Shop mit 2.000 Produkten, weil sich veraltete Transients, Sessions und Plugin-Reste über Zeit ansammeln. Der SQL-Schnellcheck auf die Gesamtgröße der autogeladenen wp_options-Daten ist für jeden Shop sinnvoll, unabhängig von der Produktanzahl.
Mein Shop ist schnell im Desktop-Test, aber langsam auf dem Handy. Warum?
Google PageSpeed Insights misst mobil mit einer gedrosselten Verbindung (simuliertes 4G mit rund 150 ms Round-Trip-Zeit). Shops mit nicht größenoptimierten Bildern oder blockierendem JavaScript schneiden mobil deutlich schlechter ab. Bilder, die Desktop-Format ausliefern statt des für Mobilgeräte passenden Formats, sind häufig die Hauptursache. Das Thema Core Web Vitals auf mobilen Geräten erklärt der Ratgeber Core Web Vitals einfach erklärt.