Kort fortalt: rel=preconnect fortæller browseren at den skal etablere forbindelse (DNS, TCP og ofte TLS) til et domæne på forhånd, så en efterfølgende request kan starte hurtigere.
Hvornår bruges det?
- Fonts/CDN-hostede assets
- Betalings- eller analytics-endpoints (kun hvis kritisk for første load)
Preconnect giver mest mening når:
- du ved at en bestemt tredjepart er kritisk tidligt (fx fonts eller et image CDN)
- du ellers ser at forbindelses-setup tager en mærkbar del af tiden
Det hjælper mindre hvis:
- ressourcen først bruges senere
- du allerede har en varm forbindelse
Faldgruber
- For mange preconnects giver overhead og kan gøre mere skade end gavn
Hvilken indflydelse har preconnect?
Rigtigt brugt kan preconnect:
- reducere latency for første request til et domæne
- gøre font-loading hurtigere (hvis font-host er ekstern)
- hjælpe på mobilnetværk hvor handshake kan være dyrt
Forkert brugt kan det:
- skabe ekstra forbindelser der aldrig bruges
- stjæle netværksressourcer tidligt i load
- gøre køen af “rigtige” downloads mindre effektiv
Hvornår blev preconnect relevant?
Da flere sites begyndte at afhænge af tredjepart (CDN, fonts, analytics), blev det vigtigt at kunne optimere forbindelses-setup. Preconnect er et af de mere direkte hints til browseren, men det kræver disciplin.
Konkrete anbefalinger
1) Start med 1–2 preconnects
Hvis du har brug for det, er det ofte nok med:
- ét font-domæne
- ét CDN-domæne
2) Tjek om du reelt har brug for det
I Network waterfall kan du se:
- DNS/TLS tid
- om requests til domænet sker tidligt
Hvis domænet først bruges sent, er preconnect sjældent værd at bruge.
3) Overvej dns-prefetch som et mildere alternativ
Hvis du kun vil hjælpe DNS-delen, kan dns-prefetch være en mindre aggressiv mulighed.
Sådan tester du om preconnect hjælper
En simpel test:
- Mål baseline (WebPageTest eller DevTools waterfall)
- Tilføj preconnect til ét domæne (fx font-host)
- Mål igen på mobilnetværk
Hvis du ikke ser forbedring i connection/TLS tiden eller i “time to first request” for domænet, er preconnect ofte unødvendig.
Typiske fejl
- Preconnect til 8–12 domæner “for en sikkerheds skyld”
- Preconnect til scripts der først bruges senere
- Preconnect til domæner der allerede er varme (ingen effekt)
Preconnect i en samlet performance-strategi
Preconnect er en finjustering, ikke en erstatning for grundlæggende optimering. Før du bruger preconnect bredt, bør du først sikre:
- god caching
- korrekt prioritering af kritiske ressourcer
- begrænset tredjepart i early load
Ellers risikerer du at optimere et lille led i kæden, mens de store flaskehalse består.
Hvornår preconnect typisk giver mest effekt
Ekstern font-host
Hvis dine første tekster afhænger af ekstern font-loading, kan preconnect reducere ventetid til første fontrequest.
Kritisk image-CDN
Hvis hero-billede eller andre tidlige billeder ligger på et separat domæne, kan preconnect hjælpe med hurtigere opstart af request.
Kritisk API-kald tidligt
Kun hvis et API-kald er nødvendigt for tidlig rendering, kan preconnect være relevant.
Hvornår preconnect sjældent giver mening
- domænet bruges først sent i sessionen
- domænet rammes kun i edge-cases
- ressourcen er ikke vigtig for første viewport
I disse tilfælde er preconnect ofte ren overhead.
Praktisk kontrol i waterfall
Når du tester, bør du sammenligne:
- connection setup tid før/efter
- starttidspunkt for første request til domænet
- effekt på LCP/FCP i samme testmiljø
Hvis effekten er minimal, så fjern hintet igen. Færre hints er ofte bedre.
Typiske fejl i implementering
- preconnect til både gamle og nye domæner efter migration
- duplikerede hints i layout og komponenter
- preconnect uden løbende verifikation
Udvidet tjekliste
- Hvert preconnect er knyttet til en kritisk tidlig ressource
- Antallet af preconnects er holdt lavt
- Effekt er verificeret i målinger
- Overflødige hints er fjernet igen
FAQ
Skal man preconnect’e til alle tredjeparts scripts?
Nej. Det er næsten altid en dårlig idé.
Preconnect bør være reserveret til det der er kritisk for første viewport, ellers bruger du tidlige forbindelser på domæner der ikke hjælper – og risikerer at gøre prioriteringen dårligere.
Start typisk med 0–1 preconnects og mål om connection/TLS faktisk bliver hurtigere, og om første request til domænet starter tidligere.
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.
