WooCommerce schneller machen: die wirksamsten Performance-Hebel
Von Manuel Hack, ihp media · Aktualisiert am 16. Juni 2026
Das Wichtigste in 30 Sekunden
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. LCP-Einbußen von 13–15 % entstehen genau dort.
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 bis hin zum gefährlichsten aller Fehler: dem fremden Warenkorb-Inhalt für einen anderen Kunden.
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.
Cart-Fragmente (wc-ajax): der unsichtbare Performance-Fresser
Kurz gesagt: WooCommerce feuert bei jedem Seitenaufruf einen Ajax-Request an /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:
Das ist ein tiefer Eingriff und setzt voraus, dass das Theme die Warenkorb-Anzeige im Header nicht dauerhaft aktuell halten muss. Bei Shops ohne Header-Warenkorb-Counter ist es die einfachste Lösung mit der stärksten Wirkung.
Objekt-Cache und Redis: Datenbankabfragen aus dem RAM beantworten
Kurz gesagt: Ein persistenter Objekt-Cache speichert Abfrageergebnisse in Redis oder Memcached. Statt jedes Mal MySQL zu fragen, liefert PHP die Antwort aus dem Arbeitsspeicher. Das wirkt besonders auf dynamischen Seiten wie Warenkorb und Checkout, die nicht seitengecacht werden können.
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, Kategorien, Versandregeln und globale Shop-Optionen werden bei aktivem Redis-Cache aus dem Speicher beantwortet, nicht aus der Datenbank. Das reduziert die Datenbankauslastung messbar.
Das empfohlene Plugin ist Redis Object Cache von Till Krüss. Es installiert ein Drop-in-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:
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.
Kurz gesagt: WordPress liest bei jedem Seitenaufruf alle autogeladenen Zeilen aus 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 einen SELECT * FROM wp_options WHERE autoload = 'yes' ausführen und das Ergebnis an PHP übergeben. Ohne Index auf dem autoload-Feld muss MySQL dabei die gesamte Tabelle durchsuchen.
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 = 'yes';
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 damit bis zu 40-mal schneller, der Checkout läuft bis zu 1,5-mal schneller für Shops mit großem Bestellvolumen. 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
Kurz gesagt: Die Anzahl der Plugins ist weniger entscheidend als deren Qualität. Ein schlecht programmiertes Plugin kann mehr Datenbankabfragen auslösen als zehn gut optimierte zusammen. Query Monitor macht sichtbar, welches Plugin wie viele Abfragen erzeugt.
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.
Kurz gesagt: Bilder sind in den meisten Shops das größte Datenvolumen. WebP spart gegenüber optimiertem JPEG typischerweise 25–35 %. Das Hauptproduktbild oberhalb des sichtbaren Bereichs darf nicht lazy geladen werden, das kostet laut web.dev-Studie bis zu 15 % beim LCP.
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 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, wartet der Browser, bis es in den Viewport scrollt, was es per Definition bereits ist, sobald die Seite lädt.
Die Lösung: 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 ab 10.6 eine saubere Filter-Schnittstelle.
Bildformat: WebP als Standard, AVIF für Unterstützte
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 gilt: WebP ist der sichere Standard heute, AVIF der Schritt für morgen. 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
Kurz gesagt: WooCommerce empfiehlt offiziell PHP 8.3 oder höher und MySQL 8.0 oder höher. Ohne OPcache muss PHP bei jedem Request den Quellcode neu parsen. Ohne ausreichendes Memory-Limit (mindestens 256 MB, empfohlen 512 MB) brechen Checkout- und Bulk-Operationen ab.
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 messbar: PHP 8 verarbeitet objektintensiven Code wie WooCommerce schneller, weil der JIT-Compiler (Just In Time Compilation) eingesetzt wird. 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
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 und 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
In einem Projekt betreuten wir einen Onlineshop mit rund 800 Produkten, der seit drei Jahren auf demselben Hoster lief. Der LCP auf der Startseite lag bei 4,2 Sekunden, der Checkout bei 3,8 Sekunden. Der Checkout war nie gecacht, reagierte aber trotzdem langsam.
Die Analyse mit Query Monitor zeigte 187 Datenbankabfragen auf der Produktlisten-Seite, davon 43 durch ein Bewertungs-Aggregations-Plugin, das jeden Seitenaufruf vollständig neu berechnete, statt Ergebnisse zu cachen. Der zweite Fund: wp_options enthielt 2.800 autogeladene Zeilen, 1,9 MB gesamt, überwiegend veraltete Transients aus einem zuvor deinstallierten Versanddienstleister.
Maßnahmen: wp_options bereinigt (auf 380 Zeilen, 210 KB reduziert), das Bewertungs-Plugin durch eine schlanke Alternative ersetzt, Redis aktiviert, PHP von 7.4 auf 8.3 aktualisiert, Cart-Fragmente auf Warenkorb- und Checkout-Seiten beschränkt. Kein Hoster-Wechsel war nötig, der bestehende Hoster bot Redis als optionalen Dienst an. Ergebnis nach allen Maßnahmen: Startseiten-LCP 1,9 Sekunden, Checkout-Seite 1,4 Sekunden. Der Checkout war das größte Ergebnis, weil der Objekt-Cache dort die Abfragen auf Versandregeln, Steuerklassen und Kundendaten aus dem RAM beantwortete statt aus der Datenbank.
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?
Das Wichtigste zum Mitnehmen
Cart-Fragmente und ein überladenes wp_options sind 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.
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.
