JavaScript in Head vs Footer: Hoe Het de Core Web Vitals Beïnvloedt
Waarom defer in de head de moderne best practice is, en wanneer footer plaatsing nog steeds logisch is
Het korte antwoord: defer in de head
Laatst beoordeeld door Arjen Karel in maart 2026
Het klassieke advies was om JavaScript in de footer te plaatsen. Dat advies is achterhaald. Nu async en defer in elke browser worden ondersteund, is de beste plaats voor de meeste scripts in de <head> met een defer attribuut.
De reden komt neer op de preload scanner: je browser ontdekt head scripts onmiddellijk en begint ze parallel te downloaden met het parsen van HTML. Footer scripts worden later ontdekt, wat een latere start van het downloaden betekent. Het resultaat is hetzelfde niet-blokkerende gedrag, maar met een snellere ontdekking van resources.
Volgens de 2025 Web Almanac faalt 85% van de pagina's nog steeds voor de audit van render-blocking resources. Dat is een enorm aantal. Ondertussen steeg de Total Blocking Time op mobiel met 58% jaar op jaar tot een mediaan van 1.916 ms. JavaScript wordt zwaarder, niet lichter. De plaatsing van je scripts correct krijgen is een van de gemakkelijkste dingen die je kunt doen om je First Contentful Paint en Largest Contentful Paint te verbeteren.
Hoe de preload scanner werkt
De preload scanner is een tweede HTML parser die vooruitloopt op de hoofd parser. Hij scant snel de ruwe HTML en begint kritieke resources (afbeeldingen, CSS, JavaScript) op te halen voordat de hoofd parser ze bereikt. De preload scanner haalt resources ongeveer in de volgorde op waarin hij ze ontdekt.
Hier is waar script plaatsing van belang is. Een script in de <head> wordt vrijwel onmiddellijk ontdekt. Een script onderaan de <body> wordt later ontdekt, vooral bij grote HTML documenten. Die vertraging kan je honderden milliseconden kosten op een mobiele verbinding.
Dynamisch geïnjecteerde scripts (aangemaakt via JavaScript) zijn volledig onzichtbaar voor de preload scanner. De scanner ontdekt alleen resources die aanwezig zijn in de HTML markup die door de server wordt geretourneerd. Daarom is JavaScript uitstellen via HTML attributen bijna altijd beter dan het injecteren van scripts met code.
JavaScript in de head
Door JavaScript in de <head> van de pagina te plaatsen, wordt het zo vroeg mogelijk ontdekt door de preload scanner.
Voordelen
- Vroege ontdekking: De preload scanner vindt head scripts vóór de inhoud van de body. Het downloaden begint zo vroeg mogelijk.
- Eerdere uitvoering: Scripts in de head (met
defer) worden uitgevoerd voordat scripts die later in het document worden ontdekt. Voor een gedetailleerde vergelijking, zie defer vs async JavaScript en de Core Web Vitals. - Code scheiding: Het houden van script referenties in de
<head>scheidt ze van de content markup, waardoor de HTML makkelijker te onderhouden is.
Nadelen
- Render blokkerend (zonder defer of async): Een gewone
<script>in de head blokkeert HTML parsing totdat het script is gedownload en uitgevoerd. Dit is dodelijk voor je First Contentful Paint. Gebruik altijddeferofasyncop externe scripts in de head om dit te voorkomen. - Bandbreedte concurrentie: Head scripts met een hoge prioriteit concurreren om bandbreedte met je CSS, fonts en LCP afbeelding. Op tragere verbindingen kan dit je Largest Contentful Paint voorbij de 2,5 seconden grens duwen.
Wanneer head plaatsing gebruiken
Gebruik de <head> voor scripts die kritiek zijn voor de pagina-ervaring: je menu, cookiemelding, slider of elk script dat invloed heeft op wat de bezoeker above the fold ziet. Voeg defer (of async als de uitvoeringsvolgorde er niet toe doet) toe om te voorkomen dat rendering wordt geblokkeerd. Feature detection libraries horen ook thuis in de head, omdat ze moeten draaien voordat de body wordt geparseerd.
JavaScript in de footer
JavaScript net voor de afsluitende </body> tag plaatsen was jarenlang het standaard prestatieadvies. Het idee: laat de HTML eerst renderen, download scripts daarna.
Voordelen
- Niet-blokkerend als standaard: Footer scripts blokkeren de initiële rendering niet omdat de HTML erboven al is geparseerd.
- Lagere bandbreedte concurrentie: Tegen de tijd dat de browser de footer scripts bereikt, zijn je CSS, fonts en LCP afbeelding al begonnen met downloaden.
Nadelen
- Late ontdekking: De preload scanner vindt footer scripts later dan head scripts. Op een grote pagina betekent dit een latere start van het downloaden en een latere uitvoering.
- Verouderd patroon:
<script defer>in de<head>bereikt hetzelfde niet-blokkerende gedrag met een eerdere ontdekking. Footer plaatsing was de workaround voordatdeferuniversele browserondersteuning had. Dat tijdperk is voorbij.
Wanneer footer plaatsing nog steeds logisch is
Footer plaatsing kan logisch zijn voor scripts waarvan je echt niet wilt dat ze concurreren om bandbreedte tijdens het initiële laden van de pagina: analytics, A/B testing tools of social widgets. Maar zelfs voor deze is defer in de head meestal de betere keuze vanwege een eerdere ontdekking door de preload scanner.
Moderne script attributen
Naast async en defer zijn er nog twee attributen die de moeite waard zijn om te kennen:
type="module": Module scripts worden standaard uitgesteld (deferred). Je hoeft defer niet toe te voegen aan een module script omdat het zich al op die manier gedraagt. Het toevoegen van async aan een module script overschrijft het standaard defer gedrag en laat het uitvoeren zodra het klaar is met downloaden.
fetchpriority: Standaard krijgen async en defer scripts een lage netwerkprioriteit. Door fetchpriority="high" toe te voegen aan een async script krijg je een niet-blokkerende download met hoge prioriteit. Dit is de ideale combinatie voor scripts die kritiek zijn voor de gebruikerservaring, maar rendering niet mogen blokkeren. Voor het volledige plaatje, zie de gids voor bronprioritering en JavaScript prioriteitsniveaus.
Een praktische strategie voor script plaatsing
Niet alle scripts verdienen dezelfde behandeling. Ik hanteer een benadering op vier niveaus:
- Render-kritieke scripts: Scripts die de zichtbare lay-out van de pagina beïnvloeden (menu, slider, above-the-fold UI). Plaats ze in de
<head>zonderdeferals ze uitgevoerd moeten worden voor first paint. Houd deze zo klein mogelijk omdat ze rendering blokkeren en je Core Web Vitals schaden. - Belangrijke scripts: Scripts die kritiek zijn voor conversie of interactie (formulieren, navigatie, cookietoestemming). Plaats ze in de
<head>metdeferofasync. - Normale scripts: Scripts die de eerste pagina weergave niet beïnvloeden (carrousels, modale vensters, tabbladen). Plaats ze in de
<head>metdefer. - Nice-to-have scripts: Scripts zonder welke je zou kunnen als het absoluut moest (analytics, chat widgets, social sharing). Laad deze nadat de pagina klaar is met renderen, met behulp van het
loadevent ofrequestIdleCallback. Zie 16 methoden om JavaScript uit te stellen voor technieken. Als je veel ongebruikt JavaScript hebt in deze categorie, zie hoe je ongebruikt JavaScript kunt verminderen.
Met de DOMContentLoaded en load events kun je de timing van de uitvoering bepalen, ongeacht waar het script is geplaatst in de HTML. Dit is nuttig om ervoor te zorgen dat je code op het juiste moment draait.
Code voorbeelden
Voorbeeld 1: JavaScript in de head (render-blocking)
<!DOCTYPE html>
<html>
<head>
<title>JavaScript in de Head Voorbeeld</title>
<script>
function showMessage() {
alert("Hallo van JavaScript in de head!");
}
</script>
<!-- Dit script blokkeert rendering -->
<script src="script.js"></script>
</head>
<body>
<button onclick="showMessage()">Klik Mij</button>
</body>
</html>
In dit voorbeeld blokkeert script.js in de <head> de rendering. De browser zal de knop niet weergeven totdat het script is gedownload en uitgevoerd. Voeg defer toe aan de script tag om dit op te lossen.
Voorbeeld 2: JavaScript in de footer
<!DOCTYPE html>
<html>
<head>
<title>JavaScript in de Footer Voorbeeld</title>
</head>
<body>
<button onclick="showMessage()">Klik Mij</button>
<!-- Script aan het einde van de body -->
<script src="script.js"></script>
<script>
function showMessage() {
alert("Hallo van JavaScript in de footer!");
}
</script>
</body>
</html>
Hier laadt script.js na de HTML-inhoud, zodat het rendering niet blokkeert. Maar de preload scanner ontdekt het later dan het in de head zou doen. Het gebruik van <script defer src="script.js"></script> in de <head> geeft je hetzelfde niet-blokkerende gedrag met een eerdere download ontdekking.
Voorbeeld 3: Event listeners gebruiken
<!DOCTYPE html>
<html>
<head>
<title>Event Listener Voorbeeld</title>
<script>
window.addEventListener('load', function() {
console.log("Pagina is volledig geladen.");
});
</script>
</head>
<body>
<!-- Pagina content -->
</body>
</html>
De load event listener zorgt ervoor dat de code binnen de callback alleen draait nadat de pagina volledig is geladen, ongeacht waar het script is geplaatst. Dit is handig voor niet-kritieke initialisatie die moet wachten totdat alles klaar is.
Verifieer je wijzigingen
Nadat je scripts van de footer naar defer in de <head> hebt verplaatst, verifieer je de impact met Real User Monitoring. Je FCP en LCP zouden beide moeten verbeteren. Op sites die worden gemonitord door CoreDash, hebben origins die defer gebruiken voor de meerderheid van hun scripts een 18% snellere mediane FCP dan origins die nog steeds vertrouwen op footer plaatsing.
Ask AI why your INP spiked.
CoreDash is the only RUM tool with MCP support. Connect it to your AI agent and query your Core Web Vitals data in natural language. No more clicking through dashboards.
See How It Works
