Wanneer het preloaden van stylesheets (g)een zin heeft
Het verkennen van de overwegingen van het preloaden van stylesheets voor web prestatieoptimalisatie.

Wanneer het preloaden van stylesheets (g)een zin heeft
Ik kom regelmatig gepreloade stylesheets tegen en veel verkeerde informatie eromheen. Het preloaden van een bron (meestal) verandert de prioriteit en de tijd waarop deze is gepland voor download.
Echter, zoals veel optimalisatiestrategieën die ik dagelijks tegenkom, heeft het preloaden van stylesheets meestal niet veel zin.
In dit artikel zal ik onderzoeken wanneer het preloaden van stylesheets zin heeft en wanneer het misschien niet de beste keuze is.
Table of Contents!
- Wanneer het preloaden van stylesheets (g)een zin heeft
- Het idee van het preloaden van stylesheets:
- Geval 1: de stylesheet preloaden net voor het declareren ervan.
- Geval 2: de stylesheet preloaden met een link header.
- Geval 3: 103 early hints voor stylesheets
- Geval 4: stylesheets preloaden om asynchrone CSS te bereiken
- Geval 5: stylesheets pre-cachen
Het idee van het preloaden van stylesheets:
Voordat we in de overwegingen duiken, laten we kort het concept van het preloaden van stylesheets herzien. Stylesheets zijn render blocking. Dit betekent dat terwijl stylesheets worden gedownload, de pagina niet door de browser wordt gerenderd en alles wat de bezoeker ziet een leeg scherm is.
Om de tijd die nodig is om stylesheets te downloaden te minimaliseren, nemen ontwikkelaars soms hun toevlucht tot het preloaden van stylesheets. Preloading omvat het vooraf ophalen van kritieke bronnen, waardoor de latentie die gepaard gaat met het laden ervan wanneer ze daadwerkelijk nodig zijn, wordt geminimaliseerd. Dit wordt meestal bereikt met de <link> tag met het rel="preload" attribuut.
Geval 1: de stylesheet preloaden net voor het declareren ervan.
Soms proberen ontwikkelaars, in al hun enthousiasme, de CSS-impact te minimaliseren door deze in de HTML opnieuw te laden net voor de daadwerkelijke CSS-declaratie. Dit ziet er ongeveer zo uit:
<link rel="preload" as="style" href="style.css"> <link rel="stylesheet" href="style.css">
Dit slaat nergens op en in het beste geval vertraagt u de pagina niet! Een browser leest de html en begint alle kritieke bronnen op de pagina te laden, meestal in de volgorde waarin ze deze vinden. Dit betekent dat als u de preload regel zou verwijderen, de browser de stylesheet toch zou hebben gevonden en de stylesheet hoe dan ook zou zijn gaan downloaden. U heeft zojuist een extra regel toegevoegd, dat is alles! Maar het wordt erger. Gepreloade stylesheets krijgen een lagere prioriteit dan normale stylesheets. Dus in de slechtste omstandigheden zou u uw pagina daadwerkelijk vertragen!
3 gepreloade stylesheets

3 normale stylesheets

