Langsom webshop i december – hvad gør du her og nu?

I vores arbejde med hastighedsoptimering af webshops er december altid sandhedens time. Alt det, der “gik an” i september, falder fra hinanden, når du ganget det med juletrafik, kampagner og utålmodige brugere. Normalt snakker jeg gerne om arkitektur, langsigtede løsninger, refaktorering og Core Web Vitals, men det er ikke det, du har brug for lige nu. Du har brug for akut brandslukning – ting du kan gøre i dag, uden at smadre checkout eller vælte hele sitet.

Derfor får du her en nøje prioriteret nødplan, som kombinerer to ting:

• forklarende tekst, så du forstår, hvorfor du gør tingene
• konkrete lister, så du kan sætte flueben og faktisk komme videre

Målet er ikke at gøre din shop perfekt – målet er at gå fra “vi bløder” til “den kan holde til resten af december”.

Trin 1: Er din shop død – eller bare tung og stresset?

Før du begynder at skrue vildt på billeder, scripts, cache og CDN, skal du kende diagnosen. Der er stor forskel på, om din webshop reelt er ved at køre i seng på serverniveau, eller om den “bare” er blevet for tung i frontend. Det føles ens for kunden (“det virker ikke”), men teknisk set sender det dig ned ad to ret forskellige spor.

Lav først et simpelt reality check:

• Åbn webshoppen i et inkognitovindue (ingen cookies, ingen admin, ingen gamle sessions).
• Besøg forsiden, en stor kategoriside, en produktside og checkout.
• Læg mærke til:
  • Får du 5xx-fejl, gateway timeouts eller sider der aldrig svarer?
  • Eller loader siderne – bare langsomt og hakkende?

Hvis du ser 500/502/504-fejl og timeouts, er det ofte tegn på, at serveren ikke kan følge med: CPU er i knæ, database hænger, PHP workers står i kø, eller en integration opfører sig ekstremt langsomt. I de situationer kan du optimere billeder alt det, du vil – det hjælper ikke nok i sig selv. Så handler det i stedet om at få fat i din host og eventuelt skrue midlertidigt ned for trafikken, indtil I har fundet en løsning.

En enkel mini-tjekliste til den vurdering:

• Du har et serverproblem, hvis:
  • Siderne ofte slet ikke loader.
  • Du får 5xx eller gateway timeouts flere gange i træk.
  • Admin også er utrolig sløv eller utilgængelig.
• Du har primært et performanceproblem i frontend, hvis:
  • Siderne loader hver gang, men føles tunge.
  • Det især er forsiden, kategori og produktvisning, der sejler.
  • Checkout virker, men føles langsom og træls.

I praksis ender jeg tit med begge spor: lidt server-flaskehals og en frontend, der er blevet oppustet over tid. Men at kende den dominerende fejl retter din opmærksomhed de rigtige steder – og sparer dig en masse tid.

Trin 2: Akut kontakt til hosting – når huset brænder

Hvis du har konstateret, at der er reelle nedbrud eller nær-nedbrud, skal du ikke starte med at rode i tema, CSS og billeder. Du skal starte med din host. De kan se ressourceforbrug, logs og køer på en måde, du ikke kan fra WordPress-backend eller lignende.

Her hjælper det at være specifik, når du henvender dig. I stedet for at skrive “min shop er langsom”, så skriv noget i stil med:

• “Vi har markant mere trafik pga. decemberkampagner – oplever 5xx-fejl.”
• “Checkout fejler periodisk, og vi ser gateway timeouts.”
• “Har I mulighed for midlertidigt at skrue op for CPU, RAM eller antallet af PHP workers her i december?”

Ofte kan hosting gøre én eller flere af disse ting ret hurtigt:

• opgradere din plan midlertidigt
• åbne for flere PHP-processer, så flere brugere kan betjenes samtidigt
• pege på konkrete flaskehalse (en tung database-query, et plugin der æder ressourcer, en logfil der er ved at eksplodere)

Imens hosting undersøger deres del, giver det mening at skrue en smule ned for de mest ekstreme trafikspidser:

• pauser du et enkelt nyhedsbrev eller sænker budgettet på den værste kampagne i nogle timer, kan det være nok til, at serveren lige får luft.
• målet er ikke at slukke for alt – men at undgå, at du hælder mere benzin på bålet, mens I stadig forsøger at få flammerne under kontrol.

Trin 3: Sluk for det tunge julepynt (funktioner) – hurtigt og nådesløst

