Prefetch och preload: styr webbläsarens laddning och LCP

Prefetch och preload är två olika sätt att tala om för webbläsaren vilka filer den ska hämta, och i vilken ordning, för att din sida ska kännas snabbare. De ser nästan likadana ut i koden, en <link rel>-tagg med ett par attribut, men de löser helt olika problem. Det ena skyndar på något som behövs just nu. Det andra laddar i förväg något som troligen behövs strax. Blandas de ihop är det lätt hänt att sidan blir långsammare i stället för snabbare, och då försvinner mycket av den vinst du är ute efter med sidhastighet.

Tänk dig en besökare som öppnar din startsida. Webbläsaren läser HTML uppifrån och ner, hittar resurser och laddar dem i en viss ordning. Med ett resurstips kan den ordningen ändras. Det är här prefetch, preload och deras släktingar kommer in. De är hints, vänliga tips till webbläsaren, inte kommandon den måste lyda, och hur snabbt sidan till slut känns påverkar i sin tur både klickfrekvens (CTR) i sökresultatet och hur många besökare som faktiskt stannar.

★ SNABBVERSIONEN

Preload hämtar en resurs som behövs på den aktuella sidan med högre prioritet, ofta för att förbättra LCP och FCP.
Prefetch hämtar med låg prioritet något som sannolikt behövs på nästa sida, när webbläsaren är ledig.
Prerender går längre och förbereder en hel sida i bakgrunden, men kostar mer resurser.
Preconnect öppnar bara förbindelsen i förväg (DNS, TCP, SSL) utan att hämta någon fil.
Allt detta är hints; en webbläsare som inte stöder dem hoppar tyst över dem.

Vad är prefetch och preload egentligen?

Båda är värden på attributet rel i en länktagg. En <link rel="preload"> eller <link rel="prefetch"> placeras i sidans <head> (eller injiceras med JavaScript), och webbläsaren tolkar tipset. Skillnaden ligger i prioritet och tidpunkt, och båda hör till den bredare verktygslådan för sidhastighet.

En preload link säger: den här filen behövs på den här sidan, hämta den tidigt och med hög prioritet även innan den stötts på i koden. Det är användbart för resurser som upptäcks sent, till exempel ett typsnitt som först nämns i ett CSS-regelverk via @font-face, eller en hjältebild som laddas via CSS i stället för en vanlig <img>. Driver du sajten på WordPress finns det dessutom praktiska grepp i guiden om SEO för WordPress som rör hur teman laddar typsnitt.

En prefetch link säger: den här filen kommer troligen att behövas snart, men inte nu, så hämta den vid ledig tid. Resursen läggs i cachen med låg prioritet. När besökaren sedan klickar vidare ligger filen redan där.

Den enkla minnesregeln: preload är för nuet och brådska, prefetch är för framtiden och spekulation. Väljs fel av de två stjäls antingen bandbredd från det som syns nu, eller så missas vinsten med att förbereda nästa steg.

Hur ser koden ut i praktiken?

Syntaxen följer samma mönster. En prefetch link rel prefetch pekar ut en URL med ett href. En rel preload link rel gör samma sak men kräver oftast att as anges, så att webbläsaren vet vilken typ av resurs det handlar om (typsnitt, skript, stil, bild). Anges typen fel kan filen hämtas två gånger, vilket motverkar hela poängen med ett snabbt laddningsförlopp.

<link rel="preload" as="font" href="..."> för ett typsnitt på aktuell sida.
<link rel="prefetch" href="..."> för en sida eller resurs som besökaren tros gå till härnäst.
<link rel="preconnect" href="https://fonts.googleapis.com"> för att öppna förbindelsen i förväg.
<link rel="prerender" href="..."> (eller motsvarande regel) för att förbereda en hel nästa sida.

En link rel preload link behöver as, medan en enkel prefetch link rel ofta klarar sig utan. Det beror på att preload agerar direkt och måste veta hur resursen ska prioriteras, medan prefetch bara fyller cachen för senare bruk. Var de här filerna laddar långsamt syns ofta i en mätning, något du kan följa upp via rapporterna i Google Search Console.

Varför spelar det här någon roll för sidhastigheten?

Hastighet handlar inte bara om hur stora filerna är, utan om i vilken ordning de hämtas och när de blir användbara. Två mått nämns ofta: FCP, när det första innehållet ritas ut, och LCP, när det största synliga elementet är klart. Båda påverkas av vilka resurser som hämtas tidigt, och de utgör en central del av arbetet med att optimera sidhastigheten. Enligt Googles tröskelvärden bör LCP ligga under 2,5 sekunder för att räknas som bra, och en sent upptäckt resurs kan ensam äta upp en stor del av den marginalen.