Geval 2: de stylesheet preloaden met een link header.
Dit idee is interessant. We kunnen de server link server header gebruiken om een stylesheet te preloaden. Dat zou er ongeveer zo uitzien:
Link: <style.css>; rel=preload; as=style
Het idee hier is om de browser de stylesheet in de wachtrij te laten plaatsen voordat hij begint met het parsen van de HTML. Dit is een vrij goed idee en ik vind het leuk hoe de geest van een ontwikkelaar die dit bedacht werkt! Maar helaas zult u hier in het echte leven heel weinig voordeel uit halen. We hebben het over een paar microseconden. Dat zijn behoorlijk teleurstellende resultaten, maar maak u geen zorgen. We kunnen deze stap gebruiken om enkele echte verbeteringen aan te brengen!
Geval 3: 103 early hints voor stylesheets
Dit is het enige idee dat u daadwerkelijk wat Core Web Vitals resultaten zal opleveren! Het verzenden van early hints voor stylesheets zal statistieken zoals de first contentful paint en de largest contentful paint verbeteren.
103 early hint headers worden verzonden voor het daadwerkelijke html-antwoord. Dat betekent dat terwijl u de HTML downloadt, de browser ook parallel stylesheets kan gaan downloaden. Het beste scenario is dat tegen de tijd dat de HTML klaar is met downloaden, de stylesheets misschien ook zijn gedownload. Dit betekent dat er nul render blocking tijd is van die stylesheets. En dit kan en gebeurt op langzamere netwerken! Op snellere netwerken is het effect minder duidelijk, maar het gebruik van 103 early resource hints is in bijna alle gevallen nog steeds sneller!
Een 103 early hint antwoord ziet er ongeveer hetzelfde uit als een preload link header. Om 103 early hints te gebruiken, moet u uw webserver of uw CDN configureren.
HTTP/1.1 103 Early Hints Link: </style.css>; rel=preload; as=style
Sommige CDN's zoals CloudFlare laten u een 103 early hint activeren door simpelweg een link preload header in te stellen (zoals beschreven in idee 2)
Geval 4: stylesheets preloaden om asynchrone CSS te bereiken
Een bekende truc om CSS non-render-blocking te maken, is om de stylesheet te preloaden en zodra deze is geladen toe te voegen aan de pagina. Het idee is eenvoudig en ziet er zo uit:
<link
rel="preload"
href="style.css"
as="style"
onload="this.onload=null;this.rel='stylesheet'"
>Het is gebaseerd op de normale preload code <link rel="preload" as="style" href="style.css"> en voegt een onload event listener toe onload="this.onload=null;this.rel='stylesheet'" die de link verandert in zijn definitieve vorm <link rel="stylesheet" href="style.css">
Dit is nog een idee dat gewoon logisch is. Als een stylesheet niet render blocking is, kan de browser doorgaan met het parsen en renderen van de pagina zonder te stoppen en te wachten op de stylesheet. Wees echter voorzichtig!
- Doe geen async CSS in de zichtbare viewport. Dit zal waarschijnlijk een Cumulative Layout Shift veroorzaken en dat zal leiden tot een slechte User Experience
- Overweeg de afweging. Async CSs zal waarschijnlijk een re-render van verschillende delen van de pagina veroorzaken. Dit zal invloed hebben op statistieken zoals de Interaction to Next Paint.
Geval 5: stylesheets pre-cachen
In zeldzame gevallen zie ik handige oplossingen die proberen cachebestanden voor op te warmen voor volgende paginaweergaven. En hoewel ik het enthousiasme waarmee die oplossingen worden gemaakt toejuich. Doe dit alsjeblieft NIET!
Het idee is simpel: op de homepage zou u, als u dat zou willen, de stijlen voor een andere pagina al kunnen pre-cachen. Laten we zeggen de productpagina. Op een gegeven moment na het laden van de pagina zou u stylesheets preloaden om ze aan de browsercache toe te voegen.
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');
});
Op het eerste gezicht ziet dit er niet slecht uit. Op elke productpagina zijn cart.css en shop.css nu beschikbaar en zullen ze het renderen niet meer blokkeren. Er zijn een paar redenen om dit niet te doen!
- Er zijn betere manieren, bijvoorbeeld speculatieve prerendering of door een service worker te gebruiken.
- U zult waarschijnlijk bronnen verspillen en de afweging zal het niet waard zijn! Laten we eerlijk zijn: als het preloaden van bronnen eenvoudig was, zouden browsers er beter in zijn geweest.
- Oplossingen zoals deze zijn moeilijk te onderhouden en zullen waarschijnlijk in de toekomst op een gegeven moment problemen veroorzaken
- U moet alle stylesheets preloaden, niet slechts een paar. Omdat alle stylesheets render blocking zijn en parallel worden gedownload, kan slechts 1 stylesheet hetzelfde effect hebben als meerdere stylesheets.
17 years of fixing PageSpeed.
I have optimized platforms for some of the largest publishers and e-commerce sites in Europe. I provide the strategy, the code, and the RUM verification. Usually in 1 to 2 sprints.
View Services
