Hvis din hjemmeside føles langsom, er der næsten altid en konkret flaskehals bag. Og hvis du rammer rigtigt fra starten, kan du ofte få markant bedre hastighed på få timers arbejde.
Hurtig triage før du læser videre
- Åbn Search Console → Core Web Vitals - er LCP, INP eller CLS røde på mobil?
- Én repræsentativ URL i PageSpeed Insights - er problemet server (TTFB), billede (LCP), eller scripts (INP)?
- DevTools → Network waterfall - er dokumentet langsomt, eller er det assets der dominerer?
Så ved du om næste skridt er cache/TTFB, billeder, render-blocking eller JavaScript/INP.
I denne artikel får du 5 klassiske grunde til at en hjemmeside er langsom - plus hvad du typisk kan gøre ved dem. Jeg skriver med fokus på det, der faktisk flytter noget for rigtige brugere: Core Web Vitals (LCP, INP, CLS) og det der ligger under dem (billeder, CSS, JavaScript og server/TTFB).
Pas på: “Performance score” er ikke et mål i sig selv
Et højt tal i et værktøj kan stadig betyde langsomme brugeroplevelser, hvis du optimerer til testen frem for til feltdata og konkrete metrikker. Brug score som trend og som pejlemærke - men prioriter Search Console, CrUX og tydelige problemer (høj LCP, høj INP, høj CLS) som sandhedskilde. Ellers ender du med at trimme det, der ser godt ud i rapporten, mens brugerne stadig venter.
Først: Find flaskehalsen (så du ikke skyder i blinde)
Når nogen siger “min hjemmeside er langsom”, mener de typisk én af tre ting:
- Den viser ikke noget hurtigt (ofte et LCP-problem: store billeder/hero, render-blocking, høj TTFB).
- Den føles tung at bruge (ofte et INP-problem: for meget JavaScript, lange tasks, tunge tredjeparts scripts).
- Den hopper rundt mens den loader (ofte et CLS-problem: fonts, billeder uden dimensioner, elementer der skubber hinanden).
Du får mest effekt ved at starte med 10 minutters “diagnose”, før du begynder at optimere. Det kræver ikke avancerede værktøjer:
- Kør en test i PageSpeed Insights og se hvad der bliver fremhævet (LCP/INP/CLS + anbefalinger).
- Åbn Chrome DevTools → Network og kig på waterfall: hvad starter tidligt, hvad blokerer, hvad er tungt?
- Find dit LCP-element: er det et billede, en blok med tekst, en slider, et banner?
Det lyder simpelt, men det er dér forskellen ligger: Mange optimerer det, der er nemt at ændre, i stedet for det der faktisk bremser siden.
Hvis du vil have et hurtigt “kompas”, så start sådan her:
- Er TTFB høj? Så giver det mening at kigge på server/caching først.
- Er LCP høj, men TTFB OK? Så kig på hero-billede, render-blocking og kritisk CSS.
- Er INP dårlig? Så er det næsten altid JavaScript og tredjeparts scripts.
- Er CLS høj? Så er det layout/typografi/billeder uden dimensioner.
1) Billederne er for tunge (og ofte dit LCP-problem)
Hvis din forside har et stort hero-billede, et produktfoto eller et banner, er chancen høj for, at det er dit LCP-element. Og hvis billedet er tungt, vinder du stort ved at optimere det.
En vigtig nuance: “tunge billeder” handler ikke kun om filstørrelse. Det handler også om hvornår billedet bliver hentet, og om browseren får lov til at prioritere det.
Hvis dit hero-billede ligger “bagved” et script, en slider eller en CSS background, kan du have et billede på 200 KB og stadig få en dårlig LCP - fordi billedet først bliver opdaget sent.
Tegn du kan se med det samme
- Siden loader “tom” i et par sekunder, og så kommer der pludselig et stort billede.
- Du ser store billedfiler i waterfall (ofte flere hundrede KB eller MB).
- PageSpeed nævner “Properly size images”, “Serve images in next-gen formats” eller “Preload LCP image”.
De tre fejl jeg ser igen og igen
- PNG/JPEG i original størrelse (fx 3000px bredt) bliver sendt til mobilen.
- Billedet bliver ikke komprimeret – eller er komprimeret “forkert” (for høj kvalitet, forkert format).
- Hero/LCP-billedet bliver lazy-loadet. Det gør LCP værre, fordi browseren venter med at hente det.
Der er også en fjerde, som er lidt mere skjult: du har billedet som CSS background. Så kan browseren ikke altid prioritere det lige så godt, og du får ofte dårligere kontrol over preload og responsive størrelser.
Hurtig løsning vs. robust løsning
- Hurtig løsning: Komprimer og konverter til WebP/AVIF, og sørg for at hero-billedet ikke lazy-loades.
- Robust løsning: Brug responsive billeder (flere størrelser), og lad browseren vælge rigtigt via
srcset+sizes. Så sender du ikke “desktop-billedet” til mobil.
Et praktisk eksempel (set mange gange): Et hero-billede på 1,8 MB bliver vist i 1200px bredde på desktop og 360px på mobil - men serveren sender stadig originalen til alle. Her kan du ofte hente flere sekunders LCP ved at lave 2-4 størrelser og komprimere fornuftigt.
Hvis du vil gøre det ordentligt, så læs:
2) Render-blocking CSS og fonts holder siden tilbage
Du kan have en stærk server og optimerede billeder - og stadig få en side der føles langsom - hvis browseren sidder og venter på CSS og fonts, før den kan male siden.
Det er typisk her man oplever “hvid side”-problemet: serveren svarer hurtigt, men der går tid før siden ser færdig ud.
Hvorfor “pæn” CSS kan gøre siden langsom
To klassiske scenarier:
- Du loader meget CSS, som kun bruges på få sider, men det bliver hentet på alle sider.
- CSS kommer tidligt og blokerer rendering, især hvis det ligger i én stor fil og ikke kan cache’s godt.
Når “above the fold” først kan tegnes efter CSS’en er hentet, kan du få en langsom oplevelse selv ved relativt små filer - især på mobilnet.
Et meget almindeligt mønster er, at et tema eller et design-system lægger alt i én stor CSS-fil, selvom du kun bruger en lille del på den konkrete side. Det kan være “ok” på desktop med cache, men det straffer førstegangsbesøg på mobil.
Hvis du har problemer her, så kig på:
Font-loading der giver CLS eller sen tekst
Fonts er en af de ting, der ser uskyldige ud, men som kan give både:
- CLS (tekst skifter størrelse eller flytter sig)
- sen tekst (FOIT/FOUT), hvor man ser “usynlig” tekst et øjeblik
Det handler typisk om preload, font-display, og om du bruger for mange varianter/weights.
Et tip der ofte hjælper: Hvis du bruger flere font-weights, så spørg dig selv om du virkelig kan se forskel på 500/600/700 i praksis. Mange sites kan klare sig med 2 weights (fx regular + semibold) og få færre downloads, mindre blocking og mindre risiko for CLS.
Relevant:
3) For meget JavaScript (dårlig INP og “hak” i siden)
Hvis siden føles langsom, selvom den “loader”, er det ofte fordi JavaScript stjæler tid fra browserens hovedtråd. Resultatet er en side der hakker, klik der reagerer sent, og scroll der føles tung.
Det her rammer især sites med mange plugins og widgets. Der kan sagtens være 10-20 scripts, som hver især “kun lige” gør lidt - men samlet bliver det meget.
Typiske syndere
- Sliders/carousels du ikke reelt har brug for.
- “Alt-i-en” page builders der pumper JS ind på hver side.
- Tracking, chat-widgets og heatmaps der bliver hentet tidligt.
- Store bundles hvor 80% ikke bruges på den konkrete side.
Et “klassisk” tegn: Du klikker i menuen eller på en knap, og der går et halvt sekund før noget reagerer. Det er præcis den slags, INP forsøger at fange.
Hvis du vil finde den hurtigste gevinst, så kig efter:
- scripts der bliver loaded på alle sider, men kun er nødvendige på få (fx et formular-script der kun bruges på kontakt-siden)
- scripts der kører før brugeren overhovedet interagerer (chat/heatmap kan ofte udsættes)
- scripts der laver DOM-magi (flytter elementer, måler layout) - de kan udløse både INP-problemer og CLS-problemer
Sådan spotter du lange tasks
I DevTools → Performance kan du optage et load + lidt interaktion. Kig efter:
- Long tasks (gule/røde blokke) der varer længe.
- Perioder hvor CPU’en er presset, mens siden burde være “klar”.
Hvis du vil dykke ned i INP:
4) Serveren er langsom (høj TTFB)
TTFB (Time To First Byte) er ikke “hele sandheden”, men den er et godt rødt flag. Hvis TTFB er høj, kan det være svært at få en hurtig oplevelse, fordi alt andet starter sent.
Hvis du vil være praktisk: En høj TTFB betyder ofte, at du kan optimere alt muligt på frontenden og stadig føle, at siden “starter langsomt”. Derfor er TTFB et godt sted at starte, når det er skævt.
Hvad TTFB reelt fortæller dig
TTFB er tiden fra brugerens request til serveren sender første byte tilbage. Høj TTFB kan betyde:
- tung server-side rendering
- langsom database
- ingen caching (eller caching der bliver bypasset)
- for langt til serveren (ingen CDN/edge)
Cache/CDN og database-flaskehalse
Her er de typiske årsager jeg ser i praksis:
- Ingen helside-cache på sider der burde kunne cache’s (blog, landingssider, ordbog, guides).
- Cache der bliver bypasset pga. cookies, query-strings, eller et plugin der sætter “no-cache” i bestemte flows.
- Tungt tema / mange hooks der gør hver request dyr (især på CMS sites).
- Langsom database (dårlige queries, mange autoloaded options, for store tabeller).
- Ingen CDN/edge cache på statiske assets (billeder, fonts, JS).
Hvis du driver WordPress eller et andet CMS, kan caching alene ofte flytte meget - men kun hvis det er sat op, så mest muligt faktisk kan serveres hurtigt.
En hurtig test: Åbn samme side 2 gange. Hvis anden load ikke er markant hurtigere (og især hvis HTML stadig har høj TTFB), er der ofte noget galt med cache-flowet.
Læs videre her:
5) Layout skifter undervejs (CLS) og gør siden “ustabil”
CLS handler ikke om “hastighed” i klassisk forstand. Det handler om ro. Når elementer flytter sig, mens brugeren er ved at læse eller klikke, opleves siden som dårligere - også selvom den er hurtigt hentet.
CLS-problemer føles ofte “små” når man selv kigger på siden, fordi man ved hvad der skal stå hvor. Men for brugere er det irriterende - især hvis de prøver at trykke på noget, og knappen flytter sig i det øjeblik de klikker.
Hvad der udløser CLS i praksis
Her er de mest almindelige årsager:
- Billeder uden width/height (browseren ved ikke hvor meget plads der skal reserveres).
- Fonts der skifter (fallback-font → webfont) og ændrer tekstens højde/bredde.
- Bannere/popups der bliver injiceret i toppen efter load.
- Annoncer/embeds der kommer ind uden reservet plads.
Små fixes der ofte løser meget
- Sæt altid dimensioner på billeder (eller reserver plads via CSS/aspect-ratio).
- Gør font-loading stabilt (preload +
font-display: swap+ begræns antal varianter). - Undgå at “skubbe” indhold ned med elementer der kommer sent - brug overlays eller reserveret plads.
Hvis du arbejder med embeds (YouTube, kort, iframes), så er en af de nemmeste CLS-fixes at wrappe embed’et i en container med fast aspect ratio. Så reserverer du pladsen, før embed’et bliver hentet.
Vil du fixe CLS systematisk:
Opsamling: Hvad du bør gøre i hvilken rækkefølge
Hvis du kun tager én ting med herfra, så lad det være rækkefølgen. Den gør det meget lettere at arbejde struktureret:
- Mål rigtigt: Start med LCP/INP/CLS og find LCP-element + long tasks + tydelige layout-shifts.
- Fjern de store “vægtklodser”: billeder (format, størrelse, prioritering) og render-blocking.
- Gør interaktion let: skær JavaScript ned, udsæt tredjeparts scripts, og fjern unødvendige widgets.
- Sænk TTFB: caching, CDN/edge, og fjern dyre server-flows.
- Stabiliser layout: dimensioner, fonts og “sent indhold”.
Når du arbejder sådan, får du både en side der scorer bedre i værktøjer - og (vigtigere) en side der føles hurtigere.
Næste skridt (interne links)
- Vil du starte med det mest almindelige LCP-problem? Læs Forbedr LCP med billeder.
- Har du mistanke om JavaScript/INP? Start i Forbedr INP ved at reducere JavaScript.
- Er din side langsom før den overhovedet viser noget? Se Forbedr TTFB med cache.
- Vil du forstå målingerne bedre? Læs Hvad er Core Web Vitals?.
Relaterede blogindlæg
Cookie banner og Core Web Vitals: den oversete årsag til dårlig brugeroplevelse
2026-03-24Se hvordan cookie bannere og consent scripts kan påvirke load, layout og interaktion, og lær hvordan du undgår at de ødelægger brugeroplevelsen.
Hvordan tredjeparts scripts gør din hjemmeside langsom
2026-03-26Få overblik over hvordan chat widgets, tracking, consent, video embeds og andre tredjeparts scripts påvirker LCP, INP, CLS og TTFB.
Fetchpriority, preload og preconnect: hvornår de hjælper og hvornår de gør skade
2026-03-23Lær hvornår fetchpriority, preload og preconnect faktisk forbedrer load, og hvornår de bare skaber mere støj og dårlig prioritering i browseren.
Sådan læser du en waterfall og finder flaskehalse i load
2026-02-10Lær at læse en waterfall korrekt og find problemer med TTFB, LCP, render blocking og tredjepart, så du kan prioritere den rigtige optimering.
Hvordan du spotter render delay (uden at stirre på score)
2026-04-01Render delay er ofte grunden til at LCP bliver 1–2 sekunder for sent, selv når TTFB ser fin ud. Her er metoden til at finde årsagen hurtigt – og vælge den rigtige type fix.
Reverse proxy og TTFB: sådan finder du cache-, TLS- og routing-fejl i praksis
2026-03-30Reverse proxy-laget kan være årsagen til høj TTFB, mystiske cache misses og 502/504-fejl. Lær hvad du skal kigge efter i headers og waterfall, og få et praktisk debug-flow.
FAQ
Hvad er et “godt” load time i 2026?
Det afhænger af siden og trafikken, men som tommelfingerregel bør du sigte efter, at det vigtigste indhold vises hurtigt og stabilt. I praksis giver det mening at arbejde efter Core Web Vitals: LCP under 2,5 sek., INP under 200 ms og CLS under 0,1. Brug CrUX (feltdata) som facit og Lighthouse som diagnoseværktøj.
Skal jeg altid optimere billeder først?
Ofte ja, fordi billeder typisk er den største vægt og ofte er LCP-elementet. Men hvis TTFB er høj eller JavaScript blokerer interaktion, kan det give mere effekt at starte der. Start med at finde LCP-elementet og flaskehalsen i waterfall.
Hvorfor er min side hurtig på min egen computer, men langsom for brugerne?
Din computer har typisk cache, hurtig forbindelse og måske ingen latency til dit netværk. Brugere har langsommere net, andre enheder og længere afstand til serveren. Derfor er feltdata (CrUX) og realistiske tests (throttling i DevTools) vigtige.
Hjælper et caching-plugin altid?
Caching hjælper ofte, men kun hvis det er korrekt sat op. Du kan stadig have dårlig performance pga. tunge billeder, render-blocking, lange JS-opgaver eller dårlig font-loading. Caching er ét lag i en samlet strategi.
Eksterne kilder
Her er de officielle dokumentationer og værktøjer der passer til artiklens emne: måling, Core Web Vitals og diagnose i browseren.
Næste skridt i samme emne
Fortsæt fra forklaring til handling med guides, emner og ordbog.
