Cart fragments belaster forsiden i WooCommerce, selv når ingen lægger varer i kurven

Hvad cart fragments egentlig gør

WooCommerce bruger scriptet wc-cart-fragments til at holde kurv-indholdet opdateret uden fuld genindlæsning af siden. Mekanismen bruges typisk til minicart i headeren, så antal varer og subtotal kan ændres, når en kunde lægger noget i kurven. Ifølge Best practices for the use of the “cart fragments” API – The WooCommerce Developer Blog kan denne funktion være nyttig, men den har også en omkostning, fordi den udløser AJAX-kald og ekstra behandling på sider, hvor mange brugere aldrig interagerer med kurven.

Det vigtige er, at cart fragments ikke kun er et frontend-problem. Selve browseren sender en request, men hver request rammer også WordPress, WooCommerce, PHP og ofte databasen. Hvis forsiden får meget trafik, kan selv små ekstra kald blive til mærkbar belastning. Det gælder især, hvis et tema altid viser en dynamisk minicart i headeren, eller hvis scripts indlæses globalt uden hensyn til sidetype.

Hvorfor det rammer forsiden hårdt

Forsiden er ofte den mest trafikerede side i en webshop. Hvis alle besøgende udløser et AJAX-kald for at opdatere kurven, selv når de bare scroller forbi kampagnebannere eller læser om virksomheden, bruger shoppen ressourcer på noget, som ikke forbedrer oplevelsen for hovedparten af brugerne. Den type trafik kan være særligt dyr, fordi forsidebesøg ofte kommer fra annoncer, sociale medier og nyhedsbreve, hvor mange brugere ikke går direkte i købstilstand.

Problemet bliver tydeligere på shops med page cache eller CDN-cache. Den cachede HTML kan leveres hurtigt, men cart fragments-kaldet går udenom page cache og kræver dynamisk behandling. Derfor kan en side se hurtig ud ved første blik, mens serveren stadig arbejder unødigt hårdt i baggrunden. WooCommerce beskriver generelt i Performance Documentation – WooCommerce, at performance skal vurderes på tværs af tema, udvidelser, servermiljø og datamængde. Cart fragments er et godt eksempel på netop det samspil.

Sådan genkender du problemet

Den mest direkte metode er at åbne browserens udviklingsværktøjer og se under Network-fanen. Besøg forsiden i et inkognito-vindue, filtrér på XHR eller fetch, og kig efter requests relateret til WooCommerce, især admin-ajax.php eller kald knyttet til cart fragments. Hvis der sker et AJAX-kald kort efter sideindlæsning, uden at du har klikket på noget, er det et tegn på, at kurv-opdatering sker automatisk.

Du bør også kontrollere, om scriptet wc-cart-fragments.js eller tilsvarende registreres på sider, hvor ingen minicart er nødvendig. Nogle temaer og plugins indlæser scriptet globalt, selv om kun få templates bruger funktionen. Det er en klassisk årsag til unødvendigt JavaScript-arbejde og ekstra requests.

På serversiden kan problemet vise sig som mange requests til admin-ajax.php, høj PHP-aktivitet og varierende svartider under belastning. Hvis TTFB ser rimelig ud for cachede sider, men CPU-forbrug og samtidige PHP-processer alligevel stiger, kan bagvedliggende AJAX-kald være en del af forklaringen. WooCommerce anbefaler i Troubleshooting a slow site: documentation – WooCommerce at isolere flaskehalse systematisk frem for at antage, at hele sitet bare er “langsomt”.

Typiske tekniske årsager

Temaet viser en dynamisk minicart i headeren på alle sider.
WooCommerce-scripts er ikke conditionally enqueued, men indlæses globalt.
Et plugin afhænger af fragment-opdateringer til wishlist, prisvisning eller custom header-elementer.
Kurven eller minicart-komponenten er bygget på ældre mønstre, hvor cart fragments altid antages nødvendige.
Der bruges mange tredjepartsudvidelser, som hver især kobler sig på WooCommerce-fragments eller AJAX-events.

Det er vigtigt at skelne mellem behov og vane. Nogle shops har reelt brug for live-opdateret minicart på de fleste sider. Men i mange implementationer er funktionen bare standardadfærd, ikke et bevidst valg. Hvis brugeren først ser relevant kurv-info på selve produktsiden, kurvsiden eller checkout, giver global opdatering sjældent mening.

Løsning 1: Fjern cart fragments fra sider, hvor funktionen ikke bruges

Den mest oplagte løsning er at forhindre indlæsning af cart fragments på sider, hvor der ikke findes en minicart eller et andet element, der afhænger af live-opdatering. Det kan gøres i temaets functions.php eller i et site-specifikt plugin. Målet er ikke nødvendigvis at deaktivere funktionen overalt, men at begrænse den til relevante sidetyper.

add_action( 'wp_enqueue_scripts', function() {
    if ( is_admin() ) {
        return;
    }

    if ( ! is_cart() && ! is_checkout() && ! is_woocommerce() ) {
        wp_dequeue_script( 'wc-cart-fragments' );
        wp_deregister_script( 'wc-cart-fragments' );
    }
}, 100 );

Koden ovenfor er et simpelt eksempel, men den skal tilpasses den konkrete shop. Hvis headeren på forsiden faktisk viser en fungerende minicart, kan denne løsning skabe forkert kurvantal eller stale data. Derfor skal du altid afklare, hvilke templates og komponenter der er afhængige af scriptet, før du fjerner det.

