Eliminate render-blocking resources Lighthouse-waarschuwing oplossen
Raak render-blocking resources kwijt en verbeter de Core Web Vitals
'Eliminate render-blocking resources' in het kort
Wanneer een browser render-blocking CSS of JavaScript tegenkomt in de <head>, stopt hij met alles. Er worden geen pixels op het scherm getekend totdat die resources klaar zijn met downloaden en uitvoeren. Dat is wat de 'Eliminate render-blocking resources' waarschuwing in Lighthouse je vertelt: iets in je <head> vertraagt de first paint.
Los deze Lighthouse-waarschuwing op door deze render-blocking resources te verwijderen of uit te stellen (defer). Volgens de Web Almanac 2025 slaagt slechts 15% van de mobiele pagina's voor deze audit. Dat is 85% van het web met onnodige renderingvertragingen.
Wat is de 'Eliminate render-blocking resources' Lighthouse-waarschuwing?
Laatst beoordeeld door Arjen Karel in maart 2026
Wat veroorzaakt de Eliminate render-blocking resources waarschuwing in Lighthouse? Lighthouse markeert pagina's die een van de volgende kenmerken hebben:
- Een script-tag in de head die niet is uitgesteld (deferred).
Scripts in de head van de pagina zijn standaard render-blocking als ze niet het defer of async attribuut hebben. - Een gekoppeld stylesheet dat overeenkomt met de apparaatmedia (device media).
Een <link rel="stylesheet"> blokkeert het renderen van de pagina als het niet is uitgeschakeld en overeenkomt met de media van de browser. Bijvoorbeeld, <link rel="stylesheet" media="print"> blokkeert het renderen op beeldschermapparaten niet.
Te veel render-blocking resources zullen hoogstwaarschijnlijk directe invloed hebben op First Contentful Paint (FCP) en Largest Contentful Paint (LCP). Vodafone verminderde render-blocking JavaScript en zag een verbetering van 31% in LCP, wat zich vertaalde in een omzetstijging van 8%.
Volgens de Web Performance Calendar laadt 67,7% van de websites minstens één render-blocking externe partij (third party). Google Fonts alleen al is verantwoordelijk voor render-blocking verzoeken op meer dan 5,8 miljoen sites.
Wat veroorzaakt 'render-blocking resources'?
Render-blocking resources zijn altijd stylesheets en JavaScripts in de head van de pagina. Dit betekent dat ze alleen kunnen worden toegevoegd door je CMS, door je webdeveloper of door een plugin. Als je de oorsprong van een render-blocking resource probeert te vinden, zoek dan op deze plaatsen:
- De template. De template van je website is de eerste plek om te zoeken. Zoek de plaats waar de <head> code zich bevindt en zoek naar hardgecodeerde stijlen en scripts.
- Het CMS. Soms heeft het CMS zelf bepaalde scripts (bijvoorbeeld jQuery) nodig om goed te werken.
- Plugins. Plugins zijn berucht om het injecteren van stijlen en scripts in de pagina. Zelfs als een plugin maar op één pagina wordt gebruikt, laadt deze vaak zijn resources op elke pagina.
Het JavaScript-hoofdstuk van de Web Almanac 2024 (de meest recente editie met data op scriptniveau) ontdekte dat hoewel 87% van de pagina's async gebruikt op ten minste één script, slechts 49% van de individuele script-tags dit ook daadwerkelijk heeft. En slechts 13% van de scripts gebruikt defer. De meeste scripts op het web worden nog steeds zonder een van beide attributen geladen, wat betekent dat ze rendering blokkeren.
Hoe 'Eliminate render-blocking resources' te fixen
Om render-blocking resources op te lossen, moet je ervoor zorgen dat ze rendering niet meer blokkeren. De beste oplossing is om de resource helemaal te verwijderen. Oude, ongebruikte scripts en stylesheets die nog in de <head> staan, komen vaker voor dan je denkt. Als je ze niet kunt verwijderen, stel ze dan uit (defer).
JavaScript uitstellen
JavaScript kan worden uitgesteld door het attribuut defer of async toe te voegen aan de script-tag.
<!-- deferred: downloadt parallel, voert uit na HTML parsing, op volgorde --> <script defer src="script.js"></script> <!-- async: downloadt parallel, voert onmiddellijk uit wanneer gereed (willekeurige volgorde) --> <script async src="script.js"></script>
Voor de meeste scripts is defer de veiligere keuze omdat het de uitvoeringsvolgorde behoudt. Gebruik async voor scripts die volledig onafhankelijk zijn, zoals analytics. Als je ES-modules (<script type="module">) gebruikt, krijg je automatisch defer-gedrag. Module scripts blokkeren nooit rendering.
Voor een complete gids over alle manieren om JavaScript timing te regelen, zie 16 methoden om JavaScript uit te stellen. Als je wilt begrijpen hoe async en defer de Core Web Vitals verschillend beïnvloeden, hebben we daar ook een speciaal artikel over.
Stylesheets uitstellen
Het uitstellen van stylesheets is lastiger dan het uitstellen van scripts. Wanneer een stylesheet wordt uitgesteld, wordt de pagina eerst zonder die stijlen gerenderd, waarna de browser ze toepast zodra ze geladen zijn. Dit veroorzaakt flikkeringen en layout shifts. Daarom moet je uitgestelde stylesheets combineren met inline critical CSS.
Stap 1: Inline je critical CSS. Critical CSS is de minimale set stijlen die nodig is om het zichtbare deel van de pagina te renderen. Inline dit direct in een <style> tag in de <head>. Dit geeft de browser alles wat hij nodig heeft om de above-the-fold inhoud te tekenen zonder te hoeven wachten op een extern bestand. Critical CSS handmatig extraheren is vervelend. Je kunt onze Critical CSS Generator gebruiken om dit te automatiseren.
<style>/* critical CSS hier */</style>
Stap 2: Laad de rest met lage prioriteit. Voor het niet-kritieke stylesheet voeg je fetchpriority="low" toe om de browser te vertellen dat deze resource niet mag concurreren met kritieke inhoud:
<link rel="stylesheet"
href="styles.css"
fetchpriority="low">
Mogelijk zie je oudere artikelen een media="print" hack aanbevelen die na het laden overschakelt naar media="all". Ik raad dit niet aan. Het misbruikt het media attribuut voor iets waarvoor het niet is ontworpen, het hangt af van een kwetsbare onload handler, en als die handler faalt, worden je stijlen nooit toegepast. Het gebruik van fetchpriority="low" is de juiste, semantische benadering: het vertelt de browser precies wat je bedoelt zonder trucjes.
Voor stylesheets die je op de huidige pagina helemaal niet nodig hebt (bijvoorbeeld stijlen die alleen op een specifiek paginatype worden gebruikt), is de schoonste oplossing om de ongebruikte CSS te verwijderen van die pagina.
De impact van render-blocking resources verminderen
Soms kun je render-blocking resources niet elimineren. Misschien heb je geen toegang tot de template of vereist je CMS bepaalde scripts. Er zijn een paar manieren om de impact te verminderen:
- Minify en comprimeer je stijlen en scripts.
Kleinere resources hebben minder invloed op de laadprestaties dan grotere resources. Zorg ervoor dat gzip of brotli compressie is ingeschakeld op je server. - Vermijd het aaneenschakelen van kritieke verzoeken (chaining critical requests).
Als een render-blocking stylesheet een ander stylesheet laadt via@import, heb je een verzoekketen (request chain) gecreëerd. Het tweede bestand kan pas beginnen met downloaden als het eerste volledig is geladen en geparseerd. Gebruik in plaats daarvan afzonderlijke<link>tags zodat beide parallel downloaden. - Laad resources per pagina uit (Unload resources).
Als een resource niet van één pagina kan worden verwijderd, betekent dat niet dat het op alle pagina's vereist is. WordPress plugins hebben de neiging om scripts en stijlen toe te voegen aan alle pagina's, zelfs wanneer de plugin maar op een paar actief is. - Prioriteer wat belangrijk is.
Gebruik resource prioritization om ervoor te zorgen dat kritieke resources eerst laden en niet-kritieke resources niet concurreren om bandbreedte.
In de monitoring data van CoreDash zagen sites die alle render-blocking resources elimineerden hun FCP gemiddeld met [CD:placeholder]ms verbeteren.
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
