Kort svar: Resource hints omprioriterer browserens arbejde – de skaber ikke mere båndbredde. Derfor virker de kun målrettet:
preloadtil den ene kritiske ressource, der ellers opdages sent (typisk LCP-billedet eller hovedfonten),preconnecttil de 1-2 tredjepartsdomæner, der leverer kritisk indhold, ogfetchpriority="high"på LCP-billedet. Flere hints end det stjæler prioritet fra hinanden – så bliver medicinen til forgiftning.
Preload-tags er blevet et slags hastigheds-amulet: 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, er dem, der bruger få og præcise; de sider, der taber, har tyve preloads fra gamle eksperimenter. Denne guide viser de tre hints, deres rigtige brug – og oprydningen.
Kontrolramme: WordPress 7.1 og PHP 8.4.23 udgør versionsgrundlaget pr. 30. august 2026. Terminaleksemplet er genskabt.
| 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+TLS) til et domæne på forhånd | 1-2 tredjepartsdomæner med kritisk indhold |
| fetchpriority | Hæver/sænker prioriteten på et element | high på LCP-billedet; low på pynt |
(Og så er der dns-prefetch – en mildere preconnect, fint til mindre vigtige domæner – og prefetch, der gætter på næste sides behov: en niche, ikke et førstehåndsværktøj.)
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 selv – dér er preload oftest spildt eller direkte skadelig (dobbelt-hentning ved forkert srcset-match). 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 duplikeres:
Hver ny tredjepartsforbindelse koster DNS + TCP + TLS, før første byte kan hentes – preconnect betaler den regning forud. Men forbindelser er dyre at holde åbne, så brug den kun på domæner, der leverer kritisk, tidligt indhold (fx en video-CDN på en videoside). Endnu bedre: fjern behovet – lokalt hostede fonts og færre tredjepartsscripts slår enhver preconnect. Et hint er altid næstbedst efter ikke at behøve det.
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 dobbelt-hentnings-risikoen. WordPress sætter den selv på det formodede LCP-billede i mange tilfælde, og cache-plugins gør det mere præcist. Den anden retning er lige så nyttig: fetchpriority="low" på pynt over folden (dekorative ikoner, badges), så de ikke konkurrerer med det vigtige.
crossorigin – ellers hentes de to gange. Klassikeren blandt preload-fejl.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.
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.
Langt hen ad vejen, jo – FlyingPress og LiteSpeed håndterer font-preload og LCP-prioritet fornuftigt. Din opgave er at lade være med at lægge manuelle hints oveni – og at verificere resultatet i Netværk-fanen.
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.