Når vi bliver kaldt ind til en langsom webshop i december, er der et mønster, der går igen: forsiden og de vigtigste kategori-sider er blevet pyntet som et stormagasin i november. Slider på slider, video, animationer, fancy produkt-karusseller og personlige anbefalinger overalt. Det er alt sammen meget flot, men teknisk set er det ofte noget svineri, når 10x flere brugere rammer det samme layout.

Her er det, jeg gør i praksis, når det skal gå stærkt:

1. Fjerner eller slår sliders fra
   De fleste sliders kombinerer flere store billeder, ekstra JavaScript og ofte lazy load-logik, der ikke er lavet særlig elegant. Jeg sætter én statisk hero med ét billede og én klar besked – det konverterer typisk lige så godt, og loadtiden falder tydeligt.
2. Slår video i hero fra
   Video-baggrunde ser smarte ud på en designpræsentation, men når en træt mobil på 4G skal hente dem juleaften, er det en katastrofe. I december konverterer et godt, statisk billede langt bedre end et fedt video-loop, der aldrig når at loade, før brugeren er væk.
3. Deaktiverer tunge dynamiske sektioner
   Sektioner som “Andre købte også”, “Udvalgt til dig” og avancerede gaveguides, der kræver ekstra databasekald og AJAX, står ofte og trækker tænder ud. Jeg fjerner dem fra forsiden og de største kategorier – eller forenkler dem markant.

Konkrete steder du kan kigge og klikke ting fra:

• Tema-indstillinger (ofte kan du slå slider, video og visse moduler fra uden kode).
• Page builder (Elementor, Gutenberg, WPBakery osv.), hvor sektioner kan deaktiveres pr. side.
• Widgets og moduler på forsiden og kategori-templates.

Hvis du vil gøre det ekstra systematisk, kan du tænke i:

• Behold:
  • hero med ét billede og klar CTA
  • simple produkt-grids
  • få, tydelige kampagnebokse
• Sluk midlertidigt for:
  • sliders med flere slides
  • video-baggrunde
  • avancerede product carousels og dynamiske lister
  • parallax-animationer og alt det visuelle lir

Det kan godt føles lidt som at rive julepynten ned midt i festen, men hvis valget står mellem en mindre flashy forside der virker – og en vildt flot forside der ikke gør – så er svaret rimelig klart.

Trin 4: Eksterne scripts – den usynlige performance-dræber

Når vi laver hastighedsanalyser på webshops, ender vi ofte med at sidde i netværkspanelet og tælle eksterne scripts. Det er ikke unormalt at se 10–20 forskellige kald til andre domæner: tracking, heatmaps, chat, widgets, AB-tests, sociale plugins og alt muligt, som løbende er blevet skruet på i marketing-projekter. Hver for sig virker de uskyldige, men tilsammen gør de en stor forskel – især på mobil.

Typiske eksterne scripts, der er værd at kigge på:

• heatmap- og recordingsværktøjer (Hotjar, Clarity, Crazy Egg osv.)
• AB-test-platforme og personalisering
• chat-widgets (Intercom, Zendesk, Drift osv.)
• sociale feeds (Instagram-wall, Facebook-fansider)
• kundefeedback, popups og “gamification”-widgets

I december er mit råd meget simpelt: du har ikke råd til at alt det kører på alle sider.

En praktisk måde at rydde op på:

• Lav to kolonner på et papir eller i et dokument:
  • “Skal køre for at vi kan sælge og måle salg”
  • “Nice to have – kan slukkes midlertidigt”
• I “skal køre” ligger typisk:
  • Google Analytics / Matomo
  • én eller to nøgle-pixels (fx Meta + Google Ads)
  • scripts til cookie-samtykke, hvis nødvendigt juridisk
• I “nice to have” ligger ofte:
  • heatmaps og recordings
  • AB-tests og eksperimenter
  • chat (kan evt. nøjes med kundeservice-side)
  • sociale walls og små gimmicks

Det konkrete træk i december er:

• sluk alle værktøjer i “nice”-kolonnen midlertidigt
• behold kun de absolut nødvendige tracking-scripts
• sørg for at du stadig kan måle omsætning, men ikke meget mere end det

Og igen: du kan altid tænde det hele igen i januar. Men hvis din shop i december ikke kan trække både salg og 15 forskellige analyseværktøjer, så prioriterer du salget – ikke analysen.

Trin 5: Checkout er helligt – men stadig et sted du kan rydde op

