Trin-for-trin
Find det reelle LCP-element på en konkret URL (Lighthouse/PSI) og notér URL og type.
Læs waterfall: er problemet TTFB, discovery, filstørrelse eller prioritering?
Hvis discovery er sent: overvej preload af præcis den ressource - ellers ikke.
Hvis billedet kendes tidligt men starter sent: prøv fetchpriority="high" på LCP-`<img>` og mål igen.
Undgå at tilføje flere preloads end nødvendigt - én ændring ad gangen.
Verificér LCP og waterfall efter deploy på staging.
Resource hints (preload, preconnect, dns-prefetch) og fetchpriority er kraftfulde værktøjer - og derfor farlige når de bruges uden diagnose. Mange sites ender med et <head> fyldt med «sikkerheds»-tags, mens LCP stadig er dårlig fordi HTML er sen, eller fordi det forkerte billede er optimeret.
Denne guide lærer dig at bruge fetchpriority og preload præcist: ét problem ad gangen, med waterfall som dommer.
Hvornår denne guide er relevant
Langsom LCP trods optimerede filer
Filerne er små, men starter for sent i waterfall.
Ressourcer der opdages for sent
LCP-billedet er ikke i første HTML, eller kommer via JS/CSS på en måde der udskyder start.
Før du går i gang
Find det reelle LCP element
Brug PageSpeed/Lighthouse - ikke antagelser.
Tjek om problemet er discovery, prioritet eller HTML
Hvis TTFB er høj, skal du ikke starte med preload af et billede - se fejlsøg LCP.
Den korte beslutningsregel (så du ikke skyder med spredehagl)
Der er tre typiske situationer - og de har tre forskellige “rigtige” greb:
-
Discovery-problem (ressourcen opdages for sent)
- Typisk tegn: LCP-ressourcen starter først sent i waterfall, fordi browseren først finder den sent i HTML eller efter CSS/JS.
- Typisk greb: preload (men kun den præcise ressource) eller flyt discovery tidligere.
-
Prioritets-problem (ressourcen opdages tidligt, men starter stadig sent)
- Typisk tegn: URL’en er kendt tidligt, men konkurrerer med andre tidlige downloads.
- Typisk greb:
fetchpriority="high"på LCP-<img>og/eller reducer konkurrenter (tredjepart, render-blocking).
-
Ressource-problem (den starter tidligt, men er tung)
- Typisk tegn: download starter tidligt, men tager længe (stor fil eller forkert størrelse).
- Typisk greb: dimensioner/srcset/sizes/format - preload hjælper næsten ikke.
Trin 1: Vurdér om preload giver mening
Kritiske billeder
Preload kun den præcise URL som LCP, når den ellers ville starte for sent.
Det vigtigste (og mest oversete) er, at preload skal matche det browseren ender med at hente. Hvis du preloader “desktop-hero.webp”, men mobilen ender med en anden srcset-variant, får du nemt:
- spildt preload
- eller værre: dobbelt download
Hvis du bruger responsive billeder, så preload med imagesrcset / imagesizes (så browseren vælger samme variant som den ellers ville). Eksempel:
<link
rel="preload"
as="image"
href="/img/hero-960.webp"
imagesrcset="/img/hero-480.webp 480w, /img/hero-960.webp 960w, /img/hero-1440.webp 1440w"
imagesizes="(max-width: 768px) 100vw, 960px"
/>Kritiske fonts
Ét snit ad gangen - og match type/crossorigin korrekt.
Eksempel (font preload):
<link
rel="preload"
href="/fonts/inter-var.woff2"
as="font"
type="font/woff2"
crossorigin
/>Typiske fejl i fonts:
- preload af flere weights “for en sikkerheds skyld”
- preload af font der ikke bruges i første viewport
- forkert
crossorigin(så preload ikke genbruges)
Kritiske stylesheets
Sjældent første valg - ofte er render-blocking bedre at løse strukturelt.
Trin 2: Brug fetchpriority rigtigt
Hvornår det giver mening på billeder
På LCP-<img> der konkurrerer med tredjepart eller mange parallelle requests.
Eksempel:
<img
src="/img/hero-960.webp"
width="960"
height="540"
decoding="async"
fetchpriority="high"
alt="..."
/>Hvis du samtidig lazy-loader alt andet under folden (og bruger low på under-fold thumbnails), får du ofte en mere stabil LCP end hvis du bare hælder flere hints i <head>.
Hvornår det ikke gør
På billeder under folden - her kan low hjælpe hero med at vinde.
Sammenhæng med lazy loading
Lazy load ikke LCP-billedet - se LCP med billeder.
Trin 3: Brug preconnect med omtanke
Tredjepart med vigtig tidlig forbindelse
CDN eller font-host der bruges i første viewport.
Hvornår det er støj
Preconnect til analytics-domæner du ikke skal tale med før efter samtykke.
Trin 4: Undgå klassiske fejl
For mange preloads
Hvert preload konkurrerer om båndbredde.
Preload af ikke kritiske assets
Tjek at filen faktisk er på LCP-stien.
Forkert font preload
Fejl i href, as, type eller crossorigin gør preload værdiløs.
Trin 5: Test netværksrækkefølgen bagefter
Waterfall
Starter LCP-ressourcen tidligere uden at skade HTML/CSS?
Prioritering i browseren
Færre unødige parallelle tunge downloads i toppen.
Effekt på LCP
Mål på mobil og sammenlign før/efter.
Sådan verificerer du at preload faktisk virker (og ikke bare står i head)
Det her er den del, der skiller “vi satte et tag ind” fra “vi flyttede LCP”:
- Network → filtrér på ressource
- starter requesten tidligere?
- er der kun én download (ingen dobbelt)?
- Initiator
- kommer download fra preload, eller fra HTML/CSS senere?
- Timing
- flytter det LCP-start (discovery) eller bare “download”?
- Efter deploy
- tjek igen: caching, redirects og bundling kan ændre URL’er og gøre preload irrelevant
Checkliste
- Kun én hovedændring ad gangen
- LCP-element og problemtype bekræftet
- Ingen overflødig preload/preconnect i skabelonen
Afslutning
Bedre prioritering slår flere tags. Brug hints når målingen viser et konkret hul i discovery eller rækkefølge.
Læs også fetchpriority, preload og preconnect forklaret, LCP med billeder og waterfall.
Relaterede guides
Gør hero til LCP: sådan ændrer du struktur, CSS og prioritering
2026-04-01Hvis LCP bliver en tilfældig paragraf i stedet for hero, får du både dårligere tal og en måling der ikke matcher brugerens første indtryk. Her er en konkret metode til at få hero (H1/billede) til at blive LCP – uden at snyde.
Sådan fejlsøger du LCP fra start til slut
2026-03-27Følg en praktisk arbejdsgang til at finde årsagen til høj LCP, fra serverrespons og render blocking til billeder, prioritering og netværksrækkefølge.
Lazy-load billeder korrekt uden at skade LCP og brugeroplevelse
2026-01-15Se hvordan du bruger lazy loading rigtigt, undgår at skade LCP og vælger de billeder der skal prioriteres tidligt i stedet.
Fjern render blocking CSS og JavaScript for hurtigere første visning
2025-12-20Lær hvordan du reducerer render blocking fra CSS og JavaScript, så siden viser indhold hurtigere og giver bedre FCP og LCP.
Brug Transfer-Encoding (chunked) til progressiv rendering: hurtigere første visning
2026-04-02Lær at finde ud af om din server eller reverse proxy buffer HTML-svar, og få streaming (chunked) til at flytte første visning og LCP i den rigtige retning.
Forbedr LCP med billeder: hero, formater, preload og responsive størrelser
2026-03-18Lær hvordan du forbedrer LCP ved at optimere hero-billedet med rigtige dimensioner, AVIF eller WebP, preload og korrekt responsive opsætning.
FAQ
Skal jeg preload alle hero billeder?
Nej. Preload kun det billede der er LCP på den konkrete side, og kun når det ellers opdages for sent. Forskellige skabeloner har forskellige LCP-elementer.
Hvornår skal jeg bruge fetchpriority?
Når `<img>` er LCP-elementet og konkurrerer med andre tidlige ressourcer - så kan `high` hjælpe browseren med at vælge rigtigt. Brug `low` på billeder under folden for at flytte budget væk fra hero.
Er preconnect altid en gevinst?
Nej. Preconnect til domæner I ikke henter kritisk indhold fra tidligt, er bare ekstra håndtryk og CPU. Hold listen kort.
Næste skridt efter guiden
Brug emnesider, ordbog og blog til at validere og uddybe næste ændring.
