Utgangspunkt
Butikken hadde en kjent WooCommerce-form: fungerende katalog, en checkout som ikke kunne ødelegges, flere markedsskript, et tema med år med overrides, og røde mobile Core Web Vitals på viktige maler.
Forretningsrisikoen var konkret. Enhver optimalisering som berørte handlekurv, betaling, lager, skatt eller sesjon måtte gå via staging, måling og rollback.
Diagnose
Første steg var å skille malfamilier: forside, kategori, produkt, handlekurv, checkout og innholdssider. Hver familie hadde ulike ytelsesgrenser, så én samlet score ville skjult flaskehalsene.
Hovedproblemet var sjelden én stor fil. Det var summen: tredjepartsskript for tidlig, ubrukt CSS, bilde-sizing-drift, cache-misser på sider som trygt kunne caches, og JavaScript-arbeid i første interaksjonsvindu.
Arkitekturvalg
Prosjektet startet ikke med omskriving. Første beslutning var å beskytte checkout-korrekthet, deretter flytte bare trygge flater mot sterkere caching og lettere rendering.
Cloudflare håndterte edge-regler, cache-grenser, redirects, botfiltrering og observabilitet. WordPress og WooCommerce forble kommersiell sannhetskilde. Frontend-endringer ble scoped per malfamilie, ikke som generisk tema-opprydding.
Leveransemodell
Arbeidet gikk i korte batcher: baseline, skriptrevisjon, bilde- og layoutfikser, cache-policy, checkout-isolasjon, staging-validering, produksjonsutrulling, deretter måling etter lansering.
Hver batch hadde en rollback-sti. Det betyr mer enn en dramatisk lansering når omsetningen går gjennom samme checkout som optimaliseres.
Resultatbånd
Eksakte tall er konfidensielle. Det publiserbare resultatet er at hovedfamilien av kommersielle maler gikk fra røde Core Web Vitals mot grønne terskler, mens checkout-adferd ble stabil.
Den gjenbrukbare lærdommen: ytelsesgjenoppretting i WooCommerce handler mindre om perfekt score og mer om riktig grense mellom cachebare kommersielle sider og live transaksjonsflyter.