WooCommerce Performance: Shop unter 2 Sekunden

Nur 31 % der WooCommerce-Shops bestehen die Core Web Vitals, Shopify schafft 52 %. HPOS, Cart Fragments, Redis: die Hebel für einen Shop unter 2 Sekunden.

Ein Kunde klickt auf deine Anzeige, landet auf der Produktseite und wartet. Eine Sekunde auf den ersten Text, vier Sekunden auf das Produktbild. Laut Google brechen 53 % der Mobile-Nutzer ab, wenn eine Seite länger als 3 Sekunden lädt. Den Klick hast du bezahlt, der Kauf passiert beim Wettbewerber, und in deinem Analytics-Dashboard steht ein weiterer Bounce.

Wie viel Geld dabei liegen bleibt, haben Deloitte und Google in der Studie "Milliseconds Make Millions" gemessen: 37 Brands, 30 Millionen Sessions. Im Retail brachten 0,1 Sekunden schnellere Ladezeit 8,4 % mehr Conversions und 9,2 % höhere Warenkorbwerte. Auf einen Shop mit 20.000 € Monatsumsatz übertragen sind das rund 1.700 € zusätzlich pro Monat, für eine Zehntelsekunde und ohne einen Euro mehr Werbebudget.

Dieser Artikel zeigt dir die Hebel, die einen WooCommerce-Shop unter 2 Sekunden bringen, geordnet nach Aufwand und Wirkung: vom 15-Minuten-Fix für Cart Fragments bis zur HPOS-Migration. Zu jedem Hebel gibt es die Zahl, die er auf der Uhr bewegt.

Was eine Sekunde Ladezeit kostet

Portent hat 100 Millionen Pageviews ausgewertet und einen klaren Zusammenhang gefunden: Pro zusätzlicher Sekunde Ladezeit sinkt die Conversion Rate um 4,42 %. Ein Shop, der in 1 Sekunde lädt, konvertiert mit 3,05 %. Derselbe Shop bei 5 Sekunden: 0,67 %. Gleiche Produkte, gleicher Traffic, ein Bruchteil des Umsatzes.

Die Bounce-Daten von Google und SOASTA zeigen dasselbe Muster von der anderen Seite: Steigt die Ladezeit von 1 auf 3 Sekunden, wächst die Absprungwahrscheinlichkeit um 32 %. Bei 5 Sekunden sind es 90 %. Jeder Absprung auf einer Produktseite ist ein Kunde, der dein Angebot nie gesehen hat.

Bevor du den ersten Hebel anfasst, halte den Ist-Zustand fest. PageSpeed Insights zeigt dir zwei Datensätze: oben die Felddaten aus dem Chrome User Experience Report, also was echte Besucher in den letzten 28 Tagen erlebt haben, darunter den Labortest. Für die Diagnose zählen die Felddaten. Und miss nicht nur die Startseite: Der Umsatz entsteht auf Produktseiten und im Checkout, also gehören genau diese URLs in den Test. Ein Shop mit schneller Startseite und 4-Sekunden-Produktseiten hat sein Problem dort, wo PageSpeed-Screenshots selten hinschauen.

Laut HTTPArchive bestehen nur 31 % aller WooCommerce-Shops alle Core Web Vitals, bei Shopify sind es 52 %. Der Unterschied entsteht in der Konfiguration: Shopify liefert Hosting, Caching und Bildoptimierung ab Werk, bei WooCommerce musst du das selbst einstellen. Dafür gehört dir der ganze Stack, mit allen Möglichkeiten, die wir in WooCommerce vs. Shopify 2026 gegenübergestellt haben. Ein konfigurierter WooCommerce-Shop spielt in derselben Liga, die 31 % zeigen nur, wie viele Shops nie konfiguriert wurden.

Warum dein Shop kein normales WordPress ist

Die Standard-Ratschläge für WordPress-Performance gelten auch für Shops: gutes Hosting, schlankes Theme, wenige Plugins, aktuelles PHP. Diese Basics haben wir in WordPress langsam? Die 10 häufigsten Performance-Killer durchgerechnet. Wenn dein Shop auf 8-€-Shared-Hosting mit 40 Plugins läuft, fang dort an.

WooCommerce legt auf diese Basics drei Baustellen drauf, die eine Firmenwebsite nicht hat:

