Von 40 auf 98 PageSpeed: wie ich einen WooCommerce-Shop transformiert habe

Jede Sekunde zahlt im E-Commerce. Für einen WooCommerce-Shop, der Tausende von Bestellungen pro Monat verarbeitet, bedeutet das direkt verlorenen Umsatz. Diese Fallstudie dokumentiert, wie ich bei WPPoland einen kriselnden europäischen Möbel-E-Commerce-Shop von einem PageSpeed-Score von 40 auf 98 transformiert habe - und was das für ihr Geschäftsergebnis bedeutete.

#Möbel-Onlineshop mit WooCommerce als Fallstudie

Mein Kunde betreibt einen mittelgroßen Online-Möbelshop, der Kunden in Mittel- und Westeuropa bedient. Mit einem Katalog von über 3.500 Produkten und 12.000 Produktbildern waren die Einsätze hoch. Ihr WooCommerce-Shop war über fünf Jahre organisch gewachsen und hatte mit jeder Plugin-Installation, Theme-Anpassung und Drittanbieter-Integration technische Schulden angehäuft.

Anfang 2026 verlor der Shop massiv Umsatz. Wettbewerber mit schnelleren Seiten rangierten in den Suchergebnissen vor ihnen, und mobile Nutzer - die 64 Prozent ihres Traffics ausmachten - verließen die Seite in Scharen.

#Warum der WooCommerce-Shop langsam war

Als ich die Seite erstmals auditierte, fand ich ein bekanntes, aber schweres Muster der Performance-Degradation:

• 38 aktive Plugins, viele mit überlappender Funktionalität
• Shared Hosting ohne serverseitiges Caching
• Unoptimierte Datenbank mit über 2,3 Millionen abgelaufenen Transients
• 12.000 Produktbilder als unkomprimierte PNG- und JPEG-Dateien
• Kein CDN - alle Assets von einem einzigen Origin-Server in Deutschland
• Render-blockierendes JavaScript von 14 Plugins, die auf jeder Seite laden
• 5-Schritte-Checkout mit 22 Formularfeldern

Das Ergebnis war eine Seite, die sich auf Mobilgeraten kaputt anfühlte. Seiten brauchten 8 Sekunden zum Laden, das Layout sprang herum während Elemente renderten, und der Checkout-Prozess war so umständlich, dass 68 Prozent der Besucher die Seite verließen, bevor sie einen Kauf abschlossen.

#WooCommerce-Metriken vor der Optimierung

#WooCommerce schneller machen in 7 Phasen

Ich verfolge einen systematischen, datengetriebenen Ansatz zur WordPress-Speed-Optimierung. Jede Phase baut auf der vorherigen auf, und ich messe den Einfluss jeder Änderung isoliert, bevor ich zur nächsten übergehe.

#Phase 1: Technisches Audit (Tage 1-3)

Bevor ich eine einzige Zeile Code berührte, verbrachte ich drei Tage damit, jeden Aspekt der Seite zu profilieren:

• GTmetrix Waterfall-Analyse zur Identifizierung der langsten Request-Ketten
• WebPageTest Multi-Standort-Tests von Frankfurt, London und Warschau
• Chrome DevTools Performance Panel zur Profilierung der Hauptthread-Aktivitat
• Datenbank-Abfrage-Logging mit dem Query Monitor Plugin zur Identifizierung langsamer Abfragen
• Plugin-Profilierung zur Messung des Einflusses jedes Plugins auf die Ladezeit

Das Audit ergab, dass 73 Prozent der Ladezeit auf drei Faktoren zurückzuführen waren: unoptimierte Bilder (31 Prozent), übermäßiges JavaScript (26 Prozent) und langsame Datenbankabfragen (16 Prozent).

#Phase 2: Server-Optimierung (Tage 4-7)

Das Fundament jeder schnellen Website ist der Server. Ich migrierte den Kunden von Shared Hosting zu einem dedizierten VPS mit folgendem Stack:

• LiteSpeed Web Server mit HTTP/3- und QUIC-Unterstützung
• Redis Object Cache für persistentes WordPress Object Caching
• MariaDB 11.4 mit optimierter my.cnf-Konfiguration
• PHP 8.3 mit aktiviertem OPcache Preloading

Die LiteSpeed-Konfiguration enthielt spezifisches Tuning für WooCommerce:

