Preload, prefetch og preconnect: når hver av dem faktisk hjelper
Ressurshint er nyttige når de treffer reelle flaskehalser i nettleseren. Brukt ukritisk skaper de prioritetsstøy og kan noen ganger gjøre sider tregere.
Innholdsfortegnelse
- Ressurshint er ikke magi
- Hva nettleseren allerede gjør godt
- Preload: for ressurser på gjeldende side som oppdages for sent
- Preload og LCP-bilder
- Prefetch: for neste side, ikke denne
- Preconnect: for kostbare forbindelser til viktige opprinnelser
- DNS-prefetch: den lettere slektningen
- Slik bestemmer du: en praktisk arbeidsflyt
- 1. Identifiser flaskehalsen
- 2. Legg til ett hint om gangen
- 3. Sjekk prioriteringsbivirkninger
- 4. Verifiser hoder og hurtigbufring
- Vanlige feil
- Å forhåndslaste for mye
- Å bruke prefetch for nødvendige ressurser
- Å preconnecte til hver tredjepart
- Å glemme mobile forhold
- En enkel beslutningstabell
- Den rolige regelen
Ressurshint er ikke magi
preload, prefetch og preconnect blir ofte behandlet som en sjekkliste for ytelse. Legg til noen tagger i <head>, kjør Lighthouse på nytt, føl deg bedre. Det er ikke slik de fungerer.
Disse hintene er instruksjoner til nettleserens innlastingsløp. De kan hjelpe når du vet noe nettleseren ikke kan oppdage tidlig nok. De kan skade når du gjetter, overprioriterer ikke-kritisk arbeid eller varmer opp forbindelser brukerne aldri trenger.
Kortversjonen:
- Bruk
preloadfor ressurser som kreves av den gjeldende siden, men som oppdages for sent. - Bruk
prefetchfor sannsynlige ressurser til fremtidig navigasjon, ikke nødvendige ressurser for gjeldende side. - Bruk
preconnectfor viktige tredjepartsopprinnelser der oppsett av forbindelse er en reell forsinkelse.
Det praktiske spørsmålet er ikke «hvilket hint er raskest?» Det er «hva venter nettleseren på, og kan dette hintet fjerne den ventingen?»
Hva nettleseren allerede gjør godt
Moderne nettlesere er ikke passive filnedlastere. De tolker HTML, skanner fremover etter ressurser, tildeler prioritet, gjenbruker forbindelser, utsetter arbeid som ikke er synlig, og tilpasser seg nettverksforhold.
Det betyr at ressurshint bør brukes selektivt. Hvis et stilark, script, bilde eller en font allerede oppdages tidlig og får riktig prioritet, kan et ekstra hint gjøre ingenting. Enda verre: det kan konkurrere med ressurser som betyr mer.
Før du legger til hint, se på en waterfall-sporing i DevTools eller en labrapport. Hvis du bruker Lighthouse, start med diagnostikken i stedet for poengsummen; vi har en egen guide om å lese en Lighthouse-rapport uten panikk — men merk at riktig URL skiller mellom store og små bokstaver, så bruk den lenkede artikkelen fra nettstednavigasjonen din ved behov.
De reelle bevisene er vanligvis synlige på tre steder:
- En kritisk ressurs starter sent fordi nettleseren oppdager den sent.
- En forbindelse til en viktig opprinnelse tar merkbar tid før den første forespørselen.
- En ressurs for neste side er svært forutsigbar og billig å hente i inaktiv tid.
Hvis ingen av disse stemmer, er et hint sannsynligvis bare pynt.
Preload: for ressurser på gjeldende side som oppdages for sent
preload forteller nettleseren: «Hent denne ressursen nå fordi den gjeldende siden vil trenge den.»
Et typisk eksempel er en webfont som refereres inne i CSS. Nettleseren må laste ned HTML, oppdage CSS, laste ned CSS, tolke den, oppdage fonten og deretter be om fonten. Hvis den fonten er viktig for tekst som er synlig ved første visning, kan oppdagelsen skje sent nok til å gi layoutforskyvninger eller forsinket tekstgjengivelse.
En preload kan flytte den forespørselen tidligere:
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>Attributtet as er viktig. Det forteller nettleseren hvilken type ressurs dette er, noe som påvirker prioritet, hurtigbuffer, content security policy og forespørselshoder. Fonter trenger også vanligvis crossorigin, selv når de serveres fra samme nettsted, fordi henting av fonter bruker CORS-modus.
Gode kandidater for preload inkluderer:
- Den primære webfonten som brukes til synlig tekst.
- Et hero-bilde som er Largest Contentful Paint-elementet og ikke kan oppdages tidlig.
- En kritisk CSS-fil som lastes indirekte.
- En modul eller et script som trengs svært tidlig, men som er skjult bak et annet script.
Dårlige kandidater for preload inkluderer:
- Hver eneste fontvekt i designsystemet.
- Bilder under bretten.
- Script som ikke trengs for innledende gjengivelse.
- Ressurser nettleseren allerede oppdager i den første HTML-biten.
Preload er kraftig fordi det påvirker prioritet på gjeldende side. Det er også derfor det er lett å misbruke. Hvis du forhåndslaster fem store ressurser, hjelper du ikke lenger nettleseren. Du krangler med den.
Fonter er det klassiske tilfellet. Å forhåndslaste én primær fontfil kan hjelpe. Å forhåndslaste seks vekter og kursiver gjør som regel ting verre. Hvis fonter er flaskehalsen din, rydd først i fontsettet; guiden vår til hvorfor webfonter fortsatt er den enkleste ytelsesgevinsten på de fleste nettsteder dekker den oppryddingen mer detaljert.
Preload og LCP-bilder
Å forhåndslaste et LCP-bilde kan være nyttig når bildet ikke er synlig i den opprinnelige HTML-en. Vanlige årsaker er CSS-bakgrunnsbilder, klientgjengitte komponenter eller responsiv bildelogikk som dukker opp sent.
Men hvis hero-bildet ditt allerede ligger i HTML som et <img> med fornuftige srcset, sizes, dimensjoner og uten lazy loading, kan nettleseren sannsynligvis finne det raskt. I så fall kan det være mer passende å legge til fetchpriority='high' enn preload, avhengig av siden.
En god test: Hvis bildeforespørselen starter sent i waterfall-visningen og blir LCP-elementet, bør du vurdere preload. Hvis den starter tidlig, men lastes ned sakte, er problemet størrelse, format, CDN-atferd eller servertid — ikke oppdagelse. For valg av bildeformat, se når AVIF slår WebP og når det ikke gjør det.
Prefetch: for neste side, ikke denne
prefetch forteller nettleseren: «Denne ressursen kan bli nødvendig snart, men den kreves ikke akkurat nå.»
Den forskjellen er viktig. Prefetch har med vilje lav prioritet. Nettleseren kan hente den i inaktiv tid og lagre den for senere bruk. Den kan også hoppe over den på dårlige forbindelser, i datasparemodus eller under minnepress.
Bruk prefetch når brukerintensjonen er sterk nok til at neste ressurs er sannsynlig.
Gode kandidater for prefetch inkluderer:
- Neste steg i en flersidig checkout.
- Søkeresultater etter at en bruker begynner å skrive et søk, hvis neste rute er forutsigbar.
- Dokumentasjonssider lenket fra en innholdsfortegnelse når brukeren aktivt leser nærliggende innhold.
- Rute-chunks i en single-page app etter at en bruker holder pekeren over eller fokuserer et navigasjonselement.
Dårlige kandidater for prefetch inkluderer:
- Hele navigasjonstreet ditt.
- Store videoer eller bildegallerier.
- Tredjepartsscript «for sikkerhets skyld».
- Sider brukerne sjelden besøker som neste steg.
Prefetch er der tilbakeholdenhet lønner seg. En ressurs som hentes og aldri brukes, er ikke gratis. Den bruker båndbredde, serverkapasitet, energi og muligens brukerens data. På mobilnett kan spekulativ henting være direkte lite brukervennlig.
For mange nettsteder er den beste prefetch-strategien intensjonsbasert. Ikke prefetch prissiden så snart forsiden lastes. Prefetch den når brukeren åpner prismenyen, holder pekeren over prislenken eller scroller nær en call-to-action som sterkt forutsier navigasjon.
Husk også at nettleseratferd varierer. Noen nettlesere er konservative med prefetch; noen personverninnstillinger reduserer eller deaktiverer spekulativ lasting. Behandle prefetch som en opportunistisk forbedring, ikke en korrekthetsmekanisme.
Preconnect: for kostbare forbindelser til viktige opprinnelser
preconnect forteller nettleseren: «Begynn å sette opp en forbindelse til denne opprinnelsen nå.»
Det kan omfatte DNS-oppslag, TCP-forbindelse og TLS-forhandling. For tredjepartsopprinnelser kan dette oppsettet ta hundrevis av millisekunder, spesielt på nettverk med høy latenstid. Hvis siden snart trenger en kritisk forespørsel fra den opprinnelsen, kan preconnect gjøre den senere forespørselen raskere.
Eksempel:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>Gode kandidater for preconnect inkluderer:
- En fontopprinnelse som brukes til tekst som blokkerer gjengivelse.
- En kritisk API-opprinnelse som trengs under innledende interaksjon.
- En CDN-opprinnelse som leverer ressurser synlige ved første visning.
- En betalings- eller identitetsleverandør som trengs umiddelbart etter brukerhandling.
Dårlige kandidater for preconnect inkluderer:
- Analyse- og annonseendepunkter som ikke er kritiske for brukeren.
- Opprinnelser som bare brukes i noen økter.
- Lange lister med tredjeparter.
- Ressurser fra samme opprinnelse, der nettleseren allerede har eller snart vil åpne forbindelsen.
Preconnect har en opprettholdelseskostnad. Åpne sockets bruker minne og nettverksressurser. Nettlesere vil lukke ubrukte forbindelser, men det gjør ikke unødvendige preconnects ufarlige.
En nyttig regel: preconnect til høyst én eller to tredjepartsopprinnelser med høy sikkerhet på en side. Hvis du blir fristet til å legge til flere, trenger tredjepartsarkitekturen din sannsynligvis mer gjennomgang enn hintene dine trenger utvidelse.
DNS-prefetch: den lettere slektningen
Du kan også se dns-prefetch:
<link rel='dns-prefetch' href='https://example-cdn.com'>Dette løser bare domenenavnet. Det åpner ikke en TCP- eller TLS-forbindelse. Det er billigere enn preconnect, men også mindre nyttig.
DNS-prefetch kan være rimelig for tredjepartsopprinnelser med lavere sikkerhet der full preconnect føles for aggressivt. I praksis: Hvis en opprinnelse er kritisk og definitivt brukes snart, foretrekk preconnect. Hvis den bare er mulig, bruk enten DNS-prefetch eller gjør ingenting.
Slik bestemmer du: en praktisk arbeidsflyt
Start med måling, ikke tagger.
1. Identifiser flaskehalsen
Åpne en ytelsessporing og se etter sen oppdagelse. Startet forespørselen om fonten, hero-bildet eller scriptet først etter at en annen fil var lastet ned og tolket? Det er en kandidat for preload.
Hvis en forespørsel først starter etter et langt DNS/TCP/TLS-oppsett til en tredjepartsopprinnelse, er det en kandidat for preconnect.
Hvis den gjeldende siden er fin, men neste navigasjon er forutsigbart treg, kan prefetch hjelpe.
2. Legg til ett hint om gangen
Ressurshint påvirker hverandre. Legg til ett, test det, og behold det bare hvis waterfall-visningen forbedres og brukerrettede målinger ikke går tilbake.
For preload, følg med på om ressursen det hintes om faktisk brukes snart. Chrome kan advare når en forhåndslastet ressurs ikke brukes kort tid etter innlasting. Ta den advarselen på alvor.
3. Sjekk prioriteringsbivirkninger
En preload kan trekke båndbredde bort fra CSS, JavaScript eller bilder som betyr mer. En preconnect kan oppta en forbindelsesplass. En prefetch kan legge til bakgrunnstrafikk.
Riktig utfall er ikke «filen det hintes om starter tidligere». Riktig utfall er «siden blir merkbart bedre for brukerne». Se på LCP, INP, CLS og real-user monitoring der det er mulig.
4. Verifiser hoder og hurtigbufring
Hint kan sendes i HTML eller HTTP Link-hoder. Hoder er nyttige når serveren tidlig vet hva siden vil trenge, men de er vanskeligere å inspisere uformelt. Hvis du feilsøker om et hint faktisk finnes i produksjon, er rå hoder viktige; dette er akkurat den typen situasjon som dekkes i guiden vår til feilsøking av redirects og HTTP headers.
Hurtigbufring betyr også noe. Å forhåndslaste en ressurs med feil credentials, feil as eller andre URL-parametere kan føre til doble nedlastinger. Det er en av de vanligste måtene en velment preload blir en ytelsesfeil på.
Vanlige feil
Å forhåndslaste for mye
Hvis alt er kritisk, er ingenting det. Begrens preload til ressurser som trengs for innledende gjengivelse eller umiddelbar interaktivitet. En typisk side bør ha null til tre preloads, ikke tjue.
Å bruke prefetch for nødvendige ressurser
Prefetch har lav prioritet og er valgfritt. Ikke bruk det for ressurser som kreves av den gjeldende siden. Hvis siden trenger det nå, vurder preload eller normal HTML-oppdagelse.
Å preconnecte til hver tredjepart
Sider med mange tredjeparter har ofte ti eller flere eksterne opprinnelser. Å preconnecte til alle skaper støy. Velg den ene eller de to som både er kritiske og forutsigbart brukes.
Å glemme mobile forhold
Ressurshint er mest verdifulle på tregere forbindelser, men også farligst der. En bortkastet prefetch på en rask desktop-forbindelse er en avrundingsfeil. På et begrenset mobilabonnement er det en dårlig byttehandel.
En enkel beslutningstabell
| Situasjon | Beste hint | Hvorfor | |---|---:|---| | Kritisk font oppdaget gjennom CSS | preload | Gjeldende side trenger den, oppdagelsen er sen | | Hero-bilde skjult bak CSS eller klientgjengivelse | preload | Kan forbedre LCP hvis bildet starter sent | | Sannsynlig neste rute etter brukerintensjon | prefetch | Hjelper fremtidig navigasjon uten å blokkere gjeldende side | | Kritisk tredjeparts font-/API-opprinnelse | preconnect | Fjerner forbindelsesoppsett fra den kritiske stien | | Mulig, men usikker tredjepartsopprinnelse | dns-prefetch eller ingen | Lavere kostnad, lavere sikkerhet | | Bilde under bretten | ingen | La lazy loading og nettleserprioritet virke |
Den rolige regelen
Ressurshint fungerer best når de er kjedelige og spesifikke. Én font. Ett LCP-bilde. Én viktig tredjepartsopprinnelse. Én sannsynlig neste rute etter intensjon.
De fungerer dårlig når de brukes som optimisme: kanskje brukeren vil trenge dette, kanskje nettleseren bør hente det, kanskje flere hint betyr mer hastighet.
Nettlesere optimaliserer allerede aggressivt. Jobben din er ikke å mikrostyre hver forespørsel. Jobben din er å korrigere de få tilfellene der nettleseren mangler informasjon i riktig øyeblikk.
Ofte stilte spørsmål
Bør jeg forhåndslaste alle fontene mine?
Er prefetch trygt å bruke for hver interne lenke?
Hva er forskjellen mellom preconnect og dns-prefetch?
Kan ressurshint forbedre Core Web Vitals?
Bør ressurshint legges til i HTML eller HTTP-hoder?
Kilder og videre lesning