Løsning 2: Erstat dynamisk minicart med en enklere komponent

Hvis problemet skyldes et header-element, kan en bedre løsning være at redesigne netop den komponent. Mange shops klarer sig fint med et statisk kurv-link eller et ikon uden live-subtotal på ikke-transaktionelle sider. Dermed fjernes behovet for AJAX-opdatering ved hvert sidebesøg. Det kan give både lavere JavaScript-omkostning og mindre backend-belastning.

Hvis du bruger et tema med indbygget minicart, skal du undersøge, om det kan slås fra pr. template eller erstattes med en blok- eller menu-løsning uden fragment-afhængighed. WooCommerce har i de senere år bevæget sig væk fra automatisk brug af cart fragments i alle scenarier, netop fordi den gamle adfærd ofte var for dyr i praksis.

Løsning 3: Undersøg afhængigheder fra plugins og custom kode

Nogle shops har allerede deaktiveret minicart visuelt, men scriptet indlæses stadig, fordi et plugin har registreret afhængighed til wc-cart-fragments. Her er det ikke nok at se på frontend. Du skal også gennemgå temaets og pluginernes enqueue-logik, samt om custom JavaScript lytter efter WooCommerce-events knyttet til kurv-opdatering.

Et godt arbejdsmønster er at lave en staging-kopi og derefter deaktivere eller isolere plugins ét ad gangen, mens du måler antal requests og belastning. Hvis et produktfilter-, search- eller tracking-plugin uventet bruger WooCommerce-fragments, skal det vurderes, om afhængigheden er nødvendig. På shops med mange udvidelser er denne type sideeffekt ikke usædvanlig.

Løsning 4: Brug cache rigtigt, men ikke som erstatning for fejlfinding

Persistent object cache med for eksempel Redis kan reducere noget af backend-omkostningen ved gentagne operationer, især hvis WooCommerce eller andre plugins ellers udfører de samme opslag mange gange. WordPress beskriver objektcache i WP_Object_Cache – Class | Developer.WordPress.org, og generel cache-arkitektur i Cache – Advanced Administration Handbook | Developer.WordPress.org. Men object cache fjerner ikke selve problemet, hvis unødvendige AJAX-kald stadig bliver sendt til PHP på hver sidevisning.

Med andre ord: Redis kan gøre en dårlig adfærd mindre dyr, men ikke god. Hvis forsiden udløser tusindvis af fragment-kald om dagen uden funktionel gevinst, bør du først reducere eller eliminere kaldet. Derefter kan cache-lag bruges til at forbedre resten af applikationens effektivitet.

Hvordan du måler, om løsningen virker

Sammenlign antal requests på forsiden før og efter ændringen i browserens Network-fane.
Mål om admin-ajax.php får færre kald i serverlogs eller APM-værktøj.
Sammenlign PHP-responstid og samtidige PHP-processer ved belastningstest.
Kontrollér om Core Web Vitals påvirkes indirekte, især hvis mindre JavaScript giver hurtigere interaktivitet.
Test at kurv, minicart og checkout stadig fungerer korrekt for både gæster og indloggede brugere.

Core Web Vitals er ikke en direkte måling af cart fragments, men færre scripts og mindre baggrundsarbejde kan forbedre brugeroplevelsen, især på mobile enheder. web.dev samler de centrale principper for web performance på Web performance | web.dev. I praksis bør du dog måle både frontend og backend, fordi gevinsten ofte er størst på serverbelastning og cache-effektivitet snarere end alene på visuel loadtid.

Hvornår du ikke bør deaktivere cart fragments blindt

Det er ikke altid korrekt at fjerne cart fragments. Hvis shoppen bygger på en minicart, der forventes at opdatere øjeblikkeligt efter add-to-cart fra arkivsider, produktkort eller AJAX-baserede købsknapper, kan deaktivering give inkonsistent adfærd. Det samme gælder specialløsninger, hvor kurvdata vises i header, sidepanel eller sticky elementer gennem hele kunderejsen.

Du bør derfor tænke i funktionelle krav, ikke bare i performance. Spørgsmålet er ikke “kan scriptet fjernes?”, men “hvor på sitet skaber live-kurv værdi, og hvor er det bare en dyr vane?” Den skelnen er ofte nok til at finde en løsning, som både er hurtigere og mere robust.

Sæt problemet ind i en større WooCommerce-kontekst

Cart fragments er kun én mulig flaskehals. Hvis shoppen også har tunge produktfiltre, langsom produktsøgning, ineffektiv databasebrug eller svag hosting-konfiguration, skal de problemer håndteres særskilt. Du kan læse mere i Sådan gør du en langsom WooCommerce-webshop hurtigere og Når WooCommerce produktfiltre gør store kataloger langsomme. Pointen er, at en hurtig webshop kræver præcis fejlfinding: frontend, PHP, database og infrastruktur påvirker hinanden, men skal ikke blandes sammen analytisk.

Når cart fragments belaster forsiden, er det som regel et tegn på for bred indlæsning af dynamisk funktionalitet. Løsningen er sjældent dramatisk. Ofte handler det om at begrænse scripts, forenkle headeren, fjerne unødige afhængigheder og teste konsekvenserne grundigt. Det giver typisk mere stabile svartider og en mere forudsigelig drift, især på shops med meget trafik.