Checkout er det mest følsomme sted i hele systemet. Det er her alle integrationer kommer sammen: betalingsgateway, fragtmoduler, lager, rabatkoder, kundeloyalitet, alt. Det er også det sidste sted, kunden har lyst til at opleve sløvhed, fejl eller mærkeligt opførsel, for det føles direkte utrygt. I december er checkout det sidste sted, du eksperimenterer frit – men du kan godt gøre en del, uden at pille ved de farlige ting.

Jeg plejer at tænke på checkout som et “støjsvagt rum”. Det vil sige:

• ingen popups og exit-intent på checkout
• ingen chat-widgets der lægger sig over vigtige felter
• ingen ekstra marketing-widgets, der skal “inspirere” kunden
• ingen tunge scripts, som reelt ikke har noget med checkout at gøre

Hvis du har mulighed for det, kan du lave en regel i dit tema eller performance-plugin, der siger:

• følgende scripts må ikke loades på /cart og /checkout
• chat og heatmaps må ikke vises på checkout
• tracking kan være lidt “slankere” på checkout end på resten af sitet

Rent praktisk kan du teste checkout ved at:

• tage mobilen, køre på 4G og gennemføre en ordre som en almindelig kunde
• lægge mærke til, om noget flakker, hopper, blinkende popups, fejlbeskeder og andet lir
• teste både godkendte og bevidst “forkerte” kort, så du ser, hvordan fejl håndteres

Målet er, at checkout i december føles rolig, fokuseret og teknisk stabil – også selv om resten af din shop lige har været igennem et mini-jordskælv af optimeringer.

Trin 6: Billederne – hvor du næsten altid henter store, hurtige gevinster

Hvis jeg kun måtte røre én ting på en shop i december, ville jeg vælge billederne. Hver. Eneste. Gang. I praksis er billeder næsten altid den største komponent i den samlede datamængde – især når der er tale om kampagnesites, juleuniverser og produktlister med mange billeder. Og det er også det område, hvor du kan gøre mest på kortest tid uden at ændre kode.

Sådan angriber jeg det i praksis:

1. Find de største billeder på de vigtigste sider
   • Åbn forsiden i Chrome DevTools → Network → filtrer på Img og sorter efter størrelse.
   • Gør det samme på:
     • din største julekategori
     • en typisk produktside
   • Skriv de største filer ned: hero-bannere, kategoribilleder, store kampagnegrafikker.
2. Tjek, om de er overdimensionerede
   • Brug “Inspect” i browseren og se, hvor stort billedet faktisk vises.
   • Hvis billedet er 3000 px bredt, men vises i 1200 px, kan du uden videre skære det ned.
3. Lav et hurtigt, men bevidst optimeringsflow
   • Skaler hero-bannere ned til fx 1600 px bredde – det er nok til de fleste layouts.
   • Skaler produktbilleder ned til noget i stil med 800–1200 px.
   • Eksportér i JPEG eller WebP med en komprimering, der giver:
     • 150–400 KB pr. hero-billede
     • 50–200 KB pr. produktbillede

Du behøver ikke perfektion. I en decembersituation er det langt vigtigere, at siderne går fra fyldt med 1–2 MB-billeder til noget mere beskedent, end at du undgår hver eneste lille komprimeringsartefakt.

En lille “hitliste” til billed-optimering i julemåneden:

• forsiden – specielt hero og kampagne-sektioner
• jule-/gave-kategorier med meget trafik
• produktsider for top-sellere
• blogindlæg eller landingssider, der bruges i kampagner

Hvis du har et billede-plugin, der understøtter WebP og responsive billeder (srcset), kan du aktivere det – men igen: det vigtigste er, at de værste syndere bliver slanke, ikke at du når det perfekte setup på 24 timer.

Trin 7: Cache – få serveren til at lave mindre af det samme arbejde

Når funktioner og billeder er trimmede, er næste naturlige step at sørge for, at serveren ikke skal opfinde den dybe tallerken for hver eneste sidevisning. Det er her, cache kommer ind. Mange frygter lidt cache, fordi de har prøvet, at “det hele gik galt, og kurven virkede ikke”, men hvis du holder dig til nogle klare principper, kan du skrue ret aggressivt op uden at smadre webshoppen.

Grundreglen er:

Cache alt, hvad der er nogenlunde statisk – og undgå at cache det, der er personligt eller afhænger af sessionen.

Det betyder i praksis:

• Gode kandidater til cache:
  • forsiden
  • kategorisider
  • produktlister
  • produktsider
  • landingssider for kampagner
