WooCommerce-ytelse: checkout, cache og Core Web Vitals

Standard WooCommerce stopper opp før katalogen blir interessant. En ren installasjon med noen hundre produkter føles rask i staging, mens samme tema med titusener av produkter og ordrer får lang TTFB, cart fragments står i kø på butikkarkivet og tabellen wp_options vokser uten at noen merker det.

Problemet er ikke plattformen, men konfigurasjonen og år med plugins som har hopet seg opp. En rask butikk krever arbeid nettopp på disse punktene, og den bredere planen ligger i WooCommerce-ytelsesoptimalisering 2026.

Dette er en feltguide for å gjøre WooCommerce klar for reell last. Den forutsetter skalltilgang, WP-CLI og vilje til å lese slow query-loggen.

#Hvordan HPOS-migreringen i WooCommerce fungerer

I et tiår lagret WooCommerce ordrer som innlegg av typen shop_order i wp_posts (samme tabell som bloggartiklene dine), og hver ordrelinje, adresse og hvert metadatafelt ble spredt over rader i wp_postmeta. En spørring som “ordrer fra mai” betydde å skanne en tabell blandet med revisjoner, autolagringer og sideutkast, og deretter tre eller fire JOIN mot postmeta for å sette sammen hver ordre.

High Performance Order Storage flytter ordrene til wc_orders, wc_order_addresses, wc_order_operational_data og wc_orders_meta. Ordrelister treffer indekserte kolonner direkte i stedet for å bygge hver rad fra postmeta.

HPOS har vært standard for nye installasjoner siden WooCommerce 8.2, utgitt i oktober 2023, ifølge HPOS-dokumentasjonen. Butikker som startet før den versjonen kjører ofte fortsatt med lagring i innlegg, og derfor er migreringen fortsatt første punkt i de fleste revisjoner.

Dette fikser ikke HPOS alene:

• Egne plugins som fortsatt skriver til postmeta-nøkler i stedet for ordre-API-et, kommer stille ut av synk når kompatibilitetsmodus slås av
• Plugins som leser ordredata med get_post_meta($order_id, ...) i stedet for $order->get_meta(), returnerer tomme verdier når den gamle tabellen ikke lenger er autoritativ
• Rapporter bygget på WP_Query mot shop_order må skrives om

Arbeidsflyt:

1. WooCommerce -> Innstillinger -> Avansert -> Funksjoner, slå på High Performance Order Storage med kompatibilitetsmodus på
2. La synkroniseringen gå utenfor rushtid; i en stor butikk kan den ta flere timer
3. Kontroller med wp wc hpos verify_data
4. Test alle plugins som berører ordrer i en uke, mens kompatibilitetsmodus fortsatt skriver til postmeta
5. Slå av kompatibilitetsmodus først når du har bekreftet at hver slik plugin leser fra HPOS

wp wc hpos status
wp wc hpos sync --batch-size=500
wp wc hpos verify_data

#HPOS-kommandoer i WP-CLI etter WooCommerce 8.9

Eldre veiledninger bruker navnerommet wp wc cot. WooCommerce 8.9.0 merket det som foreldet: de gamle kommandoene kjører fortsatt, men hver av dem skriver ut en advarsel med etterfølgeren under wp wc hpos, og verify_cot_data heter nå verify_data (CLIRunner.php). Dokumentasjonen for HPOS-verktøyene i CLI og kommandoenes egne docblocks viser dagens sett:

• wp wc hpos status viser HPOS-innstillingene og synkroniseringsstatus
• wp wc hpos count_unmigrated teller ordrer som fortsatt venter på synkronisering
• wp wc hpos sync migrerer ordrer i bunker, og --batch-size er 500 som standard
• wp wc hpos verify_data sammenligner begge datalagrene; flagget --re-migrate synkroniserer ordrer med avvik på nytt og kan overskrive en ordre, så prøv det i staging først
• wp wc hpos diff 123 viser avvikene for én ordre
• wp wc hpos compatibility-mode enable og disable slår synkroniseringen av og på uten å åpne adminpanelet
• wp wc hpos cleanup fjerner gamle innleggsdata for migrerte ordrer. Dokumentasjonen kaller kommandoen destruktiv, og uten argumenter gjør den ingenting; wp wc hpos cleanup all behandler alle ordrer

Kjør cleanup først når kompatibilitetsmodus har vært av lenge nok til at ingen plugin leser den gamle kopien, og alltid etter en sikkerhetskopi av databasen.

#Hvordan gjøre en egen plugin kompatibel med HPOS

