Langsom checkout i WooCommerce: fra „Afgiv ordre“ til kvittering

Kort svar: Checkout er webshoppens tungeste side: den kan ikke caches, kører AJAX-kald ved hver ændring og venter på betalingsgatewayen ved “Afgiv ordre”. Mål først, hvor tiden går – sideindlæsning, opdateringer undervejs eller selve ordreafgivelsen – og ret derefter det led: hurtigere u-cachet PHP (server og object cache), færre tunge scripts og plugins på checkout, og kun de betalingsmetoder, fragtmetoder og felter, der bruges.

Fagligt gennemgået: 2. oktober 2026

En langsom checkout mærkes dobbelt: kunden står med kortet fremme og venter – og hvert ekstra sekunds ventetid øger risikoen for, at købet ikke bliver gennemført. Samtidig er checkout den side, hvor almindelige hastighedstricks ikke gælder: page cache er udelukket, og indholdet er dynamisk pr. kunde. Derfor kræver den sin egen tilgang.

Før du ændrer noget: Mål før du retter, og ret ét led ad gangen. Test plugin- og temaændringer på en staging-kopi, og lav testordrer med betalingsgatewayens testtilstand – ikke på live-checkout midt i åbningstiden. Notér, hvilke indstillinger du ændrer, så du kan rulle tilbage.

1. Mål, hvor tiden går

Åbn browserens Netværk-fane, og gennemfør en testordre i et privat vindue. Del oplevelsen op i tre led, og notér tiden for hvert: første indlæsning af checkout-siden, AJAX-kaldene når adresse eller fragt ændres, og selve ordreafgivelsen. De tre led har hver deres årsager – og målingen afgør, hvilket afsnit du skal bruge:

Led	Request i Netværk-fanen	Kig efter
1. Sideindlæsning	Selve checkout-siden (dokumentet)	Tid til første byte (TTFB) og antal scripts
2. Opdateringer undervejs	?wc-ajax=update_order_review (klassisk checkout) eller kald til /wp-json/wc/store/ (blok-checkout)	Svartid ved ændring af adresse, postnummer eller fragt
3. Ordreafgivelse	?wc-ajax=checkout eller /wp-json/wc/store/v1/checkout	Tiden fra klik på “Afgiv ordre” til svar – og derefter gatewayens egne kald

Vil du måle serverens svartid uden browserens scripts, kan du bruge curl. Bemærk, at en tom kurv typisk sender dig videre fra checkout til kurven, så kopiér sessionscookien fra en browser med varer i kurven, hvis du vil måle selve checkout. Brug adressen på din egen checkout-side:

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s  Total: %{time_total}s\n" \
  -H "Cookie: DIN_SESSIONSCOOKIE" https://dinbutik.dk/checkout/

Sammenlign med en produktside, der leveres fra cache. Er forskellen stor, er det den u-cachede PHP, der skal arbejdes med. Til at se, hvad der sker inde i PHP, er pluginnet Query Monitor nyttigt på staging: det viser langsomme databaseforespørgsler, og hvilke plugins der står bag dem.

2. Ret led 1: selve siden indlæses langsomt

Checkout leveres altid af u-cachet PHP – her måles serverens reelle hastighed. Fire greb flytter mest:

• Object cache (Redis/Memcached): færre gentagne databasekald pr. sidevisning – ofte den største enkeltgevinst på dynamiske sider, hvis hostingen understøtter det.
• Nyere PHP-version: målbart hurtigere afvikling – se guiden til sikker PHP-opgradering.
• Færre aktive plugins på checkout: hvert plugin, der loader scripts og kører kode på siden, lægger til. Er hele butikken langsom – ikke kun checkout – så start i stedet i guiden om langsom WooCommerce.
• En database, der er ryddet op: udløbne kundesessioner, transients og store autoload-data gør hver forespørgsel tungere. WooCommerce rydder selv udløbne sessioner via planlagte opgaver – det kræver, at wp-cron faktisk kører.

Tjek også, om butikken bruger WooCommerce’ ordrelager HPOS (High-Performance Order Storage) under WooCommerce → Indstillinger → Avanceret → Funktioner. Det har været standard for nye butikker siden WooCommerce 8.2 og gemmer ordrer i egne tabeller i stedet for i den almindelige indlægstabel. Ældre butikker kører ofte stadig på det gamle lager. Skift kun efter test på staging, og kontrollér at dine plugins understøtter HPOS – WooCommerce viser en advarsel om plugins, der ikke gør.

3. Ret led 2: opdateringer undervejs hænger

Hver gang kunden ændrer postnummer eller fragtvalg, genberegner WooCommerce ordren via AJAX. Tager de kald flere sekunder, føles checkout “hængende”, selvom siden loadede fint. Typiske syndere:

