Kort svar: En belastningstest af webshoppen sender mange virtuelle kunder igennem butikken på samme tid, så du kan se, hvornår svartiden stiger, og fejlene begynder. Test kurv og checkout, ikke kun forsiden, kør testen på en kopi af shoppen efter aftale med hostingen, og test til mindst det dobbelte af din forventede travleste time. Gør det tre-fire uger før Black Friday, så der er tid til at rette det, du finder.
Kontrolgrundlag: Metoden og regneeksemplet er egne. Hostious’ planer og egenskaber er aflæst på /woocommerce-hosting/ og /woocommerce-serviceaftale/ 3. november 2026.
En belastningstest af webshoppen er den eneste måde at kende loftet, før kunderne finder det. Uden en test er “vi har rigeligt med plads” et gæt. Med en test ved du, at shoppen kan klare 400 samtidige kunder med en svartid under et sekund – og at den knækker ved 650.
Denne guide viser, hvordan du planlægger og gennemfører testen, hvor mange virtuelle kunder du skal sende igennem, og hvordan du læser resultatet. Den handler om selve testen. Hvordan du regner kampagnetrafik ud og sikrer, at kampagnesiden kommer fra cache, står i guiden om kapacitet før en kampagne.
Hvad er en belastningstest – og hvilken type skal du bruge?
En belastningstest er en kontrolleret simulering af mange besøgende. Et værktøj sender et stigende antal virtuelle brugere igennem sitet efter et fast mønster og måler svartid og fejl undervejs. Der findes fire typer, og de svarer på hvert sit spørgsmål:
| Type | Sådan kører den | Spørgsmålet, den besvarer |
|---|---|---|
| Belastningstest (load) | Stiger roligt til den forventede travleste time og holder niveauet | Klarer shoppen det, vi forventer? |
| Stresstest | Fortsætter op, til noget går i stykker | Hvor er loftet – og hvad knækker først? |
| Spidstest (spike) | Springer fra næsten intet til fuld belastning på få sekunder | Hvad sker der, når nyhedsbrevet går ud ved midnat? |
| Udholdenhedstest (soak) | Holder et højt niveau i flere timer | Holder shoppen hele Black Week, eller vokser problemerne over tid? |
Før Black Friday har de fleste webshops brug for de tre første. En udholdenhedstest er relevant, hvis kampagnen varer flere dage, og du har set shoppen blive langsommere i løbet af en travl dag.
Hvor og hvornår du må teste
Den vigtigste regel: Test aldrig en webshop i drift uvarslet. En belastningstest ligner et angreb, og den kan blive blokeret – eller få den rigtige shop til at gå ned for rigtige kunder.
Den bedste løsning er en kopi af shoppen med de samme plugins, det samme tema og et realistisk antal produkter, ordrer og kunder. Et tomt testsite måler noget andet end virkeligheden. Ligger kopien på samme type server som den rigtige shop, får du tal, du kan bruge.
Tre ting skal være på plads, før du starter:
- Aftal testen med hostingen: tidspunkt, varighed og hvilken adresse der testes. Så bliver testen ikke blokeret, og udbyderen kan se, hvad der sker på serveren.
- Sæt betalingen i testtilstand på kopien, og slå ordremails fra, så tusind testordrer ikke ender hos rigtige kunder eller i regnskabet.
- Notér udgangspunktet: svartiden for forside, produktside, kurv og checkout med én bruger. Det er dit nulpunkt.
Hos Hostious følger staging med fra Woo StartUp, så du kan lave en kopi af shoppen og teste den uden at røre butikken. Skriv til supporten før testen, så vi ved, at trafikken er planlagt. Med WooCommerce serviceaftale gennemføres desuden et testkøb gennem checkout efter hver opdatering, så en rettelse efter testen ikke stopper betalingen.
Byg et realistisk scenarie
En test, der kun henter forsiden, siger næsten intet. Forsiden kommer fra cache og koster serveren ingenting. Det er kurv, checkout, søgning og filtre, der belaster. Scenariet skal derfor ligne det, rigtige kunder gør på kampagnedagen.
Et typisk Black Friday-scenarie for en webshop kan se sådan ud. Brug din egen fordeling fra analyseværktøjet, hvis du har den:
| Brugerrejse | Andel af virtuelle brugere | Rammer cache? |
|---|---|---|
| Forside → kategori → produktside | 50 % | Ja, næsten altid |
| Søgning eller filtrering → produktside | 20 % | Nej – søgning går til databasen |
| Produktside → læg i kurv → kurv | 20 % | Nej |
| Hele vejen gennem checkout til betaling | 10 % | Nej |
Lad hver virtuel bruger vente nogle sekunder mellem klikkene, som en rigtig kunde ville gøre. Uden pauser bliver hver bruger til en maskine, der klikker hundrede gange i minuttet, og testen bliver urealistisk hård.
Hvor mange virtuelle kunder skal du teste med?
Antallet af samtidige brugere er det tal, der volder mest besvær. Regn det ud fra ordrer, som du kender, i stedet for at gætte:
- Forventede ordrer i den travleste time: fx 135.
- Konverteringsrate i den time: fx 4,5 %. Det giver 135 / 0,045 = 3.000 besøg i timen.
- Gennemsnitlig besøgslængde: fx 6 minutter. Det giver 3.000 × 6 / 60 = 300 samtidige besøgende.
- Sikkerhedsmargen: test til mindst det dobbelte – her 600 – fordi trafikken aldrig fordeler sig jævnt over timen.
Kør testen i trin, ikke på én gang: 50 brugere i fem minutter, så 100, 200, 300 og så videre. Hold hvert trin længe nok til, at svartiden falder til ro. Så kan du se præcist, hvor kurven knækker.
Hvad du skal måle – og hvornår du stopper
Gennemsnitlig svartid er det mindst nyttige tal. Et gennemsnit på et sekund kan dække over, at hver tyvende kunde venter otte sekunder. Mål i stedet disse fire:
| Måling | Hvad den viser | Stopkriterium (eksempel) |
|---|---|---|
| Svartid, 95. percentil | Hvor længe de langsomste 5 % venter | Over 3 sekunder i kurv eller checkout |
| Fejlrate | Andelen af svar med 5xx-fejl eller timeout | Over 1 % |
| Gennemførte forespørgsler pr. sekund | Hvor meget shoppen faktisk leverer | Stopper med at stige, selvom brugerne stiger |
| Serverens ressourcer | CPU, ledige PHP-processer og database | PHP-processerne er brugt op i flere minutter |
Det interessante punkt er knækket: det trin, hvor svartiden pludselig stiger kraftigt, eller hvor antallet af gennemførte forespørgsler holder op med at vokse. Det er shoppens reelle loft. Ligger knækket over dobbelt så højt som den forventede travleste time, er du godt rustet. Ligger det under, har du et problem, du skal løse nu.
Typiske fund – og hvad du gør ved dem
De fleste belastningstests af WooCommerce peger på et af disse fem steder:
- Kurven er langsom på alle sider. Ofte skyldes det, at kurvens indhold hentes på hver sidevisning. Se guiden om at deaktivere cart fragments.
- Checkout knækker først. Typisk for mange tunge plugins i checkout eller langsomme kald til fragt- og betalingsudbydere. Se langsom checkout i WooCommerce.
- Søgning og filtre presser databasen. Med mange produkter er opslagene tunge. Se langsom WooCommerce med mange produkter.
- Databasen svarer langsomt ved mange samtidige. Her hjælper Redis object cache ofte markant. Se Redis object cache med LiteSpeed.
- Produktsiderne kommer ikke fra cache. En cookie eller et plugin omgår cachen. Se cache-hit ratio.
Ret ét problem ad gangen, og kør samme test igen. Så ved du, hvad der virkede. Er loftet stadig for lavt, når koden er ryddet op, er det ressourcerne – og så er det tid til en større plan, anden hosting eller VPS hosting dimensioneret efter opgaven.
Vil du teste på en kopi uden at røre butikken? Med WooCommerce hosting hos Hostious følger staging med fra Woo StartUp til 239 kr./md. ekskl. moms, og webshoppen kører med egen database, Redis object cache, LiteSpeed og NVMe. Fortæl supporten, hvornår du tester, så følger vi med på serveren – og flytningen hertil er gratis.
Værktøjer og praktiske råd
Der findes flere gratis open source-værktøjer til belastningstest, fx k6, Apache JMeter og Locust. De kan alle køre brugerrejser med pauser, stige i trin og vise percentiler og fejlrate. Vælg det, din udvikler kender. Et par råd uanset værktøj:
- Kør testen fra en anden maskine end serveren, ellers måler du testværktøjet og ikke shoppen.
- Brug forskellige produkter og søgeord i scenariet. Hvis alle virtuelle kunder køber det samme produkt, rammer testen en cache, rigtige kunder ikke rammer.
- Slet testordrerne og tøm cachen bagefter, så kopien er klar til næste test.
- Gem resultaterne med dato i din driftsdokumentation. Næste år kan du sammenligne og se, om shoppen er blevet hurtigere eller langsommere.
Hvad en time med langsom eller nedlagt shop koster i kroner, og dermed hvor meget det er værd at bruge på at hæve loftet, står i guiden om, hvad nedetid koster. Hele tidsplanen frem mod kampagnen – også hvornår testen passer ind – står i guiden om Black Friday hosting.
Læs også
- Hub: Driftshåndbogen
- Black Friday hosting: sådan undgår du, at webshoppen går ned
- Hvad koster nedetid? Regn tabt omsætning ud for din webshop
- Kapacitetsplanlægning: er dit webhotel klar til morgendagens kampagne?
- Langsom checkout i WooCommerce
- Langsom WooCommerce med mange produkter
- WooCommerce hosting hos Hostious – staging fra Woo StartUp og dansk support døgnet rundt
Ofte stillede spørgsmål om belastningstest
Hvad er en belastningstest af en webshop?
En belastningstest sender mange virtuelle kunder igennem webshoppen samtidig efter et realistisk mønster – forside, produktsider, søgning, kurv og checkout – og måler svartid og fejl, mens belastningen stiger. Formålet er at finde det punkt, hvor shoppen bliver langsom eller begynder at fejle.
Må jeg belastningsteste min webshop, mens den er åben?
Kun efter aftale med hostingudbyderen og helst ikke. En test kan ligne et angreb, blive blokeret eller gøre shoppen langsom for rigtige kunder. Test på en kopi af shoppen med samme plugins og data, og aftal tidspunktet med udbyderen.
Hvor mange samtidige brugere skal jeg teste med?
Regn fra dine ordrer: forventede ordrer i den travleste time divideret med konverteringsraten giver besøg pr. time. Gang med besøgslængden i minutter og del med 60 for at få samtidige besøgende. Test derefter til mindst det dobbelte.
Hvornår skal jeg lave en belastningstest før Black Friday?
Tre til fire uger før, så der er tid til at rette det, testen finder, og teste igen, før ændringsstoppet går i gang. I 2026 betyder det en test i slutningen af oktober eller første uge af november.
Hvem tilbyder hosting med staging til belastningstest?
Hostious tilbyder WooCommerce hosting med staging fra Woo StartUp til 239 kr./md. ekskl. moms, så du kan teste på en kopi af shoppen. Webshoppen kører med egen database, Redis object cache, LiteSpeed og NVMe, og dansk support følger med på serveren, når du har aftalt testen.
Udgivet 3. november 2026Opdateret 3. november 2026