Wat zijn render-blocking resources? Uitleg voor SEO

Definitie

Render-blocking resources zijn CSS- en JavaScript-bestanden die de browser eerst moet laden voordat hij iets op het scherm zet. Ze vertragen FCP en LCP, en dus je Core Web Vitals.

Wat zijn render-blocking resources?

Een browser tekent pas iets op het scherm als hij weet hoe de pagina eruitziet. Daarvoor wacht hij op bepaalde CSS- en JavaScript-bestanden. Zolang die laden, blijft het scherm leeg. Dat zijn render-blocking resources.

Lighthouse markeert twee soorten. Een <script> in de <head> zonder async of defer. En een <link rel="stylesheet"> zonder disabled-attribuut en zonder media-attribuut dat niet op het apparaat van toepassing is. Let op: media="all" telt gewoon als blokkerend.

Sinds Lighthouse 13 heet de audit "Render-blocking requests" en staat hij bij de insights. De oplossing is hetzelfde gebleven: zet alleen in de <head> wat nodig is voor de eerste weergave, en laad de rest later.

Zo werkt het in Magento/Hyvä, Shopify en Laravel

Magento met Luma laadt veel JavaScript via RequireJS en een grote stylesheet. Magento heeft instellingen om JavaScript naar onderen te verplaatsen en critical CSS te gebruiken, maar dat lost de basis niet op. Hyvä pakt het bij de bron aan: één kleine Tailwind-stylesheet en Alpine.js in plaats van RequireJS en jQuery.

In Shopify bepaalt je thema het meeste. Apps injecteren vaak eigen scripts en stylesheets in de <head>. Controleer na elke app-installatie wat er bij is gekomen. Thema's van Shopify zelf laden scripts doorgaans met defer.

In Laravel heb je volledige controle. Vite zet je JavaScript standaard als type="module", en module-scripts gedragen zich als defer. Let vooral op losse scripts van derden in je layout, zoals chatwidgets en tag managers.

Veelgemaakte fouten

- Alles op defer zetten, ook scripts die de eerste weergave nodig hebben. Dan krijg je een kale pagina die daarna verspringt.

- De volledige stylesheet inline zetten. Dan wordt je HTML groot en kan de browser de CSS niet meer cachen tussen pagina's.

- Fonts laden via een @import in een CSS-bestand. Dat geeft een extra blokkerende stap in de keten.

- Alleen naar de Lighthouse-score kijken. Controleer in CrUX of Search Console of je LCP voor echte bezoekers ook verbetert.

Blokkerend versus niet-blokkerend laden

<!-- Blokkeert rendering -->
<script src="/js/app.js"></script>
<link rel="stylesheet" href="/css/all.css">

<!-- Blokkeert niet -->
<script src="/js/app.js" defer></script>
<link rel="stylesheet" href="/css/print.css" media="print">

Verder lezen

Gerelateerde begrippen

Critical CSS FCP (First Contentful Paint)LCP (Largest Contentful Paint)Core Web Vitals Lighthouse Third-party scripts Webfonts Total Blocking Time (TBT)

Veelgestelde vragen

Wat is het verschil tussen async en defer?+

Beide laden het script zonder de HTML-parser te blokkeren. Async voert het script uit zodra het binnen is, in willekeurige volgorde. Defer wacht tot de HTML klaar is en houdt de volgorde aan. Voor scripts die van elkaar afhangen is defer veiliger.

Is render-blocking CSS altijd slecht?+

Nee. Zonder CSS zie je eerst ongestylede inhoud. De CSS voor het eerste scherm mag blokkeren. Het probleem is CSS die pas lager op de pagina of op andere pagina's nodig is.

Telt dit direct mee voor ranking?+

Niet als losse factor. Render-blocking resources vertragen FCP en LCP. LCP is onderdeel van Core Web Vitals, en die gebruikt Google als onderdeel van page experience.

Render-blocking resources