Resource hints — Preload, prefetch og preconnect til SEO
Preload, prefetch og preconnect er HTML-hints der fortæller browseren hvad den skal hente tidligt. Korrekt brug forbedrer LCP og sideindlæsning markant.
Resource hints er <link>-tags i HTML <head> der instruerer browseren i at hente, forbinde til eller prioritere ressourcer proaktivt — før de normalt ville blive opdaget i parsing-processen. De er direkte relevante for Core Web Vitals og LCP-optimering: korrekt brug af preload og preconnect kan reducere LCP med hundredvis af millisekunder ved at fjerne latency på kritiske ressourcer som LCP-billeder og webfonts.
Preload — kritiske ressourcer nu
<link rel="preload"> instruerer browseren i at hente en ressource med høj prioritet, tidlig i sideindlæsningen. Det er relevant for ressourcer der er kritiske for current page men opdages sent i parsing — typisk LCP-billedet, den primære webfont eller kritisk CSS:
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
<link rel="preload" as="font" href="/fonts/inter.woff2" crossorigin>fetchpriority="high" er en tilføjelse der eksplicit markerer ressourcen som høj-prioritet. For LCP-billedet er det den stærkeste kombination.
En advarsel: preload uden brug resulterer i en browser-advarsel i DevTools og spilder båndbredde. Preload kun ressourcer der faktisk bruges på current page.
Preconnect — reducer DNS-tid
<link rel="preconnect"> opretter en tidlig forbindelse til en ekstern origin. Det inkluderer DNS-lookup, TCP-handshake og TLS-forhandling — typisk 100-300ms per origin. Brug det til domæner der er kritiske for current page:
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>Begræns preconnect til 2-4 kritiske origins. Forbindelser holdes åbne og bruger netværksressourcer — for mange preconnect-hints er kontraproduktive.
DNS-prefetch — lavere cost end preconnect
<link rel="dns-prefetch"> laver kun DNS-lookup — ingen TCP eller TLS. Det er billigere end preconnect og passende til origins der bruges på current page men ikke er kritiske:
<link rel="dns-prefetch" href="https://analytics.example.com">Brug dns-prefetch til analytics, tracking og andre tredjepartsscripts der ikke er kritiske for render.
Prefetch — forbered næste side
<link rel="prefetch"> downloader ressourcer til en fremtidig navigation med lav prioritet i ledig båndbredde. Det er effektivt til at gøre næste sideindlæsning nærmest øjeblikkelig:
<link rel="prefetch" href="/naeste-artikel/">Moderne frameworks som Next.js og Astro implementerer automatisk prefetch for sider der er visible i viewport via <a>-tags — det er en af grundene til at disse frameworks leverer fremragende navigation-UX.
→ Denne artikel er en del af Web Performance — Core Web Vitals og teknisk hastighed.
Andre artikler i samme emne
- Animation performance — Frame rate og jank-fri bevægelse
- Billedoptimering — Formater, størrelser og SEO
- Browser rendering pipeline — Fra HTML til pixels
- CLS-problemer — Årsager til Cumulative Layout Shift og løsninger
- Core Web Vitals — LCP, INP og CLS forklaret
- CSS — Cascading Style Sheets og SEO
- CSS containment — Isolér rendering og accelerér layout
- Font-optimering — Webfonts, FOUT og SEO
- HTTP/2 og HTTP/3 — Protokoller der eliminerer latency-overhead
- INP-optimering — Interaction to Next Paint og Core Web Vitals
- JavaScript bundle-optimering — Code splitting, tree shaking og analyse
- Kritisk renderingsti — Hvad browseren gør før du ser noget
- Latency — Forsinkelse i netværket og hvad du kan gøre ved det
- Lazy loading — Udskyd indlæsning af billeder og ressourcer
- LCP-optimering — Sådan forbedrer du Largest Contentful Paint
- Long Tasks og LoAF — Hvad blokerer main thread
- Navigation og resource timings — Browserens performance-API
- PageSpeed og SEO — Hastighed som rankingfaktor
- Performance budgets — Grænser der forhindrer regressioner
- Performance timings — Hvornår er det for langsomt?
- Responsive images — srcset, sizes og art direction
- Responsivt design — Mobile-first og SEO
- RUM vs. syntetisk monitoring — To syn på web performance
- Service Workers — Offline caching og PWA performance
- Speculative loading — Prefetch og prerender af næste side
- Startup performance — Hurtig app-start og time to interactive
- Tredjeparts-scripts og performance — Impact og strategier
- Tredjepartsscripts — Analytics, ads og performance-konsekvenser
- TTFB og hosting — Server response time og SEO
- Video performance — Lazy loading, formater og indlæsningsstrategi
- Viewport tag — Meta viewport og mobil-rendering
- Web Workers — Parallel JavaScript uden main thread-blokning
Ofte stillede spørgsmål
- Hvad er forskellen på preload og prefetch?
- Preload henter en ressource til brug på den aktuelle side med høj prioritet. Den bruges til at fremskynde ressourcer der er kritiske for current page render. Prefetch henter ressourcer til brug på en fremtidig side med lav prioritet. Den forbereder næste side som brugeren sandsynligvis navigerer til.
- Kan man overbruge resource hints?
- Ja. Preload på for mange ressourcer forsinker det der faktisk er kritisk — browseren prioriterer preloaded ressourcer og downprioriterer andre. Brug preload selektivt til 2-3 kritiske ressourcer per side: LCP-billedet, primær font og evt. kritisk CSS. Prefetch er mere tilgivende men påvirker stadig netværk.
- Hvad er fetchpriority og adskiller det sig fra preload?
- fetchpriority er en HTML-attribut der eksplicit signalerer prioritet til browseren: high, low eller auto. Det er et supplement til preload, ikke en erstatning. For LCP-billedet giver kombinationen `<link rel='preload' as='image' fetchpriority='high'>` den stærkeste signal om at billedet skal hentes med maksimal prioritet tidligst muligt.
- Understøtter alle browsere Speculation Rules API til prefetch?
- Speculation Rules API understøttes i Chromium-browsere (Chrome, Edge, Opera) fra 2023. Firefox og Safari understøtter det ikke endnu. Den klassiske `<link rel='prefetch'>` er bredt understøttet i alle moderne browsere og er fortsat den sikreste fallback-løsning til resource-prefetch.
- Hvad er modulepreload og hvornår er det relevant frem for preload?
- modulepreload er en specialiseret variant af preload designet til JavaScript ES-moduler — det downloader, parser og kompilerer modulet frem for blot at downloade det. Det er relevant for applikationer der bruger native ES-moduler eller moderne bundlers der outputter module-format. For traditionelle JavaScript-bundles bruges `as='script'` med standard preload. modulepreload er ikke bredt understøttet i ældre browsere, men alle moderne browsere fra 2022 understøtter det.
Placering i ordbogen
- Animation performance — Frame rate og jank-fri bevægelse
- Billedoptimering — Formater, størrelser og SEO
- Browser rendering pipeline — Fra HTML til pixels
- CLS-problemer — Årsager til Cumulative Layout Shift og løsninger
- Core Web Vitals — LCP, INP og CLS forklaret
- CSS — Cascading Style Sheets og SEO
- CSS containment — Isolér rendering og accelerér layout
- Font-optimering — Webfonts, FOUT og SEO
- HTTP/2 og HTTP/3 — Protokoller der eliminerer latency-overhead
- INP-optimering — Interaction to Next Paint og Core Web Vitals
- JavaScript bundle-optimering — Code splitting, tree shaking og analyse
- Kritisk renderingsti — Hvad browseren gør før du ser noget
- Latency — Forsinkelse i netværket og hvad du kan gøre ved det
- Lazy loading — Udskyd indlæsning af billeder og ressourcer
- LCP-optimering — Sådan forbedrer du Largest Contentful Paint
- Long Tasks og LoAF — Hvad blokerer main thread
- Navigation og resource timings — Browserens performance-API
- PageSpeed og SEO — Hastighed som rankingfaktor
- Performance budgets — Grænser der forhindrer regressioner
- Performance timings — Hvornår er det for langsomt?
- Responsive images — srcset, sizes og art direction
- Responsivt design — Mobile-first og SEO
- RUM vs. syntetisk monitoring — To syn på web performance
- Service Workers — Offline caching og PWA performance
- Speculative loading — Prefetch og prerender af næste side
- Startup performance — Hurtig app-start og time to interactive
- Tredjeparts-scripts og performance — Impact og strategier
- Tredjepartsscripts — Analytics, ads og performance-konsekvenser
- TTFB og hosting — Server response time og SEO
- Video performance — Lazy loading, formater og indlæsningsstrategi
- Viewport tag — Meta viewport og mobil-rendering
- Web Workers — Parallel JavaScript uden main thread-blokning