Hvorfor er min hjemmeside langsom — og hvad det koster dig

Du åbner din egen hjemmeside. Den er der med det samme. Så må den vel være hurtig nok?

Nej. Din browser har gemt hele siden fra sidst. Din kunde har aldrig været der før, sidder på mobil ude på en byggeplads, og venter. Det er hendes oplevelse, der afgør, om hun ringer — og det er den, du aldrig selv får at se.

Her er de seks årsager, vi støder på igen og igen, hvordan du måler det rigtigt, og hvad du kan rette i dag uden at hyre nogen.

"Langsom" er ikke en fornemmelse — det er tre tal

Google måler sideoplevelse på tre værdier, kaldet Core Web Vitals. Du behøver ikke kunne dem udenad, men du skal kende dem, når du ser dem i en rapport:

• LCP — hvornår det største element på siden er synligt. Typisk dit hero-billede eller din overskrift. Mål: under 2,5 sekunder.
• INP — hvor lang tid der går fra et klik eller tryk, til der sker noget synligt. Mål: under 200 millisekunder. Denne afløste den tidligere FID-måling i 2024.
• CLS — hvor meget indholdet hopper rundt, mens siden loader. Det er den, der får dig til at ramme forkert knap. Mål: under 0,1.

Hastighed indgår i Googles rangering, men lad være med at gøre det til hovedargumentet — relevans vejer tungere. Den rigtige grund er mere direkte: en besøgende, der venter, er en besøgende, der lukker fanen. Og hvis du betaler for annoncer, betaler du for det klik uanset om siden nåede at loade.

De 6 typiske årsager

1. Billeder lagt direkte op fra kameraet

Det er langt den hyppigste. Et foto på 4-6 MB bliver lagt op, og CSS skalerer det ned til 400 pixels bredde i browseren. Men browseren henter hele filen alligevel — hele det oprindelige billede skal downloades, før det kan vises småt.

Løsningen: skaler billedet ned til den bredde, det faktisk vises i, gem det som WebP i stedet for JPEG, og sæt altid width og height på billedet. Det sidste er gratis og fjerner en stor del af de layout-hop, der ødelægger CLS.

2. Et helt bibliotek for at vise tolv ikoner

Et konkret eksempel fra vores egen side. 22 af vores sider hentede et komplet ikonbibliotek på 402 KB — for at kunne vise 31 ikoner. Vi byggede en udgave med præcis de ikoner, der bliver brugt: 5,7 KB. Identisk udseende, 396 KB mindre at hente på hvert eneste sidevisning.

Det samme mønster går igen med skrifttyper, animationsbiblioteker og slider-plugins: hele værktøjskassen bliver hentet for at bruge ét værktøj. Det er sjældent svært at rette — det er bare noget, ingen har kigget efter.

3. Effekter der kører hele tiden

Custom musemarkører, partikelspor, animerede baggrunde. De ser flotte ud i en demo, men de koster ved hver eneste musebevægelse og ved hvert eneste billede på skærmen — permanent, hele besøget igennem.

Tal fra vores egen side, målt før og efter vi fjernede en custom cursor og et partikelspor: 800 simulerede musebevægelser kostede 26,1 millisekunders arbejde på hovedtråden før — og 3,2 millisekunder efter. Det er forskellen på en side, der føles skarp, og en, hvor markøren slæber bagefter.

4. Skrifttyper der blokerer teksten

Henter du skrifttyper fra Google Fonts, skal browseren først slå et fremmed domæne op og oprette forbindelse, før det første bogstav kan tegnes. På en langsom mobilforbindelse er det let et halvt sekund, hvor brugeren ser en blank side.

Løsningen er at lægge skrifttypen på dit eget domæne som woff2, bruge font-display:swap, så teksten vises i en reserveskrift med det samme, og kun hente de vægte, du faktisk bruger. De fleste sider henter fire-fem vægte og bruger to.

5. Tredjepartsscripts

Chatwidget, statistik, Facebook-pixel, cookiebanner, bookingmodul. Hver enkelt er en forbindelse til et domæne, du ikke selv styrer hastigheden på. Fire-fem af dem, og du har lagt et halvt sekund oveni, før dit eget indhold overhovedet er begyndt.

