Artikel

Annonce – sponsoreret indhold

Hvorfor er din webshop langsom?

Få overblik over de mest almindelige årsager til en langsom webshop - fra billeder og scripts til hosting - og hvad du selv kan optimere.

Person ved skrivebord med flere skærme, der viser webanalyse og indlæsningsikoner for en langsom hjemmeside.
Illustration. Foto lavet med AI — ikke dokumentation.

Hvorfor er min webshop langsom? Oftest fordi siden læsser mere kode, flere billeder og flere eksterne scripts, end den har brug for, og fordi serveren bruger for lang tid på at svare. Typiske årsager er mange plugins, et tungt tema, uoptimerede billeder, tredjepartsscripts og manglende caching. Det rammer både konverteringsraten og dine placeringer i Google, fordi hastighed indgår i Core Web Vitals. Her får du de konkrete syndere, de tjek du selv kan lave, og et pejlemærke for, hvornår det ikke længere nytter at lappe på den eksisterende løsning.

Start med kodegrundlaget

Mange webshops bliver langsomme allerede ved opsætningen. Færdige platforme og plugin-tunge CMS-løsninger er bygget til at kunne alt for alle, og din webshop arver derfor kode til funktioner, du aldrig bruger. De hyppigste syndere er:

  • Oppustet plugin-kode: Hvert plugin kan tilføje egne CSS- og JavaScript-filer, ofte på alle sider, også dem hvor funktionen slet ikke bruges. Et slider-plugin kan fx loade sine filer på kassesiden. Plugins stiller desuden ekstra databaseforespørgsler, hver gang en side bygges.
  • Uoptimerede temaer: Multifunktionelle temaer leveres med sidebyggere, animationsbiblioteker og skrifttyper i mange varianter. Browseren skal hente og fortolke det hele, før kunden ser noget brugbart.
  • Tunge scripts: Chat-widgets, heatmaps, annonce-pixels, anmeldelsesmoduler og flere analyseværktøjer oveni hinanden blokerer ofte hovedtråden i browseren. Det forsinker, at siden reagerer på klik.
  • Dårlig serverkonfiguration: Billig delt hosting, gammel PHP-version, manglende komprimering og ingen server-caching giver lang svartid, før siden overhovedet begynder at indlæse.

Fællesnævneren er, at problemet sidder i fundamentet og ikke i en enkelt indstilling. Derfor vælger nogle virksomheder at gå en anden vej. JP-WEBDesign bygger fx manuelt kodede sites fra bunden i PHP, Tailwind CSS og Vue.js uden de standardskabeloner og tunge plugins, som ellers skaber “kodesuppe”. Pointen er, at siden kun indeholder den kode, den faktisk skal bruge. Det er en reel mulighed, hvis du allerede har prøvet at optimere uden at nå i mål.

Før du tager stilling til det, bør du dog vide, hvor din egen flaskehals ligger. Hvis du er i tvivl om, om langsomheden også trækker dine placeringer ned, kan 7 fejl der saboterer din webshops placering i Google give et bredere overblik over andre typiske SEO-problemer.

Sådan måler du, hvad der faktisk er galt

Gæt er dyre. Start med tre gratis værktøjer:

  1. PageSpeed Insights: Viser både laboratorietest og rigtige brugerdata, hvis din webshop har nok trafik. Test både forsiden, en kategoriside, en produktside og kurven. Det er sjældent de samme sider, der er langsomme.
  2. Google Search Console: Rapporten for Core Web Vitals grupperer URL’er med samme problem. Her kan du se, om fejlen rammer hele skabelonen eller kun enkelte sider.
  3. Chrome DevTools (fanerne Network og Performance): Her ser du, hvilke filer der fylder mest, hvilke der blokerer visningen, og hvor længe serveren er om at svare.

Kend de tre Core Web Vitals. LCP måler, hvornår det største synlige element er indlæst, og en god værdi regnes typisk for under 2,5 sekunder. INP måler, hvor hurtigt siden reagerer på brugerens handlinger, hvor en god værdi typisk ligger under 200 millisekunder. CLS måler, om indholdet hopper rundt under indlæsning, og bør typisk ligge under 0,1.

Se også på TTFB, altså tiden til serverens første svar. Er den høj, hjælper det ikke at komprimere billeder. Så ligger problemet i hosting, database eller manglende server-caching.

Billeder, caching og scripts: de tre tjek, du selv kan lave

Billeder

Uoptimerede billeder er den hyppigste årsag til en dårlig LCP-score. Tjek følgende:

  • Bruger du moderne formater som WebP eller AVIF i stedet for store JPEG- og PNG-filer?
  • Er billederne skaleret til den størrelse, de vises i? Et produktbillede i fuld kameraopløsning, der vises som et lille thumbnail, er spild.
  • Bruger du loading="lazy" på billeder under skærmbunden, men ikke på det store hovedbillede øverst? Lazy loading af det øverste billede forsinker LCP.
  • Har alle billeder angivet bredde og højde? Ellers hopper layoutet, og CLS stiger.

