Website

TBT Verkorten met Vertraging en Asynchroon Laden van JavaScript op je Website

  • Leestijd: 13 minuten
  • Hostragons Team
TBT Verkorten met Vertraging en Asynchroon Laden van JavaScript op je Website

Het vertraagd laden van JavaScript is een techniek waarbij je JavaScript-bestanden die het renderen van de pagina blokkeren, zorgvuldig uitstelt om zo de Total Blocking Time (TBT) te verlagen. Door niet-kritieke scripts te voorzien van defer of async attributen zorg je ervoor dat de hoofdthread minder wordt geblokkeerd. Hierdoor ziet de gebruiker de pagina sneller, kan hij eerder klikken en verbeteren je Core Web Vitals. Om vertraagd laden toe te passen, bepaal je eerst welke scripts kritisch zijn. Meestal gebruik je defer voor scripts met afhankelijkheden en async voor onafhankelijke derde-partij scripts. Meet daarna de TBT met tools zoals PageSpeed Insights, Lighthouse en Chrome DevTools.

Performanceproblemen op moderne websites komen vaker door oncontroleerbaar JavaScript dan door afbeeldingen. In een webshop bijvoorbeeld zorgen productfilters, livechat, advertentiepixels, analytics, reactiesystemen, A/B-testtools en thema-scripts samen voor een langdurig bezette hoofdthread. Dit is vooral merkbaar op mobiele apparaten. Een gebruiker kan de titel al zien maar krijgt geen respons bij het aanraken van het menu; in Lighthouse zie je dan een hoge Total Blocking Time.

In deze gids leggen we uit wat defer en async precies doen, wanneer je welke moet gebruiken, hoe je dit toepast in WordPress en maatwerkprojecten, waar je op moet letten bij het meten, en realistische TBT-winst kunt behalen. De aanbevelingen gelden voor websites gehost op Hostragons infrastructuur, maar zijn ook toepasbaar volgens algemene webstandaarden. We belichten ook hoe een goede hosting, CDN, SSL en caching de JavaScript-optimalisatie ondersteunen. Hostragons web hosting pakketten

Wat is TBT en waarom is het zo belangrijk voor JavaScript?

TBT staat voor Total Blocking Time en meet hoe lang de hoofdthread van de browser geblokkeerd is, waardoor de pagina niet direct reageert op gebruikersinteractie. In laboratoriumtests met Lighthouse meet TBT de som van alle taken die langer dan 50 milliseconden duren tussen First Contentful Paint en Time to Interactive. Een JavaScript-taak van 180 ms draagt dan 130 ms bij aan de TBT (180 ms minus 50 ms drempel).

Deze metriek is cruciaal voor de gebruikerservaring. Wanneer een bezoeker na het openen van een pagina op het menu, de winkelwagen of een zoekveld tikt terwijl de browser nog scripts uitvoert, duurt het even voordat er respons is. Dit voelt voor de gebruiker als haperingen, traagheid of een kapotte site. Hoewel Google in 2026 geen totaalscore voor paginabeleving geeft, hebben sites die snel en stabiel reageren betere gebruikerswaardering en conversie.

Veelvoorkomende signalen van een hoge TBT

  • Een TBT hoger dan 300 ms in de mobiele PageSpeed Insights-rapportage.
  • Waarschuwingen voor 'Reduce JavaScript execution time' of 'Minimize main-thread work' in Lighthouse.
  • De pagina is zichtbaar maar menu, sliders, filters of formulieren reageren vertraagd.
  • Derde-partij advertenties, livechat of analytics scripts hebben een hoge impact in rapporten.
  • Met name instapmodel Android-apparaten ervaren scroll- en klikvertraging.

Een goede richtlijn is om TBT onder de 200 ms te houden voor de meeste content-sites. Voor complexere e-commerce of SaaS interfaces is dat lastiger en zijn extra maatregelen zoals code-splitting, verwijderen van onnodige pakketten, caching, serveroptimalisatie en kritisch CSS vereist. Toch is vertraagd laden vaak de eerste en makkelijkste stap met snel resultaat.

Wat zijn Defer en Async?

Standaard stopt de browser met het parseren van HTML zodra hij een <script>-tag tegenkomt, downloadt het script, voert het uit en gaat dan verder met het laden van de pagina. Dit is soms nodig voor kritieke scripts, maar veroorzaakt bij elk script onnodige vertraging. De attributen defer en async veranderen dat gedrag door het downloaden en uitvoeren van scripts anders te regelen.

