Kort fortalt: rel=preload er et hint til browseren om at en bestemt ressource er vigtig og bør hentes tidligt, før browseren normalt ville opdage den.
Hvornår giver det mening?
- Fonts der bruges i første viewport
- Hero-billeder der ofte er LCP-elementet
Det giver især mening når en ressource ellers bliver “opdaget” sent, fx:
- et hero-billede ligger dybt i HTML eller kommer via CSS background
- fonts bliver først hentet når CSS er downloaded og parsed
Preload kan dermed flytte download-start frem og reducere ventetid.
Hvilken indflydelse har preload?
Rigtigt brugt kan preload:
- reducere LCP (hero-billede hentes tidligere)
- reducere FOIT/FOUT for kritiske fonts
- gøre first paint mere stabil
Forkert brugt kan preload:
- stjæle båndbredde fra vigtigere ressourcer
- øge konkurrencen tidligt i load
- føre til spild hvis ressourcen ikke bruges (eller bruges senere)
Hvornår blev preload indført?
Preload blev introduceret for at give udviklere en mere eksplicit måde at fortælle browseren hvad der er kritisk. Det er især nyttigt på moderne sites hvor critical path ikke altid er tydelig for browseren tidligt (pga. CSS, frameworks og dynamic rendering).
Faldgruber
- Preload for meget kan gøre alt langsommere
- Preload af noget der ikke bruges tidligt giver spild
Udvidet liste af faldgruber:
- preloader både AVIF/WebP/JPEG for samme billede (dobbelt arbejde)
- preloader mange font-weights der ikke er nødvendige for første viewport
- preloader store scripts der ikke er kritiske for første render
Konkrete anbefalinger (praktisk)
1) Preload kun det du er sikker på er kritisk
Typisk er det:
- ét hero-billede
- én font-fil (ikke 6 weights)
2) Brug as= korrekt
Eksempler:
as="image"for billederas="font"+crossoriginfor fonts (hvis relevant)
3) Tjek at preload faktisk bliver brugt
I DevTools Network kan du se om:
- ressourcen blev hentet tidligt
- ressourcen senere blev hentet igen (dårligt tegn)
4) Test på mobil
Preload-effekten er ofte tydeligst på mobilnetværk. Hvis du kun tester på hurtig desktop, kan du miste de reelle gevinster/ulemper.
Eksempler (sådan ser det ud i praksis)
Preload af et hero-billede
Det giver især mening hvis:
- billedet ellers opdages sent
- det ofte er LCP-elementet
Husk at du stadig skal bruge responsive billeder. Preload bør pege på den variant der reelt bliver brugt i første viewport.
Preload af fonts
Fonts giver mening at preload’e hvis de:
- bruges i hero/overskrift i første viewport
- ellers loader sent via CSS
Men preload kun få, ellers stjæler du tidlig båndbredde.
Sådan verificerer du preload
Praktisk metode:
- Åbn DevTools → Network
- Reload siden (hard reload)
- Bekræft at ressource-requesten starter tidligt
- Tjek om browseren downloader ressourcen igen senere (dårligt tegn)
- Kig efter “Unused preload” advarsler i console (hvis relevant)
Typiske spørgsmål du bør stille før du tilføjer preload
- Er dette faktisk en kritisk ressource for første viewport?
- Er problemet discovery (starter download for sent), eller er det TTFB/render-blocking/CPU?
- Vil preload konkurrere med vigtigere ressourcer (CSS/HTML/hero)?
FAQ
Skal man altid preload’e LCP-billedet?
Nej. Hvis billedet allerede opdages tidligt (fx et `<img>` højt i HTML), kan preload være overflødigt.
Preload er mest relevant når du har et **discovery-problem**: billedet opdages sent (fx via CSS background eller dybt i DOM), og derfor starter download for sent.
Brug waterfall til at afgøre om preload giver mening – og undgå at preload’e flere kandidater “for en sikkerheds skyld”.
Kan preload forbedre INP?
Kun indirekte. Preload kan reducere unødvendig ventetid på *kritiske ressourcer*, men INP handler primært om CPU/JavaScript og hvad der sker under interaktioner.
Hvis du har dårlig INP, skal du typisk kigge efter long tasks, tunge event handlers og tredjepart – ikke flere resource hints i `<head>`.
Næste skridt fra begreb til handling
Guides og blogindlæg der matcher begrebets emne - ud fra fælles tags og sidens fokus.
Brug Transfer-Encoding (chunked) til progressiv rendering: hurtigere første visning
Læ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.
Gør hero til LCP: sådan ændrer du struktur, CSS og prioritering
Hvis 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
Fø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.
Hvordan du spotter render delay (uden at stirre på score)
Render 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.
Fetchpriority, preload og preconnect: hvornår de hjælper og hvornår de gør skade
Lær hvornår fetchpriority, preload og preconnect faktisk forbedrer load, og hvornår de bare skaber mere støj og dårlig prioritering i browseren.
5 grunde til at din hjemmeside er langsom og hvad du gør ved det
Se de mest almindelige årsager til en langsom hjemmeside, hvordan du spotter dem, og hvilke ændringer der typisk giver mest effekt først.
