Mange teams kaster preload, preconnect og fetchpriority ind i <head> «for en sikkerheds skyld». Det kan virke harmløst, men browseren har allerede en prioriteringsstrategi - og for mange hints kan flytte båndbredde og CPU forkert. Når hero-billedet stadig kommer sent, er svaret sjældent «mere preload», men oftere sent HTML, høj TTFB eller forkert discovery.
Denne artikel skelner mellem signalerne, og hvornår de faktisk hjælper LCP og netværksrækkefølge - og hvornår de gør mere skade end gavn. Brug den sammen med waterfall-artiklen så du ser effekten i kæden, ikke kun i checklisten.
Hvad fetchpriority, preload og preconnect er
Hvad de gør forskelligt
- preconnect: etabler tidlig forbindelse (DNS + TLS) til et domæne.
- preload: hent en specifik ressource tidligt (ofte fordi den ellers opdages sent).
- fetchpriority: signal om høj eller lav prioritet for en kendt ressource (typisk billeder).
Hvorfor de tit blandes sammen
De handler alle om «hurtigere», men de griber ind på forskellige led i kæden.
Hvornår de faktisk hjælper
Hero billede og LCP
Når LCP er et billede og det enten opdages sent eller starter download for sent, kan fetchpriority="high" på <img> eller målrettet preload af netop den URL hjælpe - se LCP med billeder.
Kritiske fonts
Når I har identificeret ét kritisk snit og undgår at preload’e hele familien - ellers skaber I støj.
Tredjepart med vigtig tidlig forbindelse
Preconnect til CDN eller font-host hvis I reelt henter kritiske filer derfra tidligt.
Hvornår de gør skade
For mange preloads
Browseren konkurrerer med sig selv - prioriteringsindlægget forklarer hvorfor rækkefølge betyder mere end antal tricks.
Forkert preload af ikke kritiske assets
I sender store filer tidligt uden at de er på LCP-stien.
Overstyring af browserens egen prioritering
For mange high flags overalt udvander effekten.
Sådan vælger du rigtigt
Start med det reelle LCP element
Find det i Lighthouse - gæt ikke.
Tjek netværksrækkefølge
Waterfall afslører om HTML eller TTFB er den egentlige flaskehals.
Tænk i én kritisk forbedring ad gangen
Ellers ved du ikke hvad der virkede.
Typiske fejl i praksis
Hero billede uden effekt fordi HTML kommer for sent
Ret TTFB og render-blocking først - se TTFB og render-blocking.
Font preload uden korrekt brug
Forkert as/type, eller preload af filer I ikke bruger på den side.
Preconnect til ting der ikke er vigtige
Hvert ekstra domæne koster opsætning.
Hvad du bør måle bagefter
Netværk og waterfall
Er den kritiske ressource flyttet tidligere uden at skade andet?
LCP forbedring i praksis
På mobil, ikke kun desktop lab.
Om prioriteringen faktisk blev bedre
Færre konkurrerende tunge requests tidligt.
Afslutning
Brug hints målrettet og testet - ikke som standard i alle skabeloner.
Gå videre til den praktiske guide til fetchpriority og preload, LCP med billeder, fjern render-blocking og sådan læser du en waterfall.
Relaterede blogindlæg
5 grunde til at din hjemmeside er langsom og hvad du gør ved det
2025-11-14Se de mest almindelige årsager til en langsom hjemmeside, hvordan du spotter dem, og hvilke ændringer der typisk giver mest effekt først.
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.
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.
Range request i praksis: når 206 Partial Content ikke sker (og hvad det koster)
2026-04-02En feltguide til at spotte når browseren forsøger at bruge Range request, men ender med at få hele filer retur (200 i stedet for 206). Lær at se det i DevTools og ret fejl i proxy/CDN/origin.
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.
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.
FAQ
Skal jeg altid preload mit hero billede?
Nej. Preload hjælper når billedet opdages sent eller starter download for sent i forhold til LCP. Hvis billedet allerede er tidligt i HTML og prioriteret korrekt, kan preload være unødvendigt eller endda skade ved at stjæle båndbredde fra vigtigere ting.
Hvad er forskellen på preload og fetchpriority?
Preload fortæller browseren at hente en ressource tidligt den ellers måske ikke ville have fundet endnu. Fetchpriority justerer prioritering for ressourcer browseren allerede kender til - typisk på `<img>` og `<link rel=stylesheet>` i understøttede browsere.
Hvornår giver preconnect mening?
Når du tidligt ved at du skal hente kritiske ressourcer fra et andet domæne (fx CDN eller font-leverandør), og DNS+TLS-handshake ellers kommer sent. Unødig preconnect til mange domæner bliver støj.
Næste skridt i samme emne
Fortsæt fra forklaring til handling med guides, emner og ordbog.
