Kort fortalt: Resource hints er små deklarationer i HTML (<link rel="…">) der fortæller browseren noget om kommende ressourcebehov - før den ellers ville opdage dem ved at parse dokumentet. De erstatter ikke sund arkitektur, men kan reducere ventetid på DNS, TLS og første byte af kritiske filer, især når du har mange third-party origins eller en TTFB der forsinker al anden opdagelse.
De vigtigste typer (og hvad de gør)
| Hint | Formål i én sætning |
|---|---|
| dns-prefetch | Slå et værtsnavn op tidligt - billigt, lav risiko. |
| preconnect | DNS + TCP + TLS til et origin - dyrere, brug sparsomt. |
| preload | Hent en konkret ressource tidligt (høj prioritet i denne navigation). |
| prefetch | Hent noget til næste navigation med lav prioritet - ikke til nuværende LCP. |
modulepreload | Hent ES-moduler tidligt - relevant for moderne bundlere. |
Hvordan hints passer ind i den kritiske vej
Hints påvirker critical request chain: de kan forkorte tiden til at kritiske forbindelser og filer er i gang - men de fjerner ikke tunge billeder eller dårlig servertid. Tænk på dem som prioriterings- og paralleliseringsværktøjer, ikke som erstatning for optimering af indhold.
Hvornår hints giver mest værdi
- Du har identificeret 1–2 flaskehalse (fx font på CDN, hero-billede på kendt URL).
- Du bruger mange tredjeparts-domæner - dns-prefetch eller preconnect kan spare serielle DNS/TLS-trin.
- Din HTML kommer sent - så betyder tidlig opdagelse ekstra meget (kombinér evt. med Early Hints hvis infrastrukturen understøtter det).
Faldgruber og fejlbrug
- Preload af forkert type eller URL - browseren bruger tid og båndbredde på det forkerte; LCP kan blive værre.
- Prefetch i stedet for preload til nuværende LCP - prefetch er lav prioritet og til næste side; det løser ikke dagens hero-billede.
- For mange preconnects - åbner TLS-sessioner du ikke bruger; kan presse svage mobilnet.
- Hints som erstatning for at flytte kritiske ressourcer ind i HTML - hvis billedet kan stå tidligere i dokumentet, er det ofte klarere end komplekse hints.
Sammenhæng med HTTP-versioner
HTTP/2 og HTTP/3 ændrer hvordan streams multiplexes, men hints handler om tidspunkt og prioritering før browseren ellers ville vide, hvad den skulle hente. De er derfor stadig relevante - bare ikke som universalmiddel.
Relaterede begreber
- fetchpriority - prioritering af én konkret ressource (ofte
<img>) - Critical request chain, LCP
- CDN - hints og edge kan kombineres, men skal testes end-to-end
FAQ
Hvor mange hints kan jeg sætte?
Færre, men rigtige, slår mange tilfældige. Hvert hint bruger CPU og netværk - for mange konkurrerer om den samme tidlige båndbredde og kan udskyde dit LCP-element.
Er preload altid godt for LCP?
Kun hvis du preloader den *faktiske* LCP-ressource og URL’en er stabil. Forkert preload kan skubbe vigtige downloads og forværre situationen.
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.
Få edge cache-hit på HTML: undgå cookies, forkert Vary og dårlige cache keys
Mange sites har CDN, men får stadig høj TTFB fordi HTML ikke caches. Lær et praktisk workflow til at få cache-hit på offentlige sider uden at servere forkert indhold.
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.
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.
Reverse proxy og TTFB: sådan finder du cache-, TLS- og routing-fejl i praksis
Reverse 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.
