När förhandsladdning av stilmallar (inte) är meningsfullt

En utforskning av övervägandena kring förhandsladdning av stilmallar för webbprestandaoptimering.

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-02-07

När förhandsladdning av stilmallar (inte) är meningsfullt

Jag stöter regelbundet på förhandsladdade stilmallar och en hel del felaktig information kring dem. Att förhandsladda en resurs ändrar (vanligtvis) dess prioritet och tidpunkten den schemaläggs för nedladdning. Dock, likt många optimeringsstrategier som jag dagligen stöter på, är förhandsladdning av stilmallar oftast inte meningsfullt. I den här artikeln kommer jag att utforska när förhandsladdning av stilmallar är meningsfullt och när det kanske inte är det bästa valet.

Idén med förhandsladdning av stilmallar:

Innan vi dyker in i övervägandena, låt oss kort gå igenom konceptet med förhandsladdning av stilmallar. Stilmallar är renderingsblockerande. Det innebär att medan stilmallar laddas ner kommer sidan inte att renderas av webbläsaren och allt besökaren ser är en tom skärm. 

För att minimera tiden det tar att ladda ner stilmallar kommer utvecklare ibland att tillgripa förhandsladdning av stilmallar. Förhandsladdning innebär att hämta kritiska resurser i förväg, vilket minimerar fördröjningen som uppstår vid laddning av dem när de faktiskt behövs. Detta uppnås vanligtvis genom att använda <link>-taggen med attributet rel="preload".

Fall 1: förhandsladdning av stilmallen precis innan den deklareras.

Ibland försöker utvecklare, i all sin entusiasm, minimera CSS-påverkan genom att förhandsladda den i HTML:en precis före den faktiska CSS-deklarationen. Det ser ut ungefär så här:

<link rel="preload" as="style" href="style.css">
<link rel="stylesheet" href="style.css">

Nu är detta inte meningsfullt alls och i bästa fall kommer du inte att sakta ner sidan! En webbläsare kommer att läsa HTML:en och börja ladda alla kritiska resurser på sidan, mestadels i den ordning den hittar dem. Det innebär att om du tog bort preload-raden skulle webbläsaren ha hittat stilmallen ändå och börjat ladda ner den oavsett. Du har bara lagt till en extra rad, det är allt! Men det blir värre. Förhandsladdade stilmallar får en lägre prioritet än vanliga stilmallar. Så i värsta fall skulle du faktiskt sakta ner din sida!

3 förhandsladdade stilmallar

3 vanliga stilmallar

Fall 2: förhandsladdning av stilmallen med en link-header.

Den här idén är intressant. Vi kan använda [url=https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Link]serverns link-header[/url] för att förhandsladda en stilmall. Det skulle se ut ungefär så här:

Link: <style.css>; rel=preload; as=style

Idén här är att få webbläsaren att köa stilmallen innan den börjar tolka HTML:en. Det här är en ganska bra idé och jag gillar hur tankarna hos utvecklaren som kom på detta fungerar! Men tyvärr får du i verkligheten väldigt liten nytta av detta. Vi pratar om några mikrosekunder. Det är ganska nedslående resultat men oroa dig inte. Vi kan använda detta steg för att göra några riktiga förbättringar!

Fall 3: 103 early hints för stilmallar

Det här är den enda idén som faktiskt ger dig resultat för Core Web Vitals! Att skicka early hints för stilmallar kommer att förbättra mätvärden som First Contentful Paint och Largest Contentful Paint.

103 early hint-headers skickas innan det faktiska HTML-svaret. Det innebär att medan du laddar ner HTML:en kan webbläsaren också börja ladda ner stilmallar parallellt.  Det bästa scenariot är att vid den tidpunkt då HTML:en har laddats klart kan stilmallarna också ha laddats ner. Det innebär att det inte finns någon renderingsblockerande tid från dessa stilmallar. Och detta kan och händer faktiskt på långsammare nätverk! På snabbare nätverk är effekten mindre tydlig men att använda 103 early resource hints är fortfarande snabbare i nästan alla fall!

