Sidehastighed beskriver, hvor hurtigt en side viser sit vigtigste indhold, reagerer på brugerens input og forbliver visuelt stabil. En hastighedstest hjælper dig med at finde flaskehalse, men resultatet skal læses i sammenhæng med den side og de besøgende, du vil hjælpe.
Start med en vigtig ydelses- eller produktside. Undersøg problemet, vælg én afgrænset rettelse, og sammenlign før og efter på samme grundlag.
Guiden viser, hvordan du læser PageSpeed Insights og prioriterer hastighedsoptimering på en mindre hjemmeside. Du får en metode til at vælge næste indsats uden at gøre en enkelt testscore til målet for hele arbejdet.
Hvad er forskellen på feltdata og en labtest?
PageSpeed Insights viser to forskellige billeder af siden. Feltdata fra Chrome User Experience Report bygger på virkelige Chrome-besøg over de seneste 28 dage. Labtesten bruger Lighthouse til en simuleret indlæsning under bestemte forhold.
Brug feltdata til at vurdere den målte brugeroplevelse og labtesten til at undersøge mulige årsager. Tjek altid, om feltdata gælder denne URL eller hele origin, fx https://eksempel.dk. Data for origin samler besøg på tværs af sider og dokumenterer ikke i sig selv et problem på den konkrete underside.
Mangler feltdata, kan der være for få målinger. Det er ikke en godkendelse eller en fejl. Arbejd videre med gentagne labtest og praktisk afprøvning. Ved større behov kan egen måling af virkelige besøg supplere, men den kræver særskilt opsætning.
Hvilke hastighedstal skal du se på?
Core Web Vitals beskriver tre dele af oplevelsen. De gode grænser nedenfor vurderes ved 75-percentilen, særskilt for mobil og computer. Det betyder, at mindst 75 % af de målte besøg skal ligge på eller under grænsen.
| Mål | Hvad fortæller det? | God grænse |
|---|---|---|
| LCP | Hvornår det største synlige billede eller tekstfelt er vist. | Højst 2,5 sek. |
| INP | Hvor hurtigt siden viser en reaktion på klik, tryk og tastaturinput. | Højst 200 ms |
| CLS | Hvor meget synligt indhold flytter sig uventet. | Højst 0,1 |
CLS er et tal uden tidsenhed. TTFB, tiden til den første byte, kan hjælpe med at undersøge serverens levering, men er ikke et af de tre Core Web Vitals.
Den almindelige Lighthouse-test indlæser siden uden at bruge den og måler derfor ikke INP fra virkelige interaktioner. Total Blocking Time (TBT) kan pege på blokerende arbejde i labtesten. TBT og INP er forskellige mål, så en lav TBT beviser ikke, at alle knapper reagerer hurtigt.
Sådan læser du en PageSpeed-test
- Vælg den rigtige adresse. Test den konkrete side, der er vigtig for henvendelser eller køb. Forsiden repræsenterer ikke automatisk resten af hjemmesiden.
- Se mobil og computer hver for sig. Notér dato, adresse og enhed, så du kan gentage testen på samme grundlag.
- Kontrollér feltdataenes omfang. Er det URL eller origin? Hvilket af de tre mål har et problem, og har du data nok til at vurdere det?
- Find den relevante diagnose i labtesten. Ved langsom visning undersøger du LCP-element og indlæsning. Ved træge handlinger undersøger du scripts og den konkrete handling. Ved hop i indholdet undersøger du layoutskift.
- Gem en baseline. Kør fx tre sammenlignelige labtest og notér typisk resultat og udsving. Brug samme fremgangsmåde efter rettelsen.
Scoren kan variere, selv om du ikke ændrer noget. En højere score er et nyttigt signal, men læs også de konkrete tider og afprøv siden. Forslag om sparet tid er estimater, som ikke bare kan lægges sammen til en lovet forbedring.
Hvilken flaskehals bør du undersøge først?
Det vigtigste indhold kommer sent frem
Find først, hvad labtesten udpeger som LCP-element. Er det det store topbillede, skal du undersøge både billedets størrelse, hvornår det bliver hentet, og hvornår det bliver vist. En mindre fil løser ikke en forsinkelse, der skyldes, at browseren først opdager billedet sent.
Tilpas billeder til den faktiske visning og vurder fx WebP eller AVIF. Et vigtigt billede i første skærmbillede bør normalt ikke vente på lazy loading. Billeder længere nede kan ofte indlæses senere. Læs også om billedoptimering.
Hvis ventetiden starter før selve indholdet, skal du undersøge serverlevering, cache og eventuelle omdirigeringer. Cache og dit webhotel kan være en del af undersøgelsen. Skift ikke hosting alene på baggrund af en rød samlet score.
Menu, filtre eller knapper reagerer langsomt
Prøv den handling, brugeren har problemer med, også mens siden indlæses. JavaScript kan optage browserens hovedtråd, så input må vente. Undersøg, hvilke scripts eller funktioner der udfører arbejdet, før du vælger at reducere, udsætte eller opdele det.
På WordPress er antallet af plugins alene en dårlig diagnose. Et plugin, der indlæser tung kode på alle sider, er en anden opgave end flere små funktioner, der kun kører, hvor de bruges. Afprøv ændringer på en kopi, og bevar de funktioner, siden er afhængig af.
Tekst og knapper hopper under læsningen
Se efter billeder, indlejrede elementer eller andet indhold uden reserveret plads. Undersøg også, om et skrifttypeskift flytter teksten. Billedmål og en stabil plads til senere indhold kan forebygge hop. Problemet kan opstå efter indlæsningen, så rul gennem siden og afprøv den i stedet for kun at se på startskærmen.
Prioritér efter vigtig side, konkret problem og indsats
Lav en kort opgaveliste med: URL, observeret problem, dokumentation, foreslået rettelse og kontrol bagefter. En god opgave er “undersøg det sent indlæste topbillede på ydelsessiden”. “Gør hele siden hurtigere” er for upræcist til at aftale eller følge op på.
- Først: Et tydeligt problem på en vigtig side, som du kan dokumentere og afgrænse. Fx et meget stort topbillede, når LCP-undersøgelsen peger på billedets hentetid.
- Dernæst: Problemer, der går igen i en fælles skabelon. En rettelse kan være relevant for flere sider, men skal kontrolleres på repræsentative undersider.
- Senere: Små udsving og detaljer, hvor brugeren allerede har en god oplevelse, og arbejdet er omfattende. Vurder, om budgettet gør mere nytte et andet sted.
Eksempel: et stort topbillede på en ydelsesside
Forestil dig, at et topbillede fylder flere megabyte, og at labtesten viser det som LCP-element. Det giver en konkret hypotese: billedleveringen kan være en flaskehals.
Gem originalen, lav en passende billedversion, og sammenlign under samme forhold. Kontrollér også beskæring og kvalitet på mobil. Hvis LCP ikke forbedres, undersøg næste del af indlæsningen frem for at komprimere videre uden retning.
Eksemplet er konstrueret. Det er ikke en kundecase eller et løfte om en bestemt besparelse, score eller salgsstigning.
Tjekliste før og efter en hastighedsrettelse
- Har du valgt en vigtig URL og gemt målinger med dato og enhed?
- Ved du, om feltdata gælder siden eller hele origin?
- Har du en backup og mulighed for at tilbageføre ændringen?
- Er rettelsen knyttet til en konkret flaskehals?
- Er cache- og optimeringsindstillinger afstemt, så flere løsninger ikke overlapper?
- Har du gentaget målingerne på samme grundlag?
- Virker menu, formular, beregner, booking eller køb stadig i en aftalt test?
- Er layout og billeder kontrolleret på mobil og computer?
Ændr én afgrænset ting ad gangen. Ryd relevante cachelag efter behov, og afprøv som udlogget besøgende. Ved formularer og køb skal en test planlægges, så den ikke sender uønskede beskeder eller opretter rigtige ordrer.
Labtesten kan vise ændringen med det samme. Feltdataenes 28-dages periode indeholder i begyndelsen også besøg fra før rettelsen. Notér derfor ændringsdatoen og følg udviklingen, før du vurderer den langsigtede effekt.
Hvad betyder sidehastighed for SEO og salg?
Google anbefaler gode Core Web Vitals som en del af en god sideoplevelse. Det gør hastighed relevant for teknisk SEO, men en grøn testscore er ikke en garanti for placeringer. Siden skal stadig besvare den rigtige søgning og være brugbar.
For en mindre virksomhed er det nyttigt at følge, om besøgende kan finde og bruge den vigtige handling: læse ydelsen, beregne en pris eller kontakte virksomheden. En hurtigere side giver ikke automatisk flere salg, hvis tilbuddet er uklart eller næste skridt er svært at finde.
Kilder og videre læsning
Målemetoden bygger på Googles forklaring af PageSpeed Insights og oversigt over Web Vitals. De tekniske råd er afgrænset efter web.dev’s vejledninger om LCP, INP og CLS. Se også Googles vejledning om Core Web Vitals i Search.
Faglige kilder og indhold gennemgået 17. oktober 2026.