Konfidensiell WooCommerce-ytelsesgjenoppretting

Mariusz Szatkowski

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.

De største kostnadene summerte seg: tredjepartsskript for tidlig, ubrukt CSS, bilde-sizing-drift, cache-misser på sider som trygt kunne caches, og ucachet wc-ajax=get_refreshed_fragments ved hvert sidelast som under last oversvømte PHP-FPM-poolen.

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

Måling 30 dager etter utrulling i den konfidensielle EU-B2B-butikken: LCP 5,4s til 1,8s (-66%), checkout-TTFB 2,1s til 0,4s (-80%), main-thread-blokkering 1 200ms til 180ms (-85%), cart-to-checkout-abandonment 42% til 34% (-19%).

Den gjenbrukbare lærdommen: ytelsesgjenoppretting i WooCommerce handler mindre om perfekt score og mer om riktig grense mellom cachebare kommersielle sider og live transaksjonsflyter.

Ofte stilte spørsmål

Hvordan fikser jeg treg WooCommerce-checkout på mobil uten å bygge butikken på nytt?

Start med måling på handlekurv-, checkout- og produktmaler, ikke med omskriving. I en konfidensiell EU-B2B-butikk (12 000+ SKU-er) fikset vi treg mobilcheckout ved å fjerne over 450 000 autoload-rader i wp_options, stanse wc-ajax=get_refreshed_fragments ved hvert sidelast, flytte over 25 piksler til Cloudflare Zaraz og legge til Redis uten checkout-grupper. Checkout-TTFB falt fra 2,1s til 0,4s og LCP fra 5,4s til 1,8s; hver batch hadde staging og rollback ved betalingsdrift.

Hva forårsaker trege WooCommerce cart fragments under høy trafikk?

Standard mini-cart fyrer ucachet wc-ajax=get_refreshed_fragments ved hvert sidelast. Under parallell trafikk flommer disse AJAX-kallene PHP-FPM-poolen, køer databaseforbindelser og legger latens før checkout i det hele tatt starter. Her kom wp_options-bloat (2,1 GB, over 450 000 autoload-rader) i tillegg. Fix: slå av automatisk fragmentoppdatering, oppdater cart-state først etter add-to-cart (vi brukte sessionStorage), og rydd autoload.

Hvordan kan en WooCommerce-butikk redusere checkout-latens uten å ødelegge betalinger?

Behandle checkout som ucachebar og isoler den før katalogtuning. Bruk Redis for transients og query-output, men ekskluder session- og checkout-grupper så skatt, lager og ERP-priser forblir nøyaktige. Flytt markedsskript til edge (Cloudflare Zaraz). Lever i små batcher med staging og rollback; cache aldri sider med sesjonscookies. Målt resultat: checkout-TTFB 2,1s til 0,4s med stabil B2B-betalingsadferd.

Hvorfor er ikke kunden navngitt?

Kontrakten hindrer offentlig navngiving, skjermbilder, trafikdetaljer og enkelte kommersielle identifikatorer. De målte ytelsesdeltaene og ingeniørmetoden er publiserbare og dokumentert over.