5 JavaScript prioriteitsniveaus en hoe je ze gebruikt

Niet alle scripts zijn gelijk

Eén ding is altijd duidelijk geweest: niet alle JavaScript is gelijk. Sommige scripts handelen kritieke interacties af zoals 'menu-interactie' of 'toevoegen aan winkelwagen', terwijl andere scripts veel minder belangrijk zijn. Neem bijvoorbeeld je 'exit intent' pop-upscript dat bezoekers die je site dreigen te verlaten uitnodigt om een vragenlijst in te vullen. Ik weet zeker dat we allemaal zonder die laatste zouden kunnen leven, maar het zou erg lastig zijn om door een website te navigeren zonder de eerste.

Toch wordt dit onderscheid op 'je gemiddelde website' op technisch niveau nauwelijks gemaakt. Alle JavaScripts worden 'gewoon toegevoegd' aan de pagina en de browser mag het zelf uitzoeken. Dat is een probleem, want je browser heeft geen idee wat belangrijk is en wat niet. Wij, als ontwikkelaars, weten dat wel. Laten we dat dus oplossen!

Laatst beoordeeld door Arjen Karel in maart 2026

De mediane mobiele pagina laadt 646 KB aan JavaScript verspreid over 22 verzoeken, volgens de 2025 Web Almanac. Ongeveer 44% van dat JavaScript wordt zelfs nooit uitgevoerd. Slechts 13% van de pagina's slaagt voor de audit van Lighthouse voor render-blocking bronnen. Het probleem is niet alleen hoeveel JavaScript je laadt. Het gaat erom wanneer en in welke volgorde.

Hoe JavaScript-prioriteit de Core Web Vitals kan beïnvloeden

Zomaar scripts aan de pagina toevoegen zonder de juiste overweging kan alle 3 de Core Web Vitals beïnvloeden. De Largest Contentful Paint, de Interaction to Next Paint en de Cumulative Layout Shift.

Voorbeeld: de LCP-netwerkbron wordt vertraagd door render blocking JavaScripts

De Largest Contentful Paint is gevoelig voor concurrentie om bandbreedte en CPU. Wanneer te veel scripts strijden om vroege netwerkbronnen, zal dit de Largest Contentful Paint netwerkbron vertragen en vroeg CPU-werk zal de LCP vertragen door de main thread te blokkeren.

De Interaction to Next Paint kan worden beïnvloed door scripts die vlak voor een interactie worden uitgevoerd. Wanneer scripts worden uitgevoerd, blokkeren ze de main thread en vertragen ze elke interactie gedurende die uitvoeringstijd.

Scripts kunnen ook een Cumulative Layout Shift veroorzaken als scripts 'veranderen hoe de pagina eruitziet'. Advertentiescripts die banners in de pagina injecteren en sliders zijn hier berucht om.

5 soorten JavaScript-prioriteiten

Ik maak graag onderscheid tussen 5 soorten JavaScript-prioriteiten.

• Render-kritisch: deze scripts behoren tot de slechtste om te hebben. Ze veranderen de lay-out van de pagina en zonder het laden van deze scripts zal de lay-out compleet anders zijn. Voorbeeld: sommige slider-scripts of een A/B-test.
• Kritieke scripts: Deze scripts handelen kritieke paginafunctionaliteit af en zonder deze scripts zijn kritieke taken zoals het toevoegen van een product aan een winkelwagen, zoeken op de site of navigatie niet mogelijk.
• Belangrijke scripts: Deze scripts handelen belangrijke bedrijfslogica af en je site is hiervan afhankelijk. Bijvoorbeeld: Analytics.
• Nice-to-have scripts: Deze scripts zijn leuk om te hebben, maar als het erop aankomt hebben we ze niet echt nodig om de pagina te laten functioneren. Bijvoorbeeld een chatwidget of een exit intent.
• Toekomstige scripts: Deze scripts kunnen kritiek of nice-to-have zijn, maar we hebben ze op dit moment niet nodig omdat er 'andere stappen' moeten worden genomen voordat we deze scripts daadwerkelijk kunnen gebruiken. Bijvoorbeeld een multi-stage checkout-script.

Voordat we elk prioriteitsniveau bekijken, is hier hoe Chrome netwerkprioriteit toewijst aan verschillende scripttypes:

Het begrijpen van deze standaarden is de sleutel tot resourceprioritering.

