JavaScript Defer vs Async en hoe dit de Core Web Vitals beïnvloedt
Leer wanneer je async op JavaScript moet toepassen en wanneer defer voor de beste Core Web Vitals-resultaten
JavaScript Defer vs Async en hoe dit de Core Web Vitals beïnvloedt
Wanneer ik de Core Web Vitals van een klant controleer, ontdek ik vaak dat er op een pagina weinig onderscheid is tussen parser-blocking (sync), asynchrone of deferred JavaScript. Dat is zonde want verschillende scripts hebben verschillende optimale timings.
Laatst beoordeeld door Arjen Karel in maart 2026
Table of Contents!
- JavaScript Defer vs Async en hoe dit de Core Web Vitals beïnvloedt
- In het kort
- 1. Synchrone JavaScript (sync)
- 2. Asynchrone JavaScript (async)
- 3. Deferred JavaScript (defer)
- 4. Module scripts
- Vergelijkingstabel
- Veelgestelde vragen
- Hoe async en defer de Core Web Vitals beïnvloeden
- Nog een stap verder: laad scripts op aanvraag (on demand)
Volgens de Web Almanac 2025 slaagt slechts 15% van de mobiele pagina's voor de audit van render-blocking resources. De mediane pagina laadt 22 scripts van in totaal meer dan 630 KB, waarbij 251 KB van die JavaScript volledig ongebruikt blijft. De meeste sites laden veel te veel JavaScript in, en laden het op het verkeerde moment.
In het kort
'Normale' JavaScript in de head van de pagina blokkeert de browser bij het parsen van de HTML totdat het is gedownload en uitgevoerd. Async scripts downloaden op de achtergrond maar worden uitgevoerd zodra ze klaar zijn, wat het parsen nog steeds kan onderbreken. Deferred scripts downloaden op de achtergrond en wachten tot het parsen voltooid is voordat ze worden uitgevoerd, in de volgorde van het document.
Gebruik defer voor alles wat de DOM aanraakt. Gebruik async voor scripts die volledig onafhankelijk zijn (analytics, tracking pixels). Gebruik geen van beide (sync) alleen als het script moet worden uitgevoerd voordat de pagina rendert. Gebruik in geval van twijfel defer.
1. Synchrone JavaScript (sync)
Standaard zijn scripts in de head van de pagina synchroon. Wanneer de browser een synchroon script tegenkomt, stopt deze met het parsen van de HTML, downloadt het script en voert het uit voordat hij verder gaat. Dit betekent dat er geen pixels worden getekend totdat alle sync scripts klaar zijn. Voor grote of trage scripts creëert dit een zichtbare vertraging in de First Contentful Paint.
<!DOCTYPE html> <html> <head> <title>Sync JavaScript Voorbeeld</title> <script src="script1.js"></script> <script src="script2.js"></script> </head> <body> <!-- Pagina inhoud hier --> </body> </html>
De browser moet script1.js downloaden en uitvoeren voordat hij zelfs maar aan script2.js begint. Ondertussen rendert er niets. De mediane mobiele pagina heeft al een Total Blocking Time van bijna 2 seconden in 2025. Synchrone scripts in de head maken dit erger.
2. Asynchrone JavaScript (async)
Het toevoegen van het async attribuut vertelt de browser om het script op de achtergrond te downloaden terwijl hij doorgaat met het parsen van de HTML. Het script wordt uitgevoerd zodra het klaar is met downloaden, waar de parser zich op dat moment ook bevindt. Het parsen pauzeert alleen tijdens de uitvoering.
<!DOCTYPE html> <html> <head> <title>Async JavaScript Voorbeeld</title> <script src="script1.js" async></script> <script src="script2.js" async></script> </head> <body> <!-- Pagina inhoud hier --> </body> </html>
Async scripts garanderen geen uitvoeringsvolgorde. Welk script als eerste klaar is met downloaden, wordt als eerste uitgevoerd. Als script2.js afhankelijk is van script1.js, zal async op onvoorspelbare wijze dingen kapot maken. Gebruik async alleen voor scripts die volledig onafhankelijk zijn van elkaar en de DOM.
Iets om je bewust van te zijn: in Chrome krijgen async scripts standaard een Lage netwerkprioriteit (Low network priority). Dit betekent dat de browser ze mogelijk later begint te downloaden dan je verwacht. Als je wilt dat een async script snel laadt (zonder het parsen te blokkeren), voeg dan fetchpriority="high" toe.
3. Deferred JavaScript (defer)
Het defer attribuut downloadt het script ook op de achtergrond, maar de uitvoering wordt uitgesteld totdat het HTML-document volledig is geparseerd. Deferred scripts worden uitgevoerd in documentvolgorde, net voordat het DOMContentLoaded event afgaat.
<!DOCTYPE html> <html> <head> <title>Defer JavaScript Voorbeeld</title> <script src="script1.js" defer></script> <script src="script2.js" defer></script> </head> <body> <!-- Pagina inhoud hier --> </body> </html>
Defer is de veiligste keuze voor de meeste scripts. De DOM is volledig beschikbaar wanneer het script wordt uitgevoerd, de uitvoeringsvolgorde blijft behouden en de first paint wordt niet geblokkeerd. The Telegraph stelde al hun scripts uit en verbeterde de laadtijd van advertenties met 4 seconden.
4. Module scripts
Als je ES modules (<script type="module">), krijg je automatisch defer gedrag. Module scripts downloaden op de achtergrond, worden uitgevoerd na het parsen en behouden de volgorde. Het expliciet toevoegen van defer heeft geen effect omdat het al de standaard is.
Je kunt async toevoegen aan een module script als je wilt dat het wordt uitgevoerd zodra de dependency graph is opgelost, in plaats van te wachten tot het parsen is voltooid.
Vergelijkingstabel
| Attribuut | Downloads | Voert uit | Blokkeert parsen? | Volgorde behouden? |
|---|---|---|---|---|
geen (sync) |
Blokkeert parsen tijdens download | Direct na het downloaden | Ja (download + uitvoering) | Ja |
async |
Op de achtergrond | Zodra het downloaden is voltooid | Alleen tijdens uitvoering | Nee |
defer |
Op de achtergrond | Na HTML parsing, voor DOMContentLoaded | Nee | Ja |
type="module" |
Op de achtergrond | Na HTML parsing (hetzelfde als defer) | Nee | Ja |
Veelgestelde vragen
Wat als ik zowel async als defer op dezelfde tag gebruik? Async wint. Het defer attribuut wordt volledig genegeerd. Dit patroon bestond vroeger als fallback voor IE9, maar in 2026 is er geen reden om beide te gebruiken.
Werken async en defer op inline scripts? Nee. Beide attributen worden genegeerd op klassieke inline scripts (zonder src). Ze werken alleen op externe scripts. De uitzondering is <script type="module">, dat standaard wordt uitgesteld, zelfs wanneer het inline is.
Is defer beter dan het plaatsen van scripts aan het einde van de body? Ja. Een deferred script in de <head> begint onmiddellijk met downloaden (parallel aan het parsen van de HTML). Een script aan het einde van de body kan pas beginnen met downloaden als de parser het bereikt. Defer geeft je een vroegere ontdekking en een latere uitvoering, wat het beste van twee werelden is.
Hoe async en defer de Core Web Vitals beïnvloeden
Synchrone scripts schaden de FCP direct omdat er niets wordt getekend totdat ze klaar zijn. Ze schaden ook de LCP als het LCP-element pas kan renderen als de scripts voltooid zijn.
Async scripts verbeteren de FCP (de first paint wordt niet geblokkeerd door de download), maar kunnen nog steeds INP problemen veroorzaken als ze worden uitgevoerd tijdens gebruikersinteractie en de hoofdthread (main thread) blokkeren.
Defer scripts geven je de beste paint-statistieken (paint metrics) omdat ze de initiële render helemaal niet hinderen. De afweging: als je pagina afhankelijk is van JavaScript om content weer te geven (single-page apps), kan defer de LCP daadwerkelijk vertragen omdat de content niet verschijnt totdat het script is uitgevoerd na het parsen.
In monitoring data van CoreDash zagen sites die alle niet-kritieke scripts verplaatsten van sync naar defer hun FCP gemiddeld met [CD:placeholder]ms verbeteren.
Nog een stap verder: laad scripts op aanvraag (on demand)
Async en defer kunnen een pagina versnellen door de parser niet te blokkeren, maar het is belangrijk om op te merken dat het uitstellen van scripts niet al je problemen zal oplossen. Bijvoorbeeld, het largest contentful paint-element is kwetsbaar voor netwerk- en CPU-concurrentie veroorzaakt door deferred en async scripts. De interaction to next paint wordt ook beïnvloed door scripts die vroeg tijdens het laden van de pagina worden uitgevoerd. Daarom moet je, waar mogelijk, scripts op aanvraag laden om meer controle te hebben over hun impact op de paginaprestaties. Lees hoe wij scripts op aanvraag laden.
Voor een compleet overzicht van alle JavaScript laadstrategieën, zie 16 methoden om JavaScript uit te stellen. Als je te maken hebt met de Lighthouse render-blocking resources waarschuwing, behandelt die gids de oplossing. Je kunt het laden ook finetunen met JavaScript prioriteitsniveaus en de optimale scriptplaatsing in de head vs footer kiezen.
I have done this before at your scale.
Complex platforms, large dev teams, legacy code. I join your team as a specialist, run the performance track, and hand it back in a state you can maintain.
Discuss Your Situation
