Preload, prefetch og preconnect: hvornår de hver især faktisk hjælper
Resource hints er nyttige, når de matcher reelle flaskehalse i browseren. Brugt i blinde tilføjer de prioritetsstøj og kan nogle gange gøre sider langsommere.
Indholdsfortegnelse
- Resource hints er ikke magi
- Hvad browseren allerede gør godt
- Preload: til ressourcer på den aktuelle side, der opdages for sent
- Preload og LCP-billeder
- Prefetch: til den næste side, ikke denne
- Preconnect: til dyre forbindelser til vigtige origins
- DNS-prefetch: den lettere fætter
- Sådan beslutter du: en praktisk arbejdsgang
- 1. Identificér flaskehalsen
- 2. Tilføj ét hint ad gangen
- 3. Tjek bivirkninger på prioritet
- 4. Verificér headers og caching
- Almindelige fejl
- At preloade for meget
- At bruge prefetch til påkrævede ressourcer
- At preconnecte til alle tredjeparter
- At glemme mobile forhold
- En simpel beslutningstabel
- Den rolige regel
Resource hints er ikke magi
preload, prefetch og preconnect bliver ofte behandlet som en performance-tjekliste. Tilføj et par tags til <head>, kør Lighthouse igen, og få det bedre. Sådan fungerer de ikke.
Disse hints er instruktioner til browserens indlæsningspipeline. De kan hjælpe, når du ved noget, browseren ikke kan opdage tidligt nok. De kan skade, når du gætter, overprioriterer ikke-kritisk arbejde eller varmer forbindelser op, som brugerne aldrig får brug for.
Den korte version:
- Brug
preloadtil ressourcer, der kræves på den aktuelle side, men opdages for sent. - Brug
prefetchtil sandsynlige fremtidige navigationsressourcer, ikke til nødvendige ressourcer på den aktuelle side. - Brug
preconnecttil vigtige tredjeparts-origins, hvor forbindelsesopsætning er en reel forsinkelse.
Det praktiske spørgsmål er ikke “hvilket hint er hurtigst?” Det er “hvad venter browseren på, og kan dette hint fjerne den ventetid?”
Hvad browseren allerede gør godt
Moderne browsere er ikke passive filhentere. De parser HTML, scanner fremad efter ressourcer, tildeler prioriteter, genbruger forbindelser, udskyder arbejde, der ikke er synligt, og tilpasser sig netværksforhold.
Det betyder, at resource hints bør bruges selektivt. Hvis et stylesheet, script, billede eller font allerede opdages tidligt og får den rigtige prioritet, gør et ekstra hint måske ingenting. Endnu værre: Det kan konkurrere med ressourcer, der betyder mere.
Før du tilføjer hints, så kig på en waterfall-trace i DevTools eller en laboratorierapport. Hvis du bruger Lighthouse, så begynd med diagnostikken frem for scoren; vi har en separat guide til at læse en Lighthouse-rapport uden at gå i panik — men bemærk, at den korrekte URL skelner mellem store og små bogstaver, så brug den linkede artikel fra din sides navigation, hvis det er nødvendigt.
Det reelle bevis er som regel synligt tre steder:
- En kritisk ressource starter sent, fordi browseren opdager den sent.
- En forbindelse til en vigtig origin tager mærkbar tid før den første request.
- En ressource til næste side er meget forudsigelig og billig at hente i inaktiv tid.
Hvis ingen af disse er sande, er et hint sandsynligvis pynt.
Preload: til ressourcer på den aktuelle side, der opdages for sent
preload fortæller browseren: “Hent denne ressource nu, fordi den aktuelle side får brug for den.”
Et typisk eksempel er en webfont, der refereres inde i CSS. Browseren skal hente HTML, opdage CSS, hente CSS, parse det, opdage fonten og derefter anmode om fonten. Hvis den font er vigtig for tekst i den synlige del af siden, kan opdagelsen ske så sent, at det forårsager layout shifts eller forsinket tekstgengivelse.
Et preload kan flytte den request tidligere:
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>Attributten as er vigtig. Den fortæller browseren, hvilken type ressource dette er, hvilket påvirker prioritet, caching, content security policy og request-headers. Fonts har også som regel brug for crossorigin, selv når de serveres fra samme site, fordi font-hentning bruger CORS-tilstand.
Gode kandidater til preload inkluderer:
- Den primære webfont, der bruges til synlig tekst.
- Et hero-billede, der er Largest Contentful Paint-elementet og ikke kan opdages tidligt.
- En kritisk CSS-fil, der indlæses indirekte.
- Et modul eller script, der skal bruges meget tidligt, men er skjult bag et andet script.
Dårlige kandidater til preload inkluderer:
- Alle fontvægte i designsystemet.
- Billeder under folden.
- Scripts, der ikke er nødvendige for initial rendering.
- Ressourcer, som browseren allerede opdager i den første HTML-del.
Preload er kraftfuldt, fordi det påvirker prioriteten på den aktuelle side. Det er også derfor, det er let at misbruge. Hvis du preloader fem store assets, hjælper du ikke længere browseren. Du diskuterer med den.
Fonts er det klassiske tilfælde. At preloade én primær fontfil kan hjælpe. At preloade seks vægte og kursiver gør som regel tingene værre. Hvis fonts er din flaskehals, så ryd først op i fontsættet; vores guide til hvorfor web fonts stadig er den letteste performance-gevinst på de fleste sites dækker den oprydning mere detaljeret.
Preload og LCP-billeder
Preloading af et LCP-billede kan være nyttigt, når billedet ikke er synligt i den oprindelige HTML. Almindelige årsager inkluderer CSS-baggrundsbilleder, klient-renderede komponenter eller responsive image-logik, der dukker op sent.
Men hvis dit hero-billede allerede findes i HTML som et <img> med fornuftige srcset, sizes, dimensioner og ingen lazy loading, kan browseren sandsynligvis finde det hurtigt. I det tilfælde kan det være mere passende at tilføje fetchpriority='high' end preload, afhængigt af siden.
En god test: Hvis billedets request starter sent i waterfallen og bliver LCP-elementet, så overvej preload. Hvis den starter tidligt, men downloader langsomt, er problemet størrelse, format, CDN-adfærd eller serverlatens — ikke opdagelse. For beslutninger om billedformater, se hvornår AVIF slår WebP, og hvornår det ikke gør.
Prefetch: til den næste side, ikke denne
prefetch fortæller browseren: “Denne ressource kan snart blive nødvendig, men den er ikke påkrævet lige nu.”
Den forskel er vigtig. Prefetch har med vilje lav prioritet. Browseren kan hente den i inaktiv tid og gemme den til senere brug. Den kan også springe den over på dårlige forbindelser, i data-saving modes eller under hukommelsespres.
Brug prefetch, når brugerens intention er stærk nok til at gøre den næste ressource sandsynlig.
Gode kandidater til prefetch inkluderer:
- Næste trin i en checkout over flere sider.
- Søgeresultater efter at en bruger begynder at skrive en forespørgsel, hvis den næste route er forudsigelig.
- Dokumentationssider linket fra en indholdsfortegnelse, når brugeren aktivt læser nærliggende indhold.
- Route chunks i en single-page app, efter at en bruger hover eller fokuserer på et navigationselement.
Dårlige kandidater til prefetch inkluderer:
- Hele dit navigationstræ.
- Store videoer eller billedgallerier.
- Tredjeparts-scripts “for en sikkerheds skyld.”
- Sider, som brugere sjældent besøger som det næste.
Prefetch er der, hvor tilbageholdenhed betaler sig. En ressource, der hentes og aldrig bruges, er ikke gratis. Den bruger båndbredde, serverkapacitet, energi og muligvis brugerens data. På mobilnetværk kan spekulativ hentning være direkte uvenligt.
For mange sites er den bedste prefetch-strategi intentionsbaseret. Prefetch ikke prissiden, så snart forsiden indlæses. Prefetch den, når brugeren åbner prismenuen, hover over prislinket eller scroller tæt på en call-to-action, der stærkt forudsiger navigation.
Husk også, at browseradfærd varierer. Nogle browsere er konservative med prefetch; nogle privatlivsindstillinger reducerer eller deaktiverer spekulativ indlæsning. Behandl prefetch som en opportunistisk forbedring, ikke som en korrekthedsmekanisme.
Preconnect: til dyre forbindelser til vigtige origins
preconnect fortæller browseren: “Begynd at oprette en forbindelse til denne origin nu.”
Det kan inkludere DNS-opslag, TCP-forbindelse og TLS-forhandling. For tredjeparts-origins kan denne opsætning tage hundredvis af millisekunder, især på netværk med høj latens. Hvis siden snart har brug for en kritisk request fra den origin, kan preconnect gøre den senere request hurtigere.
Eksempel:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>Gode kandidater til preconnect inkluderer:
- En font-origin, der bruges til renderingsblokerende tekst.
- En kritisk API-origin, der er nødvendig under den første interaktion.
- En CDN-origin, der serverer assets i den synlige del af siden.
- En betalings- eller identitetsudbyder, der er nødvendig umiddelbart efter brugerhandling.
Dårlige kandidater til preconnect inkluderer:
- Analytics- og annonceendpoints, der ikke er brugerkritiske.
- Origins, der kun bruges i nogle sessioner.
- Lange lister af tredjeparter.
- Ressourcer på samme origin, hvor browseren allerede har eller snart vil åbne forbindelsen.
Preconnect har en holdeomkostning. Åbne sockets bruger hukommelse og netværksressourcer. Browsere lukker ubrugte forbindelser, men det gør ikke unødvendige preconnects harmløse.
En nyttig regel: Preconnect til højst én eller to tredjeparts-origins med høj sikkerhed på en side. Hvis du bliver fristet til at tilføje flere, har din tredjepartsarkitektur sandsynligvis mere brug for et eftersyn, end dine hints har brug for udvidelse.
DNS-prefetch: den lettere fætter
Du kan også se dns-prefetch:
<link rel='dns-prefetch' href='https://example-cdn.com'>Dette resolver kun domænenavnet. Det åbner ikke en TCP- eller TLS-forbindelse. Det er billigere end preconnect, men også mindre hjælpsomt.
DNS-prefetch kan være rimeligt til tredjeparts-origins med lavere sikkerhed, hvor fuld preconnect føles for aggressivt. I praksis: Hvis en origin er kritisk og helt sikkert bruges snart, så foretræk preconnect. Hvis det blot er muligt, så brug enten DNS-prefetch eller gør ingenting.
Sådan beslutter du: en praktisk arbejdsgang
Begynd med måling, ikke tags.
1. Identificér flaskehalsen
Åbn en performance-trace, og kig efter sen opdagelse. Startede font-, hero-billede- eller script-requesten først, efter at en anden fil var hentet og parset? Det er en kandidat til preload.
Hvis en request først starter efter en lang DNS/TCP/TLS-opsætning til en tredjeparts-origin, er det en kandidat til preconnect.
Hvis den aktuelle side er fin, men den næste navigation forudsigeligt er langsom, kan prefetch hjælpe.
2. Tilføj ét hint ad gangen
Resource hints interagerer. Tilføj ét, test det, og behold det kun, hvis waterfallen forbedres, og brugerrettede metrics ikke går tilbage.
For preload skal du holde øje med, om den hintede ressource faktisk bruges kort tid efter. Chrome kan advare, når en preloadet ressource ikke bruges kort efter indlæsning. Tag den advarsel alvorligt.
3. Tjek bivirkninger på prioritet
Et preload kan trække båndbredde væk fra CSS, JavaScript eller billeder, der betyder mere. Et preconnect kan optage en forbindelsesplads. Et prefetch kan tilføje baggrundstrafik.
Det rigtige resultat er ikke “den hintede fil starter tidligere.” Det rigtige resultat er “siden bliver meningsfuldt bedre for brugerne.” Kig på LCP, INP, CLS og real-user monitoring, hvor det er muligt.
4. Verificér headers og caching
Hints kan sendes i HTML eller HTTP Link headers. Headers er nyttige, når serveren tidligt ved, hvad siden får brug for, men de er sværere at inspicere tilfældigt. Hvis du debugger, om et hint faktisk er til stede i produktion, betyder rå headers noget; det er præcis den slags situation, der dækkes i vores guide til debugging af redirects og HTTP headers.
Caching betyder også noget. Preloading af en ressource med uoverensstemmende credentials, forkert as eller forskellige URL-parametre kan forårsage dobbelte downloads. Det er en af de mest almindelige måder, et velment preload bliver til en performance-bug.
Almindelige fejl
At preloade for meget
Hvis alt er kritisk, er intet det. Begræns preload til ressourcer, der er nødvendige for initial rendering eller øjeblikkelig interaktivitet. En typisk side bør have nul til tre preloads, ikke tyve.
At bruge prefetch til påkrævede ressourcer
Prefetch har lav prioritet og er valgfrit. Brug det ikke til assets, som den aktuelle side kræver. Hvis siden har brug for det nu, så overvej preload eller normal HTML-opdagelse.
At preconnecte til alle tredjeparter
Sider med mange tredjeparter har ofte ti eller flere eksterne origins. At preconnecte til dem alle skaber støj. Vælg den ene eller de to, der både er kritiske og forudsigeligt bruges.
At glemme mobile forhold
Resource hints er mest værdifulde på langsommere forbindelser, men også farligst dér. Et spildt prefetch på en hurtig desktopforbindelse er en afrundingsfejl. På et begrænset mobilabonnement er det en dårlig handel.
En simpel beslutningstabel
| Situation | Bedste hint | Hvorfor | |---|---:|---| | Kritisk font opdaget gennem CSS | preload | Den aktuelle side har brug for den, opdagelsen er sen | | Hero-billede skjult bag CSS eller klient-rendering | preload | Kan forbedre LCP, hvis billedet starter sent | | Sandsynlig næste route efter brugerintention | prefetch | Hjælper fremtidig navigation uden at blokere den aktuelle side | | Kritisk tredjeparts font/API-origin | preconnect | Fjerner forbindelsesopsætning fra den kritiske sti | | Mulig, men usikker tredjeparts-origin | dns-prefetch eller ingen | Lavere omkostning, lavere sikkerhed | | Billede under folden | ingen | Lad lazy loading og browserprioritet virke |
Den rolige regel
Resource hints fungerer bedst, når de er kedelige og specifikke. Én font. Ét LCP-billede. Én vigtig tredjeparts-origin. Én sandsynlig næste route efter intention.
De fungerer dårligt, når de bruges som optimisme: måske får brugeren brug for dette, måske bør browseren hente det, måske betyder flere hints mere hastighed.
Browsere optimerer allerede aggressivt. Din opgave er ikke at micromanage hver request. Din opgave er at rette de få tilfælde, hvor browseren mangler information på det rigtige tidspunkt.
Ofte stillede spørgsmål
Bør jeg preloade alle mine fonts?
Er prefetch sikkert at bruge til alle interne links?
Hvad er forskellen på preconnect og dns-prefetch?
Kan resource hints forbedre Core Web Vitals?
Bør resource hints tilføjes i HTML eller HTTP headers?
Kilder & videre læsning
