Kort svar: Checkout er shoppens 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/object cache), færre tunge scripts på checkout, og kun de betalingsmetoder og felter, der bruges.
En langsom checkout mærkes dobbelt: kunden står med kortet fremme og venter – og hver ekstra ventesekund koster gennemførte ordrer. Samtidig er checkout den side, hvor almindelige hastighedstricks ikke gælder: page cache er forbudt, og indholdet er dynamisk pr. kunde. Derfor kræver den sin egen tilgang.
Kontrolramme: WordPress 7.1, WooCommerce 11.0 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Terminaleksemplet er genskabt med illustrative tider – det er ikke målinger af hostious.io.
Åbn browserens Netværk-fane, og gennemfør en testordre i inkognito. 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 (kig efter ?wc-ajax=update_order_review), og selve ordreafgivelsen (?wc-ajax=checkout). De tre led har hver deres årsager – og målingen afgør, hvilket afsnit du skal bruge:
Checkout leveres altid af u-cachet PHP – her måles serverens reelle hastighed. Tre greb flytter mest:
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: fragt- og afgiftsberegninger med eksterne opslag (pakkeshop-lister, live-rater), mange fragtmetoder i zonen og tunge tredjepartsscripts (chat, tracking), der blokerer browseren – prøv checkout med scripts slået fra via en ren testprofil. Reagerer felterne slet ikke, er det kurv-opdateringsproblemet, ikke hastighed.
Ved ordreafgivelsen sker alt på én gang: ordren oprettes, lager reserveres, mails køes – og betalingsgatewayen kontaktes. Ventetiden her er ofte gatewayens svartid, som du ikke selv styrer; men du styrer resten: send ordremails asynkront (via kø frem for i selve requesten), hold antallet af aktive betalingsmetoder nede (hver metode kan loade egne scripts), og sørg for at baggrundsjobs faktisk kører, så arbejde kan skubbes derover. Ender ordrer som “Afventer betaling”, er det ikke hastighed, men callback-flowet – se den guide.
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 WooCommerce-hosting med NVMe og object cache mere end flere frontend-tricks.
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.
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.
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.
