Ausgangslage
Der Shop hatte eine vertraute WooCommerce-Struktur: funktionierender Katalog, ein Checkout, der nicht beschädigt werden durfte, mehrere Marketing-Skripte, ein Theme mit Jahren an Overrides und rote mobile Core Web Vitals auf wichtigen Templates.
Das Geschäftsrisiko war konkret. Jede Optimierung an Warenkorb, Payment, Bestand, Steuern oder Session musste über Staging, Messung und Rollback abgesichert sein.
Diagnose
Der erste Schritt war die Trennung der Template-Familien: Homepage, Kategorie, Produkt, Warenkorb, Checkout und Content-Seiten. Jede Familie hatte andere Performance-Grenzen.
Die teuersten Kosten summierten sich: zu frühe Drittanbieter-Skripte, ungenutztes CSS, Bilddrift, Cache-Misses und uncached wc-ajax=get_refreshed_fragments bei jedem Laden, das unter Last den PHP-FPM-Pool flutete.
Architekturentscheidung
Das Projekt begann nicht mit einem Rewrite. Die erste Entscheidung war, Checkout-Korrektheit zu schützen und nur sichere Oberflächen in Richtung stärkeres Caching und leichteres Rendering zu bewegen.
Cloudflare übernahm Edge-Regeln, Cache-Grenzen, Redirects, Bot-Filterung und Observability. WordPress und WooCommerce blieben die kommerzielle Source of Truth.
Delivery-Modell
Die Arbeit lief in kurzen Batches: Baseline, Skript-Audit, Bild- und Layout-Fixes, Cache-Policy, Checkout-Isolation, Staging-Validierung, Production-Rollout und Messung nach dem Launch.
Jeder Batch hatte einen Rollback-Pfad. Das ist wichtiger als ein dramatischer Launch, wenn Umsatz durch denselben Checkout läuft, der optimiert wird.
Ergebnisbereiche
Messung 30 Tage nach Deployment im vertraulichen EU-B2B-Shop: LCP 5,4s auf 1,8s (-66%), Checkout-TTFB 2,1s auf 0,4s (-80%), Main-Thread-Block 1.200ms auf 180ms (-85%), Cart-to-Checkout-Abbruch 42% auf 34% (-19%).
Die wiederverwendbare Lektion: WooCommerce-Performance-Recovery bedeutet nicht, einem perfekten Score hinterherzulaufen, sondern die Grenze zwischen cachebaren kommerziellen Seiten und Live-Transaktionsflüssen richtig zu setzen.