Hoe werkt Defer?

Een script met defer wordt tijdens het parsen van de HTML op de achtergrond gedownload, maar pas uitgevoerd nadat de gehele HTML is geparsed. Bij meerdere defer-scripts wordt de volgorde van uitvoering gehandhaafd zoals ze in de HTML staan. Dit maakt defer een veilige keuze voor scripts die afhankelijk zijn van elkaar, bijvoorbeeld een bibliotheek gevolgd door een thema-script.

Een voorbeeld: <script defer src="/js/app.js"></script>. Het bestand wordt zonder blokkeren binnengehaald en pas uitgevoerd zodra de DOM klaar is. Moderne browsers ondersteunen defer goed en het is een betrouwbare optimalisatie voor klassieke scripts.

Hoe werkt Async?

Ook async downloadt het script tijdens het parsen van HTML, maar voert het direct uit zodra het downloaden klaar is. Dit kan tijdelijk het parsen van HTML pauzeren. Async scripts worden onafhankelijk van elkaar uitgevoerd, zonder volgorde-garantie. Hierdoor is async ideaal voor onafhankelijke scripts zoals analytics, advertenties, tracking pixels, externe widgets of social media codes.

Een voorbeeld: <script async src="/js/analytics.js"></script>. Dit script hoeft niet te wachten op andere scripts. Maar als het bijvoorbeeld afhankelijk is van een variabele die later wordt geladen of van jQuery, kan async fouten veroorzaken. Async is snel, maar vereist zorgvuldige classificatie.

Vergelijkingstabel Defer vs Async

Vergelijkingstabel Defer vs Async
Kenmerkdeferasync
Blokkeert het HTML parseren tijdens downloaden?Nee, downloadt op de achtergrond.Nee, downloadt op de achtergrond.
Wanneer wordt het uitgevoerd?Na het volledig parsen van HTML.Direct na het downloaden.
Wordt de uitvoer volgorde gegarandeerd?Ja, volgorde blijft behouden.Nee, eerst binnengekomen script werkt eerst.
Beste gebruikThema-scripts, afhankelijke modules, hoofdapplicatie.Onafhankelijke analytics, advertenties, pixels, externe widgets.
RisicoKan vertraging veroorzaken als scripts meteen moeten werken.Racecondities bij afhankelijkheden, fouten mogelijk.
Effect op TBTVermindert initiële blokkerende tijd veilig en gebalanceerd.Helpt bij vroege scheiding van onafhankelijke derde-partij scripts.

De vuistregel: als je script in volgorde moet draaien, gebruik defer. Is het volledig onafhankelijk, probeer dan async. Bij twijfel eerst defer op een staging-omgeving testen en console-fouten checken. gids voor staging omgeving en back-up

Stapsgewijs Plan voor Vertraging van JavaScript Laden

Willekeurig overal defer of async zetten kan op korte termijn de score verbeteren, maar breekt mogelijk belangrijke functies zoals betaling, zoeken, menu, formulieren of winkelwagen. Een gestructureerde aanpak met meten, classificeren, kleine aanpassingen, testen en monitoren is essentieel.

1. Meet de huidige prestaties

Maak een nulmeting met PageSpeed Insights voor mobiel en desktop. Noteer in het Lighthouse-rapport TBT, First Contentful Paint, Largest Contentful Paint en Speed Index. Bekijk in Chrome DevTools bij Performance de hoofdthread: lange gele blokken duiden vaak op JavaScript parsing, compilatie en uitvoering.

Voorbeeld: mobiel TBT 780 ms, JavaScript execution 2,8 seconden, main-thread werk 4,5 seconden. Na optimalisatie daalt TBT tot 280 ms, wat een verbetering van circa 64% betekent. Dergelijke data helpt om binnen het team inzicht te krijgen in welke aanpassingen effect hebben.

2. Maak een scriptinventarisatie

Lijst alle JavaScript-bestanden die geladen worden via de broncode of netwerk-tab in de browser. Bepaal per script de bron, grootte, moment van gebruik en afhankelijkheden. Verdeel ze in groepen:

  • Kritieke scripts: noodzakelijk voor eerste weergave of navigatie.
  • Afhankelijke lokale scripts: thema, slider, filter, galerij, applicatie-modules.
  • Onafhankelijke derde-partij scripts: analytics, advertenties, pixels, chat, social media.
  • Onnodige of verouderde scripts: bestanden van ongebruikte plugins.
  • Scripts met conditioneel gebruik: alleen op specifieke pagina’s, zoals formulieren op contactpagina’s.

