Uw snelheidstool geeft een rode melding: “Verwijder bronnen die de weergave blokkeren” of “Verminder de uitvoeringstijd van JavaScript”. Uw cacheplugin heeft er een schakelaar voor. U zet hem aan, de score springt omhoog, en een dag later belt een klant dat het contactformulier niet meer werkt. Herkenbaar? Dan bent u niet de enige.

JavaScript uitgesteld laden in WordPress is een van de meest effectieve snelheidsmaatregelen én een van de meest riskante. Niet omdat de techniek slecht is, maar omdat WordPress-sites tientallen scripts laden die van elkaar afhankelijk zijn. In dit artikel leggen wij uit wat de verschillende opties doen en hoe u ze inschakelt zonder dat er iets kapotgaat.

Waarom JavaScript uw site vertraagt

Als een browser een script tegenkomt in de HTML, stopt hij standaard met het opbouwen van de pagina, haalt het script op, voert het uit en gaat dan pas verder. Bij één klein script merkt u dat niet. Bij dertig scripts van thema, plugins, analytics, chatwidget en cookiebanner staat de pagina seconden lang stil voordat er iets zichtbaar wordt.

Daar komt bij dat scripts niet alleen laadtijd kosten, maar ook rekentijd. De browser moet ze uitvoeren, en op een gemiddelde telefoon gaat dat vele malen trager dan op uw laptop. Dat is precies wat de meetwaarde INP meet: hoe lang de pagina niet reageert op een klik omdat de processor bezig is met scripts.

De drie opties: defer, async en delay

De termen worden door elkaar gebruikt, maar ze doen echt iets anders.

Defer

Het script wordt op de achtergrond opgehaald terwijl de browser doorgaat met de pagina, en pas uitgevoerd als de HTML volledig is ingelezen. De volgorde van de scripts blijft behouden. Dit is de veiligste optie, omdat scripts die op elkaar wachten (bijvoorbeeld een slider die jQuery nodig heeft) nog steeds in de juiste volgorde draaien.

Async

Het script wordt ook op de achtergrond opgehaald, maar uitgevoerd zodra het binnen is, ongeacht de volgorde. Dat is sneller, maar gevaarlijk voor scripts die van elkaar afhankelijk zijn. Als de slider eerder klaar is met laden dan jQuery, crasht de slider. Async is geschikt voor losstaande scripts zoals analytics, niet voor thema- en pluginscripts.

Delay (uitstellen tot interactie)

Het script wordt helemaal niet geladen totdat de bezoeker iets doet: scrollen, bewegen met de muis, tikken op het scherm. Dit geeft veruit de grootste winst op snelheidsmetingen, omdat de meettool nooit iets aanraakt en de scripts dus nooit ziet. Het is ook de optie met het hoogste risico. Alles wat direct bij het laden zichtbaar of werkend moet zijn, zoals een slider bovenaan, een menu of een cookiebanner, gaat hiermee stuk of verschijnt met vertraging.

Stappenplan: veilig inschakelen

  1. Maak een back-up en werk bij voorkeur op een staging-omgeving. Als dat niet kan, kies dan een rustig moment en houd de site in een tweede tabblad open om te controleren.
  2. Inventariseer wat er op de site moet werken. Maak een lijstje: menu op mobiel, contactformulier, slider, winkelwagen, zoekfunctie, kaart, video, cookiebanner, chatwidget, afsprakenmodule. Dit is uw testlijst.
  3. Begin met defer, niet met delay. Zet in uw cacheplugin (WP Rocket, LiteSpeed Cache, Perfmatters of Autoptimize) alleen de optie voor uitgesteld laden aan. Sluit jQuery uit als de plugin die optie biedt.
  4. Test alles op uw lijst. Op desktop én op een echte telefoon, in een privévenster zodat u niet naar de cache kijkt. Open de browserconsole (F12) en kijk of er rode foutmeldingen staan.
  5. Werkt er iets niet? Sluit dat script uit. Elke serieuze plugin heeft een uitzonderingslijst waar u een bestandsnaam of een deel ervan kunt invullen. Zoek in de console welk script de fout geeft, voeg het toe aan de uitzonderingen en test opnieuw.
  6. Overweeg daarna pas delay, en alleen voor scripts van derden. Analytics, Facebook Pixel, Hotjar, chatwidgets, YouTube-insluitingen: die kunnen prima wachten tot de bezoeker iets doet. Themascripts en formulieren laat u met rust.
  7. Test opnieuw, en test na een week nog een keer. Sommige problemen komen pas aan het licht op een pagina die u de eerste keer niet heeft bekeken.

Wat het vaakst breekt, en hoe u het herkent

  • Contactformulieren. De knop doet niets, of de reCAPTCHA verschijnt niet. Oorzaak: het formulierscript of reCAPTCHA wordt uitgesteld terwijl het inline-script dat het aanroept al is uitgevoerd. Sluit de formulierplugin uit.
  • Sliders en carrousels. Alle dia’s staan onder elkaar, of de slider is leeg. Oorzaak: het sliderscript draait vóór jQuery of wordt vertraagd tot interactie.
  • Mobiel menu. De hamburgerknop reageert niet. Bij delay-instellingen is dit bijna gegarandeerd; sluit het menuscript van het thema uit.
  • Inline-scripts. Scripts die direct in de HTML staan en verwijzen naar jQuery (“$ is not defined”). Deze zijn lastig, omdat u ze niet altijd kunt uitstellen. Soms is de enige oplossing jQuery zelf niet uit te stellen.
  • WooCommerce. Toevoegen aan winkelwagen werkt niet, of de variatiekeuze bij een product reageert niet. Sluit de WooCommerce-scripts uit van delay, en test defer grondig.

Het uitstellen van JavaScript overlapt deels met het minimaliseren en samenvoegen ervan. Die twee worden vaak in één adem genoemd, maar hebben andere risico’s. Wat minificatie doet en wanneer dát misgaat, leest u in ons artikel over het minimaliseren van CSS en JavaScript.

Een praktijkvoorbeeld

Een makelaarskantoor in Eindhoven had de delay-functie van zijn cacheplugin ingeschakeld op advies van een snelheidsrapport. De score op mobiel steeg van 38 naar 91. Twee weken later bleek dat de woningzoekfunctie op de homepage pas reageerde nadat de bezoeker al ergens anders op had geklikt, en dat de kaart met woningen bij een deel van de bezoekers leeg bleef. De eigenaar had het niet gemerkt omdat hij de site alleen op zijn eigen laptop bekeek, waar de cache al warm was.

De oplossing was niet om delay uit te zetten, maar om de zoek- en kaartscripts uit te sluiten en alleen de scripts van derden (analytics, chat, sociale media) uitgesteld te laden. De score zakte naar 84, wat nog steeds uitstekend is, en alles werkte weer. Dit soort afweging tussen meetscore en werkende functionaliteit is de kern van elke serieuze snelheidsoptimalisatie: de score is een middel, niet het doel.

Conclusie

Begin met defer, sluit jQuery en uw formulierplugin uit, en test met een concrete lijst op een echte telefoon. Gebruik delay alleen voor scripts van derden. Kijk in de browserconsole, niet alleen naar de score. En bewaar de uitzonderingslijst ergens, zodat u na een plugin-update weet wat u had ingesteld. Wie dit zorgvuldig doet, haalt een groot deel van de snelheidswinst binnen zonder dat een klant hoeft te bellen dat het formulier stuk is. Wilt u eerst weten hoe uw site er nu voor staat? Een gratis websitecheck laat zien welke scripts de meeste tijd kosten.