Sessions und Cookies. Sobald ein Besucher etwas in den Warenkorb legt, bekommt er eine Session und individuelle Cookies. Ab diesem Moment ist seine Seitenansicht einzigartig und fällt aus dem Page Cache. Eine Blog-Seite kannst du für alle Besucher identisch ausliefern, einen Shop nicht.

Dynamische Seiten. Warenkorb, Checkout und Kundenkonto werden bei jedem Aufruf frisch in PHP gerendert. Genau auf diesen Seiten entscheidet sich der Kauf, und genau dort hilft dir klassisches Page Caching nicht weiter.

Bestelldaten in der Datenbank. Jede Bestellung erzeugt im klassischen Speicherformat Dutzende Zeilen in wp_postmeta. Ein Shop mit 50.000 Bestellungen schleppt Millionen Meta-Zeilen mit, die jede Backend-Suche und jeden Checkout bremsen.

Für jede dieser Baustellen gibt es einen eigenen Hebel: die richtigen Cache-Ausnahmen, Redis Object Cache und HPOS, der Reihe nach in den nächsten Abschnitten.

Die Caching-Falle: Was niemals in den Page Cache darf

Page Caching ist der stärkste einzelne Performance-Hebel, und im Shop zugleich der gefährlichste. Wer die Checkout-Seite cacht, riskiert, dass Kunde B die Adresse von Kunde A sieht. Wer den Warenkorb cacht, bekommt Support-Tickets über Produkte, die "von allein" im Warenkorb liegen, und Fehlermeldungen durch abgelaufene Security-Nonces. Solche Fehler kosten mehr Vertrauen, als jede Sekunde Ladezeit je einspart.

Die offizielle WooCommerce-Dokumentation nennt die Ausnahmen, die jedes Cache-Setup respektieren muss: Warenkorb, Checkout und Mein Konto dürfen nie gecacht werden. Zusätzlich muss der Cache umgangen werden, sobald eines dieser drei Cookies gesetzt ist: woocommerce_cart_hash, woocommerce_items_in_cart oder wp_woocommerce_session_.

Bereich	Page Cache?	Warum
Startseite, Kategorien, Produktseiten	Ja	Identisch für alle Besucher ohne Warenkorb
Blog und statische Seiten	Ja	Kein personalisierter Inhalt
Warenkorb (/warenkorb/)	Nein	Inhalt ist pro Session individuell
Checkout (/kasse/)	Nein	Kundendaten, Zahlungsfelder, Nonces
Mein Konto	Nein	Bestellhistorie und persönliche Daten
Requests mit woocommerce_cart_hash, woocommerce_items_in_cart oder wp_woocommerce_session_	Nein	Besucher hat eine aktive Session

Gute Cache-Lösungen kennen diese Regeln: LiteSpeed Cache schließt Warenkorb, Checkout und Kundenkonto automatisch aus, WP Rocket ebenso. Prüfen musst du das Setup trotzdem, vor allem bei serverseitigem Caching (Nginx FastCGI, Varnish) oder umbenannten Shop-Seiten, denn dort greifen die automatischen Ausnahmen oft ins Leere. Der Test dauert zwei Minuten: Lege im Inkognito-Fenster ein Produkt in den Warenkorb, öffne ein zweites Inkognito-Fenster und prüfe, ob der Warenkorb dort leer ist.

Produkt- und Kategorieseiten dürfen dagegen in den Cache, brauchen aber eine saubere Invalidierung: Ändert sich Preis oder Lagerbestand, muss die betroffene Seite aus dem Cache fliegen, sonst bestellt jemand ein Produkt, das seit Stunden ausverkauft ist. Die gängigen WordPress-Cache-Plugins hängen sich dafür an die WooCommerce-Hooks und purgen automatisch; bei serverseitigen Caches musst du die Purge-Regeln selbst verdrahten. Auch hier gilt der Zwei-Minuten-Test: Lagerbestand eines Testprodukts auf null setzen und prüfen, ob die Produktseite im Inkognito-Fenster sofort "ausverkauft" zeigt.

Eine Verbesserung an dieser Front liefert WooCommerce 10.3 (Oktober 2025): Die Funktion "Clear Customer Sessions When Empty" räumt Session-Cookies wieder ab, sobald ein Gast seinen Warenkorb leert. Vorher blieb das Cookie bestehen, und der Besucher bekam für den Rest seines Besuchs keine gecachten Seiten mehr ausgeliefert. Allein dieses Update holt einen Teil deiner Besucher zurück in den Cache.

