Kort fortalt: Med link rel="dns-prefetch" beder I browseren om at slå DNS op for et værtsnavn tidligt. Det sparer typisk én DNS-runde før socket-oprettelse - på mobil og ved langsom DNS kan det stadig mærkes, men det er et mindre aggressivt hint end preconnect.
dns-prefetch vs preconnect
| dns-prefetch | preconnect | |
|---|---|---|
| DNS | Ja | Ja |
| TCP/TLS | Nej | Ja |
| Ressource-brug | Lav | Højere |
Brug dns-prefetch når I har mange mulige tredjeparter og ikke vil åbne mange tidlige TLS-sessioner. Brug preconnect når I med høj sandsynlighed skal hente kritiske assets fra et domæne snart (fx font-CDN eller API der blokerer LCP).
Eksempel
<link rel="dns-prefetch" href="https://eksempel-tredjepart.dk" />href er en URL - browseren udleder værtsnavnet til DNS-lookup.
Hvornår giver det mening?
- I loader scripts eller pixels fra få faste domæner og vil spare første lookup.
- I ikke kan bruge preconnect overalt uden at over-forbinde.
- I vil give en lille, næsten “gratis” gevinst på første request til et nyt host.
Hvornår er det spild?
- Domænet bruges ikke på siden - ren overhead.
- I allerede har preconnect til samme host - dobbeltarbejde med lille effekt.
- Alt er samme origin - intet ekstra DNS at hente.
Placering i resource-hint-kæden
Se resource hints for overblik. dns-prefetch er ofte et første, billigt skridt før I eskalerer til preconnect eller preload til konkrete filer.
Relaterede begreber
FAQ
Er dns-prefetch sikkert at bruge mange steder?
Inden for rimelighed. For mange hints kan stadig konkurrere om tid tidligt i load, men det er typisk mindre belastende end mange preconnects. Brug kun hosts I reelt kontakter.
Skal jeg både dns-prefetch og preconnect til samme host?
Som regel nej - preconnect inkluderer DNS. Ekstra dns-prefetch giver sjældent stor ekstra gevinst og kan være redundant.
Virker det i alle browsere?
God understøttelse i Chromium-gearet; andre kan ignorere eller behandle konservativt. Betragt som progressiv forbedring.
Hjælper dns-prefetch på same-origin ressourcer?
Nej - der er intet ekstra DNS-lookup at spare når host allerede er kendt fra den aktuelle side.
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.
Range request i praksis: når 206 Partial Content ikke sker (og hvad det koster)
En 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.
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.
