WooCommerce Performance optimieren: LCP, INP und CLS für deinen Shop
07.05.2026 · 10 Min. Lesezeit
WooCommerce-Shops sind keine normalen WordPress-Seiten — und generische Performance-Ratgeber greifen deshalb oft zu kurz. Ein WooCommerce-Shop hat mehr JavaScript (Mini-Cart, Varianten-Auswahl, AJAX-Add-to-Cart), mehr externe Ressourcen (Payment-Widgets, Bewertungs-Badges, Tracking-Pixel) und Cache-Ausnahmen, die bei Standard-WordPress nicht existieren: Page-Cache wird für eingeloggte Nutzer und für alle Seiten mit gefülltem Warenkorb automatisch deaktiviert.
Das Ergebnis: viele Shops die beim PageSpeed-Test auf der Startseite gut aussehen, aber auf Produkt- und Checkout-Seiten schlecht abschneiden — genau dort wo Kunden kaufen.
In diesem Artikel gehen wir die drei Core Web Vitals durch die für WooCommerce-Shops am relevantesten sind: LCP, INP und CLS. Pro Metrik zeigen wir was das typische WooCommerce-Problem ist, was du als Quick Win sofort umsetzen kannst, und welche tiefergehende Lösung für Entwickler sinnvoll ist.
LCP bei WooCommerce
Das Problem
Das LCP-Element auf Produktseiten ist fast immer das Produktbild. WooCommerce behandelt es aber wie jedes andere Bild — es wird lazy geladen, hat kein fetchpriority-Attribut, und ein Preload-Link im <head> fehlt. Das bedeutet: Der Browser erkennt das wichtigste Bild der Seite erst spät, und fängt erst dann an es zu laden.
Auf Shop-Startseiten ist oft ein Hero-Slider das LCP-Element. Slider laden mehrere Bilder gleichzeitig — aber nur eines ist zu einem Zeitpunkt sichtbar. Der Browser verschwendet Bandbreite auf Bilder die gerade nicht gezeigt werden, während das sichtbare LCP-Bild wartet.
Quick Win
- Kein Lazy Loading für das erste Produktbild: Das Hauptbild auf Produktseiten niemals mit
loading="lazy"versehen. Viele Themes setzen das global — check im Browser-Devtools obloading="lazy"auf dem Produktbild steht. - WebP aktivieren: Wenn dein Bildoptimierungs-Plugin (Imagify, ShortPixel, Smush) WebP-Konvertierung anbietet, aktivieren. Produktbilder profitieren besonders weil sie oft groß sind.
- Hero-Slider vereinfachen oder ersetzen: Wenn der Slider primär Conversion-Optik ist aber die Performance killt, ist ein statisches Hero-Bild die bessere Wahl für LCP.
Dev-Tipp
Das LCP-Produktbild bekommt fetchpriority="high" und kein loading="lazy". Das geht über den Filter woocommerce_single_product_image_thumbnail_html oder direkt im Theme-Template single-product/product-image.php:
add_filter('woocommerce_single_product_image_thumbnail_html', function ($html) {
// Nur für das erste/aktive Bild
$html = str_replace('loading="lazy"', 'loading="eager"', $html);
$html = str_replace('<img ', '<img fetchpriority="high" ', $html);
return $html;
}, 10, 1);
Zusätzlich einen Preload-Link für das LCP-Bild im <head> ergänzen — idealerweise mit dem konkreten Bild-URL des jeweiligen Produkts:
add_action('wp_head', function () {
if (!is_product()) return;
global $product;
$image_id = $product->get_image_id();
$image_url = wp_get_attachment_image_url($image_id, 'woocommerce_single');
if ($image_url) {
echo '<link rel="preload" as="image" href="' . esc_url($image_url) . '">' . "\n";
}
}, 1);
INP bei WooCommerce
Das Problem
INP (Interaction to Next Paint) misst wie schnell eine Seite auf Nutzerinteraktionen reagiert. WooCommerce ist ein INP-Risiko aus mehreren Gründen:
Add-to-Cart-Button: Ein Klick löst einen AJAX-Request aus, aktualisiert den Mini-Cart im Header, und triggert Event-Handler in mehreren Plugins. Alles auf dem Haupt-Thread. Bei langsamen Verbindungen oder vielen aktiven Plugins ist das spürbar träge.
Varianten-Auswahl: Wenn ein Produkt mehrere Varianten hat (Farbe, Größe), berechnet WooCommerce bei jeder Auswahl synchron welche Kombination verfügbar ist, aktualisiert Preis, Bild und Lagerbestand im DOM. Bei vielen Varianten ist das eine der schwersten Operationen auf der Seite.
Cart Fragments: WooCommerce aktualisiert standardmäßig nach jedem Seitenaufruf asynchron den Mini-Cart-Inhalt via AJAX (wc-cart-fragments.js). Das ist unnötiger JavaScript-Overhead auf jeder Seite — auch wenn kein Mini-Cart vorhanden ist.
Globale Scripts: WooCommerce und viele WooCommerce-Plugins laden JavaScript global — auch auf Seiten die keinen Shop-Kontext haben (Blog, Über uns, Kontakt).
Quick Win
- Cart Fragments deaktivieren wenn kein Mini-Cart genutzt wird: Viele Themes haben gar keinen Mini-Cart im Header. Trotzdem läuft
wc-cart-fragments.jsauf jeder Seite. Prüfen und ggf. deaktivieren:
add_action('wp_enqueue_scripts', function () {
if (is_admin()) return;
wp_dequeue_script('wc-cart-fragments');
}, 11);
- WooCommerce-Scripts nur auf Shop-Seiten laden: Mit einem Plugin wie „WooCommerce Cart Fragments Deactivation" oder manuell per
wp_dequeue_scriptauf Nicht-Shop-Seiten.
Dev-Tipp
WooCommerce-Scripts gezielt nur dort laden wo sie gebraucht werden:
add_action('wp_enqueue_scripts', function () {
if (is_admin()) return;
if (!is_woocommerce() && !is_cart() && !is_checkout()) {
// WooCommerce-Scripts auf Nicht-Shop-Seiten entfernen
wp_dequeue_style('woocommerce-general');
wp_dequeue_style('woocommerce-layout');
wp_dequeue_style('woocommerce-smallscreen');
wp_dequeue_script('woocommerce');
wp_dequeue_script('wc-cart-fragments');
}
}, 99);
Für den Mini-Cart: Fragment-Caching statt Live-AJAX. WooCommerce bietet woocommerce_add_to_cart_fragments als Hook um den HTML-Output des Mini-Carts zu cachen. Transients oder Object-Cache (Redis) helfen dabei, den AJAX-Response deutlich zu beschleunigen.
CLS bei WooCommerce
Das Problem
CLS (Cumulative Layout Shift) misst unerwartete Layoutverschiebungen. WooCommerce-Shops haben mehrere typische CLS-Quellen:
Produktbilder ohne Seitenverhältnis: Wenn Breite und Höhe nicht im <img>-Tag stehen und kein aspect-ratio per CSS gesetzt ist, reserviert der Browser keinen Platz vor dem Laden. Das Bild springt rein sobald es geladen ist.
Sale-Badges und „Nur noch X auf Lager"-Hinweise: Diese werden oft per AJAX oder JavaScript nachgeladen und erscheinen nach dem ersten Render — und verschieben dabei Inhalte darunter.
Cookie-Consent-Banner als Layout-Push: Viele Banner-Plugins fügen oben oder unten ein Element ein das den Rest der Seite nach unten schiebt — nach dem initialen Render.
Dynamische Preise: Wenn Staffelpreise, Mengenrabatte oder personalisierte Preise per JavaScript berechnet werden, ändert sich die Höhe des Preisbereichs nach dem Render.
Quick Win
aspect-ratiofür Produktbilder in CSS: Sorgt dafür dass der Browser Platz reserviert bevor das Bild geladen ist:
.woocommerce-product-gallery__image img,
.attachment-woocommerce_thumbnail {
aspect-ratio: 1 / 1; /* an dein Bildformat anpassen */
width: 100%;
height: auto;
}
- Cookie-Banner als Overlay: Im Banner-Plugin einstellen dass es als
position: fixedOverlay erscheint statt als statisches Element das Layout verschiebt.
Dev-Tipp
Preis-Bereiche mit min-height stabilisieren damit dynamische Inhalte (Rabatte, Lagerhinweise) keinen Shift verursachen:
.woocommerce-variation-price,
.price {
min-height: 2.5rem; /* je nach Theme anpassen */
}
Für AJAX-geladene Badges (Sale, Ausverkauft): Container bereits im initialen HTML mitliefern aber per CSS verstecken, dann per JavaScript nur anzeigen statt neu einfügen — so gibt es keinen Layout-Shift weil der Platz bereits reserviert ist.
TTFB als Fundament
Bevor LCP, INP und CLS überhaupt verbessert werden können, muss der Server schnell antworten. WooCommerce hat hier eine wichtige Besonderheit: Page-Cache wird automatisch deaktiviert für eingeloggte Nutzer und für alle Sessions mit gefülltem Warenkorb.
Das bedeutet: sobald ein Besucher ein Produkt in den Warenkorb legt, bekommt er für alle weiteren Seiten unkachedete PHP-Responses — auch Kategorieseiten und die Startseite. Viele Caching-Plugins (WP Rocket, LiteSpeed Cache) haben spezielle WooCommerce-Modi die dieses Verhalten korrekt handhaben. Diese Modi müssen explizit aktiviert werden.
Als Basis-Infrastruktur empfiehlt sich Redis als Object-Cache: auch wenn der Page-Cache nicht greift, werden Datenbankabfragen gecacht und PHP-Ausführungszeit reduziert.
Eine ausführliche Anleitung zu TTFB-Optimierung für WordPress gibt es in unserem TTFB-Artikel.
WooCommerce-Performance kontinuierlich überwachen
Eine einmalige PageSpeed-Messung zeigt den Ist-Zustand — aber nicht ob ein WooCommerce-Update, ein neues Plugin oder eine Theme-Änderung die Performance rückgängig gemacht hat.
Mit turbometrics kannst du deine Shop-Seiten kontinuierlich überwachen: Produktseiten, Warenkorb und Checkout separat, mit täglichen oder stündlichen Messungen. turbometrics misst LCP, INP, CLS und TTFB bei jedem Scan und zeigt dir historische Trends — du siehst sofort wann eine Verschlechterung eingetreten ist und kannst sie auf eine konkrete Änderung zurückführen.
Der Alert-Modus benachrichtigt dich per E-Mail oder Webhook sobald ein CWV-Wert unter deinen definierten Schwellwert fällt — bevor Kunden es merken und bevor es sich in deinen Conversion-Raten zeigt.