De beste optimalisatie is soms geen defer toevoegen, maar onnodige scripts helemaal verwijderen. Een gecomprimeerd bestand van 90 KB kan op mobiel al gauw 300 ms parsing en uitvoering kosten. Eerst opschonen, dan uitstellen is de juiste volgorde.

3. Bepaal welke scripts met Defer geladen worden

Meestal zijn dat hoofdthema-scripts, menu-gedrag, sliders, productgalerijen en app-bundles. Belangrijk is dat deze scripts niet zwaar afhankelijk zijn van blokkades zoals document.write en dat ze kunnen wachten tot de DOM klaar is.

In WordPress kunnen scripts als jquery-migrate, hoofdthema en plugin-scripts complexe afhankelijkheden hebben. jQuery async maken is riskant omdat veel plugins jQuery in de juiste volgorde verwachten. Beter is om jQuery-afhankelijke scripts gecontroleerd met defer te laden of gebruik te maken van geoptimaliseerde laadopties in plugins. WordPress snelheid optimalisatie gids

4. Selecteer scripts voor Async

Google Analytics, advertentie-tags, Facebook Pixel, LinkedIn Insight, externe chat widgets en social share codes zijn geschikte async-kandidaten. Niet elk derde-partij script is hetzelfde: sommige livechattools willen direct gebruikerssessies starten, sommige advertentiesystemen verwachten een specifieke volgorde. Documentatie lezen is daarom essentieel.

Async voor onafhankelijke analytics is meestal onschadelijk. Om dataverlies te voorkomen, controleer triggers in real-time rapportages. Gebruik tagmanagers verstandig: stapel niet alle tags in één container, maar verdeel triggers slim. Bijvoorbeeld geen comment tracking op pagina’s zonder reacties, en geen productinteractie scripts op niet-productpagina’s.

5. Voeg conditioneel en op gebeurtenis gebaseerd laden toe

defer en async zijn een goed begin, maar nog effectiever is JavaScript laden op basis van gebruikersgedrag. Een livechat kan pas laden nadat de gebruiker 5 seconden op de pagina is, of op de helpknop klikt. Kaart-embed scripts kunnen pas laden bij scrollen naar het contactgedeelte. Videospelers starten bij het drukken op play.

Deze aanpak is vooral krachtig bij content- en zakelijke websites, waar niet elke widget op elke pagina nodig is. 200 KB minder JavaScript bij de eerste load kan TBT op zwakke mobiele toestellen met honderden milliseconden verminderen.

6. Test en rol gefaseerd uit

Test veranderingen eerst in een testomgeving. Voer handmatige tests uit op homepage, categoriepagina, product- of dienstpagina, contactpagina, inlog- en betaalpagina. Controleer browserconsole op fouten zoals ‘Cannot read property’, ‘is not defined’ of ‘undefined function’, die duiden op volgorde- of afhankelijkheidsproblemen.

Rol live gefaseerd uit: begin met onafhankelijke derde-partij scripts, dan thema-scripts. Meet na elke stap met Lighthouse op hetzelfde netwerk en apparaat. Vertrouw niet op één test, maar neem het gemiddelde van drie metingen voor betrouwbaardere resultaten.

Defer en Async in WordPress toepassen

In WordPress worden scripts geladen via wp_enqueue_script vanuit thema’s en plugins. Vanaf 2026 kun je in moderne WordPress-versies scriptstrategieën beter beheren, maar oudere thema’s, page builders en incompatibele optimalisatie-plugins zorgen soms voor conflicten.

Gebruik je een performance-plugin, stel dan een uitsluitlijst in in plaats van alles met één klik uit te stellen. Betalingspagina’s, login, adminbar, beveiliging en captcha-scripts zijn gevoelig. In WooCommerce moeten winkelwagenfragmenten, betaalgateway-scripts en variatie-selectors goed getest worden. WooCommerce hosting oplossingen

Een praktische volgorde is: verwijder ongebruikte plugins, maak plugin-scripts conditioneel (alleen op noodzakelijke pagina’s), probeer defer voor thema- en plugin-scripts, en gebruik async of vertraagd laden voor onafhankelijke derde-partij codes. Zo minimaliseer je het risico op grote verstoringen in één keer.

