Hvorfor en Black Friday-webshop skal testes nu og ikke i november
Black Friday falder i 2026 den 27. november, og Cyber Monday følger den 30. november. For mange webshops er det årets travleste døgn, og det er samtidig det døgn, hvor fejl koster mest. En side, der er langsom i fem minutter kl. 00.05, når nyhedsbrevet er sendt, kan æde en stor del af kampagnens værdi.
Problemet er, at webshoppen sjældent går ned på den måde, man forventer. Forsiden klarer sig fint, fordi den ligger i cache. Det er kurven, lagerkaldet, fragtberegningen eller betalingsvinduet, der bliver flaskehalsen, fordi de skal have fat i databasen eller et eksternt system for hver eneste kunde.
Oktober er det rigtige tidspunkt at teste. Så er der tid til at rette det, testen finder, og til at teste igen. Kommer testen i midten af november, når I kun at konstatere problemet.
Hvad en belastningstest egentlig måler
En belastningstest simulerer mange samtidige besøgende, der opfører sig som rigtige kunder: de lander på en kampagneside, søger, lægger varer i kurven og går til kassen. Målet er at finde ud af, hvor mange samtidige kunder shoppen kan klare, før oplevelsen bliver dårlig, og hvad der går i stykker først.
De tal, I skal holde øje med:
| Måling | Hvad den fortæller | Tommelfingerregel |
|---|---|---|
| Svartid (95. percentil) | Hvor langsom siden er for de 5 % langsomste kald | Sammenlign med normal drift, ikke med gennemsnit |
| Fejlrate | Andel af kald, der ender med fejl eller timeout | Bør være tæt på nul under forventet belastning |
| Gennemstrømning | Antal ordrer eller sidevisninger pr. minut | Skal matche jeres kampagnemål med margin |
| Ressourceforbrug | CPU, hukommelse og databaseforbindelser på serveren | Viser, hvilken del der mættes først |
| Eksterne kald | Svartid fra betaling, fragt og lager | Afslører afhængigheder, I ikke selv styrer |
Brug den 95. percentil frem for gennemsnittet. Et gennemsnit på et sekund kan skjule, at hver tyvende kunde venter otte sekunder på kurven, og det er netop dem, der forlader shoppen.
Sådan tester I webshoppen trin for trin
- Sæt et mål. Tag sidste års spidsbelastning eller jeres forventede kampagnetrafik, og læg en margin oven i. Uden et tal ved I ikke, hvornår testen er bestået.
- Beskriv de vigtigste kunderejser. Typisk fire eller fem: landing fra nyhedsbrev, søgning, produktside, kurv og checkout. Fordel trafikken realistisk, for de fleste besøgende køber ikke.
- Test i et miljø, der ligner produktion. Et testmiljø med samme serverstørrelse, samme plugins og en kopi af produktkataloget. Test ikke mod den rigtige betalingsløsning, men brug udbyderens testtilstand.
- Øg belastningen gradvist. Start lavt, og skru op trin for trin, så I kan se præcis, hvornår svartiden begynder at stige.
- Hold spidsen i et stykke tid. Et kort udsving klarer de fleste systemer. Det er efter 20-30 minutters vedvarende tryk, at køer og låste databaserækker viser sig.
- Ret og test igen. Første test finder næsten altid noget. Anden test viser, om rettelsen virkede.
Værktøjer som k6, JMeter og Locust bruges ofte til den slags tests. Valget af værktøj er mindre vigtigt end, at scenarierne ligner jeres rigtige kunder. En struktureret belastningstest med rapport giver jer både tallene og en prioriteret liste over rettelser.
Typiske flaskehalse i en webshop
Når testen er kørt, ser billedet ofte ens ud på tværs af platforme:
- Kurv og checkout omgår cachen. Sider med kundespecifikt indhold kan ikke caches på samme måde som produktsider, så hver kunde rammer databasen direkte.
- Plugins og apps, der kalder eksterne tjenester. Et fragtmodul, der henter pakkeshops fra PostNord eller GLS for hver visning, kan blive langsomt, når tusind kunder gør det samtidig.
- Lagersynkronisering. Et ERP- eller lagersystem, der opdaterer lagertal hvert minut, kan låse tabeller i det øjeblik, trafikken topper.
- Søgning. Standardsøgningen i mange platforme er ikke bygget til mange samtidige forespørgsler.
- Billeder. Store produktbilleder uden CDN belaster serveren og mobilforbindelsen hos kunden.
Kører I Shopify, bærer platformen selv hostingen, men apps, scripts fra tredjepart og integrationer til lager og regnskab kan stadig være svage led. Kører I WooCommerce eller en anden selvhostet løsning, er serveren, databasen og cachen jeres eget ansvar.
Test hele kæden, ikke kun forsiden. En webshop er aldrig stærkere end det langsomste system, den venter på under checkout, og det er ofte et eksternt kald, I ikke har tænkt over.
Et realistisk eksempel
En dansk webshop med sportsudstyr på WooCommerce forventer omkring fire gange så mange samtidige besøgende som en normal fredag. Første test viser, at produktsiderne klarer sig fint, men at kurven begynder at give timeouts ved omkring halvdelen af målet. Årsagen er et plugin til gavekort, der slår op i en tabel uden indeks ved hver visning af kurven.
Efter rettelsen, et ekstra lag objektcache og en midlertidig opgradering af databaseserveren i kampagneugen, består anden test med margin. Desuden flyttes lagersynkroniseringen fra hvert minut til hvert femte minut i kampagneperioden.
Tjekliste til ugen før Black Friday
- Frys ændringer: ingen nye plugins, apps eller temaopdateringer i kampagneugen.
- Aftal, hvem der overvåger shoppen i de første timer, og hvem der kan træffe beslutninger.
- Hav en simpel vedligeholdelsesside klar, hvis noget skal lukkes kortvarigt.
- Tjek, at backup er kørt og kan gendannes, før kampagnen starter.
- Informer betalings- og fragtpartnere, hvis I forventer markant mere trafik end normalt.
- Skalér serveren op i god tid, hvis jeres hosting kræver det, og husk at skalere ned igen bagefter.
Klar til næste kampagne
En belastningstest er ikke kun til Black Friday. Resultaterne kan bruges før jul, udsalg og store kampagner hele året. Har I brug for hjælp til både test og rettelser, kan vi teste og optimere jeres webshop på afstand. Læs også, hvordan vi arbejder med detail og e-handel, eller send os en kort beskrivelse af jeres platform og forventede trafik.
Apply-redaktionen
Udvikling