Quick Wins: vier Hebel unter einer Stunde

1. Cart Fragments dequeuen

Cart Fragments sind der bekannteste WooCommerce-spezifische Bremsklotz. Der AJAX-Endpoint /?wc-ajax=get_refreshed_fragments aktualisiert den Mini-Cart im Header, damit der Warenkorb-Zähler auch auf gecachten Seiten stimmt. Der Request selbst ist nicht cachebar und trifft bei jedem einzelnen Pageview dein PHP, auch wenn der Besucher nur durch den Blog scrollt. Auf einem ausgelasteten Server kostet das pro Aufruf mehrere hundert Millisekunden Serverlast.

Seit WooCommerce 7.8 lädt der Core das Script nur noch, wenn es gebraucht wird. Viele Themes und Page Builder laden es trotzdem auf jeder Seite. Ob deiner dazugehört, siehst du im Netzwerk-Tab der Browser-DevTools: nach "wc-ajax" filtern und eine beliebige Blog-Seite aufrufen.

Drei Lösungswege: ein Dequeue-Snippet, der Script Manager von Perfmatters oder ESI bei LiteSpeed (dazu unten mehr). Das Snippet gehört ins Child Theme oder in ein Code-Snippets-Plugin:

add_action('wp_enqueue_scripts', function() {
    if (!is_cart() && !is_checkout()) {
        wp_dequeue_script('wc-cart-fragments');
    }
}, 11);

Der Trade-off: Der Mini-Cart-Zähler aktualisiert sich auf gecachten Seiten erst nach einem Reload oder dem Wechsel in den Warenkorb. Für Shops, deren Header keinen Warenkorb-Zähler zeigt, ist das gratis. Für alle anderen ist ein Zähler, der eine Seite später nachzieht, meist das kleinere Übel als ein PHP-Hit pro Pageview.

2. Heartbeat API drosseln

Die WordPress Heartbeat API pollt im Standard alle 15 Sekunden admin-ajax.php. Bei dir und deinen Mitarbeitern, die den ganzen Tag Bestellungen im Backend bearbeiten, summieren sich offene Tabs zu konstanter PHP-Last, die sich der Server mit deinen Kunden teilt. Perfmatters, LiteSpeed Cache oder das Plugin Heartbeat Control drosseln das Intervall auf 60 Sekunden oder schalten Heartbeat im Frontend ganz ab. Aufwand: 10 Minuten.

3. PHP-Version anheben

Kinsta-Benchmarks messen für WooCommerce rund 21 % mehr Requests pro Sekunde beim Sprung von PHP 7.4 auf 8.4. Das ist ein Klick im Hoster-Panel, vorher auf einer Staging-Kopie getestet, weil ältere Plugins unter PHP 8.x Fehler werfen können. Wenn dein Shop noch auf 7.4 läuft, ist das der billigste Server-Upgrade, den du je machst.

4. WooCommerce-Core aktuell halten

Die letzten Releases waren Performance-Releases: 10.3 bringt das erwähnte Session-Cleanup für Gäste, 10.4 (Dezember 2025) lädt Admin- und REST-Komponenten nur noch bei Bedarf und senkt den TTFB pro API-Request um 30–60 ms. Davon profitieren Headless-Setups, mobile Apps und jedes Plugin, das die REST-API nutzt. Ein Core-Update mit Backup und kurzem Checkout-Test ist in 15 Minuten erledigt.

HPOS: der unterschätzte Datenbank-Hebel

High-Performance Order Storage (HPOS) ist die größte Architektur-Änderung in der Geschichte von WooCommerce, und in vielen Bestandsshops liegt sie ungenutzt herum. Klassisch speichert WooCommerce Bestellungen als Posts: Die Bestellung landet in wp_posts, jedes Detail von der Lieferadresse bis zur Zahlungsart als eigene Zeile in wp_postmeta. HPOS gibt Bestellungen eigene, dafür gebaute Tabellen mit Indizes an den richtigen Stellen.

Die offiziellen WooCommerce-Benchmarks zum Unterschied:

In Zahlen: 1.000 Bestellungen anlegen dauert mit HPOS 15,2 statt 78,1 Sekunden, die Suche nach Bestellungen über Metadaten läuft 10x schneller, das Filtern nach Kunde 40x. Für deine Käufer zählt vor allem die vierte Zahl: Der Checkout wird 1,5x schneller, weil die Bestellung beim Abschluss in die schlanken Tabellen geschrieben wird statt in Dutzende Meta-Zeilen.