Tips voor maatwerk en frameworkprojecten

In moderne frameworks zoals React, Vue, Angular, Next.js of Nuxt is optimalisatie meer dan alleen defer toevoegen. Bundelgrootte, code-splitting, tree shaking, dynamic imports en hydration bepalen je TBT. Een enkele grote bundle van 700 KB blokkeert de hoofdthread lang, ook met defer.

Gebruik route-gebaseerde code-splitting zodat bijvoorbeeld beheerpanelen, grafiekbibliotheken of geavanceerde editors niet onnodig worden geladen. Laad zware componenten dynamisch bij gebruik. Identificeer ongebruikte dependencies met analysetools. Overweeg lichtere alternatieven voor grote datum-, grafiek- of animatiebibliotheken.

Let op bij server-side rendering of statische generatie: ondanks snelle HTML kan de hydration-fase met honderden actieve componenten veel TBT veroorzaken. Vermijd onnodige client-side JavaScript bij statische content; dit is een belangrijk aspect van performance in 2026.

Hosting, serverreactietijd en JavaScript-prestaties

TBT meet de tijd die JavaScript in de browser draait, maar hosting beïnvloedt dit indirect. Langzame Time To First Byte (TTFB), ontbrekende compressie, geen HTTP/2 of HTTP/3, slechte caching en grote afstand tot de server zorgen voor vertraagde levering van scripts. Dit verlengt de paginalaadcyclus en schaadt de gebruikerservaring.

Een goede hostingomgeving met Brotli- of Gzip-compressie, effectieve browsercaching, up-to-date PHP, snelle opslagtechnologie en CDN-integratie ondersteunt optimalisaties. Correct ingestelde SSL-certificaten zijn belangrijk voor moderne browserfeatures, HTTP/2 en veilige derde-partij integraties. Hostragons SSL certificaten Hostragons domeinnaam controle

Een JavaScript-bestand van 320 KB kan met Brotli worden teruggebracht tot 95 KB. Hoewel dit niet direct TBT halveert (want TBT meet uitvoeringstijd), verkort het wel downloadtijd, verbetert het resourceprioritering en versnelt het de totale laadtijd. Daarom moeten defer, async, caching en goede hosting samen worden ingezet.

Checklist voor meten en validatie

PageSpeed score alleen zegt niet alles over succesvolle optimalisatie. Gebruik deze checklist om het echte effect te beoordelen:

  • Is de mobiele TBT voor en na optimalisatie vergeleken?
  • Zijn de duurste JavaScript-bestanden in de execution time afgenomen?
  • Is het aantal lange taken in Chrome DevTools Performance gedaald?
  • Zitten er geen JavaScript-fouten in de console?
  • Werken menu, zoekfunctie, filters, formulieren, winkelwagen en betaling vlekkeloos?
  • Worden derde-partij analytics en advertentietags correct getriggerd?
  • Verbeteren INP en interactievertragingen in real-user monitoring?
  • Zijn de testen herhaald na het legen van cache?

Belangrijk is om labdata (zoals TBT uit Lighthouse) en fielddata (zoals Interaction to Next Paint, INP) te scheiden. Hoewel INP in de praktijk leidend is, helpt een lagere TBT meestal ook bij het verbeteren van INP omdat minder hoofdthread-blokkades optreden.

Veelgemaakte fouten en hoe ze te vermijden

Alle scripts tegelijk async maken

Dit is een veelvoorkomende valkuil. Async garandeert geen volgorde, waardoor afhankelijkheden kunnen falen. Wat op één toestel werkt, kan op langzame verbindingen of in andere browsers breken. Bij afhankelijkheden is defer een veiligere keuze.

jQuery en afhankelijke plugins verkeerd uitstellen

Veel WordPress-plugins vertrouwen op jQuery in de juiste volgorde. jQuery async maken zorgt ervoor dat plugin-scripts voor jQuery worden uitgevoerd, wat fouten veroorzaakt. Analyseer afhankelijkheden en sluit kritieke scripts uit van async.

Derde-partij scripts ongereguleerd laten

Eigen thema optimaliseren maar advertenties, chat en analytics vergeten is riskant. Deze scripts zijn vaak de zwaarste kluiven in Lighthouse. Verwijder ongebruikte tags, laad ze conditioneel en stel ze uit waar mogelijk.

Plugins installeren zonder meten