WooCommerce advarer butikkeieren når de prøver å slå på HPOS mens en plugin som har erklært seg inkompatibel er aktiv, og viser samme advarsel på plugin-siden. For plugins som ikke er WooCommerce-utvidelser vises advarselen bare når plugin-headeren har linjen WC tested up to. En egen plugin erklærer statusen sin i hovedfilen, slik HPOS-oppskriftsboken viser:

add_action( 'before_woocommerce_init', function() {
    \Automattic\WooCommerce\Utilities\FeaturesUtil::declare_compatibility( 'custom_order_tables', __FILE__, true );
} );

Erklæringen er et løfte, ikke en reparasjon. Koden bak må laste ordrer med wc_get_order() i stedet for get_post() og skrive metadata gjennom ordreobjektet (update_meta_data(), add_meta_data(), delete_meta_data() og deretter save()) i stedet for update_post_meta(). Da avgjør WooCommerce hvilke tabeller som får skrivingen. Oppskriftsboken påpeker at save() er en relativt kostbar operasjon, så en løkke som lagrer ordren etter hver enkelt metadataendring er et ytelsesproblem i seg selv. Kode som må skille mellom lagringsmotorene kan kalle OrderUtil::custom_orders_table_usage_is_enabled().

#Hvordan slå av cart fragments i WooCommerce

En eldre WooCommerce-butikk, eller en med handlekurv-widget i headeren, viser i GTmetrix eller WebPageTest forespørselen ?wc-ajax=get_refreshed_fragments på hver side. Det er WooCommerce som spør PHP om handlekurv-ikonet i headeren har endret seg: på forsiden, i bloggen, i kategoriarkiver, på “Om oss”-siden. Også når handlekurven er tom.

Den enkleste regelen for rekkevidde:

add_action( 'wp_enqueue_scripts', function() {
    if ( is_cart() || is_checkout() || is_product() ) {
        return;
    }
    wp_dequeue_script( 'wc-cart-fragments' );
}, 11 );

Plugins som Perfmatters og Asset CleanUp tilbyr dette som en bryter i panelet. Begge veier fører til samme mål: cart fragments skal bare kjøre der et handlekurv-ikon faktisk må oppdateres live.

Hvis du virkelig trenger en teller i headeren på hver side, lagre den i localStorage og oppdater den med JavaScript ved legg-i-handlekurv-hendelser, i stedet for å spørre serveren.

#Når WooCommerce fortsatt laster cart fragments etter versjon 7.8

WooCommerce 7.8 endret standardoppførselen. Ifølge innlegget på WooCommerce-utviklerbloggen Best practices for the use of the “cart fragments” API (16. juni 2023) legges skriptet ikke lenger inn på alle ruter i butikken. Det lastes fortsatt i tre tilfeller: på sider der handlekurv-widgeten vises, når et tredjepartsskript registrerer cart fragments-skriptet som avhengighet, og når kode legger det inn eksplisitt. Samme innlegg nevner at enkelte temaer, blant dem Storefront, har widgeten fast i malene sine.

I en oppdatert butikk er forespørselen i fossefallet derfor et symptom med en årsak som kan spores. Søk etter håndtaket wc-cart-fragments i sidekilden, og finn hvilken temamal eller plugin som drar det inn. Å fjerne skriptet uten den sjekken kan ødelegge en handlekurv i headeren som temaet fortsatt oppdaterer via fragments, og en plugin som oppgir skriptet som avhengighet, legger det inn igjen uansett.

#Objektcache eller transienter i databasen

WooCommerce bruker transienter mye: prisintervaller for varianter, oppslag av attributtermer, fraktberegninger. Uten objektcache havner transientene i wp_options. Om de lastes ved hver forespørsel avhenger av utløpstiden: set_transient() lagrer en transient uten utløp med autoload og en med utløp uten autoload, pluss en egen rad _transient_timeout_. WooCommerce lagrer transientene for variantpriser og undervarianter med 30 dagers utløp (datalageret for variable produkter), så de øker først og fremst antall rader i wp_options. Vekten i autoload kommer fra alternativer som plugins skriver uten utløp.

Velg én cache-backend og hold deg til den. Enten Redis eller Memcached som ekte objektcache, eller transienter i databasen. Å blande dem gir invalideringsfeil som er vanskelige å feilsøke.

# Autoload-størrelse i wp_options
wp db query "SELECT SUM(LENGTH(option_value)) AS bytes, COUNT(*) AS rows FROM wp_options WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');"

# De største alternativene med autoload
wp db query "SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload IN ('yes', 'on', 'auto-on', 'auto') ORDER BY bytes DESC LIMIT 20;"