Der Haken: Seit WooCommerce 8.2 ist HPOS nur für Neuinstallationen der Standard. Ein Shop, der vorher schon lief, bleibt auf dem alten Post-Speicher, bis du manuell migrierst. Genau die Bestandsshops mit Jahren an Bestellhistorie, die am meisten profitieren würden, fahren also noch im alten Format.

Ob deiner dazugehört, prüfst du unter WooCommerce → Einstellungen → Erweitert → Funktionen: Steht bei "Order data storage" noch "WordPress posts storage (legacy)", speichert dein Shop im alten Format. Ein zweites Indiz liefert die Datenbank selbst: Existiert die Tabelle wp_wc_orders und enthält Daten, ist HPOS aktiv.

Die Migration läuft über WooCommerce → Einstellungen → Erweitert → Funktionen. Vorher gehören drei Dinge erledigt: ein vollständiges Backup, ein Kompatibilitäts-Check deiner Plugins (alles, was direkt per SQL auf wp_posts zugreift statt über die WooCommerce-APIs, braucht ein Update oder einen Ersatz) und ein Probelauf auf Staging. Für den Übergang bietet HPOS einen Sync-Modus, der beide Speicherformate parallel pflegt; damit kannst du im Livebetrieb testen und notfalls zurückwechseln. Bei einem Shop mit Standard-Plugins ist das ein halber Tag Arbeit, bei stark individualisierten Setups eher zwei.

Redis Object Cache: schneller, wo der Page Cache nicht greift

Die Caching-Falle von oben hat eine Konsequenz: Ausgerechnet Warenkorb, Checkout und eingeloggte Kunden, also die umsatznächsten Seitenaufrufe, laufen bei jedem Request durch PHP und die Datenbank. Ein Page Cache kann hier per Definition nichts ausrichten; diese Requests beschleunigt nur ein Object Cache.

An dieser Stelle hilft die Unterscheidung zweier Cache-Ebenen, die im Alltag oft in einen Topf wandern. Der Page Cache speichert fertige HTML-Seiten und liefert sie aus, ohne PHP zu starten; das übernimmt dein Cache-Plugin oder der Server. Der Object Cache arbeitet eine Ebene tiefer: Er beschleunigt die Datenbank-Zugriffe innerhalb eines PHP-Requests. "Ich habe doch schon ein Cache-Plugin" beantwortet also nur die erste Ebene. Für die Seiten, die nie in den Page Cache dürfen, ist die zweite Ebene der einzige Cache, der überhaupt arbeiten darf.

Redis legt die Ergebnisse von Datenbank-Abfragen im Arbeitsspeicher ab. Beim nächsten Request liest WordPress Optionen, Produktdaten und Session-Informationen aus dem RAM statt sie per SQL neu zusammenzusuchen. Auf dynamischen Seiten sinkt der TTFB damit um 40–75 %, in der Praxis von typisch 600–900 ms auf 80–200 ms. Das ist der Unterschied zwischen einem Checkout, der sich zäh anfühlt, und einem, der reagiert.

Das Setup: Dein Hoster muss Redis anbieten (bei Managed-WordPress- und LiteSpeed-Hostern üblich, bei Billig-Shared-Hosting selten), dann verbindet das kostenlose Plugin Redis Object Cache WordPress mit dem Dienst. Rechnen tut sich das ab ungefähr 1.000 Besuchern pro Tag oder sobald regelmäßig mehrere Kunden gleichzeitig im Checkout stehen. Darunter ist der Effekt messbar, aber andere Hebel auf dieser Liste bringen pro Stunde Aufwand mehr.

Datenbank und Bilder: die mittleren Hebel

wp_options aufräumen

Alle Optionen mit dem Flag autoload = yes lädt WordPress bei jedem einzelnen Request, egal ob sie gebraucht werden. Deinstallierte Plugins hinterlassen dort gern Datenreste, abgelaufene Transients stapeln sich. Der Richtwert liegt unter 1 MB; ein dokumentierter Praxisfall zeigt die Größenordnung des Effekts: Nach dem Aufräumen von 8 MB auf 380 KB fiel der TTFB von 1,2 auf 0,4 Sekunden. So prüfst du deinen Wert:

SELECT ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_mb
FROM wp_options
WHERE autoload = 'yes';