Om det viktigaste typsnittet upptäcks sent ser besökaren först osynlig eller fel text, och sedan ett hopp när rätt typsnitt laddats. Med en rel preload link kan hämtningen startas tidigare och upplevelsen jämnas ut. På liknande sätt kan en preload av hjältebilden förbättra LCP. Hur de här siffrorna utvecklas över tid följer du enklast i data från Search Console.

Prefetch jobbar i andra änden. Den gör inget för den aktuella sidan, men kan göra nästa sidladdning nästan omedelbar. Det märks tydligast på sajter med tydliga navigeringsmönster, där en stor andel går från sida A till sida B, ett mönster som ofta hänger ihop med en genomtänkt innehållsstrategi.

Preload förbättrar i regel upplevd laddningstid på den sida besökaren tittar på.
Prefetch förbättrar navigeringen vidare, inte den aktuella sidan.
Preconnect minskar fördröjningen mot en extern server, till exempel googleapis com för typsnitt.
Prerender kan få nästa sida att kännas ögonblicklig, men till en högre kostnad i minne och data.

Vad betyder de olika prioriteterna?

Webbläsaren har en intern kö där resurser får olika prioritet. En preload-resurs får higher priority och hämtas före mindre brådskande filer. En prefetch-resurs får lägst prioritet och får vänta tills annat är klart. Just därför ska inte allt preloadas, för då blir ingenting prioriterat och problemet har bara flyttats runt. I praktiken räcker det ofta med en handfull preload-taggar per sida; går antalet över tio eller femton är det ett tecken på att resursen läggs på fel ställe, något som annars läcker bort samma sorts hastighet som resten av ditt sidhastighetsarbete försöker vinna.

Prefetch, preload, prerender och preconnect, vad är skillnaden?

De fyra resurstipsen löser olika delar av samma problem. Det är lätt att blanda ihop dem, så här står de sida vid sida.

Hämtar en fil

Preload och prefetch laddar faktiskt ner en resurs. Preload gör det nu med hög prioritet för aktuell sida. Prefetch gör det när webbläsaren är ledig, för en trolig nästa sida.

Förbereder mer än en fil

Prerender med rel prerender (eller link rel prerender href) förbereder en hel sida i bakgrunden. Preconnect hämtar ingen fil alls, utan öppnar bara förbindelsen i förväg.

Här är en jämförelse av när respektive tips typiskt används:

Resurstips	Vad det gör	När du använder det
Preload	Hämtar kritisk resurs nu, hög prioritet	Typsnitt, hjältebild, sent upptäckt fil
Prefetch	Hämtar resurs för nästa sida, låg prioritet	Trolig nästa sida i ett känt flöde
Prerender	Förbereder hela nästa sida	Mycket hög sannolikhet att sidan besöks
Preconnect	Öppnar DNS, TCP och SSL i förväg	Extern server som googleapis.com

Ett vanligt missförstånd är att prerender och prefetch är samma sak fast olika starka. Skillnaden är större än så. En link rel prerender href bygger upp nästa sida med allt vad det innebär av skript och rendering, medan prefetch bara fyller cachen med råa filer. Prerender kostar därför mer och bör användas sparsamt. Vill du se hur andra sajter i din nisch hanterar laddning kan en konkurrentanalys ge en fingervisning.

Vad är Speculation Rules och hur passar det in?

I nyare Chrome finns The Speculation Rules, ett API där regler beskrivs i ett skript för vilka URLs webbläsaren får prefetcha eller prerendera, och hur ivrigt. I stället för en tagg per länk anges mönster.

Webbläsaren kan be att förbereda alla länkar i huvudmenyn.
Den kan styras att agera först vid hovring, inte direkt vid sidladdning.
Kontrollen blir mer finkornig än vad enskilda rel prerender href-taggar ger.

Det här är ett område som utvecklas snabbt och där stödet varierar mellan webbläsare. För den som vill läsa mer i detalj är MDN en bra och uppdaterad källa, men för det praktiska hänger det ihop med din övergripande innehållsstrategi för hur sidorna länkar till varandra. Allt fler söker dessutom via AI-svar, och hur en sida laddar spelar roll även för synlighet i generativa sökmotorer (GEO).

Vanliga missförstånd om prefetch och preload

Det cirkulerar en del halvsanningar om de här teknikerna, ofta från trådar på Stack Overflow där svaren blandar ihop begreppen. Här är några av de vanligaste.

💡

VANLIG MISS

Att preloada allt gör inte sidan snabbare. Om allt har hög prioritet har ingenting det. Preloada bara ett fåtal verkligt kritiska resurser, som det typsnitt eller den bild som annars upptäcks för sent.