WordPress kjører mange spørringer for å bygge en enkelt produktside: varianter, priser, lagerstatus. Redis holder resultatene av disse spørringene i RAM. Når Redis er satt opp på serveren, som administrert tjeneste hos verten eller som egen redis-server-instans, og object-cache.php ligger på plass, skriver set_transient() til objektcachen i stedet for til wp_options, transientene flytter til RAM og presset på autoload synker.

#Autoload-verdier i WordPress 6.6 og grensen på 800 KB

WordPress 6.6 endret hvordan autoload lagres. Utviklernotatet fra kjerneteamet Options API: disabling autoload for large options innfører databaseverdiene on, off, auto, auto-on og auto-off; on og off er eksplisitte valg, mens auto-on og auto-off settes av WordPress selv. Funksjonen wp_autoload_values_to_autoload() returnerer yes, on, auto-on og auto, og derfor filtrerer revisjonsspørringene over på akkurat den listen. En spørring som bare sjekker autoload = 'yes', overser alle alternativer som er lagret etter oppgraderingen, og får butikken til å se renere ut enn den er.

Endringen kom med to terskler. Et alternativ større enn 150 000 byte lastes ikke automatisk med mindre koden ber om det eksplisitt, og filteret wp_max_autoloaded_option_size flytter grensen. Nettstedhelse slår alarm når den samlede størrelsen på alternativer med autoload passerer 800 KB. Den sjekken er den billigste første testen i en ukjent butikk, fordi den ikke krever skalltilgang og navngir problemet før noen åpner en databaseklient.

#Hva som aldri skal caches i en WooCommerce-butikk

Statisk cache hjelper arkiver, produktsider og blogginnlegg. Den ødelegger alt som avhenger av brukerens sesjon, fordi hver kunde har sin egen handlekurv.

Faste unntak for enhver sidecache og enhver Cloudflare-regel:

• /handlekurv/ eller /cart/
• /kasse/ eller /checkout/
• /min-konto/ eller /my-account/
• Alle URL-er med ?wc-ajax=
• Alle forespørsler med informasjonskapselen woocommerce_items_in_cart
• REST-endepunktene under /wp-json/wc/

Cache statisk innhold (bilder, CSS, JS) på edge med Cloudflare APO for WordPress. APO kan også cache HTML for utloggede brukere og respekterer sesjonskapslene til WooCommerce når det er riktig konfigurert, men sjekk med curl -I på handlekurv og kasse at du får cf-cache-status: BYPASS. En feilkonfigurert cache som viser en annen kundes handlekurv, er et brudd på personvernforordningen (GDPR), ikke en ytelsesgevinst.

#Spørringer for variable produkter og filteret woocommerce_variable_children_args

Variable produkter med flere titalls varianter hver multipliserer JOIN-ene. Arkivet i en klesbutikk med 200 variable produkter og 30 varianter hver gjør en JOIN mot wp_posts for 6000 underprodukter ved hver lasting.

To praktiske grep:

• Begrens variantene som lastes i nedtrekkslisten til dem som er på lager og synlige
• Bruk woocommerce_variable_children_args for å holde private og utsolgte varianter utenfor første lasting på arkivsider

add_filter( 'woocommerce_variable_children_args', function( $args ) {
    if ( is_shop() || is_product_category() ) {
        $args['post_status'] = 'publish';
        $args['meta_query'][] = array(
            'key'     => '_stock_status',
            'value'   => 'instock',
        );
    }
    return $args;
} );

#Hvordan begrense veksten i Action Scheduler-tabellene

Alle WooCommerce-utvidelser som jobber i bakgrunnen, bruker Action Scheduler. Abonnementer, oppfølgingsmeldinger, gjenoppretting av forlatte handlekurver, lagersynk, ERP-integrasjoner: alt havner i wp_actionscheduler_actions og wp_actionscheduler_logs.

I en butikk med aktive abonnementer og gjenoppretting av handlekurver samler disse tabellene i løpet av et år opp et stort antall fullførte og mislykkede handlinger, og adminpanelet spør dem ved hver sidelasting for å vise køtelleren.

Vedlikeholdsskript:

# Slett fullførte og avbrutte handlinger eldre enn 31 dager
wp action-scheduler clean --before="31 days ago" --pause=1

# Se størrelsen på køen
wp db query "SELECT status, COUNT(*) FROM wp_actionscheduler_actions GROUP BY status;"

# Bekreft indekser på status og scheduled_date_gmt
wp db query "SHOW INDEX FROM wp_actionscheduler_actions;"

#Hvor lenge Action Scheduler beholder fullførte og mislykkede handlinger