Caching

Uden caching bygger serveren siden forfra til hver besøgende. Tjek, at du har browser-caching for statiske filer, server- eller sidecaching for sider, der ikke er personlige, og gerne et CDN, hvis dine kunder bor langt fra serveren. Komprimering med Gzip eller Brotli og en nyere PHP-version hører også med. På Apache-servere styres meget af dette via .htaccess-filen, og en fejlkonfigureret fil kan i sig selv koste hastighed.

Scripts

Lav en liste over alle scripts, der loader, og spørg om hvert enkelt: Bruger vi det aktivt? Skal det køre på alle sider? Kan det indlæses senere? Fjern gamle pixels fra annoncekanaler, du ikke længere bruger. Udskyd chat-widgets, til brugeren interagerer. Tjek, at du ikke har flere værktøjer, der måler det samme. Hvert script du fjerner, forbedrer typisk INP.

Hvornår er langsomheden indbygget i løsningen?

Du kan optimere længe uden at komme i mål, hvis fundamentet er problemet. Det er ofte tilfældet, når:

  • du har fjernet scripts og komprimeret billeder, men TTFB stadig er høj, fordi platformen laver mange databasekald pr. side,
  • funktioner, du har brug for, kræver et plugin, som tilføjer tung kode på hele sitet,
  • en opdatering af et plugin eller tema jævnligt ødelægger det, du har finjusteret,
  • dit tema indeholder en sidebygger, du ikke kan slippe af med uden at bygge designet om,
  • du har særlige behov som integration til økonomisystem, fragt eller lagerstyring, der løses med flere lag af tilføjelser i stedet for ren integration.

I de situationer er det værd at overveje, om en skræddersyet løsning er mere holdbar. Vi har gennemgået forskellene mere indgående i Skræddersyet webshop eller standardplatform, sådan vælger du.

Hvad får du ud af manuelt kodet i praksis?

En manuelt kodet webshop bygges op omkring dine faktiske behov. Hos JP-WEBDesign betyder det bl.a. en modulær struktur, hvor globale elementer som topbar og navigation ligger i centrale filer, og MariaDB-databaser til større systemer og webshops. Der kan kodes skræddersyede API-integrationer til fx e-conomic, CRM, fragtløsninger og betalingsgateways. Ingen plugins skal indlæses “for en sikkerheds skyld”, og du bestemmer selv, hvilke scripts der kommer ind.

Der er også ulemper, som du bør veje ærligt:

  • Du er afhængig af en udvikler til ændringer, i stedet for selv at kunne installere et plugin.
  • Startomkostningen er normalt højere end at sætte en standardplatform op.
  • Du skal have en tydelig kravspecifikation, så du får bygget det, du reelt har brug for.
  • Kvaliteten afhænger af udviklerens håndværk. Stil derfor krav om dokumentation og referencer.

Optimere eller skifte? Pejlemærker til beslutningen

Brug disse spørgsmål til at afgøre, hvilken vej der er mest rentabel for din webshop.

Optimer den eksisterende webshop, hvis:

  • problemet primært er billeder, scripts og manglende caching,
  • TTFB er rimelig, og kun enkelte sider trækker scoren ned,
  • dit setup er forholdsvis enkelt, og du kan klare dig med få plugins,
  • dit budget ikke rummer en ny løsning lige nu.

Overvej en fuldt kodet løsning, hvis:

  • du har optimeret grundigt, og scoren stadig er dårlig på tværs af hele sitet,
  • væsentlig funktionalitet kun kan leveres via tunge tilføjelser,
  • du alligevel står over for et redesign eller en større ombygning,
  • du har komplekse integrationer, hvor standardløsningen bliver en lappeløsning,
  • dårlig hastighed koster dig målbart i kampagnetrafik, konverteringer eller placeringer.

Et praktisk råd: Dokumentér dine nuværende målinger for LCP, INP, CLS og TTFB på nøgleskabeloner, før du ændrer noget. Så kan du måle effekten af optimeringen, og du kan stille konkrete krav til målbar hastighed, hvis du beder om tilbud på en ny løsning.

Opsummeret ligger svaret sjældent i én fejlindstilling. Ofte er det en kombination af tung kode, for mange scripts og en svag serveropsætning. Det første kan du ofte rette selv. Hvis fundamentet er kernen i problemet, er en skræddersyet, manuelt kodet løsning den mest holdbare vej, så længe du er indstillet på en højere startinvestering og tættere samarbejde med en udvikler.

Næste opgave?

Ordrebidrag: hvad er der tilbage af en ordre?Produktdata: gennemgå fem produkter ad gangenTjek en produktside med kundens spørgsmål