Preload, prefetch och preconnect: när var och en faktiskt hjälper
Resursanvisningar är användbara när de matchar verkliga flaskhalsar i webbläsaren. Använda blint skapar de prioriteringsbrus och kan ibland göra sidor långsammare.
Innehållsförteckning
- Resursanvisningar är inte magi
- Vad webbläsaren redan gör bra
- Preload: för resurser på den aktuella sidan som upptäcks för sent
- Preload och LCP-bilder
- Prefetch: för nästa sida, inte den här
- Preconnect: för dyra anslutningar till viktiga ursprung
- DNS-prefetch: den lättare kusinen
- Så bestämmer du: ett praktiskt arbetsflöde
- 1. Identifiera flaskhalsen
- 2. Lägg till en anvisning i taget
- 3. Kontrollera prioriteringsbiverkningar
- 4. Verifiera headers och cachelagring
- Vanliga misstag
- Att preloada för mycket
- Att använda prefetch för resurser som krävs
- Att preconnecta till varje tredjepart
- Att glömma mobila förhållanden
- En enkel beslutstabell
- Den lugna regeln
Resursanvisningar är inte magi
preload, prefetch och preconnect behandlas ofta som en checklista för prestanda. Lägg till några taggar i <head>, kör Lighthouse igen, känn dig nöjd. Det är inte så de fungerar.
Dessa anvisningar är instruktioner till webbläsarens laddningspipeline. De kan hjälpa när du vet något som webbläsaren inte kan upptäcka tillräckligt tidigt. De kan skada när du gissar, överprioriterar icke-kritiskt arbete eller värmer upp anslutningar som användarna aldrig behöver.
Den korta versionen:
- Använd
preloadför resurser som krävs för den aktuella sidan, men som upptäcks för sent. - Använd
prefetchför sannolika resurser vid framtida navigering, inte för nödvändigheter på den aktuella sidan. - Använd
preconnectför viktiga tredjepartsursprung där anslutningsetablering är en verklig fördröjning.
Den praktiska frågan är inte ”vilken anvisning är snabbast?” Det är ”vad väntar webbläsaren på, och kan den här anvisningen ta bort den väntan?”
Vad webbläsaren redan gör bra
Moderna webbläsare är inte passiva filhämtare. De tolkar HTML, skannar framåt efter resurser, tilldelar prioriteringar, återanvänder anslutningar, skjuter upp arbete som inte är synligt och anpassar sig efter nätverksförhållanden.
Det betyder att resursanvisningar bör vara selektiva. Om en stilmall, ett script, en bild eller ett typsnitt redan upptäcks tidigt och får rätt prioritet kan en extra anvisning inte göra någon skillnad. Än värre: den kan konkurrera med resurser som spelar större roll.
Innan du lägger till anvisningar, titta på en waterfall-spårning i DevTools eller en labbrapport. Om du använder Lighthouse, börja med diagnostiken snarare än poängen; vi har en separat guide om att läsa en Lighthouse-rapport utan panik — men observera att rätt URL är skiftlägeskänslig, så använd den länkade artikeln från webbplatsens navigering vid behov.
De verkliga bevisen syns vanligtvis på tre ställen:
- En kritisk resurs startar sent eftersom webbläsaren upptäcker den sent.
- En anslutning till ett viktigt ursprung tar märkbar tid före den första förfrågan.
- En resurs för nästa sida är mycket förutsägbar och billig att hämta under inaktiv tid.
Om inget av detta stämmer är en anvisning förmodligen dekoration.
Preload: för resurser på den aktuella sidan som upptäcks för sent
preload säger till webbläsaren: ”Hämta den här resursen nu eftersom den aktuella sidan kommer att behöva den.”
Ett typiskt exempel är ett webbtypsnitt som refereras inuti CSS. Webbläsaren måste ladda ner HTML, upptäcka CSS, ladda ner CSS, tolka den, upptäcka typsnittet och sedan begära typsnittet. Om typsnittet är viktigt för text ovanför vikningen kan upptäckten ske så sent att den orsakar layoutskiften eller fördröjd textrendering.
En preload kan flytta den förfrågan tidigare:
<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>Attributet as spelar roll. Det talar om för webbläsaren vilken typ av resurs det är, vilket påverkar prioritet, cachelagring, content security policy och förfrågningsheaders. Typsnitt behöver också oftast crossorigin, även när de serveras från samma webbplats, eftersom hämtning av typsnitt använder CORS-läge.
Bra kandidater för preload är:
- Det primära webbtypsnittet som används för synlig text.
- En hero-bild som är Largest Contentful Paint-elementet och inte kan upptäckas tidigt.
- En kritisk CSS-fil som laddas indirekt.
- En modul eller ett script som behövs mycket tidigt, men som döljs bakom ett annat script.
Dåliga kandidater för preload är:
- Varje typsnittsvikt i designsystemet.
- Bilder nedanför vikningen.
- Script som inte behövs för den initiala renderingen.
- Resurser som webbläsaren redan upptäcker i det första HTML-blocket.
Preload är kraftfullt eftersom det påverkar prioritet på den aktuella sidan. Det är också därför det är lätt att missbruka. Om du preloadar fem stora resurser hjälper du inte längre webbläsaren. Du argumenterar med den.
Typsnitt är det klassiska fallet. Att preloada en primär typsnittsfil kan hjälpa. Att preloada sex vikter och kursiveringar gör oftast saken värre. Om typsnitt är din flaskhals, åtgärda typsnittsuppsättningen först; vår guide till varför web fonts are still the easiest performance win on most sites går igenom den städningen mer detaljerat.
Preload och LCP-bilder
Att preloada en LCP-bild kan vara användbart när bilden inte syns i den initiala HTML-koden. Vanliga orsaker är CSS-bakgrundsbilder, klientrenderade komponenter eller responsiv bildlogik som dyker upp sent.
Men om din hero-bild redan finns i HTML som en <img> med rimliga srcset, sizes, dimensioner och utan lazy loading kan webbläsaren förmodligen hitta den snabbt. I så fall kan fetchpriority='high' vara mer lämpligt än preload, beroende på sidan.
Ett bra test: om bildförfrågan startar sent i waterfall-vyn och blir LCP-elementet, överväg preload. Om den startar tidigt men laddas ner långsamt är problemet storlek, format, CDN-beteende eller serverlatens — inte upptäckt. För beslut om bildformat, se when AVIF beats WebP and when it does not.
Prefetch: för nästa sida, inte den här
prefetch säger till webbläsaren: ”Den här resursen kan behövas snart, men den krävs inte just nu.”
Den skillnaden är viktig. Prefetch har avsiktligt låg prioritet. Webbläsaren kan hämta den under inaktiv tid och lagra den för senare användning. Den kan också hoppa över den vid dåliga anslutningar, databesparingslägen eller minnestryck.
Använd prefetch när användarens avsikt är tillräckligt stark för att göra nästa resurs sannolik.
Bra kandidater för prefetch är:
- Nästa steg i en flersidig kassa.
- Sökresultat efter att en användare börjar skriva en fråga, om nästa rutt är förutsägbar.
- Dokumentationssidor länkade från en innehållsförteckning när användaren aktivt läser närliggande innehåll.
- Rutt-chunks i en single-page app efter att en användare hovrar över eller fokuserar ett navigationsobjekt.
Dåliga kandidater för prefetch är:
- Hela ditt navigationsträd.
- Stora videor eller bildgallerier.
- Tredjepartsscript ”för säkerhets skull”.
- Sidor som användare sällan besöker härnäst.
Prefetch är ett område där återhållsamhet lönar sig. En resurs som hämtas men aldrig används är inte gratis. Den förbrukar bandbredd, serverkapacitet, energi och möjligen användardata. På mobilnät kan spekulativ hämtning vara aktivt ovänlig.
För många webbplatser är den bästa prefetch-strategin avsiktsbaserad. Prefetcha inte prissidan så snart startsidan laddas. Prefetcha den när användaren öppnar prismeny, hovrar över prislänken eller scrollar nära en uppmaning som starkt förutsäger navigering.
Kom också ihåg att webbläsarbeteende varierar. Vissa webbläsare är konservativa med prefetch; vissa sekretessinställningar minskar eller inaktiverar spekulativ laddning. Behandla prefetch som en opportunistisk förbättring, inte som en mekanism för korrekthet.
Preconnect: för dyra anslutningar till viktiga ursprung
preconnect säger till webbläsaren: ”Börja etablera en anslutning till det här ursprunget nu.”
Det kan omfatta DNS-uppslagning, TCP-anslutning och TLS-förhandling. För tredjepartsursprung kan denna etablering ta hundratals millisekunder, särskilt på nätverk med hög latens. Om sidan snart behöver en kritisk förfrågan från det ursprunget kan preconnect göra den senare förfrågan snabbare.
Exempel:
<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>Bra kandidater för preconnect är:
- Ett typsnittsursprung som används för renderingsblockerande text.
- Ett kritiskt API-ursprung som behövs under initial interaktion.
- Ett CDN-ursprung som levererar resurser ovanför vikningen.
- En betalnings- eller identitetsleverantör som behövs direkt efter en användaråtgärd.
Dåliga kandidater för preconnect är:
- Analytics- och annonsendpoints som inte är användarkritiska.
- Ursprung som bara används i vissa sessioner.
- Långa listor med tredjepartsaktörer.
- Resurser från samma ursprung, där webbläsaren redan har eller snart kommer att öppna anslutningen.
Preconnect har en hållkostnad. Öppna sockets förbrukar minne och nätverksresurser. Webbläsare stänger oanvända anslutningar, men det gör inte onödiga preconnects harmlösa.
En användbar regel: preconnecta till högst ett eller två tredjepartsursprung med hög säkerhet på en sida. Om du frestas att lägga till fler behöver din tredjepartsarkitektur troligen en översyn mer än dina anvisningar behöver utökas.
DNS-prefetch: den lättare kusinen
Du kan också se dns-prefetch:
<link rel='dns-prefetch' href='https://example-cdn.com'>Detta löser bara domännamnet. Det öppnar inte en TCP- eller TLS-anslutning. Det är billigare än preconnect, men också mindre hjälpsamt.
DNS-prefetch kan vara rimligt för tredjepartsursprung med lägre säkerhet där full preconnect känns för aggressivt. I praktiken: om ett ursprung är kritiskt och definitivt kommer att användas snart, föredra preconnect. Om det bara är möjligt, använd antingen DNS-prefetch eller gör ingenting.
Så bestämmer du: ett praktiskt arbetsflöde
Börja med mätning, inte taggar.
1. Identifiera flaskhalsen
Öppna en prestandaspårning och leta efter sen upptäckt. Startade förfrågan för typsnittet, hero-bilden eller scriptet först efter att en annan fil hade laddats ner och tolkats? Det är en preload-kandidat.
Om en förfrågan startar först efter en lång DNS/TCP/TLS-etablering till ett tredjepartsursprung är det en preconnect-kandidat.
Om den aktuella sidan är bra men nästa navigering är förutsägbart långsam kan prefetch hjälpa.
2. Lägg till en anvisning i taget
Resursanvisningar samverkar. Lägg till en, testa den och behåll den bara om waterfall-vyn förbättras och användarnära mätvärden inte försämras.
För preload, kontrollera om den anvisade resursen faktiskt används snart. Chrome kan varna när en preloadad resurs inte används kort efter laddning. Ta den varningen på allvar.
3. Kontrollera prioriteringsbiverkningar
En preload kan dra bandbredd från CSS, JavaScript eller bilder som är viktigare. En preconnect kan uppta en anslutningsplats. En prefetch kan lägga till bakgrundstrafik.
Det rätta resultatet är inte ”den anvisade filen startar tidigare.” Det rätta resultatet är ”sidan blir märkbart bättre för användarna.” Titta på LCP, INP, CLS och real-user monitoring där det är möjligt.
4. Verifiera headers och cachelagring
Anvisningar kan skickas i HTML eller HTTP Link headers. Headers är användbara när servern tidigt vet vad sidan kommer att behöva, men de är svårare att inspektera snabbt. Om du felsöker om en anvisning faktiskt finns i produktion spelar råa headers roll; det är precis den typ av situation som tas upp i our guide to debugging redirects and HTTP headers.
Cachelagring spelar också roll. Att preloada en resurs med felmatchade inloggningsuppgifter, fel as eller andra URL-parametrar kan orsaka dubbla nedladdningar. Det är ett av de vanligaste sätten en välmenande preload blir ett prestandafel.
Vanliga misstag
Att preloada för mycket
Om allt är kritiskt är inget det. Begränsa preload till resurser som behövs för initial rendering eller omedelbar interaktivitet. En typisk sida bör ha noll till tre preloads, inte tjugo.
Att använda prefetch för resurser som krävs
Prefetch har låg prioritet och är valfritt. Använd det inte för resurser som krävs av den aktuella sidan. Om sidan behöver den nu, överväg preload eller normal HTML-upptäckt.
Att preconnecta till varje tredjepart
Sidor med många tredjepartsberoenden har ofta tio eller fler externa ursprung. Att preconnecta till alla skapar brus. Välj den ena eller de två som både är kritiska och används förutsägbart.
Att glömma mobila förhållanden
Resursanvisningar är mest värdefulla på långsammare anslutningar, men också farligast där. En bortkastad prefetch på en snabb stationär anslutning är ett avrundningsfel. På ett begränsat mobilabonnemang är det en dålig avvägning.
En enkel beslutstabell
| Situation | Bästa anvisning | Varför | |---|---:|---| | Kritiskt typsnitt som upptäcks via CSS | preload | Den aktuella sidan behöver det, upptäckten är sen | | Hero-bild dold bakom CSS eller klientrendering | preload | Kan förbättra LCP om bilden startar sent | | Sannolik nästa rutt efter användaravsikt | prefetch | Hjälper framtida navigering utan att blockera den aktuella sidan | | Kritiskt typsnitts-/API-ursprung från tredje part | preconnect | Tar bort anslutningsetablering från den kritiska vägen | | Möjligt men osäkert tredjepartsursprung | dns-prefetch eller inget | Lägre kostnad, lägre säkerhet | | Bild nedanför vikningen | inget | Låt lazy loading och webbläsarens prioritet arbeta |
Den lugna regeln
Resursanvisningar fungerar bäst när de är tråkiga och specifika. Ett typsnitt. En LCP-bild. Ett viktigt tredjepartsursprung. En sannolik nästa rutt efter avsikt.
De fungerar dåligt när de används som optimism: kanske behöver användaren detta, kanske borde webbläsaren hämta det där, kanske betyder fler anvisningar mer hastighet.
Webbläsare optimerar redan aggressivt. Din uppgift är inte att detaljstyra varje förfrågan. Din uppgift är att korrigera de få fall där webbläsaren saknar information vid rätt ögonblick.
Vanliga frågor
Bör jag preloada alla mina typsnitt?
Är prefetch säkert att använda för varje intern länk?
Vad är skillnaden mellan preconnect och dns-prefetch?
Kan resursanvisningar förbättra Core Web Vitals?
Bör resursanvisningar läggas till i HTML eller HTTP-headers?
Källor och vidare läsning
