Defer vs Async JavaScript en hoe dit de Core Web Vitals beïnvloedt
Leer wanneer je JavaScript async of defer moet laden voor de beste Core Web Vitals resultaten
Defer vs Async JavaScript en hoe dit de Core Web Vitals beïnvloedt
Wanneer ik de Core Web Vitals van een klant audit, merk ik vaak dat er op een pagina weinig onderscheid wordt gemaakt 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!
- Defer vs Async JavaScript 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: scripts op aanvraag laden
Volgens de 2025 Web Almanac slaagt slechts 15% van de mobiele pagina's voor de render-blocking resources audit. De mediane pagina laadt 22 scripts met een totale grootte van meer dan 630 KB, waarbij 251 KB van die JavaScript volledig ongebruikt blijft. De meeste sites laden veel te veel JavaScript, 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 alsnog kan onderbreken. Deferred scripts downloaden op de achtergrond en wachten tot het parsen is voltooid voordat ze worden uitgevoerd, in de volgorde van het document.
Gebruik defer voor alles wat met de DOM te maken heeft. 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 bij 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 verdergaat. Dit betekent dat er geen pixels op het scherm verschijnen totdat alle sync scripts klaar zijn. Bij grote of trage scripts zorgt dit voor een zichtbare vertraging in 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 content hier --> </body> </html>
De browser moet script1.js downloaden en uitvoeren voordat hij überhaupt aan script2.js begint. Ondertussen wordt er niets gerenderd. De mediane mobiele pagina heeft in 2025 al een Total Blocking Time van bijna 2 seconden. 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 downloaden is voltooid, ongeacht waar de parser zich op dat moment 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 content 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 dingen onvoorspelbaar stukmaken. Gebruik async alleen voor scripts die volledig onafhankelijk zijn van elkaar en van de DOM.
Iets om rekening mee te houden: in Chrome krijgen async scripts standaard een Lage netwerkprioriteit. Dit betekent dat de browser mogelijk later begint met downloaden dan je verwacht. Als je een async script snel wilt laden (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 geparst. Deferred scripts worden uitgevoerd in de volgorde van het document, vlak voordat het DOMContentLoaded event wordt geactiveerd.
<!DOCTYPE html> <html> <head> <title>Defer JavaScript Voorbeeld</title> <script src="script1.js" defer></script> <script src="script2.js" defer></script> </head> <body> <!-- Pagina content hier --> </body> </html>
Defer is de veiligere keuze voor de meeste scripts. De DOM is volledig beschikbaar wanneer het script draait, de uitvoeringsvolgorde blijft behouden en de eerste paint wordt niet geblokkeerd. The Telegraph heeft al hun scripts deferred en verbeterde de laadtijd van advertenties met 4 seconden.
4. Module scripts
Als je ES modules gebruikt (<script type="module">), krijg je automatisch defer gedrag. Module scripts downloaden op de achtergrond, voeren uit na het parsen en behouden hun volgorde. Het expliciet toevoegen van defer heeft geen effect omdat dit al de standaard is.
Je kunt async toevoegen aan een module script als je wilt dat het wordt uitgevoerd zodra de afhankelijkheidsgrafiek is opgelost, in plaats van te wachten tot het parsen is voltooid.
Vergelijkingstabel
| Attribuut | Downloadt | Voert uit | Blokkeert parsen? | Volgorde behouden? |
|---|---|---|---|---|
geen (sync) |
Blokkeert parsen tijdens download | Direct na download | Ja (download + uitvoering) | Ja |
async |
Op de achtergrond | Zodra de download 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 een fallback voor IE9, maar in 2026 is er geen reden meer 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 deferred is, zelfs als het inline is.
Is defer beter dan scripts aan het einde van de body plaatsen? Ja. Een deferred script in de <head> begint direct 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 vroegere ontdekking en latere uitvoering, wat het beste van twee werelden is.
Hoe async en defer de Core Web Vitals beïnvloeden
Synchrone scripts schaden FCP direct omdat er niets gepaint wordt totdat ze klaar zijn. Ze schaden ook LCP als het LCP-element niet kan renderen totdat scripts zijn voltooid.
Async scripts verbeteren FCP (de eerste paint wordt niet geblokkeerd door de download) maar kunnen alsnog INP problemen veroorzaken als ze worden uitgevoerd tijdens een gebruikersinteractie en de main thread blokkeren.
Defer scripts geven je de beste paint metrics omdat ze helemaal niet interfereren met de initiële render. De afweging: als je pagina afhankelijk is van JavaScript om content te tonen (single-page apps), kan defer de LCP daadwerkelijk vertragen omdat de content niet verschijnt totdat het script na het parsen draait.
In CoreDash monitoring data zagen sites die alle niet-kritieke scripts van sync naar defer verplaatsten, hun FCP gemiddeld met 340ms verbeteren.
Nog een stap verder: scripts op aanvraag laden
Async en defer kunnen een pagina versnellen door de parser niet te blokkeren, maar het is belangrijk om te weten dat het deferren van scripts niet al je problemen zal oplossen. Bijvoorbeeld, het Largest Contentful Paint-element is kwetsbaar voor netwerk- en CPU-competitie 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 te deferren. Als je te maken hebt met de Lighthouse render-blocking resources waarschuwing, behandelt die gids de oplossing. Je kunt het laden ook verfijnen met JavaScript prioriteitsniveaus en de optimale scriptplaatsing in de head vs footer kiezen.
Performance degrades the moment you stop watching.
I set up the monitoring, the budgets, and the processes. That is the difference between a fix and a solution.
Let's talk
