Guide · Teknik for ejere
Hjemmesidens hastighed: sådan bliver jeres side hurtig
En hurtig hjemmeside viser sit vigtigste indhold på højst 2,5 sekunder, reagerer på klik inden for 200 millisekunder og hopper ikke rundt, mens den indlæser. Det er Googles tre Core Web Vitals: LCP, INP og CLS. Her får I forklaringen uden fagsprog, en gratis måde at teste jeres side på, de rettelser der giver mest, og et regneeksempel på, hvad en langsom side koster.
11 min. læsning · Opdateret 1. oktober 2026
Marketingansvarlig har lige sat en kampagne i gang på Google og Meta og betaler for hvert klik. Landingssiden ser flot ud på kontorets store skærm, men på en telefon i S-toget tager det fem sekunder, før billedet øverst dukker op, og knappen hopper ned, lige som man vil trykke. En del af de betalte besøgende er væk, før siden er færdig. Hastighed er en af de få ting på en hjemmeside, der både påvirker Google, brugeroplevelsen og salget på én gang, og det er heldigvis også en af de mest målbare.
Hvor hurtig skal en hjemmeside være?
Google har lavet et konkret svar. En side regnes for hurtig, når mindst 75 % af besøgene opfylder disse tre grænser, målt på rigtige brugere:
LCP
Højst 2,5 sekunder, før hovedindholdet er synligt
INP
Højst 200 millisekunder, før siden reagerer på klik
CLS
Højst 0,1, så indholdet ligger stille
Hvad er Core Web Vitals? LCP, INP og CLS forklaret
Core Web Vitals er tre målinger, Google bruger til at beskrive, hvordan det føles at bruge en side. De måler det, brugeren oplever: hvornår ser jeg noget, hvornår kan jeg bruge det, og ligger det stille.
LCP: hvornår ser brugeren hovedindholdet?
Largest Contentful Paint måler, hvor lang tid der går, fra brugeren klikker, til det største element i det synlige vindue er vist. Det er oftest det store billede øverst, en video eller en overskrift. Grænsen for godt er 2,5 sekunder. De klassiske syndere er et billede på flere megabyte, en langsom server eller skrifttyper og scripts, der skal hentes, før noget må vises.
INP: hvor hurtigt reagerer siden, når man klikker?
Interaction to Next Paint erstattede den ældre måling FID i marts 2024. INP måler, hvor lang tid der går, fra brugeren trykker på en knap, åbner en menu eller skriver i et felt, til skærmen viser en reaktion. Grænsen er 200 millisekunder. Sider med meget JavaScript, mange sporingsscripts eller tunge chatwidgets har ofte problemer her, fordi telefonen har travlt med at køre kode, når brugeren trykker.
CLS: hopper indholdet rundt?
Cumulative Layout Shift måler, hvor meget indholdet flytter sig uventet, mens siden indlæses. Det er den irriterende oplevelse, hvor man er ved at trykke på et link, og et billede eller en annonce pludselig skubber alt ned. Grænsen er 0,1. Typiske årsager er billeder uden angivet størrelse, bannere der indsættes øverst og skrifttyper, der skifter størrelse, når de er hentet.
Googles grænser for de tre Core Web Vitals, målt på 75 % af besøgene.
| Måling | God | Skal forbedres | Dårlig | Typisk årsag til problemer |
|---|---|---|---|---|
| LCP | ≤ 2,5 s | 2,5–4 s | > 4 s | Store billeder, langsom server |
| INP | ≤ 200 ms | 200–500 ms | > 500 ms | For meget JavaScript, tredjepartsscripts |
| CLS | ≤ 0,1 | 0,1–0,25 | > 0,25 | Billeder uden mål, sene bannere |
Hvordan tester I hjemmesidens hastighed gratis?
- Åbn PageSpeed Insights fra Google, og indtast adressen på jeres forside og jeres vigtigste landingsside.
- Vælg fanen Mobil, og læs feltdata øverst: står der "Bestået" ud for Core Web Vitals?
- Rul ned til den simulerede test, og notér scoren og de tre største anbefalinger.
- Åbn Google Search Console, og gå til rapporten Core Web Vitals for at se, hvilke grupper af sider der har problemer.
- Test på en almindelig telefon på mobilnet, ud over kontorets wifi, og læg mærke til, om noget hopper.
- Gentag hver måned og efter hver større ændring, så I fanger forringelser tidligt.
Labdata (simuleret test)
- Én test på en simuleret telefon og forbindelse
- Viser resultatet med det samme
- Godt til at finde årsager og afprøve rettelser
- Svinger fra test til test
Feltdata (rigtige brugere)
- Målt på rigtige Chrome-brugere over 28 dage
- Det, Google bruger i sin vurdering
- Kræver en vis mængde trafik
- Reagerer langsomt på forbedringer
Hvad gør en hjemmeside langsom?
Når vi gennemgår langsomme sider, er det næsten altid de samme forklaringer, der går igen. Typisk er det mange små ting, der er lagt oven på hinanden over flere år, efterhånden som nye værktøjer og kampagner er kommet til:
- Billeder uploadet direkte fra kameraet eller billedbanken i fuld størrelse.
- Sporingsscripts fra fem forskellige værktøjer, hvoraf to ikke længere bruges.
- En chatwidget, et cookiebanner og en videoafspiller, der alle indlæses før indholdet.
- Et WordPress-tema med indbygget sidebygger og 30 plugins, der hver tilføjer deres egne filer.
- Mange forskellige skrifttyper og vægte, der hentes fra eksterne servere.
- Billigt delt webhotel uden cache, hvor serveren bruger et sekund på at svare.
- En slider øverst på forsiden med fem store billeder, hvoraf kun ét ses.
Hvordan gør I hjemmesiden hurtigere? De ti rettelser, der virker bedst
Rettelserne sorteret efter, hvor meget de typisk giver i forhold til indsatsen.
| Rettelse | Forbedrer | Indsats |
|---|---|---|
| Komprimér billeder og brug moderne formater som WebP eller AVIF | LCP | Lav |
| Angiv bredde og højde på alle billeder og videoer | CLS | Lav |
| Fjern sporingsscripts og plugins, der ikke bruges | INP, LCP | Lav |
| Hent billeder længere nede på siden først, når de nærmer sig skærmen | LCP | Lav |
| Prioritér hovedbilledet, så det hentes først | LCP | Lav |
| Host skrifttyper selv, og brug færre vægte | LCP, CLS | Lav til middel |
| Indlæs chat, video og kort først, når brugeren skal bruge dem | INP, LCP | Middel |
| Slå cache og et CDN til | LCP | Middel |
| Del JavaScript op, så kun det nødvendige hentes på hver side | INP | Middel til høj |
| Byg siderne på forhånd på serveren, fx med Next.js | Alle tre | Høj, typisk ved ny side |
Betyder hastighed noget for Google og for salget?
Google har bekræftet, at Core Web Vitals indgår i vurderingen af siders oplevelse, som er et rangeringssignal. Det er et beskedent signal i forhold til, hvor relevant og nyttigt indholdet er, så en hurtig side med tyndt indhold vinder ikke over en grundig side, der er lidt langsommere. Hastighed fungerer bedst som en fordel, når indholdet i forvejen er stærkt, og som en bremse, når siden er meget langsom. Den største effekt ligger hos brugerne. Offentlige undersøgelser fra Google og store webshops har gentagne gange vist, at hurtigere sider hænger sammen med flere, der bliver, og flere, der køber.
Et regneeksempel: I køber 10.000 klik om måneden til 8 kr. stykket, altså 80.000 kr. Hvis siden er så langsom, at hver tiende besøgende giver op, før den er indlæst, betaler I 8.000 kr. om måneden for besøgende, der aldrig så jeres tilbud. Det er 96.000 kr. om året, før vi taler om de kunder, der blev, men købte mindre, fordi siden føltes tung. Til sammenligning koster en målrettet hastighedsgennemgang med de vigtigste rettelser typisk en brøkdel af det. Tallene er et eksempel; brug jeres egen klikpris og trafik. Hastighed hænger tæt sammen med konverteringsoptimering, og de to bør planlægges sammen.
Er WordPress langsommere end Next.js?
En velbygget WordPress-side med et let tema, få plugins og god cache kan sagtens bestå Core Web Vitals. Problemet er, at mange WordPress-sider ender med tunge temaer og sidebyggere, og at hvert nyt plugin tilføjer kode. Next.js er bygget til at levere færdige sider fra serveren, optimere billeder automatisk og kun sende det JavaScript, hver side har brug for. Det gør det lettere at være hurtig fra starten og at forblive hurtig, efterhånden som siden vokser. Vi har sammenlignet de to i Next.js vs WordPress, og et headless CMS kan give jeres redaktører den samme frihed som WordPress oven på en hurtig Next.js-side.
Hvordan foregår et hastighedsprojekt?
1. Mål udgangspunktet
Feltdata, simulerede tests og Search Console for de vigtigste sidetyper.
2. Find de største syndere
Hvilke billeder, scripts og skabeloner står for mest af ventetiden?
3. Tag de hurtige gevinster
Billeder, ubrugte scripts og mål på medier rettes først, ofte på få dage.
4. Ret de strukturelle problemer
Tema, hosting og JavaScript, eller en ny side, hvis fundamentet er for tungt.
5. Overvåg løbende
Månedlig måling, så et nyt script eller et tungt billede ikke sniger sig ind igen.
Skal I alligevel bygge ny side, så gør hastighed til et krav i tilbuddet: "alle sidetyper skal bestå Core Web Vitals på mobil ved lancering". Det er en af de mest konkrete måder at måle en leverandør på. Læs også, hvad der ellers hører med i en SEO-venlig hjemmeside.
Hvordan bygger Ceptiv hurtige hjemmesider?
Vi bygger i Next.js, React og TypeScript, med billedoptimering, færdigbyggede sider og så lidt tredjepartskode som muligt. Hastighed testes på mobil før lancering, og den faste månedlige drift dækker hosting, opdateringer og overvågning, så siden forbliver hurtig. Har I en eksisterende side, der er blevet langsom, kan en UX-audit kombinere hastighed med en gennemgang af brugeroplevelsen. Vores webpakker starter ved 18.000 kr. plus 600 kr. om måneden; se dem under priser.
Send adressen på jeres side og jeres vigtigste mål, så får I en fast pris inden for 24 timer på enten en hastighedsgennemgang eller en ny, hurtig side.
Spørgsmål om hjemmesidens hastighed
Hvorfor får vi en ny PageSpeed-score, hver gang vi tester?
Hvad er en god PageSpeed-score?
Gør cookiebanneret vores hjemmeside langsommere?
Hjælper det at skifte til bedre hosting?
Hvor lang tid går der, før Google ser forbedringerne?
Er hastighed vigtigere på mobil end på computer?
Skal vi bygge det for jer?
I får et fastpristilbud inden for 24 timer.