“Prefetch gör aktuell sida snabbare.” Nej, prefetch rör nästa sida. Den påverkar inte det besökaren ser nu.
“Preload och prerender är samma sak.” Nej, preload hämtar en fil, prerender bygger en hel sida.
“Fler hints är alltid bättre.” Nej, för många kan minska vinsten genom att slösa bandbredd och batteri.
“En hint är ett kommando.” Nej, den följs inte alltid; webbläsaren får avgöra.
“Det funkar likadant i alla webbläsare.” Nej, beteendet skiljer sig, särskilt för prerender.

Den sista punkten är värd att stanna vid. Eftersom resurstipsen är just tips, inte order, kan en webbläsare välja att inte agera, till exempel vid lågt batteri eller en dyr mobiluppkoppling. Det är en feature, inte en bugg, och påminner om varför du alltid bör verifiera i en mätning snarare än att lita på teorin, gärna med hjälp av Google Search Console.

Påverkar prefetch och preload SEO direkt?

Inte direkt på det sätt många tror. Google rankar inte en sida högre bara för att den har en preload link. Men sidhastighet och hur snabbt sidan känns är en del av användarupplevelsen, och den väger in. Det hänger ihop med hur Google bedömer kvalitet och tillit över lag, något du kan läsa mer om i förklaringen av E-E-A-T. Snabbare sidor i kombination med bra innehåll brukar prestera bättre, så indirekt finns en koppling, ungefär som när snabb laddning samspelar med konverteringsoptimering och faktiskt påverkar hur många som stannar.

Så använder du prefetch och preload i praktiken

Innan en enda tagg rörs: mät först. Använd ett hastighetsverktyg och titta i Search Console på hur sidorna presterar. Då framgår det om problemet ligger i laddningsordningen eller någon annanstans, som tunga bilder eller för många skript.

Mät nuläget med ett hastighetsverktyg och notera FCP och LCP.
Hitta den resurs som upptäcks sent men behövs tidigt, ofta ett typsnitt.
Lägg en preload på den resursen och ange rätt typ med as.
Identifiera den vanligaste nästa sidan i ett känt flöde.
Lägg en sparsam prefetch på den sidan eller dess tyngsta resurs.
Mät igen och behåll bara de hints som faktiskt hjälpte.

Det mesta av det här går att göra själv, även utan dyra verktyg. Många hastighetsverktyg är gratis, och i WordPress finns plugins som kan injicera preload-taggar, något som tas upp närmare i guiden om SEO för WordPress. Var bara försiktig så att inte flera plugins staplas som gör samma sak. Driver du ett lokalt företag är snabba sidor extra värdefulla, exempelvis när någon googlar på mobilen, vilket vi går in på i guiden om lokal SEO i Göteborg.

Vilka resurser är värda att preloada?

Fokus bör ligga på det som syns först och annars laddas sent. Generellt gäller att ju tidigare en kritisk resurs hämtas, desto jämnare blir upplevelsen, vilket är samma grundtanke som löper genom hela arbetet med sidhastighet.

Det huvudtypsnitt som används i rubriker ovanför vikningen.
En hjältebild som laddas via CSS i stället för en vanlig <img>.
Ett kritiskt skript som behövs för att sidan ska bli användbar.
En stilmall som annars upptäcks sent i kedjan.

Några fällor återkommer hos den som precis upptäckt teknikerna:

Att preloada resurser som redan hittas tidigt i HTML, vilket bara skapar dubbelarbete.
Att glömma as på en rel preload link rel, så filen hämtas två gånger.
Att prefetcha tunga sidor som sällan besöks och därmed slösa data.
Att lita på prerender brett, trots att stödet är ojämnt utanför Chrome.

🥷

NINJA-FAKTA

🥷 Preconnect är ofta den billigaste vinsten. Att i förväg öppna förbindelsen (DNS, TCP och SSL) mot en extern server som fonts.googleapis.com kostar nästan inget och kan korta laddningen med flera tiondels sekunder. Den hämtar ingen fil, den röjer bara vägen.

Hur samspelar resurstips med servern och cachen?

En sak som lätt glöms bort är att det som hämtas i förväg behöver ligga kvar. Servern styr det via Cache-Control. Om servern säger åt webbläsaren att inte cacha, eller att resursen snabbt blir för gammal, kan en prefetch vara bortkastad när besökaren väl klickar vidare, och då går en bit av den hastighetsvinst du jobbat för förlorad.

Sätt rimlig Cache-Control på resurser som prefetchas, så de finns kvar.
Se till att en preloadad fil verkligen används på sidan, annars varnar webbläsaren.
Tänk på att hämtning från servern fortfarande kostar en rundresa om förbindelsen är ny.
Kom ihåg att preconnect kan förkorta just den rundresan mot servern.