1. Render-kritische scripts

Deze scripts veranderen direct de lay-out van de pagina. Zonder deze scripts ziet de pagina er compleet anders uit dan het beoogde ontwerp. Voorbeelden zijn scripts voor sliders of A/B-testframeworks die de lay-out vroeg in het laadproces wijzigen.

Het probleem met deze scripts is dat ze niet kunnen worden uitgesteld of vertraagd. Elke vertraging zal ervoor zorgen dat de website-layout verschuift, wat een slechte UX veroorzaakt en waardoor de Core Web Vitals falen.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Page Title</title>
    <link href="styles.css" rel="stylesheet" />
    <script src="render-critical.js"></script>
  </head>
  <body></body>
</html>

Best Practices:

• Vermijd render-kritische scripts waar mogelijk. Herschrijf je code om de afhankelijkheid van dit soort scripts te verwijderen.
• Als het niet te vermijden is, inline of laad dan alleen de absoluut noodzakelijke delen van deze scripts.
• Gebruik geen defer of async op deze scripts en plaats ze bovenaan de head om een zo vroeg mogelijke download te triggeren.

2. Kritieke scripts

Deze scripts maken fundamentele interacties mogelijk. Zonder deze scripts worden kritieke taken zoals sitenavigatie, items toevoegen aan een winkelwagen, cookiemeldingen of het uitvoeren van een zoekopdracht onmogelijk. Ze zijn onmisbaar voor de kernfunctionaliteit van de site.

Deze scripts moeten in de head van de pagina worden geplaatst met het async- of defer-attribuut. Zie voor een volledige vergelijking van deze twee benaderingen async vs defer en hoe ze de Core Web Vitals beïnvloeden.

<script defer src="critical.js"></script>
<script async src="critical.js"></script>

Best Practices:

• Beperk dit soort scripts tot een minimum en combineer deze functionaliteit niet met andere, minder kritieke functionaliteit.
• Laad deze scripts vroeg met behulp van async of defer, afhankelijk van hun afhankelijkheden.
• Gebruik Real User Monitoring om knelpunten in de uitvoering te identificeren en zorg ervoor dat de prestaties aansluiten bij de behoeften van de gebruiker.

3. Belangrijke scripts

Deze scripts ondersteunen je bedrijf, maar zijn niet nodig om de pagina te laten werken. Analytics-scripts bieden bijvoorbeeld essentiële gegevens, maar hoeven niet te worden geladen vóór belangrijkere visuele elementen. Het onderscheid tussen kritieke en belangrijke scripts kan een punt van discussie zijn, dus zorg ervoor dat je met alle belanghebbenden praat voordat je deze prioriteit instelt!

Er zijn 2 betrouwbare manieren om de scriptprioriteit voor dit soort scripts te verlagen.

<html>
<head>
<!-- method 1: inject after DOMContentLoaded -->
<script>
  document.addEventListener('DOMContentLoaded', function() {
    var script = document.createElement('script');
    script.src = 'important.js';
    document.body.appendChild(script);
  });
</script>
</head>
<body>

<!-- method 2: place at the bottom of the page -->
<script defer src="important.js"></script>
</body>
</html>

1: Injecteren na DOMContentLoaded

Door het script te injecteren na het DOMContentLoaded-event, zorg je ervoor dat het script direct begint met downloaden nadat de HTML volledig is geparseerd. Hierdoor krijgen ontdekbare resources, zoals afbeeldingen en lettertypen, voorrang. Deze methode biedt een balans: het script begint vroeg genoeg met laden om vertragingen in functionaliteit te voorkomen, maar concurreert niet met vroege resources die cruciaal zijn voor de initiële paginarenderering.

2: Plaatsen onderaan de pagina

Deze klassieke techniek stelt het laden van het script uit totdat de browser het volledige document heeft verwerkt en bereikt ongeveer hetzelfde resultaat als techniek 1. Het enige verschil is dat techniek 1 de preload-scanner van je browser overslaat, terwijl deze techniek dat niet doet. De preload-scanner is een lichtgewicht snelle scanner die je browser gebruikt om snel kritieke bronnen te identificeren en in de wachtrij te plaatsen. Het overslaan van de preload-scanner kan een goed idee zijn als de kans bestaat op lazy loaded afbeeldingen in de viewport, terwijl het gebruik van de preload-scanner het laden van dit script zal versnellen.