Performance-plugins kunnen nuttig zijn, maar voegen vaak zelf weer extra JavaScript en CSS toe. Diagnoseer eerst het probleem, kies daarna het juiste gereedschap. Controleer met testrapporten of de plugin daadwerkelijk TBT reduceert.

Conflicten tussen caching, minificatie en async/defer

Als minificatie, bundeling, defer en async samen worden ingezet, kan de volgorde van bestanden veranderen. Dit leidt tot onverwachte fouten in productie. Maak na wijzigingen alle cachelagen schoon: CDN, servercache en applicatiecache.

Een realistisch optimalisatiescenario

Stel je een middelgrote zakelijke website voor met 18 JavaScript-verzoeken op de homepage. Hiervan zijn 5 thema- en menugedrag, 4 slider- en animatiescripts, 3 formulieren en kaartmodules, en 6 analytics, pixels en livechat codes. De initiële mobiele TBT is 920 ms.

Stap 1: verwijder twee ongebruikte animatie-plugins, bespaar 140 KB gecomprimeerde JavaScript. TBT daalt naar 760 ms.
Stap 2: zet thema- en slider-scripts op defer, test afhankelijkheden. TBT daalt naar 480 ms.
Stap 3: laad kaart-script alleen bij scroll naar contact, start livechat na 7 seconden, maak analytics en pixels async. TBT zakt naar 210 ms.

Dit scenario laat zien dat een gelaagde aanpak het verschil maakt. defer en async zijn krachtige middelen, maar het beste resultaat bereik je door onnodige code te verwijderen, conditioneel te laden, goede caching toe te passen en te zorgen voor een solide hostingomgeving.

Conclusie: een gebalanceerde en geteste JavaScript-strategie verlaagt TBT

Vertraagd JavaScript laden is een van de meest praktische en effectieve manieren om TBT te verlagen. defer biedt een veilige oplossing voor scripts die in volgorde en na de DOM moeten draaien, terwijl async ideaal is voor onafhankelijke derde-partij scripts. Succes begint met meten, scripts classificeren, onnodige bestanden verwijderen, gefaseerd testen en de echte gebruikerservaring monitoren.

Hostragons biedt een snelle, veilige en schaalbare hostingomgeving die samen met JavaScript-optimalisatie, caching en SSL zorgt voor stabiele webprestaties. Wil je je TBT verbeteren? Start dan met een nulmeting en zet kleine, meetbare stappen vooruit. Bekijk onze hostingoplossingen voor de beste infrastructuur. Hostragons web hosting pakketten

Veelgestelde vragen

Kun je defer en async tegelijk gebruiken?

Als je beide tegelijk op een script zet, kan in moderne browsers async voorrang krijgen, waardoor de volgorde verloren gaat. Daarom wordt het afgeraden beide attributen samen te gebruiken. Gebruik defer voor afhankelijke scripts en async voor onafhankelijke.

Verlaagt vertraagd laden van JavaScript direct mijn SEO-ranking?

Niet direct, maar het verbetert paginabeleving, interactiesnelheid en Core Web Vitals, wat indirect SEO-voordeel oplevert. Snellere pagina’s zorgen voor meer tevreden bezoekers, hogere conversie en betere crawlbaarheid.

Is het veilig om elk JavaScript-bestand van defer te voorzien?

Nee. Sommige scripts moeten vroeg draaien of zijn afhankelijk van een bepaalde volgorde. Elk script moet beoordeeld worden op doel, afhankelijkheid en timing, en wijzigingen moeten in testomgeving worden doorgevoerd.

Volstaat het om alleen defer en async te gebruiken om TBT flink te verlagen?

Voor kleine en middelgrote sites kan dat al veel schelen. Voor sites met zware frameworks of veel derde-partij code zijn extra maatregelen nodig zoals code-splitting, onnodige scripts verwijderen, conditioneel laden, caching en een krachtige hosting.

Welke scripts moet ik niet async maken in WordPress?

Scripts die afhankelijk zijn van jQuery, betaal- en winkelwagenscripts, formulier- en beveiligingsscripts, en kritieke themafuncties mogen niet zomaar async. Begin met defer en sluit ze indien nodig uit van async.

Deel dit artikel:

Hostragons Team

Actuele handleidingen van ons expertteam over hosting, servers en domeinnamen. Laten we samen de juiste oplossing voor uw project vinden.

Neem contact met ons op