Fix de 'eliminate render-blocking resources' Lighthouse-waarschuwing
Kom van render-blocking resources af en verbeter de Core Web Vitals
'Eliminate render-blocking resources' in het kort
Wanneer een browser render-blocking CSS of JavaScript in de <head> tegenkomt, stopt deze met alles. Er worden geen pixels op het scherm getekend (gepaint) 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 eerste paint.
Fix deze Lighthouse-waarschuwing door deze render-blocking resources te verwijderen of uit te stellen. Volgens de 2025 Web Almanac slaagt slechts 15% van de mobiele pagina's voor deze audit. Dat betekent dat 85% van het web onnodige rendervertragingen heeft.
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 zaken bevatten:
- 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 gekoppelde stylesheet die overeenkomt met de apparaatmedia.
Een <link rel="stylesheet"> blokkeert het renderen van de pagina als deze niet is uitgeschakeld en overeenkomt met de media van de browser. Bijvoorbeeld <link rel="stylesheet" media="print"> zal het renderen op scherm-apparaten niet blokkeren.
Te veel render-blocking resources zullen hoogstwaarschijnlijk First Contentful Paint (FCP) en Largest Contentful Paint (LCP) direct beïnvloeden. 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 plug-in. Wanneer je de oorsprong van een render-blocking resource probeert te vinden, kijk dan op deze plaatsen:
- De template. De template van je website is de eerste plek om te kijken. Zoek de plek waar de <head>-code zich bevindt en zoek naar hardcoded stijlen en scripts.
- Het CMS. Soms heeft het CMS zelf bepaalde scripts nodig (bijvoorbeeld jQuery) om goed te werken.
- Plug-ins. Plug-ins staan erom bekend stijlen en scripts in de pagina te injecteren. Zelfs wanneer een plug-in slechts op één pagina wordt gebruikt, laadt deze vaak zijn resources op elke pagina.
Het JavaScript-hoofdstuk van de 2024 Web Almanac (de meest recente editie met gegevens op scriptniveau) ontdekte dat hoewel 87% van de pagina's async gebruikt op minstens één script, slechts 49% van de individuele script-tags dit daadwerkelijk heeft. En slechts 13% van de scripts gebruikt defer. De meeste scripts op het web worden nog steeds geladen zonder een van beide attributen, wat betekent dat ze rendering blokkeren.
Hoe fix je 'Eliminate render-blocking resources'
Om render-blocking resources te fixen, moet je ervoor zorgen dat ze het renderen niet langer blokkeren. De beste oplossing is om de resource in zijn geheel te verwijderen. Oude, ongebruikte scripts en stylesheets die nog steeds 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 defer- of async-attribuut 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 klaar (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">), krijg je automatisch defer-gedrag. Module-scripts blokkeren nooit het renderen.
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 op een andere manier 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, rendert de pagina eerst zonder die stijlen, waarna de browser ze toepast zodra ze geladen zijn. Dit veroorzaakt knipperen (flickering) 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 gedeelte 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 content te painten zonder te wachten op een extern bestand. Critical CSS handmatig extraheren is tijdrovend. Je kunt onze Critical CSS Generator gebruiken om dit te automatiseren.
<style>/* critical CSS here */</style>
Stap 2: Laad de rest met een lage prioriteit. Voeg voor de niet-kritieke stylesheet fetchpriority="low" toe om de browser te vertellen dat deze resource niet moet concurreren met kritieke content:
<link rel="stylesheet"
href="styles.css"
fetchpriority="low">
Misschien zie je oudere artikelen die een media="print"-hack aanbevelen die bij het laden naar media="all" overschakelt. 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 aanpak: 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 unused CSS in zijn geheel van die pagina te verwijderen.
Verminder de impact van render-blocking resources
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:
- Minificeer en comprimeer je stijlen en scripts.
Kleinere resources hebben minder impact op de laadprestaties dan grotere resources. Zorg ervoor dat gzip- of brotli-compressie is ingeschakeld op je server. - Vermijd chaining critical requests.
Als een render-blocking stylesheet een andere stylesheet inlaadt via@import, heb je een request chain gecreëerd. Het tweede bestand kan niet beginnen met downloaden totdat het eerste volledig is geladen en geparseerd. Gebruik in plaats daarvan afzonderlijke<link>-tags, zodat ze beide parallel downloaden. - Unload resources per pagina.
Als een resource niet van een bepaalde pagina kan worden verwijderd, betekent dat niet dat hij op alle pagina's vereist is. WordPress-plug-ins hebben de neiging om scripts en stijlen aan alle pagina's toe te voegen, zelfs als de plug-in slechts op een paar pagina's actief is. - Geef prioriteit aan wat belangrijk is.
Gebruik resource prioritization om ervoor te zorgen dat kritieke resources als eerste laden en niet-kritieke resources niet concurreren om bandbreedte.
In de monitoringgegevens van CoreDash zagen sites die alle render-blocking resources elimineerden hun FCP met gemiddeld 420 ms verbeteren.
Search Console flagged your site?
I deliver a prioritized fix list backed by field data. Not a 50 page PDF.
Request audit