# LiteSpeed Cache-Regeln für WooCommerce
<IfModule LiteSpeed>
  CacheLookup on
  RewriteRule .* - [E=Cache-Control:no-autoflush]
  RewriteRule ^/cart.* - [E=Cache-Control:no-cache]
  RewriteRule ^/checkout.* - [E=Cache-Control:no-cache]
  RewriteRule ^/my-account.* - [E=Cache-Control:no-cache]
</IfModule>

Die Redis-Konfiguration wurde für WooCommerce-Session-Handling optimiert:

// wp-config.php Erganzungen für Redis
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_MAXTTL', 86400);
define('WP_REDIS_PREFIX', 'wc_store_');
define('WP_REDIS_SELECTIVE_FLUSH', true);

Auswirkung nach Phase 2: TTFB sank von 2,4 Sekunden auf 180 Millisekunden.

#Phase 3: Datenbank-Bereinigung (Tage 8-11)

Funf Jahre Betrieb hatten die Datenbank in einem kritischen Zustand hinterlassen. Ich führte eine methodische Bereinigung durch:

1. Entfernung von 2,3 Millionen abgelaufenen Transients - die wp_options-Tabelle war auf 847 MB angewachsen
2. Optimierung von 47 langsamen Abfragen, die während der Auditphase identifiziert wurden
3. Hinzufügen fehlender Indizes zu den Tabellen wp_postmeta und wp_wc_order_stats
4. Bereinigung verwaister Post-Meta - 340.000 Zeilen Metadaten für gelöschte Produkte
5. Konvertierung von Tabellen zu InnoDB, wo noch MyISAM verwendet wurde

Die benutzerdefinierten Indizes verbesserten die Produktsuche und -filterung erheblich:

-- Benutzerdefinierte Indizes für WooCommerce-Produktabfragen
ALTER TABLE wp_postmeta ADD INDEX idx_meta_lookup (meta_key, meta_value(32));
ALTER TABLE wp_wc_product_meta_lookup ADD INDEX idx_price_stock (min_price, max_price, stock_status);
ALTER TABLE wp_woocommerce_order_items ADD INDEX idx_order_type (order_id, order_item_type);

Auswirkung nach Phase 3: Die Datenbank-Abfragezeit sank um 84 Prozent, und die wp_options-Tabelle schrumpfte von 847 MB auf 12 MB.

#Phase 4: Bild-Optimierung (Tage 12-15)

Mit 12.000 Produktbildern hatte diese Phase den größten individuellen Einfluss auf die Seitengröße:

• Konvertierung aller Bilder zu AVIF mit WebP-Fallback für altere Browser
• Implementierung von responsivem srcset mit Breakpoints bei 320, 640, 960, 1.280 und 1.920 Pixeln
• Lazy Loading mit nativem loading="lazy" für alle Bilder unterhalb des sichtbaren Bereichs
• Explizite Dimensionen auf jedem <img>-Tag zur Eliminierung von CLS
• Blur-up-Platzhalter mit Low Quality Image Placeholders (LQIP)

Die Bildverarbeitung wurde mit zwei WordPress-Filtern und WP-CLI automatisiert:

// AVIF-Ausgabe für generierte Bildgrößen (WordPress 6.5+)
add_filter('image_editor_output_format', function ($formats) {
    $formats['image/jpeg'] = 'image/avif';
    $formats['image/png'] = 'image/avif';
    return $formats;
});

// AVIF-Qualität 75, andere Formate unverändert
add_filter('wp_editor_set_quality', function ($quality, $mime_type) {
    return 'image/avif' === $mime_type ? 75 : $quality;
}, 10, 2);

wp media regenerate --yes

Auswirkung nach Phase 4: Die durchschnittliche Seitengröße sank von 6,8 MB auf 1,2 MB. LCP verbesserte sich von 5,1 Sekunden (nach Server-Optimierung) auf 1,4 Sekunden.

#Phase 5: JavaScript-Audit (Tage 16-19)

Das JavaScript-Audit war chirurgisch. Ich kategorisierte jedes Skript auf der Seite:

Für die Analytics-Skripte implementierte ich ein verzoeagertes Lademuster:

