Render-blocking resources: wat het is en hoe je het oplost

“Elimineer bronnen die de weergave blokkeren.” Onderaan je PageSpeed-rapport, met een geschatte tijdwinst van 1,2 seconden ernaast. Daaronder een lijstje bestandsnamen waar je niks van herkent.

Ik heb die melding jarenlang weggeklikt. Niet uit luiheid, maar omdat ik niet wist wat ik ermee moest. Het klonk als iets voor developers.

Dat is het niet. Render-blocking resources zijn een eenvoudig concept, en de oplossing zit meestal gewoon in WP Rocket. In dit artikel lees je wat ze zijn, waarom ze je laadtijd verpesten, en hoe je ze oplost zonder dat je website eruitziet alsof iemand de stylesheet is vergeten.

Wat de browser doet voordat je iets ziet

Als iemand jouw website opent, downloadt de browser eerst het HTML-bestand. Daarin staat welke stylesheets en scripts erbij horen. En hier zit het probleem: bij CSS en bij bepaalde JavaScript stopt de browser met alles wat hij aan het doen was en wacht tot die bestanden binnen zijn.

Pas daarna begint hij met tekenen.

Stel je voor dat je een boek wil lezen, maar de bibliothecaris zegt: eerst even wachten, ik moet nog vier andere boeken uit het magazijn halen die je misschien nodig hebt. Je zit ondertussen naar een lege tafel te kijken. Dat is een render-blocking resource.

Op een gemiddelde WordPress-website met een pagebuilder, een fontplugin, een cookiebanner en een formulierplugin staan al snel acht tot vijftien van die bestanden in de weg. Elk bestand is een extra verzoek, een extra wachtmoment.

Waarom render-blocking je LCP-score sloopt

LCP meet hoe snel het grootste zichtbare element op je pagina geladen is. Dat kan pas gebeuren als de browser weet hoe hij dingen moet tekenen. En dat weet hij pas als de CSS binnen is.

Elke seconde die de browser besteedt aan wachten op stylesheets, is dus een seconde dat de bezoeker naar wit staart. Ook als je afbeeldingen perfect geoptimaliseerd zijn. Ook als je hosting snel is.

Dat is precies waarom render-blocking bijna altijd bovenaan in de Opportunities staat, met een concrete tijdwinst ernaast. PageSpeed rekent je voor hoeveel sneller de pagina zou zijn als je dit oplost.

Zo los je render-blocking op in WP Rocket

Je hebt hier geen developer voor nodig. Drie instellingen doen het meeste werk, allemaal onder het tabblad Bestandsoptimalisatie.

JavaScript uitgesteld laden. Dit vertelt de browser: die scripts kun je later ophalen, ga eerst tekenen. Voor de meeste scripts is dat prima. Analytics hoeft echt niet te laden voordat je bezoeker iets ziet.

JavaScript uitvoering uitstellen. Gaat een stap verder: scripts laden pas na de eerste interactie van de bezoeker. Scrollen, klikken, bewegen met de muis. Dit levert vaak de grootste winst op, maar geeft ook het vaakst problemen. Zet hem aan en test grondig.

Gebruikte CSS optimaliseren. WP Rocket kijkt welke CSS je pagina daadwerkelijk gebruikt boven de vouw, laadt die direct, en stelt de rest uit. Dit is de instelling die de grootste sprong geeft, en ook de instelling die het vaakst iets breekt.

Zet ze één voor één aan. Niet alle drie tegelijk, want dan weet je niet welke het probleem veroorzaakt als er iets misgaat.

Wat je doet als de website ineens raar oogt

Dit gaat gebeuren. Bij mij ook, regelmatig nog.

Je zet Gebruikte CSS optimaliseren aan, ververst de pagina, en je header staat ineens links uitgelijnd terwijl hij gecentreerd hoort. Of je slider werkt niet meer. Of de knop verspringt een halve seconde na het laden.

Geen paniek, en zeker geen reden om de hele optimalisatie uit te zetten.

Wat je doet: zoek uit welk bestand het probleem veroorzaakt en sluit dat ene bestand uit. WP Rocket heeft voor elke instelling een uitsluitingslijst. Open de browser-inspector, kijk welk script of welke stylesheet hoort bij het kapotte element, en zet die op de lijst.

Je verliest dan een klein beetje snelheidswinst op dat ene onderdeel, maar houdt de winst op al het andere. Prima ruil.

Wanneer je moet stoppen met tweaken

Op een gegeven moment ben je een half uur bezig met het uitsluiten van scripts om de laatste 0,2 seconden eruit te persen. Dat is het moment om te stoppen.

Zit je LCP onder de 2,5 seconden en is je layout stabiel, dan ben je klaar. De laatste procenten kosten onevenredig veel tijd en breken vaak meer dan ze opleveren.

Blijft de melding staan terwijl je alles hebt aangezet? Dan is er meestal één plugin of één thema-onderdeel dat zich structureel verzet. Dat is een ander probleem, en dat los je op met een plugin-audit.

Benieuwd hoeveel render-blocking bestanden jouw website tegenhouden? De Website Quick Scan geeft je in een paar minuten een eerste beeld van wat er speelt, inclusief waar de meeste snelheidswinst zit. Gratis, geen gedoe.

→ Doe de gratis Website Quick Scan