Resource Hints i 2026: preload, preconnect, prefetch og fetchpriority
Komplet guide til resource hints i 2026: hvornår preload, preconnect, dns-prefetch og fetchpriority hjælper LCP, og hvordan du måler effekten i feltdata.
Resource hints er HTML- og HTTP-instruktioner, der fortæller browseren at oprette netværksforbindelser eller hente ressourcer, før parseren støder på dem. Brugt rigtigt kan de barbere hundredvis af millisekunder af din Largest Contentful Paint. I 2026 består værktøjskassen af preload, preconnect, dns-prefetch, prefetch, modulepreload, fetchpriority-attributten og HTTP 103 Early Hints. Denne guide viser hvornår, hvordan og hvorfor du skal bruge hver enkelt, med kørbare eksempler og målbare effekter på Core Web Vitals.
preload tvinger browseren til at hente en kritisk ressource med høj prioritet og er den primære måde at fremskynde LCP-billeder og kritiske fonte på.
preconnect åbner TCP- og TLS-håndtryk til tredjeparts-origins før første request (typisk en gevinst på 100–300 ms pr. origin).
dns-prefetch løser kun DNS og er en let, bagudkompatibel fallback til ældre browsere eller mange origins.
prefetch henter ressourcer til den næste navigation med lav prioritet og bør parres med Speculation Rules i 2026.
fetchpriority="high" løfter prioriteten på dit LCP-billede uden at kræve preload, og er nu understøttet i alle moderne browsere.
HTTP 103 Early Hints lader serveren sende preload-hints før HTML-responset. Det fungerer i Chrome, Edge, Cloudflare og Fastly.
Hvad er resource hints?
Resource hints er en familie af direktiver, defineret primært i W3C Resource Hints-specifikationen og HTML Living Standard, der lader dig instruere browseren om at udføre netværksarbejde proaktivt. I stedet for at vente på, at HTML-parseren opdager et <img>, et <script> eller et CSS-import, kan du fortælle browseren det øjeblikkeligt. Det kan ske via <link>-tags i <head>, en Link:-HTTP-header, eller via attributter som fetchpriority direkte på elementer.
Hvert hint adresserer et bestemt trin i request-pipelinen: DNS-opløsning, TCP-forbindelse, TLS-håndtryk eller selve ressource-hentningen. At vælge det rigtige niveau er afgørende, for stærke hints på for mange ressourcer slår sig selv ihjel ved at fortrænge det faktisk kritiske arbejde. Reglen er simpel: jo mere sikker du er på, at noget bliver brugt, jo stærkere hint må du give. LCP-optimering er det område, hvor resource hints typisk leverer den største gevinst, fordi de fjerner ventetid før hentning af det største billede eller font.
preload: kritiske ressourcer først
Brug <link rel="preload"> til ressourcer, som browseren ellers ville opdage sent, men som er nødvendige for første render. Klassiske kandidater er LCP-billedet (især når det indlæses via CSS background-image), brugerdefinerede web-fonte og kritiske JavaScript-moduler i async-injicerede chunks.
Et minimalt eksempel til et hero-billede og en font:
<!-- LCP-billede der ellers først opdages sent -->
<link
rel="preload"
as="image"
href="/img/hero.avif"
type="image/avif"
fetchpriority="high"
imagesrcset="/img/hero-800.avif 800w, /img/hero-1600.avif 1600w"
imagesizes="100vw"
>
<!-- Kritisk variable font -->
<link
rel="preload"
as="font"
href="/fonts/inter-var.woff2"
type="font/woff2"
crossorigin
>
Bemærk tre detaljer: as-attributten er obligatorisk (browseren skal kende ressourcetypen for at sætte korrekt prioritet og Accept-headers), crossorigin er obligatorisk for fonte selv fra samme origin, og imagesrcset/imagesizes lader dig preloade det rigtige responsive billede uden at duplikere data. Misser du crossorigin på en font, henter browseren den to gange (én gang for preload og én gang for det rigtige forbrug), fordi CORS-mode skal matche eksakt. Den fejl bed mig i en relancering for et par måneder siden, hvor fontfilen pludselig vejede dobbelt så meget i Network-panelet. Tjek altid det først.
Preload bør reserveres til 1–4 ressourcer pr. side. Hver preload konkurrerer om båndbredde med initial HTML, CSS og JS. Googles vejledning til preload anbefaler, at man verificerer hvert preload-hint i DevTools' Network-fane. Hvis Priority ikke er "High" eller ressourcen bruges senere end forventet, skal hintet fjernes.
preconnect: åbn forbindelsen tidligt
Når dit site henter ressourcer fra et tredjepart-origin (analytics, fonts.gstatic.com, en CDN på et andet domæne, et betalings-iframe), koster den første forbindelse en fuld runde af DNS-opslag, TCP-håndtryk og TLS-forhandling. På en typisk 4G-forbindelse er det 200–400 ms, før første byte overhovedet kan begynde at flyde. <link rel="preconnect"> kvitterer for den omkostning op front.
Brug crossorigin, når forbindelsen vil bære anonyme requests for ressourcer som fonte. Uden attributten åbner browseren en ny forbindelse alligevel, fordi credential-mode ikke matcher, og preconnect-hintet er reelt spildt.
Begræns dig til 3–4 preconnect-hints i alt. Hver åben forbindelse koster RAM på klienten og en TLS-session i serverens kø. Preconnects bør pege på origins, du vil bruge inden for de første ~2 sekunder; ellers lader browseren forbindelsen forfalde uudnyttet. Har du 10+ tredjeparts-origins? Brug dns-prefetch til halen, og preconnect kun til de 2–3 vigtigste.
dns-prefetch vs. preconnect
Forskellen mellem dns-prefetch og preconnect handler om, hvor langt i forbindelses-stacken browseren går. dns-prefetch løser kun A/AAAA-records gennem operativsystemets resolver. preconnect gør alt det plus TCP-håndtrykket og TLS-forhandlingen.
Egenskab
dns-prefetch
preconnect
Hvad det gør
Kun DNS-opslag
DNS + TCP + TLS
Typisk besparelse
20–120 ms
100–500 ms
Ressourceforbrug
Meget lavt
Moderat (åben socket)
Anbefalet antal pr. side
8–10 maks.
3–4 maks.
Browser-understøttelse
Universal (siden 2010)
Universal i moderne
Bedst til
Mange mulige origins
Få vigtige origins
I praksis kombinerer du dem ofte. Brug preconnect til 2–3 kritiske origins, og dns-prefetch til alt andet, du muligvis rammer:
I ældre browsere uden preconnect-støtte fungerer dns-prefetch stadig som fallback, hvilket gør dobbeltdeklaration sikker. Husk at validere i Chrome DevTools' Performance-fane. Under "Network requests" kan du se, om DNS-tiden faktisk er nul for de angivne origins.
prefetch og modulepreload
<link rel="prefetch"> instruerer browseren om at hente en ressource med lav prioritet og gemme den i HTTP-cachen til den næste navigation. Det er det rigtige værktøj, når du forudser hvilken side brugeren går til næste gang. For eksempel produktdetaljen efter en liste, eller checkout efter kurven.
I 2026 er den moderne afløser for naiv prefetch Speculation Rules API'en, som lader dig udtrykke regler (fx "prefetch alle interne links når brugeren hover'er i 200 ms") og endda fuldt prerender næste side. Brug stadig klassisk prefetch til enkelte deterministiske mål, fx den eneste mulige næste side i et flow.
<link rel="modulepreload"> er en specialiseret variant til ES-moduler. Den henter og parser modulet samt rekursivt dets imports, så dependency-grafen er klar, når <script type="module">-tagget kører. Hvis du leverer kode som ES-moduler (hvilket Vite, Rollup og moderne Next.js gør som default), er modulepreload markant hurtigere end almindelig preload, fordi browseren genkender afhængigheder.
fetchpriority er en HTML-attribut, ikke et <link>-tag. Den justerer den interne prioritet, som browseren tildeler en request, og virker på <img>, <link>, <script> og fetch(). Værdierne er "high", "low" og "auto" (default).
Den vigtigste use case er at markere LCP-billedet uden at skulle preloade det:
Uden hintet starter browseren billed-requests med "Low" prioritet, indtil layoutet er beregnet. Det koster typisk 100–500 ms på LCP. Med fetchpriority="high" sætter browseren det med det samme i den højeste prioritets-kø, side om side med CSS og kritiske scripts. Web.dev's fetch priority-guide dokumenterer typiske gevinster på 5–25 % af LCP i feltdata fra Chrome UX Report.
Omvendt kan du sætte fetchpriority="low" på ikke-kritiske billeder under folden eller analytics-scripts. Kombineret med loading="lazy" giver det browseren maksimal frihed til at prioritere det vigtige først. Per maj 2026 er attributten understøttet i Chrome, Edge, Safari 17.2+ og Firefox 132+.
HTTP 103 Early Hints
Early Hints er resource hints på server-niveau. Serveren sender et HTTP 103-response før det endelige 200-response og inkluderer Link:-headers med rel=preload eller rel=preconnect. Browseren behandler hintene øjeblikkeligt, uden at vente på at applikationsserveren er færdig med at generere HTML.
Effekten er størst på sider med høj server-render-tid. Hvis dit backend bruger 400 ms på at samle HTML, kan browseren allerede have hentet CSS og åbnet font-forbindelsen i de 400 ms. Cloudflare, Fastly og Akamai understøtter Early Hints i deres edge-runtime, og Chrome har understøttet 103-responses siden version 103. Implementér hintene via din CDN-konfiguration frem for i applikationskoden. Det er ofte gratis at slå til, hvis du allerede bruger en moderne edge.
For at se effekten i praksis: kør TTFB-måling med og uden Early Hints i WebPageTest, og sammenlign Start Render-tiderne. Jeg så selv en hel halvering af time-to-first-paint på en tung Next.js-side, da vi flyttede preload-hints fra HTML til 103-headers via Cloudflare.
Almindelige fejl og fælder
For mange preloads
Mere end ~4 preloads konkurrerer indbyrdes og fortrænger HTML-parserens egne discovery-requests. Hvis du har preloadet 10 ressourcer "for en sikkerheds skyld", begynder browseren faktisk at hente kritisk JS senere end uden preloads. Lighthouse rapporterer det som "Avoid chaining critical requests".
Manglende crossorigin på font-preloads
Den hyppigste fejl, ærligt talt. Browseren henter fonten to gange, og du betaler i båndbredde og forsinkelse. Reglen: as="font" kræver altid crossorigin.
preconnect der ikke bruges
Hvis du preconnecter til en origin, som først rammes efter 5+ sekunder, lukker browseren forbindelsen. Brug Performance-fanen i DevTools, og kig efter "Unused preconnect"-advarslen i konsollen.
preload uden as
Browseren ignorerer hintet og logger en advarsel. as er strengt påkrævet for at sætte prioritet og Accept-headers korrekt.
Konflikt mellem preload og fetchpriority
Hvis du både preloader et billede og sætter fetchpriority="high" på selve <img>-tagget, prøver browseren ikke at deduplicere. Vælg én strategi pr. ressource.
Sådan måler du effekten
Den eneste pålidelige måde at validere resource hints er ægte feltdata. Lab-værktøjer som Lighthouse simulerer en specifik netværksprofil og fanger ikke variabilitet, men de er stadig brugbare som regression-test før udrulning.
Baseline: Kør Lighthouse i Chrome DevTools tre gange, og noter median LCP, TBT og Speed Index. Brug "Mobile" og "Slow 4G"-throttling for realistiske tal.
Implementér ét hint ad gangen: Tilføj fx fetchpriority="high" på LCP-billedet, deploy til staging, og mål igen. Hold andre variabler konstante.
Verificér i Network-fanen: Filtrér på den hint'ede ressource. Tjek at "Priority" er, hvad du forventer, og at "Initiator" viser hintet fremfor parseren.
Slå feltdata til: Tilføj web-vitals-biblioteket (npm-pakken fra Google) og send LCP/INP/CLS til din analytics. Sammenlign 7-dages median før og efter hver udrulning.
Tjek for regressioner: Et hint, der hjælper én side, kan skade en anden. Brug Search Console's Core Web Vitals-rapport til at fange anomalier per URL-mønster.
For mere dybdegående analyse af, hvordan hints påvirker JavaScript-eksekveringstid, se vores guide til JavaScript-optimering i 2026. Netværksgevinster fra resource hints bliver hurtigt opspist, hvis din main-thread er overbelastet.
Ofte stillede spørgsmål
Hvad er forskellen på preload og prefetch?
preload henter en ressource til den nuværende navigation med høj prioritet, mens prefetch henter til en kommende navigation med lav prioritet. Brug preload til kritiske ressourcer på den aktuelle side, og prefetch til sandsynlige næste sider.
Hvornår skal jeg bruge preconnect?
Brug preconnect til 3–4 tredjeparts-origins, som du ved bliver brugt inden for de første ~2 sekunder. Typisk font-CDN, betalings-iframes eller billede-CDN på et separat domæne. Flere preconnects spilder ressourcer.
Hjælper preload Largest Contentful Paint?
Ja. Preloading af LCP-billedet kan reducere LCP med 100–500 ms, især når billedet er en CSS-baggrund eller indlæses sent af et framework. Endnu enklere er ofte fetchpriority="high" direkte på <img>-tagget.
Hvor mange preloads er for mange?
Mere end 4 preloads pr. side er typisk skadeligt. Hver preload konkurrerer om båndbredde med HTML, CSS og JS, som browseren ellers opdager naturligt. Reservér preload til de absolut mest kritiske ressourcer.
Hvad bruges dns-prefetch til?
dns-prefetch instruerer browseren om at udføre DNS-opslag for et domæne på forhånd. Det er en let, low-cost optimering, der sparer 20–120 ms ved første request til et origin. Ideel til mange tredjepartsdomæner, du muligvis kontakter.
Article changelog (1)
— SEO meta refreshed (title and description updated)
Priya is a frontend performance engineer with 11 years of experience untangling slow React and Next.js apps. She spent four years at Shopify on the Storefront Performance team, where she drove a project that cut median LCP across the Online Store theme platform from 3.4s to 1.8s by rewriting the critical render path and killing third-party tag bloat. Before that she shipped checkout perf work at Klarna.
These days she runs an independent practice helping Series B/C ecommerce companies hit a 75th-percentile INP under 200ms before they bother with redesigns. She has a soft spot for Lighthouse CI in pull-request gates and writes most of her perf budgets in YAML. Outside work she's slowly restoring a 1998 Honda CB400 and arguing with her partner about whether RUM beats lab data (it does).
Lær hvordan Speculation Rules API kan reducere LCP til næsten nul gennem prerender og prefetch. Praktisk guide med eagerness-niveauer, dokumentmønstre, Chrome DevTools-fejlfinding og produktionsklar konfiguration for 2026.
Lær at reducere din JavaScript-bundle med code splitting, tree shaking og moderne optimeringsteknikker. Praktisk guide med kodeeksempler til Vite og Webpack — fra bundleanalyse til performance-budgets.
Lær at reducere din JavaScript-bundle og forbedre Core Web Vitals med code splitting, tree shaking, Brotli-komprimering og strategier for at minimere main thread-blokering. Med kodeeksempler til 2026.
