Wanneer het pre-loaden van stylesheets (geen) zin heeft

Waarom het pre-loaden van je CSS meestal niet helpt, en de ene situatie waarin dat wel zo is

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

Wanneer het pre-loaden van stylesheets (geen) zin heeft

Ik kom regelmatig gepreloade stylesheets tegen en veel desinformatie daarover. Het pre-loaden van een resource verandert wanneer deze is ingepland voor download. Maar meestal helpt het pre-loaden van stylesheets niet. Aan de hand van vijf situaties laat ik je zien wanneer het werkt en wanneer niet.

Laatst beoordeeld door Arjen Karel in maart 2026

Het idee achter het pre-loaden van stylesheets

Stylesheets zijn render-blocking. Terwijl stylesheets worden gedownload, wordt de pagina niet door de browser gerenderd en ziet de bezoeker alleen een leeg scherm.

Om de tijd die het kost om stylesheets te downloaden te minimaliseren, nemen developers soms hun toevlucht tot pre-loaden. Pre-loaden vertelt de browser om een resource op te halen voordat deze in de HTML wordt ontdekt, zodat deze sneller klaar is. Dit wordt gedaan met de <link>-tag met het rel="preload"-attribuut.

Volgens de 2025 Web Almanac slaagt slechts 13% van de desktoppagina's voor de render-blocking resources audit. Pre-loaden is niet de oplossing. Het elimineren van onnodige render-blocking resources en het uitstellen van niet-kritieke stylesheets wel.

Situatie 1: de stylesheet pre-loaden net voordat deze wordt gedeclareerd

Soms proberen developers in al hun enthousiasme de impact van CSS te minimaliseren door deze in de HTML te pre-loaden, vlak 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 is volledig zinloos en in het beste geval vertraag je de pagina niet. Browsers hebben een ingebouwde preload-scanner die de HTML scant op te downloaden resources voordat de hoofdparser ze bereikt. Als je stylesheet-<link> al in de <head> staat, vindt de preload-scanner deze direct. Het toevoegen van een rel="preload"-hint voor dezelfde URL geeft de browser informatie die hij al heeft. Je hebt alleen een extra regel toegevoegd, meer niet.

3 gepreloade stylesheets

3 normale stylesheets

Situatie 2: de stylesheet pre-loaden met een link header

Dit idee is interessant. We kunnen de Link server header gebruiken om een stylesheet te pre-loaden. Dat ziet er ongeveer zo uit:

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

Het idee is om de browser de stylesheet in de wachtrij te laten plaatsen voordat deze begint met het parsen van de HTML. Ik hou van de denkwijze van de developer die dit bedacht heeft! Maar in de praktijk heb je er heel weinig profijt van. We hebben het over een paar microseconden. Vrij teleurstellende resultaten, maar dit idee leidt ons naar iets dat wél werkt.

Situatie 3: 103 Early Hints voor stylesheets

Dit is het enige idee dat je daadwerkelijk Core Web Vitals-resultaten oplevert. Het verzenden van early hints voor stylesheets verbetert metrics zoals de First Contentful Paint en de Largest Contentful Paint.

103 Early Hint headers worden verzonden voordat de daadwerkelijke HTML response plaatsvindt. Dat betekent dat terwijl je de HTML downloadt, de browser tegelijkertijd kan beginnen met het downloaden van stylesheets. In het beste geval zijn de stylesheets ook al gedownload tegen de tijd dat de HTML klaar is. Nul render-blocking tijd voor die stylesheets. Dit is mogelijk en gebeurt ook op tragere netwerken. Op snellere netwerken is het effect minder duidelijk, maar het gebruik van 103 Early Hints is in bijna alle gevallen nog steeds sneller.

Een 103 Early Hint response lijkt veel op een preload link header. Om 103 Early Hints te gebruiken, moet je je webserver of je CDN configureren.

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

Sommige CDN's zoals Cloudflare laten je een 103 Early Hint triggeren door simpelweg een link preload header in te stellen (zoals beschreven in Situatie 2). Zie voor een complete handleiding over implementatie en browserondersteuning 103 Early Hints: Preload Critical Resources During Server Think Time.