• Eksterne opslag: fragt- og afgiftsberegninger, der henter pakkeshop-lister eller live-rater hos en fragtudbyder ved hvert kald.
• Mange fragtmetoder i zonen: hver metode skal beregnes ved hver opdatering.
• Tunge tredjepartsscripts: chat, tracking og adresseopslag, der blokerer browseren. Prøv checkout med scripts slået fra via en ren testprofil.
• Plugins, der hænger sig på genberegningen: rabat-, gebyr- og fragtplugins kører kode ved hvert kald.

Reagerer felterne slet ikke, er det kurv-opdateringsproblemet, ikke hastighed. Opsætning af pakkeshop-vælgeren står i guiden om pakkeshop-vælger i checkout.

4. Ret led 3: “Afgiv ordre” tager lang tid

Ved ordreafgivelsen sker alt på én gang: ordren oprettes, lager reserveres, mails klargøres – og betalingsgatewayen kontaktes. Ventetiden her er ofte gatewayens svartid, som du ikke selv styrer. Men du styrer resten:

• Ordremails uden for selve ordreoprettelsen: WooCommerce kan udsætte transaktionsmails, så de ikke bremser ordreoprettelsen. Det slås til med filteret nedenfor – test på staging, at mailene stadig kommer frem.
• Færre betalingsmetoder: hver aktiv metode kan loade egne scripts og køre egne kontroller.
• Baggrundsjobs, der kører: sørg for at baggrundsjobs faktisk kører, så arbejde kan skubbes derover – og at planlagte handlinger ikke hober sig op.
• Plugins på ordrehooks: integrationer til regnskab, lager eller nyhedsbrev, der sender data synkront ved ordreoprettelsen, kan lægge sekunder til. Kig efter indstillinger for at sende i baggrunden.

<?php
// wp-content/mu-plugins/udsaet-ordremails.php
add_filter( 'woocommerce_defer_transactional_emails', '__return_true' );

Ender ordrer som “Afventer betaling”, er det ikke hastighed, men callback-flowet – se den guide. Opstår der dobbeltordrer, fordi kunden klikker igen, mens hun venter, så se guiden om dobbeltordrer i WooCommerce.

5. Undgå de typiske faldgruber

• Cache af checkout: giver ikke fart, men risiko for at blande kunders data sammen. Kurv, checkout og Min konto skal altid være undtaget.
• Delay eller defer af betalingsscripts: cache-plugins, der udskyder JavaScript, kan gøre betalingsfelter langsomme eller døde. Undtag gateway-scripts fra udskydelse.
• Bot- og firewallregler: regler, der udfordrer AJAX-kald eller gateway-callbacks, kan få checkout til at hænge eller fejle.
• Måling som indlogget administrator: admin-bjælken og ekstra plugins som administrator giver andre tal end en almindelig kunde får.

6. Verificér forbedringen

Forbedringen er reel, når du måler de samme tre led før og efter med samme kurv og ser tallet falde i det led, du arbejdede på – og når en fuld testordre stadig gennemføres korrekt med ordremail og korrekt lagertræk. Mål på mobilnetværk også; checkout-scripts rammer hårdere på mobil. Og gør målingen til en vane efter større plugin-opdateringer – checkout-regressioner sniger sig ind én opdatering ad gangen.

Er u-cachet PHP fortsat flaskehalsen på en velholdt shop, er det reelt et spørgsmål om serverkraft – dér hjælper hosting, der er sat op til WooCommerce, mere end flere frontend-tricks. Kravene står i WooCommerce hosting: 10 krav til drift.

Læs også

• Hub: WooCommerce fejl og fejlfinding
• Langsom WooCommerce med mange produkter
• WooCommerce betaling fejler
• Høj TTFB i WordPress
• Page cache, object cache og browser cache
• WooCommerce hosting hos Hostious – servere i Europa og dansk support døgnet rundt

Ofte stillede spørgsmål om langsom checkout

Hvorfor er checkout langsom, når resten af butikken er hurtig?

Fordi resten af butikken leveres fra cache – checkout gør ikke. På checkout måler du serverens rå PHP-hastighed plus alle scripts. Derfor er checkout også den ærligste måling af din hosting.

Må jeg cache checkout-siden?

Nej. Checkout indeholder kundens session og persondata – caches den, risikerer du at blande kunder sammen. Fart på checkout skal komme fra server, object cache og færre scripts, ikke fra page cache.

Hjælper det at skifte til WooCommerce-checkout-blokken?

Den moderne checkout-blok er hurtigere i nogle opsætninger og loader anderledes – men skift ikke midt i en fejlfinding. Mål først, ret flaskehalsen, og test i så fald blok-checkouten på staging med samme målinger.

Er det min server eller betalingsgatewayen, der er langsom?

Se i Netværk-fanen, hvor længe selve checkout-requesten tager, og hvad der sker bagefter. Er WooCommerce’ eget svar hurtigt, men kunden venter på gatewayens side eller 3D Secure, ligger ventetiden hos betalingsudbyderen.