För resurser från en annan domän, till exempel typsnitt från googleapis, är preconnect ofta första steget innan preload ens övervägs. Vägen öppnas, sedan sker hämtningen. Att hålla ordning på externa förbindelser hör ihop med hur väl Google hittar och förstår sajten, vilket du kan följa upp i Search Console. Vill du dessutom hjälpa sökmotorn att tolka själva innehållet rätt är strukturerad data ett separat men närliggande spår.

Spelar det roll för SPAs och dynamiska sajter?

Ja, ofta mer där. I SPAs sker navigering med JavaScript utan full omladdning, och då kan prefetch av nästa vys data eller skript göra övergången nästan omedelbar. Många ramverk gör det här automatiskt i bakgrunden, men det är bra att förstå vad som händer under huven, särskilt om en snabb övergång ska stötta din konverteringsoptimering.

För en vanlig innehållssajt är vinsten mindre dramatisk, men en väl placerad preload av typsnitt kan ändå märkas. Det viktiga är att matcha tekniken mot hur sajten faktiskt används, något som blir tydligare när du har en genomtänkt innehållsstrategi i botten.

Var hittar du tillförlitlig dokumentation?

Eftersom beteendet ändras mellan webbläsarversioner lönar det sig att kolla en uppdaterad källa innan ett tips används brett. MDN beskriver attributen och deras stöd, och i Chrome dokumenteras nyheter som The Speculation Rules tidigt.

Översikt

Resurstipsen ordnade från lättast till tyngst: preconnect, preload, prefetch, prerender.

Kontrollera aktuellt webbläsarstöd innan prerender används brett.
Verifiera syntaxen för en rel preload link mot en uppdaterad referens som MDN.
Mät effekten i ett verktyg i stället för att gissa.

Börja smått. Lägg en enda preload på det viktigaste typsnittet, mät, och bygg ut därifrån bara om siffrorna blir bättre. Att jaga varje millisekund med dussintals hints brukar ge mindre än att fixa grunderna: komprimerade bilder, vettig cache och färre tunga skript. Vill du gå djupare på hela ämnet finns mer att läsa i guiden om sidhastighet, och har du frågor är det bara att höra av sig.

Vanliga frågor

Vad är skillnaden mellan prefetch och preload?

Preload säger åt webbläsaren att hämta en resurs som behövs på den aktuella sidan med högre prioritet, till exempel ett typsnitt eller en bild ovanför vikningen. Prefetch hämtar i stället något som sannolikt behövs på nästa sida, och gör det med låg prioritet när webbläsaren är ledig. Preload handlar om nuvarande sida och brådska, prefetch om framtida navigering och spekulation. Väljs fel av de två kan bandbredd stjälas från det som syns nu, eller vinsten med att förbereda nästa steg gå förlorad.

När ska preload användas i stället för prefetch?

Preload passar när en resurs är kritisk för det som syns direkt men upptäcks sent av webbläsaren, till exempel ett typsnitt som laddas via @font-face eller en bakgrundsbild i CSS. Då startar hämtningen tidigare och både LCP och FCP kan förbättras. Preload bör inte användas för sådant som redan hittas tidigt i HTML, eftersom resursen då bara konkurrerar med sig själv. Prefetch passar bättre när resursen hör till en trolig nästa sida och inte behövs förrän besökaren faktiskt klickar vidare.

Skadar prefetch sidhastigheten om det används fel?

Ja, det kan hända. Prefetch är tänkt att köra med låg prioritet, men vid för mycket prefetch eller fel tidpunkt kan bandbredd, batteri och dataförbrukning ändå ätas upp hos besökaren, särskilt på mobil. Filer som kanske aldrig används laddas ner. Var sparsam: prefetcha bara sidor eller resurser med hög sannolikhet att besökas, och låt servern skicka rätt Cache-Control så att det som hämtas i förväg faktiskt ligger kvar i cachen när det behövs.

Stöder alla webbläsare prefetch och preload?

Stödet skiljer sig. Preload med rel preload har brett stöd i moderna webbläsare. Prefetch med rel prefetch stöds också allmänt, men hur aggressivt webbläsaren agerar varierar. Prerender och de nyare Speculation Rules är mest utbyggt i Chrome och hanteras mer försiktigt eller inte alls i andra. Aktuellt stöd går att kontrollera på MDN. Eftersom det rör sig om hints, tips snarare än order, ignorerar en webbläsare som inte förstår dem helt enkelt taggen utan att något går sönder.

Relaterade termer

Indexering GEO

✉️

VILL DU FÖRSTÅ MER?

Undrar du hur det funkar i praktiken för just din sajt? Hör av dig.