Action Scheduler rydder etter seg selv når køen kjører. Dens køopprydder sletter fullførte og avbrutte handlinger når de er eldre enn 31 dager, og filteret action_scheduler_retention_period endrer det vinduet. Siden Action Scheduler 4.0 slettes også mislykkede handlinger, som standard etter tre måneder (action_scheduler_retention_period_for_failed); kommentaren i koden knytter den perioden til den kvartalsvise regnskapssyklusen.

Oppryddingen kjører inne i køprosessen. I en butikk som slår av WP-Cron og ikke har en systemcron som kaller wp-cron.php eller wp action-scheduler run, stopper køen, og oppryddingen stopper med den, uten noen synlig feilmelding. Etterslepet etter et slikt hull kan ryddes for hånd med wp action-scheduler clean, som ifølge WP-CLI-referansen for Action Scheduler tar --status (standard canceled,complete), --before (standard 31 dager), --batch-size (standard 20) og --pause for å vente mellom bunkene på en travel database.

#Hvordan optimalisere produktbilder i WooCommerce

Produktbilder er som regel den tyngste delen av enhver butikk. Tre regler:

1. AVIF for hovedbilder og gallerier, med WebP som reserve for eldre Safari-versjoner som fortsatt dukker opp i trafikken
2. Ikke last opp rå eksporter på 4000 px. Begrens opplastingen til 2000 px på den lengste siden
3. Innebygd loading="lazy" holder; fjern gamle JavaScript-baserte lazy loadere som kolliderer med den

Skaler bildene ned før opplasting i stedet for å la WordPress lage miniatyrbilder i farten, for det skriver til wp_postmeta og blåser opp databasen.

#Hvordan rydde WooCommerce-databasen med WP-CLI

Kjør dette månedlig, oftere i butikker med mange forlatte handlekurver:

# Slett utløpte sesjoner (bare nødvendig når den planlagte oppryddingen har stoppet)
wp db query "DELETE FROM wp_woocommerce_sessions WHERE session_expiry < UNIX_TIMESTAMP();"

# Tøm WooCommerce-transienter
wp wc tool run clear_transients --user=1

# Optimaliser tabellene
wp db optimize

# Sjekk dybden i Action Scheduler-køen
wp action-scheduler status

Planlegg dette med systemcron i stedet for wp-cron.php, som bare kjører når det er trafikk. Flagget --user på wp wc tool run følger eksemplene for WooCommerce CLI; bruk ID-en til en administratorkonto i din installasjon. Den som foretrekker panelet, kan bruke WP-Optimize.

#Hvordan WooCommerce rydder i kundesesjoner

WooCommerce beskjærer allerede sesjonstabellen sin. Det registrerer en gjentakende Action Scheduler-handling, woocommerce_cleanup_sessions, som kjører hver 12. time (class-woocommerce.php), og sesjonshåndtereren sletter utløpte rader i bunker på 100 med en kort pause mellom bunkene. En gjestesesjon utløper etter to dager og en innlogget kundes etter sju; filtrene wc_session_expiration og wc_session_expiring endrer begge. Levetider over 30 dager gir en advarsel i WooCommerce-loggen, fordi lengre sesjoner får tabellen til å vokse.

Det har to følger. En sesjonstabell målt i gigabyte betyr som regel at Action Scheduler-køen ikke kjører, eller at en plugin har forlenget sesjonslevetiden, så sjekk wp action-scheduler status og disse filtrene før du sletter noe. Og kjør aldri TRUNCATE på wp_woocommerce_sessions i en butikk i drift: det tømmer alle aktive handlekurver, mens DELETE ... WHERE session_expiry < UNIX_TIMESTAMP() over bare fjerner rader som allerede har utløpt.

#Hvilke ytelsesmål for WooCommerce du bør følge

Optimaliserer du i blinde, optimaliserer du feil ting. Velg noen signaler og følg dem ukentlig:

• TTFB med kald cache på butikkarkivet og én produktside
• Tid til første byte på handlekurv og kasse med én og med fire varer i handlekurven
• Antall rader og total størrelse for alternativer med autoload i wp_options
• Dybden i Action Scheduler-køen og eldste ventende handling

Query Monitor i staging viser hvilke spørringer som dominerer. New Relic eller Datadog APM i produksjon viser den faktiske fordelingen. PageSpeed Insights er en røyktest, ikke en diagnose.

#Sist oppdatert

2026-10-14. Hvis butikken din ikke passer inn i disse mønstrene, er det ikke mønstrene som er problemet. Begynn med slow query-loggen. Vurderer du en frakoblet frontend, se headless WooCommerce med Astro. For HPOS, Redis og databasevedlikehold i en butikk i drift kan en erfaren WooCommerce-utvikler hjelpe.