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.
Das Hauptproblem war meist keine einzelne große Datei. Es war die Summe: zu frühe Drittanbieter-Skripte, ungenutztes CSS, Bildgrößen-Drift, Cache-Misses auf sicher cachebaren Seiten und JavaScript-Arbeit im ersten Interaktionsfenster.
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
Exakte Zahlen sind vertraulich. Öffentlich sagbar ist: Die wichtigste kommerzielle Template-Familie bewegte sich von roten Core Web Vitals in Richtung grüner Schwellen, während der Checkout stabil blieb.
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.