// Nicht-kritische Skripte bis zur Benutzerinteraktion verzoegern
const loadDeferredScripts = () => {
  const scripts = document.querySelectorAll('script[data-defer-src]');
  scripts.forEach(script => {
    const newScript = document.createElement('script');
    newScript.src = script.dataset.deferSrc;
    newScript.async = true;
    document.body.appendChild(newScript);
  });
};

['mouseover', 'touchstart', 'scroll', 'keydown'].forEach(event => {
  window.addEventListener(event, loadDeferredScripts, { once: true });
});

Ich eliminierte auch Render-blockierendes CSS durch Inlining kritischer Styles und Verzoeagerung des vollständigen Stylesheets:

<link rel="preload" href="/wp-content/themes/theme/style.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/wp-content/themes/theme/style.css"></noscript>

Auswirkung nach Phase 5: INP sank von 680ms auf 62ms. Die gesamte JavaScript-Payload wurde um 78 Prozent reduziert.

#Phase 6: Checkout-Optimierung (Tage 20-23)

Eine schnelle Seite bringt nichts, wenn der Checkout Conversions totet. Ich baute den gesamten Checkout-Flow neu:

• Reduzierung von 5 Schritten auf 2 (Versand + Zahlung auf einer Seite, Bestatigung auf der nächsten)
• Entfernung von 14 unnötigen Formularfeldern (Firmenname, Telefon 2, Fax usw.)
• Express-Zahlung hinzugefügt (Apple Pay, Google Pay, Klarna)
• Adress-Autocomplete mit der Google Places API
• Echtzeit-Formularvalidierung zur Fehlervermeidung bei der Übermittlung

// Unnotige WooCommerce-Checkout-Felder entfernen
add_filter('woocommerce_checkout_fields', function ($fields) {
    unset($fields['billing']['billing_company']);
    unset($fields['billing']['billing_phone_2']);
    unset($fields['billing']['billing_fax']);
    unset($fields['order']['order_comments']);
    return $fields;
});

// Express-Payment-Gateway-Unterstützung hinzufügen
add_action('woocommerce_review_order_before_payment', function () {
    if (class_exists('WC_Payment_Gateway')) {
        echo '<div id="express-checkout-buttons" class="express-payment-wrapper">';
        do_action('woocommerce_express_checkout_buttons');
        echo '</div>';
    }
});

Auswirkung nach Phase 6: Die Warenkorbabbruchrate sank um 34 Prozent. Die durchschnittliche Checkout-Zeit verkürzte sich von 4 Minuten 12 Sekunden auf 1 Minute 38 Sekunden.

#Phase 7: CDN und Edge Caching (Tage 24-28)

Die letzte Optimierungsschicht stellte sicher, dass die Performance-Gewinne über alle europäischen Märkte konsistent waren:

• Cloudflare Pro mit benutzerdefinierten Seitenregeln für WooCommerce
• Edge Caching für statische Produktseiten mit 4-Stunden-TTL
• Browser-Caching-Header mit Cache-Busting durch Content-Hashing
• Brotli-Kompression am Edge für alle textbasierten Assets
• Early Hints (103) für kritische Ressourcen

