Du har sikkert set listen: komprimer billeder, fjern render-blocking, skær JavaScript, tjek cache, ret fonts, kig på tredjepart. Problemet er ikke mangel på idéer, men rækkefølge. Mange starter med tilfældige fixes fordi et værktøj foreslår dem, eller fordi én kollega «har hørt at lazy load er godt». Performance-arbejde bør bygge på prioritering og målinger, ikke mavefornemmelse. Målet er at finde det, der reelt holder siden tilbage for brugerne du bekymrer dig om - ikke at få en grøn boble på et vilkårligt tidspunkt.
Denne artikel er til dig, der skal vælge hvad der først i en travl hverdag: marketing, produkt, udvikling eller ejer. Du får en model, du kan bruge hver gang, plus typiske fejl der stjæler tid.
Hvorfor mange starter forkert med hastighedsoptimering
Når fokus havner på score i stedet for brugeroplevelse
En samlet «score» er nem at kommunikere, men den er sjældent en plan. Læs hvorfor Lighthouse og CrUX ikke er det samme: lab og felt måler forskellige ting. Hvis du optimerer til én kørt test på wifi-desktop, kan mobil-felt stadig være rødt på de sider der betyder mest.
Hvorfor små fixes ofte stjæler tid fra de store problemer
Små wins føles godt i øjeblikket, men hvis TTFB er høj eller LCP-elementet er tungt og sent, ændrer mikro-justeringer på et ikon ingenting for oplevet hastighed. Det er derfor «score ikke er en plan» - du skal kunne pege på symptom vs. årsag (mere om det i næste afsnit).
Symptomer og årsager er ikke det samme
Grøn score kan stadig dække over tung interaktion
Lab kan se pænt ud, mens INP er dårlig fordi tunge scripts først bider, når brugeren klikker. Tjek INP og JavaScript når feltdata eller manuelle tests viser træg respons.
Dårlig LCP kan være et billede, men også discovery, HTML eller blocking
Et stort billede er en klassiker, men LCP kan også være tekst, der først tegnes sent fordi CSS/JS blokerer. Brug waterfall til at se rækkefølgen - ikke kun filstørrelse.
Høj TTFB påvirker alt andet
Langsom HTML udskyder alt: discovery af LCP-ressourcer, parsing og første paint. Hvis serveren er flaskehalsen, hjælper billedoptimering først, når TTFB er rimelig. Se TTFB og cache.
Den rigtige rækkefølge at arbejde i
Start med det brugeren mærker mest
Vælg en konkret side eller template (forside, kategori, checkout) og et flow (scroll, klik, søgning). Det er her prioriteringen bliver ærlig.
Brug feltdata hvis de findes
Search Console og CrUX fortæller, om problemet er udbredt for rigtige brugere. Brug dem til at vælge område.
Brug labdata til at finde årsagen
Når du har valgt en URL, bruger du Lighthouse, DevTools eller waterfall til at se hvorfor.
Prioritér vigtige templates og flows først
Perfekte undersider hjælper ikke, hvis checkout eller lead-formen er tung.
Hvad der typisk bør komme først
Langsom HTML og høj TTFB
Uden hurtig HTML starter alt for sent. Forbedr TTFB og cache før du bruger timer på små assets.
LCP-element og prioritering af hovedindhold
Når LCP er problemet, find elementet og ret discovery, størrelse og prioritering. LCP med billeder dækker den typiske bane.
Tunge scripts og dårlig INP
Når klik og menuer halter, er main thread og tredjepart ofte i centrum - se INP-guiden.
CLS og ting der får siden til at hoppe
Stabilitet før «pynt»: dimensioner på medier, fonts og bannere - CLS og layout.
Hvad der ofte kan vente
Små assets med begrænset effekt
Ikoner og små justeringer, der ikke ligger på kritisk sti, kan vente.
Perfekte scores på irrelevante sider
Optimér først det der har trafik og konvertering.
Mikrooptimeringer før de store blokeringer er væk
Ingen gevinst i at finpusse et billede, hvis HTML stadig ankommer langsomt eller scripts dominerer interaktion.
En praktisk model du kan bruge hver gang
Tjekliste før du ændrer noget
- Hvilken URL og hvilket flow?
- Hvad siger felt vs. lab?
- Er symptomet LCP, INP eller CLS - eller TTFB?
Sådan dokumenterer du før og efter
Gem screenshot af waterfall, notér dato, enhed og netværksprofil. Én ændring ad gangen.
Sådan vælger du næste skridt
Når den største flaskehals er ryddet, måler du igen. Først da vælger du næste kategori (fx fra TTFB til LCP-billede).
Typiske fejl og misforståelser
Hero-billede bliver lazy loadet
Det kan forværre LCP hvis billedet er LCP-elementet.
Man optimerer desktop og glemmer mobil
De fleste brugere og ofte de værste tal er mobil.
Man måler kun på forsiden
Kategori-, produkt- og artikelsider har ofte andre LCP-elementer og scripts.
Afslutning
Kort model: Vælg vigtig side og flow - læs felt - brug lab til årsag - ret den største flaskehals først - dokumentér - gentag.
Næste skridt afhænger af dit diagnosebillede:
- Høj LCP med billede i fokus: Forbedr LCP med billeder
- Dårlig INP og tung JS: Forbedr INP ved at reducere JavaScript
- Langsom HTML: Forbedr TTFB og cache
Læs også hvad Core Web Vitals er og sådan læser du en waterfall så du ikke gætter på rækkefølgen af requests.
Relaterede blogindlæg
Hvad er Core Web Vitals? LCP, INP og CLS forklaret enkelt
2026-03-20Få en praktisk forklaring på LCP, INP og CLS. Lær hvad Core Web Vitals måler, hvorfor de betyder noget, og hvordan du kommer i gang.
Lighthouse vs CrUX: hvorfor tallene ikke matcher og hvad du gør
2026-02-28Forstå forskellen på Lighthouse og CrUX. Lær hvorfor labdata og feltdata kan vise noget forskelligt, og hvordan du bruger dem rigtigt.
Vary-header og caching: undgå forkert indhold og lav cache-hit-rate
2026-03-30Vary bestemmer hvornår caches skal gemme flere varianter af samme URL (fx gzip vs brotli eller dansk vs engelsk). Lær de typiske fejl, og hvordan du tester med headers og curl.
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.
Når PageSpeed score snyder: derfor føles siden stadig langsom
2026-03-25Forstå hvorfor en grøn score ikke altid betyder en hurtig hjemmeside, og lær hvad du i stedet skal kigge på, når brugerne stadig oplever siden som tung.
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.
FAQ
Hvad skal jeg starte med, hvis min side både har høj LCP og dårlig INP?
Start med den flaskehals der rammer flest brugere i feltdata (typisk den side eller det flow der konverterer mest). Hvis TTFB er høj, forsinker alt andet, så det er ofte et naturligt første trin. Hvis HTML er rimelig, men interaktion halter, kan INP og tredjepart være næste fokus. Brug ikke én global score til at vælge - læs [Core Web Vitals](/blog/hvad-er-core-web-vitals/) som tre signaler og prioriter ud fra målgruppe og flow.
Skal jeg altid begynde med PageSpeed Insights?
PageSpeed Insights er et godt startpunkt til lab og felt, men det er ikke en plan. Brug det til at åbne en konkret URL og se, om problemet er LCP, INP eller CLS - og hop derefter til [waterfall](/blog/saadan-laeser-du-waterfall/) eller DevTools for årsag. Feltdata i Search Console fortæller ofte bedre, *hvor* problemet er størst.
Hvor meget skal jeg optimere, før det giver mening at teste igen?
Test efter hver meningsfulde ændring på samme mål og samme enhed, ellers ved du ikke, hvad der virkede. Én rettelse ad gangen på en vigtig template er bedre end fem halve fixes på én gang.
Næste skridt i samme emne
Fortsæt fra forklaring til handling med guides, emner og ordbog.