Liegt das Ergebnis über 1 MB, listet eine zweite Abfrage nach LENGTH(option_value) sortiert die größten Einträge. Meist stammen die Brocken von zwei, drei längst gelöschten Plugins und lassen sich nach einem Backup auf autoload = no setzen oder löschen.

Produktbilder: dein LCP-Element

Auf 84 % aller Produktseiten ist das Produktbild das LCP-Element, also genau das Element, an dem Google die wahrgenommene Ladezeit festmacht. Zwei Maßnahmen wirken am stärksten: moderne Formate und korrektes Laden. WebP spart gegenüber JPEG 25–35 % Dateigröße, AVIF rund 50 %, bei gleicher sichtbarer Qualität; Plugins wie Optimole, ShortPixel oder die Bildoptimierung von LiteSpeed Cache konvertieren den Bestand automatisch. Beim Laden gilt: alles unterhalb des sichtbaren Bereichs lazy-loaden, das Haupt-Produktbild dagegen nie, sondern per Preload priorisieren. Ein lazy-geladenes LCP-Bild verschenkt regelmäßig eine halbe Sekunde im Largest Contentful Paint.

Ein Detail, das in Shops gern untergeht: WooCommerce registriert eigene Bildgrößen für Galerie, Thumbnails und Kategorie-Kacheln. Wenn du das Theme gewechselt oder die Shop-Spalten umgestellt hast, passen die generierten Größen oft nicht mehr, und der Browser skaliert ein 1.200-Pixel-Bild auf eine 300-Pixel-Kachel herunter. Das Plugin Regenerate Thumbnails baut die Größen einmalig neu, danach liefert das srcset-Attribut jedem Gerät die passende Variante.

Hosting und die Hebel im Überblick

Ganz unten im Stack entscheidet der Webserver, wie schnell eine gecachte Seite überhaupt ausgeliefert werden kann. LiteSpeed beantwortet gecachte Requests in 30–50 ms, ohne PHP anzufassen; ein Nginx-Setup mit WP Rocket liegt bei 150–300 ms. Dazu kommt ein Feature, das das Cart-Fragments-Problem an der Wurzel löst: ESI (Edge Side Includes, nur in LiteSpeed Enterprise) cacht die ganze Seite und rendert nur den Mini-Cart als dynamisches Fragment hinein. Du behältst den Live-Warenkorb-Zähler und den Cache. Den vollständigen Vergleich der Webserver findest du in LiteSpeed vs. Apache vs. Nginx.

Alle Hebel, sortiert nach Aufwand:

Hebel	Aufwand	Wirkung
Heartbeat drosseln	10 Min.	Konstante admin-ajax.php-Last fällt weg
Cart Fragments dequeuen	15 Min.	Ein nicht cachebarer PHP-Request pro Pageview weniger
WooCommerce auf 10.4	15 Min.	TTFB −30–60 ms pro API-Request, Gäste-Caching nach Session-Ende
PHP 7.4 → 8.4	30 Min. + Staging-Test	ca. 21 % mehr Requests/s
wp_options autoload aufräumen	1–2 Std.	Praxisfall: TTFB 1,2 s → 0,4 s
Bilder auf WebP/AVIF	2–4 Std.	25–50 % kleinere Bilder, besserer LCP
Redis Object Cache	2–4 Std.	TTFB −40–75 % auf Cart, Checkout, Konto
HPOS-Migration	0,5–2 Tage	Checkout 1,5x, Backend bis 40x schneller
Wechsel auf LiteSpeed-Hosting	1–2 Tage	Gecachte Seiten in 30–50 ms statt 150–300 ms

Die Reihenfolge der Tabelle ist zugleich eine brauchbare Arbeitsreihenfolge: erst die Viertelstunden-Fixes, dann Datenbank und Bilder, dann die Architektur-Themen. Miss vor dem ersten Schritt deinen Ist-Zustand mit PageSpeed Insights und einem TTFB-Check, sonst weißt du hinterher nicht, welcher Hebel was gebracht hat.

Ladezeit ist dabei kein Selbstzweck. Jede eingesparte Sekunde wirkt direkt auf die Abbruchquote im Kaufprozess, neben Versandkosten und Pflicht-Registrierung einer der großen Treiber, die wir in Warenkorbabbrüche reduzieren auseinandernehmen. Und wenn du den Shop lieber betreiben als optimieren willst: Performance-Tuning gehört bei unseren E-Commerce-Projekten zum Standardumfang, nicht zur Wunschliste.