• Dårlige kandidater (som du typisk undtager):
  • kurv
  • checkout
  • “Min konto”, login, ordreoversigt
  • sider med brugerafhængige priser eller indhold

I WordPress/WooCommerce-land vil du typisk bruge:

• server-side cache hos hosten (eller en proxy som Varnish)
• et cache-plugin som LiteSpeed Cache, WP Rocket eller lignende
• browser-cache på statiske filer (billeder, CSS, JS, fonte)

De vigtigste ting at få styr på i december:

• at forsiden, kategorier og produktsider faktisk bliver cachet ordentligt for anonyme brugere
• at kurv og checkout ikke cachet som HTML
• at browser-cache er sat sådan op, at statiske filer ikke hentes forfra hele tiden

Og så en vigtig disciplin: hver gang du ændrer noget stort (tema, layout, scripts), så:

• ryd cachen
• preload de vigtigste sider (enten via plugin eller manuelt)
• test forsiden og checkout bagefter

På den måde undgår du, at den første bølge af julekunder får en helt “kold” shop, samtidig med at du slipper for spøgelsesfejl fra gamle HTML-versioner.

Trin 8: CDN – lad nogen andre tage nogle af tæskene

Når du først er oppe i et vist trafikniveau – og det er du ofte i december – kan det betale sig at lade et Content Delivery Network (CDN) håndtere noget af belastningen. Du behøver ikke at gå fuld enterprise for at få effekt; selv en relativt simpel integration kan aflaste din server og give hurtigere loadtider for brugerne.

Det CDN gør for dig i praksis:

• gemmer statiske filer (billeder, CSS, JS, fonte) på edge-servere rundt omkring
• leverer dem direkte derfra, så de ikke skal hentes fra din egen server hver gang
• aflaster din origin i forhold til både båndbredde og antal requests

Selv hvis du primært har danske kunder, kan en CDN-løsning stadig give noget, fordi filerne caches tættere på brugeren og ofte ligger på hurtige backbone-forbindelser. I praksis betyder det, at din egen server kan fokusere på det, den er god til (dynamisk indhold, checkout-logik), mens CDN’et tager sig af alt det tunge statiske.

I december vil jeg typisk anbefale følgende praksis:

• Start med at bruge CDN kun til billeder, CSS og JS.
• Behold HTML-rendringen på din origin-server.
• Lad CDN’et selv styre cache-tider på de fleste statiske filer, og finjuster først senere.

Hvis din host allerede har CDN-støtte bygget ind, er det ofte bare et spørgsmål om at slå en knap til. Hvis ikke, kan du overveje en løsning som Cloudflare, men vær opmærksom på, at du så også flytter DNS og en del af sikkerhed/Firewall over til en ny platform. Det kan sagtens lade sig gøre, men midt i december skal du være lidt ekstra koncentreret, når du piller ved DNS.

Hvornår er det tid til at tænke længere end brandslukning?

Lad os være ærlige: hvis du læser det her i december og kan genkende situationen fra sidste år, og året før det, så er problemet ikke bare “uh, vi fik lidt mere trafik end forventet”. Så har du sandsynligvis en shop, der generelt er bygget på et fundament, der er lige skrøbeligt nok, når den bliver presset. Det kan være hosting, tema, måde du bruger plugins på, arkitektur af integrationer – ofte en kombination.

Det gode ved brandslukningen er, at du får noget luft nu og kan redde salget hjem. Men du får også data og erfaringer at arbejde videre med:

• Hvilke sider kollapsede først?
• Var det primært CPU, database eller eksterne integrationer, der gav op?
• Hvilke scripts og funktioner viste sig at være unødvendige, når det kom til stykket?
• Hvor meget bedre blev det, da du havde optimeret billeder og cache?

Alle de ting bør du tage med til et januar-projekt, hvor:

• du kan teste nye hosting-opsætninger uden at miste en hel juleomsætning
• du kan opdatere tema, rydde op i plugins og måske refaktorere noget kode
• du kan lave planlagte lasttests og performance-målinger med ro i maven

Men det er januar. Lige nu gælder det om at komme igennem december uden at blive helt skaldet af at rive dig selv i håret.

Kort nød-tjekliste (til skrivebordet eller Notion)

Bare for at samle det mest akutte i én overskuelig blok, som du reelt kan arbejde efter:

1. Diagnose og host

2. Funktioner og scripts

3. Billeder

4. Cache og CDN

FAQ: Hurtige svar når pulsen er høj