# Cloudflare-Seitenregeln
URL: *example.com/product/*
Cache Level: Cache Everything
Edge Cache TTL: 4 hours
Browser Cache TTL: 1 hour

URL: *example.com/cart*
Cache Level: Bypass

URL: *example.com/checkout*
Cache Level: Bypass

Auswirkung nach Phase 7: Globaler TTFB sank auf unter 100 Millisekunden. Nutzer in Westeuropa erlebten vollständige Seitenladezeiten unter 800ms.

#WooCommerce PageSpeed vorher und nachher

Nach vier Wochen systematischer Optimierung war die Transformation dramatisch:

#Core Web Vitals eines WooCommerce-Shops richtig lesen

Die Bewertungsspalte in den Tabellen oben folgt den Schwellenwerten, die Google auf web.dev veröffentlicht. Ein guter Largest Contentful Paint erfolgt innerhalb von 2,5 Sekunden nach Beginn des Seitenladens, ein guter Interaction to Next Paint liegt bei 200 Millisekunden oder weniger und ein guter Cumulative Layout Shift bei 0,1 oder weniger. Google bewertet jede Metrik am 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. Eine Seite besteht also nur, wenn drei von vier Besuchen den Schwellenwert erreichen.

Die PageSpeed-Werte von 40 und 98 sind eine andere Art von Zahl. Es sind Laborwerte aus einem simulierten Ladevorgang, gut geeignet, um während eines Projekts wie diesem einen Stand mit dem nächsten zu vergleichen. Derselbe web.dev-Leitfaden hält fest, dass Labormessungen keine Felddaten ersetzen, weil die Core Web Vitals Feldmetriken von echten Besuchern sind. Nach einem Release zählen deshalb die Felddaten in PageSpeed Insights und der Core-Web-Vitals-Bericht in der Search Console, ein paar Wochen später, wenn genug echte Besuche erfasst sind.

#Wie Ladezeit die Conversion-Rate im Shop beeinflusst

Technische Metriken sind befriedigend, aber Geschäftsmetriken rechtfertigen die Investition:

• Die Conversion-Rate hat sich etwa verdoppelt
• Der mobile Umsatz stieg - mobile Nutzer konnten endlich frustfrei einkaufen
• Die Absprungrate halbierte sich etwa - Besucher blieben und stöberten statt zu gehen
• Das Projekt amortisierte sich in Wochen, nicht in Quartalen
• Der durchschnittliche Bestellwert stieg - schnelleres Produktstöbern führte zu mehr Artikeln im Warenkorb
• Der organische Traffic wuchs - verbesserte Core Web Vitals trugen zu besseren Suchrankings innerhalb von 8 Wochen bei

#Erkenntnisse aus der WooCommerce-Optimierung

Jedes Optimierungsprojekt lehrt mich etwas Neues. Hier sind die wichtigsten Erkenntnisse aus diesem Projekt:

#1. Wie stark beeinflusst das Hosting die WooCommerce-Geschwindigkeit

Keine Menge an Frontend-Optimierung kann einen langsamen Server kompensieren. Die Migration von Shared Hosting zu einem optimierten LiteSpeed-VPS machte 35 Prozent der gesamten Performance-Verbesserung aus.

#2. Warum die WooCommerce-Datenbank regelmäßig bereinigen

WooCommerce-Shops generieren enorme Mengen an Transient-Daten. Ohne regelmäßige Bereinigung wird die wp_options-Tabelle zum Engpass, der jedes einzelne Seitenladen beeinflusst. Automatisierte wochentliche Bereinigung sollte Standard für jeden WooCommerce-Shop sein.

#3. Wie Plugins einen WooCommerce-Shop verlangsamen

Von den 38 installierten Plugins waren 14 entweder ungenutzt, redundant oder durch leichtgewichtige Code-Snippets ersetzbar. Jedes Plugin fügt Datenbankabfragen, JavaScript und CSS hinzu - selbst wenn seine Funktionalität auf der aktuellen Seite nicht benötigt wird.

#4. Wie stark AVIF-Bilder das Seitengewicht senken

Die Konvertierung zu AVIF und Implementierung responsiver Bilder reduzierte die Seitengröße um über 80 Prozent. Diese einzelne Änderung, die weitgehend automatisiert werden kann, liefert die sichtbarste Verbesserung für Endnutzer.

#5. Wie die Checkout-UX den Umsatz beeinflusst

Das Checkout-Redesign, obwohl keine traditionelle “Performance”-Optimierung, hatte den direktesten Einfluss auf den Umsatz. Reibung im Kaufprozess zu reduzieren ist genauso wertvoll wie Ladezeiten zu verkürzen.

#6. Wie man die Wirkung jeder Optimierung misst

Durch die Implementierung von Änderungen in Phasen und Messung nach jeder einzelnen konnte ich den genauen Einfluss jeder Optimierung quantifizieren. Dieser datengetriebene Ansatz verhindert verschwendeten Aufwand und baut eine klare Erzählung für Stakeholder auf.

#Wie lange dauert eine WooCommerce-Optimierung

#Diese Methoden 2026 in WordPress und WooCommerce umsetzen

Drei der Methoden oben hängen von Funktionen in WordPress, WooCommerce und Cloudflare ab, die sich geändert haben, seit viele Anleitungen geschrieben wurden. So funktioniert jede davon laut der Dokumentation der Hersteller selbst.

#AVIF-Bilder in WordPress erzeugen

WordPress unterstützt AVIF seit Version 6.5, wie auf Make WordPress Core angekündigt. Die Unterstützung hängt von der Bildbibliothek auf dem Server ab: WordPress arbeitet mit Imagick und mit GD, und der Abschnitt zur Medienverarbeitung in den Informationen zum Website-Zustand zeigt, ob AVIF verfügbar ist. Um hochgeladene JPEG-Dateien als AVIF auszugeben, dokumentiert das Core-Team den Filter image_editor_output_format. Der Filter wp_editor_set_quality legt die Kompression zwischen 1 und 100 für einen bestimmten MIME-Typ fest. Laut der Ankündigung ist AVIF standardmäßig verlustbehaftet mit Qualität 82, und Qualität 100 schaltet in den verlustfreien Modus.

wp media regenerate kennt keine Optionen für Format oder Qualität. Die Optionen sind Anhang-IDs, --image_size, --skip-delete, --only-missing, --delete-unknown, --update-attachment-refs (nur in Nightly-Builds) und --yes (WP-CLI-Dokumentation). Die Filter bestimmen Format und Qualität, der Befehl erzeugt die Bildgrößen neu. Deshalb nutzt das Beispiel in Phase 4 beides.

#Abgelaufene Transients in WooCommerce löschen

WP-CLI löscht abgelaufene Transients mit wp transient delete --expired, und wp transient delete --all entfernt alle (WP-CLI-Dokumentation). Mit einem persistenten Object Cache wie Redis können Transients in diesem Cache statt in der Tabelle wp_options liegen, und das Handbuch zur Transients API warnt, dass Code nie davon ausgehen darf, dass ein Transient in der Datenbank steht. Die Core-Funktion delete_expired_transients(), eingeführt in WordPress 4.9, tut nichts, wenn ein externer Object Cache aktiv ist. Abgelaufene Zeilen, die vor dem Einschalten des Object Cache geschrieben wurden, bleiben deshalb in der Tabelle, bis etwas sie direkt aus der Datenbank löscht. Genau das war die Arbeit in Phase 3.

#Welche WooCommerce-Seiten und Cookies vom Cache ausgenommen werden

Die WooCommerce-Entwicklerdokumentation verlangt, Warenkorb, Kundenkonto und Checkout vom Seiten-Cache auszunehmen, weil diese Seiten Informationen zum aktuellen Kunden und seinem Warenkorb zeigen. Sie nennt außerdem Cookies, die ein Cache überspringen kann: woocommerce_cart_hash, woocommerce_items_in_cart, wp_woocommerce_session_, woocommerce_recently_viewed und store_notice[notice id]. Die LiteSpeed-Regeln in Phase 2 nehmen alle drei Seiten aus, das Cloudflare-Beispiel in Phase 7 zeigt Warenkorb und Checkout.

Cloudflare ersetzt Page Rules durch eine Reihe eigener Rules-Produkte und migriert bestehende Page Rules automatisch (Migrationsleitfaden). Ein neues Setup bildet dieselbe Logik mit Cache Rules ab: Die Cache-Berechtigung auf cachefähig zu setzen ersetzt Cache Everything, die Einstellungen Edge TTL und Browser TTL übernehmen die TTL-Werte, und eine Regel, die auf ein Cookie reagiert und die Cache-Berechtigung auf Bypass setzt, hält Besucher mit aktiver Warenkorb-Sitzung aus dem gemeinsamen Cache heraus.

#Kostenloses WooCommerce-Performance-Audit

Wenn Ihr Shop unter 70 bei PageSpeed Insights erreicht, verlieren Sie jeden Tag Kunden. Mein WooCommerce-Optimierungsservice folgt derselben bewährten Methodik, die in dieser Fallstudie beschrieben wird, zugeschnitten auf Ihren spezifischen Shop und Ihre Infrastruktur.

Ich biete ein kostenloses erstes Performance-Audit - einen detaillierten Bericht, der genau zeigt, wo Ihr Shop Geschwindigkeit verliert und wie viel Umsatz Sie das kostet. Keine Verpflichtungen, kein Verkaufsgesprach, nur Daten.

Kontaktieren Sie WPPoland, um Ihr Audit zu planen, oder erfahren Sie mehr über meine WordPress-Speed-Optimierung.

#Verwandte Ressourcen

• 100/100 Core Web Vitals für WordPress in 2026 erreichen
• WooCommerce Performance-Optimierung
• WordPress-Speed-Optimierung