Preload, preconnect og fetchpriority: prioritér det rigtige

Kort svar: Resource hints omprioriterer browserens arbejde – de skaber ikke mere båndbredde. Derfor virker de kun målrettet: preload til den ene kritiske ressource, der ellers opdages sent (typisk et LCP-baggrundsbillede eller hovedfonten), preconnect til de 1-2 tredjepartsdomæner, der leverer kritisk indhold, og fetchpriority="high" på LCP-billedet. Flere hints end det stjæler prioritet fra hinanden – så bliver medicinen til gift.

Fagligt gennemgået: 2. oktober 2026

Preload-tags er blevet et slags hastighedsamulet: kan lidt hjælpe, må meget hjælpe mere. Men hints er et nulsumsspil – alt, du løfter op, skubber noget andet ned. De sider, der vinder på hints, bruger få og præcise; de sider, der taber, har tyve preloads fra gamle eksperimenter.

Denne guide viser hintene, deres rigtige brug i WordPress, hvordan du finder de hints, siden allerede har – og hvordan du rydder op.

Før du ændrer noget: Mål LCP på de vigtigste skabeloner først (mobil, tre kørsler, medianen), så du har et sammenligningsgrundlag. Et hint, der ikke kan ses i målingen, skal ikke tilføjes.

Hintene og deres opgaver

Hint	Gør	Rigtig brug
preload	Henter en konkret fil tidligt	Én kritisk ressource, der ellers opdages sent (hovedfont, LCP-baggrundsbillede)
preconnect	Åbner forbindelsen (DNS, TCP og TLS) til et domæne på forhånd	1-2 tredjepartsdomæner med kritisk indhold
fetchpriority	Hæver eller sænker prioriteten på et element	high på LCP-billedet; low på pynt
dns-prefetch	Slår kun domænenavnet op på forhånd	Mindre vigtige tredjepartsdomæner
prefetch og speculation rules	Henter ressourcer eller sider til næste navigation	Sider, brugeren sandsynligvis går videre til

Siden WordPress 6.8 indeholder kernen spekulativ indlæsning via Speculation Rules API’et: browseren kan forhåndshente sider, brugeren sandsynligvis klikker på, med en forsigtig standardindstilling. Det påvirker næste sidevisning, ikke den aktuelle – og konkurrerer derfor ikke med LCP på den side, du måler.

1. Find de hints, siden allerede har

Tema, plugins og cache-lag tilføjer hints automatisk, så start med at se, hvad der faktisk står i <head>:

curl -s https://dit-domæne.dk/ | grep -o -E '<link[^>]+rel="(preload|preconnect|dns-prefetch|prefetch)"[^>]*>'
curl -s https://dit-domæne.dk/ | grep -o 'fetchpriority="[a-z]*"' | sort | uniq -c

Gør det samme i et privat vindue med browserens udviklerværktøjer: Netværk-fanen viser prioritet og starttidspunkt for hver request, og konsollen advarer, når en preloadet fil ikke bruges inden for få sekunder. Notér hvert hint, og hvem der sætter det (tema, cache-plugin, sidebygger eller manuel kode).

2. Preload: én – og kun én

Preload giver kun mening, når browseren ellers ville opdage ressourcen sent: en font, der først nævnes dybt i CSS’en, eller et LCP-billede, der ligger som CSS-baggrund. Et almindeligt <img> i HTML’en opdages derimod fint af sig selv – dér er preload oftest spildt eller direkte skadeligt (dobbelthentning, hvis preloaden ikke matcher det billede, srcset vælger). Reglen: preload kun det, en måling har udpeget – metoden står i LCP-guiden – og tjek bagefter i Netværk-fanen, at requesten både starter tidligere og ikke hentes to gange:

Sådan ser korrekte preloads ud for en font og et responsivt baggrundsbillede:

<link rel="preload" href="/wp-content/themes/mit-tema/fonts/hovedfont.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" as="image" href="/wp-content/uploads/hero-1200.webp"
      imagesrcset="/wp-content/uploads/hero-600.webp 600w, /wp-content/uploads/hero-1200.webp 1200w"
      imagesizes="100vw" fetchpriority="high">

imagesrcset og imagesizes sikrer, at browseren preloader samme billedstørrelse, som den senere ville vælge – ellers henter mobilen et billede, den ikke bruger.

3. Preconnect: kun til kritiske tredjeparter

Hver ny tredjepartsforbindelse koster DNS-opslag, TCP og TLS, før første byte kan hentes – preconnect betaler den regning på forhånd. Men åbne forbindelser koster også, så brug kun preconnect til domæner, der leverer kritisk, tidligt indhold (fx en video-CDN på en videoside). Henter du fonte fra et andet domæne, skal preconnect have crossorigin, fordi fonte hentes i CORS-tilstand.