Ett 103 early hint-svar ser ungefär likadant ut som en preload link-header. För att använda 103 early hints behöver du konfigurera din webbserver eller ditt CDN.  

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style

Vissa CDN:er som CloudFlare låter dig trigga en 103 early hint genom att helt enkelt sätta en link preload-header (som beskrivs i idé 2)

Fall 4: förhandsladda stilmallar för att uppnå asynkron CSS

Ett välkänt trick för att göra CSS icke-renderingsblockerande är att förhandsladda stilmallen och när den har laddats lägga till den på sidan. Idén är enkel och ser ut så här:

<link 
   rel="preload" 
   href="style.css" 
   as="style"
   onload="this.onload=null;this.rel='stylesheet'"
>

Den är baserad på den vanliga preload-koden <link rel="preload" as="style" href="style.css"> och lägger till en onload-händelselyssnare onload="this.onload=null;this.rel='stylesheet'" som ändrar länken till dess slutgiltiga form <link rel="stylesheet" href="style.css">

Det här är ytterligare en idé som helt enkelt är logisk. Om en stilmall inte är renderingsblockerande kan webbläsaren fortsätta att tolka och rendera sidan utan att behöva stanna och vänta på stilmallen. Var dock försiktig!

  • Gör inte CSS asynkron i det synliga visningsområdet. Detta kommer sannolikt att orsaka en Cumulative Layout Shift och det leder till en dålig User Experience
  • Överväg avvägningen. Asynkron CSS kommer sannolikt att orsaka en omrendering av olika delar av sidan. Detta kommer att påverka mätvärden som Interaction to Next Paint. 

Fall 5: förcacha stilmallar

Vid sällsynta tillfällen ser jag smarta lösningar som försöker förvärma cachefiler för efterföljande sidvisningar. Och även om jag applåderar entusiasmen med vilken dessa lösningar skapas. Vänligen gör INTE detta!

Idén är enkel: på startsidan kan du, om du vill, redan förcacha stilarna för en annan sida. Låt oss säga produktsidan. Vid någon punkt efter sidladdning skulle du förhandsladda stilmallar för att lägga till dem i webbläsarens cache.

function preloadStylesheet(url) {
    var link = document.createElement('link');
    link.rel = 'preload';
    link.href = url;
    link.as = 'style';
    document.head.appendChild(link);
}

window.addEventListener('load', function () {
    preloadStylesheet('cart.css');
    preloadStylesheet('shop.css');
});

Vid första anblick ser detta inte alls dåligt ut. På vilken produktsida som helst är cart.css och shop.css nu tillgängliga och kommer inte att blockera rendering längre. Det finns dock några anledningar att inte göra detta!

  1.  Det finns bättre sätt, till exempel [url=https://developer.mozilla.org/en-US/docs/Web/API/Speculation_Rules_API]spekulativ förrendering[/url] eller genom att använda en service worker.
  2. Du kommer förmodligen att slösa resurser och avvägningen kommer inte att vara värd det! Låt oss vara ärliga: om förhandsladdning av resurser var enkelt hade webbläsare varit bättre på det. 
  3. Lösningar som denna är svåra att underhålla och kommer förmodligen att orsaka problem vid någon punkt i framtiden
  4. Du behöver förhandsladda alla stilmallar, inte bara några. Eftersom alla stilmallar är renderingsblockerande och laddas ner parallellt kan bara 1 stilmall ha samma effekt som flera stilmallar.


Stop debating in Jira.

Get a definitive answer on your performance issues. I deliver a granular breakdown of your critical rendering path.

Book a Deep Dive >>

  • Definitive Answers
  • Granular Breakdown
  • Critical Path Analysis
När förhandsladdning av stilmallar (inte) är meningsfullt Core Web Vitals När förhandsladdning av stilmallar (inte) är meningsfullt