Bij sites die worden gemonitord door CoreDash, tonen pagina's die 103 Early Hints gebruiken voor hun hoofd-stylesheet een 120ms snellere FCP op het 75e percentiel in vergelijking met pagina's zonder Early Hints. De verbetering is het meest zichtbaar op mobiele verbindingen waar server think time en netwerklatentie elkaar meer overlappen.

Situatie 4: stylesheets pre-loaden om asynchrone CSS te bereiken

Een bekende truc om CSS niet render-blocking te maken, is om de stylesheet te pre-loaden en deze pas aan de pagina toe te voegen zodra deze is geladen. Het idee is simpel en ziet er als volgt 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 opnieuw een idee dat gewoon logisch klinkt. Als een stylesheet niet render-blocking is, kan de browser doorgaan met het parsen en renderen van de pagina zonder op de stylesheet te wachten. Wees echter voorzichtig!

  • Maak CSS in de zichtbare viewport niet asynchroon. Dit zal waarschijnlijk een Cumulative Layout Shift veroorzaken, wat leidt tot een slechte user experience.
  • Overweeg de trade-off. Asynchrone CSS zal waarschijnlijk leiden tot een re-render van verschillende delen van de pagina. Dit heeft invloed op metrics zoals de Interaction to Next Paint.

Een eenvoudiger modern alternatief is het gebruik van fetchpriority="low" op een gewone stylesheet link: <link rel="stylesheet" href="style.css" fetchpriority="low">. Dit vertelt de browser om de download te deprioriteren zonder de JavaScript hack. Voor de meeste use cases raad ik dit aan in plaats van de onload truc.

Situatie 5: stylesheets pre-cachen

Soms zie ik handige oplossingen die proberen cachebestanden alvast klaar te zetten voor volgende paginaweergaven. En hoewel ik het enthousiasme waarmee die oplossingen zijn gemaakt toejuich: doe dit alsjeblieft NIET.

Het idee is simpel: op de homepage zou je, als je dat zou willen, de stijlen voor een andere pagina al kunnen pre-cachen. Laten we zeggen de productpagina. Op een bepaald moment na het laden van de pagina, zou je stylesheets pre-loaden om ze toe te voegen aan de browser 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');
});

Op het eerste gezicht ziet dit er niet eens zo slecht uit. Op elke productpagina zijn cart.css en shop.css nu beschikbaar en zullen ze de render niet meer blokkeren. Er zijn echter een paar redenen om dit niet te doen:

  1. Er zijn betere manieren, bijvoorbeeld speculatieve prerendering met Speculation Rules of door een service worker te gebruiken.
  2. Je verspilt waarschijnlijk resources en de trade-off zal het niet waard zijn. Als het pre-loaden van resources makkelijk was, zouden browsers er beter in zijn.
  3. Oplossingen als deze zijn moeilijk te onderhouden en zullen in de toekomst waarschijnlijk problemen veroorzaken.
  4. Je zult alle stylesheets moeten pre-loaden, niet slechts een paar. Omdat alle stylesheets render-blocking zijn en parallel gedownload worden, kan één enkele stylesheet hetzelfde effect hebben als meerdere stylesheets.

Wat wél werkt voor CSS performance

In plaats van te grijpen naar preload hints, focus je op deze basisprincipes voor resource prioritization:

In onze Real User Monitoring data zien we dat sites die redundante CSS verwijderen en 103 Early Hints gebruiken, consistent slagen voor LCP op het 75e percentiel. Sites die alleen hun stylesheets pre-loaden zonder de onderliggende oorzaak aan te pakken (te veel CSS, te laat geladen) zien zelden een betekenisvolle verbetering.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

The RUM tool I built for my own clients.

CoreDash is what I use to audit enterprise platforms. Under 1KB tracking script, EU hosted, no consent banner. AI with MCP support built in. The same tool, available to everyone.

Create Free Account
Wanneer het pre-loaden van stylesheets (geen) zin heeftCore Web Vitals Wanneer het pre-loaden van stylesheets (geen) zin heeft