Endnu bedre er at fjerne behovet: lokalt hostede fonte og færre tredjepartsscripts slår enhver preconnect. Et hint er altid næstbedst efter ikke at have brug for det.

4. fetchpriority: den moderne genvej

For LCP-billeder, der allerede står i HTML’en, er fetchpriority="high" på img-tagget den rigtige løsning – samme effekt som preload, uden risiko for dobbelthentning. Siden WordPress 6.3 sætter kernen selv attributten på det billede, den vurderer som sandsynligt LCP-element, og cache-plugins kan gøre det mere præcist. Tjek, at det rigtige billede har fået den, og at LCP-billedet ikke samtidig har loading="lazy" – lazy load på LCP-billedet forsinker det.

Den anden retning er lige så nyttig: fetchpriority="low" på pynt over folden (dekorative ikoner, badges, billeder i en karrusel, der ikke vises først), så de ikke konkurrerer med det vigtige.

5. Ryd op i fælderne

• Preload-væggen: ti preloads er det samme som ingen prioritering. Hvert hint skal kunne forsvares med en måling.
• Døde hints: preloads, der peger på filer fra et gammelt tema eller et fjernet plugin, henter dem stadig – helt forgæves. Konsollen advarer om ubrugte preloads; lyt til den.
• Font-preload uden crossorigin: fonte skal preloades med crossorigin – ellers hentes de to gange. Klassikeren blandt preload-fejl.
• Preload af alle fontvægte: preload kun den vægt, der bruges i det synlige område ved første visning – typisk én.
• Dobbeltkonfiguration: sætter både tema og cache-plugin hints, får du dubletter. Vælg ét sted at styre dem, jf. én-ejer-reglen.

Hvor sætter du hints i WordPress?

Brug først de indstillinger, dit cache-plugin har til font-preload, LCP-billeder og preconnect – så ligger styringen ét sted. Har du brug for et hint, pluginnet ikke kan sætte, kan WordPress’ eget filter wp_resource_hints bruges til preconnect og dns-prefetch, fx i et lille site-specifikt plugin eller mu-plugin:

add_filter( 'wp_resource_hints', function ( $urls, $relation_type ) {
    if ( 'preconnect' === $relation_type ) {
        $urls[] = array( 'href' => 'https://video-cdn.eksempel.dk', 'crossorigin' );
    }
    return $urls;
}, 10, 2 );

Læg ikke hints direkte i temaets header.php, hvis temaet opdateres – så forsvinder de ved næste opdatering eller bliver glemt, når siden ændrer sig.

6. Verificér resultatet

Hint-laget er sundt, når head’en indeholder en håndfuld hints, du kan forklare; konsollen ikke advarer om ubrugte preloads; LCP-ressourcen starter tidligt og hentes præcis én gang – og LCP-målingen er målbart bedre end før hintene. Kan du fjerne et hint, uden at målingen ændrer sig, så fjern det: den korteste hint-liste, der holder målingen, er den rigtige. Følg op i feltdata efter nogle uger, jf. guiden om lab-data og CrUX.

Læs også

• Hub: WordPress performance og cache
• Dårlig LCP i WordPress: find det rigtige LCP-element
• Webfonts uden CLS og FOUT
• Tredjepartsscripts, der koster hastighed
• Hastighedsoptimering hos Hostious
• WordPress hosting hos Hostious – LiteSpeed, NVMe og Redis object cache fra WP StartUp

Ofte stillede spørgsmål om resource hints

Hvorfor gjorde mine preloads siden langsommere?

Fordi de omprioriterede forkert: båndbredden gik til de preloadede filer først – og LCP-billedet måtte vente. Hints tilføjer aldrig kapacitet; de flytter den kun.

Sætter mit cache-plugin ikke bare det rigtige selv?

Langt hen ad vejen, ja – FlyingPress og LiteSpeed Cache kan håndtere font-preload og LCP-prioritet. Din opgave er at lade være med at lægge manuelle hints oveni – og at verificere resultatet i Netværk-fanen.

Er dns-prefetch ikke altid harmløst?

Næsten – det er det billigste hint. Men tyve dns-prefetch til domæner, siden ikke længere bruger, er stadig støj og vedligeholdelsesgæld. Samme regel som alt andet: kun det, der bruges.

Skal jeg preloade LCP-billedet eller bruge fetchpriority?

Står billedet som img-tag i HTML’en, så brug fetchpriority=”high” på tagget. Preload er kun nødvendig, når billedet ellers opdages sent, fx som CSS-baggrund eller indsat med JavaScript.