Een opmerking over fetchpriority: je zou misschien verwachten dat fetchpriority="low" op een deferred script de prioriteit zou verlagen. Dat is niet zo. Deferred en async scripts laden al met een lage (Low) prioriteit in Chrome. Het toevoegen van fetchpriority="low" daaraan doet niets. Het fetchpriority-attribuut maakt alleen een verschil bij blokkerende scripts, waarbij het de prioriteit kan verlagen van Highest naar High. Zie onze complete gids voor meer manieren om JavaScript uit te stellen (defer).

4. Nice-to-have scripts

Deze scripts verbeteren de UX, maar zijn niet vereist om de site te laten functioneren. Voorbeelden zijn chatwidgets, pop-ups voor klantfeedback of optionele animaties.

Deze scripts zijn een ideale kandidaat voor een patroon genaamd 'lazy on load'. Dit betekent: wacht op het load-event van de pagina en injecteer het script vervolgens tijdens idle time. Wachten op het load-event zorgt ervoor dat het script niet concurreert om bandbreedte en CPU met belangrijkere vroege bronnen. Wachten op een idle moment zorgt ervoor dat de browser niet bezig is met belangrijkere taken zoals gebruikersinvoer.

Hier is een werkend voorbeeld:

window.addEventListener("load", () => {
  const idle = window.requestIdleCallback || ((cb) => setTimeout(cb, 1));
  idle(() => {
    const script = document.createElement("script");
    script.src = "/path/to/script.js";
    document.head.appendChild(script);
  });
});

De setTimeout fallback is nodig omdat Safari requestIdleCallback niet ondersteunt. Voor scripts die hun uitvoering ook moeten opbreken in kleinere stukken (chunks), kun je overwegen om scheduler.yield() te gebruiken om de main thread responsief te houden en je INP-score te beschermen.

Best Practices:

• Lazy-load deze scripts nadat de pagina is geladen en wacht op een idle moment.
• Begrijp dat scripts die met dit patroon worden geladen, niet gegarandeerd snel laden.

Op sites die worden gemonitord door CoreDash, scoren pagina's die niet-kritieke scripts uitstellen tot na het load-event 84% 'goed' op INP, vergeleken met 61% voor pagina's die alle scripts direct (eagerly) laden.

5. Toekomstige scripts

Toekomstige scripts zijn scripts die pas nodig zijn als aan specifieke voorwaarden is voldaan. Een multi-stage checkout-script wordt bijvoorbeeld pas relevant nadat een gebruiker artikelen aan zijn winkelwagen heeft toegevoegd. Deze scripts kunnen wachten tot veel later in de klantreis.

Kijk eens naar dit voorbeeld. Het gebruikt de IntersectionObserver om de JS-logica alleen te laden wanneer dat nodig is: wanneer het formulier in de zichtbare viewport staat.

<!DOCTYPE html>
<html>
  <head>
    <script>
      document.addEventListener("DOMContentLoaded", function () {
        const form = document.querySelector("form");
        const observer = new IntersectionObserver(function (entries) {
          entries.forEach((entry) => {
            if (entry.isIntersecting) {
              const script = document.createElement("script");
              script.src = "/sign-up.js";
              document.head.appendChild(script);
              observer.unobserve(form);
            }
          });
        });
        observer.observe(form);
      });
    </script>
  </head>
  <body>
    <form action="/sign-up" method="post">
      <label for="email">Email:</label>
      <input type="email" id="email" name="email" required />
      <button type="submit">Sign Up</button>
    </form>
  </body>
</html>

Best Practices:

• Laad deze scripts on-demand, getriggerd door gebruikersacties.
• Gebruik code-splitting technieken om alleen de onderdelen te leveren die bij elke stap nodig zijn.
• Injecteer ze alleen dynamisch wanneer dat nodig is, bijvoorbeeld wanneer een gebruiker naar een specifieke sectie scrolt.

De meeste sites hebben maar twee patronen nodig: defer voor alles wat functioneel is en het load+idle-patroon voor al het andere. Als je tijd besteedt aan het finetunen van fetchpriority op scripts, maak je het waarschijnlijk onnodig ingewikkeld. Zorg eerst voor de grote winsten: stel uit (defer) wat je kunt, vertraag wat je kunt en verwijder wat je niet nodig hebt.