Fjern dem, du ikke bruger — der ligger næsten altid et par stykker fra et gammelt kampagneforsøg. Resten skal indlæses med defer eller async, og en chat behøver først at loade, når brugeren har scrollet eller været på siden et par sekunder.

6. Selve platformen

Nogle sidebyggere sender flere hundrede kilobytes CSS og JavaScript, før dit indhold overhovedet er nævnt. Det er ikke noget, et cache-plugin retter op på — det er fundamentet.

Det er også den ærligste samtale at tage tidligt: hvis siden er bygget på noget tungt, bruger du penge hver måned på at lappe et problem, der bliver ved med at være der.

Sådan måler du det rigtigt

Kør din side gennem Googles PageSpeed Insights. Og læg så mærke til den ene skelnen, næsten alle overser — rapporten indeholder to helt forskellige ting:

Feltdata ("Oplev dine faktiske brugere"). Rigtige besøgende, målt over de seneste 28 dage. Det her er sandheden om, hvad dine kunder oplever. Har din side for lidt trafik, findes afsnittet slet ikke.

Labdata (Lighthouse-scoren). En simuleret indlæsning på en simuleret telefon. Den er god til at finde årsager — den viser præcis hvilke filer der er tunge. Men tallet svinger let ti point mellem to kørsler af samme side. Jag ikke scoren. Brug listen af problemer, ikke karakteren.

To praktiske råd: mål altid mobiltallene, ikke desktop — og mål den side, dine annoncer og dine Google-resultater faktisk sender folk hen på. Det er sjældent forsiden.

Hvad du kan rette i dag uden en udvikler

• Kør alle billeder over 200 KB gennem en WebP-konverter og læg dem op igen.
• Sæt bredde og højde på alle billeder — det fjerner layout-hop gratis.
• Sæt loading="lazy" på billeder længere nede på siden. Men aldrig på det øverste billede — der gør det det direkte langsommere.
• Slå plugins fra, du ikke bruger. Ikke bare deaktiver — fjern dem.
• Find ét tredjepartsscript, du ikke kan forklare formålet med, og fjern det.

De fem ting tager en eftermiddag og flytter typisk mere end noget plugin, du kan installere.

Hvornår det ikke kan lappes

Er dit LCP stadig over fire sekunder på mobil, efter billederne er ordnet, er det som regel ikke enkeltdele længere — det er fundamentet. På det punkt er en ny side billigere end et år med lapperier, og du får samtidig løst de ting, der egentlig kostede dig kunder: uklare tekster, svage handlingsknapper og en mobiloplevelse, der aldrig blev tænkt igennem.

Hastighed er sjældent hele problemet. Men det er det eneste problem, hvor du kan se præcis, hvad det koster — i sekunder.

Ofte stillede spørgsmål

Hvor hurtig skal min hjemmeside være?

Brug Googles egne grænser som mål: det største element på siden bør være synligt inden for 2,5 sekunder, et klik bør give synlig respons inden for 200 millisekunder, og layoutet må stort set ikke hoppe under indlæsning. Rammer du det på mobil på et almindeligt mobilnetværk, er du et godt sted.

Påvirker hastighed min placering på Google?

Ja, men mindre end de fleste tror. Core Web Vitals indgår i Googles rangering, men relevans og indhold vejer tungere. Den reelle grund til at optimere hastighed er ikke placeringen — det er, at folk forlader siden, før den er indlæst, og at en langsom side gør al din øvrige markedsføring dyrere.

Hjælper et cache-plugin?

Det hjælper på gentagne besøg og på serverens svartid, men det løser ikke for tunge billeder, for meget JavaScript eller en tung platform. Cache gør leveringen hurtigere — den gør ikke selve siden lettere. Er fundamentet tungt, flytter et plugin sjældent noget afgørende.

Hvorfor er min side hurtig på computer, men langsom på mobil?

Fordi en telefon har markant mindre processorkraft og typisk en langsommere forbindelse. JavaScript, der er gratis på en bærbar, kan tage flere sekunder på en tre år gammel telefon. Test derfor altid mobiltallene — det er dem, størstedelen af dine besøgende oplever.

Vil du vide, hvordan en langsom side også rammer din synlighed i AI-søgning, har vi skrevet om det i bliv fundet i ChatGPT.

Læs også

← Tilbage til alle artikler