'Reduce Unused JavaScript' oplossen in Lighthouse

Wat is de 'reduce unused JavaScript'-waarschuwing van Lighthouse?

Laatst beoordeeld door Arjen Karel in maart 2026

Lighthouse markeert elk JavaScript-bestand met meer dan 20 KiB aan ongebruikte code. Als je deze waarschuwing ziet, downloadt en voert je pagina JavaScript uit dat niet nodig is voor het huidige laden van de pagina.

Deze waarschuwing heeft directe invloed op je Lighthouse-prestatiescore. Maar belangrijker nog, ongebruikt JavaScript schaadt je echte gebruikers. Volgens de 2025 Web Almanac verstuurt de mediane mobiele pagina 646 KB aan JavaScript, waarvan 251 KB ongebruikt blijft op de pagina waar het geladen wordt. Op het 90e percentiel loopt dat op tot 931 KB aan verspild JavaScript.

Ondertussen steeg de mobiele Total Blocking Time met 58% jaar op jaar tot een mediaan van 1.916 ms volgens het 2025 Web Almanac Performance-hoofdstuk. JavaScript-payloads groeien sneller dan apparaten sneller worden. Op sites die door CoreDash worden gemonitord, scoren origins die hun ongebruikt JavaScript onder 100 KB houden 93% van de tijd "goed" op INP, vergeleken met 64% voor origins die 400 KB overschrijden.

Wat veroorzaakt ongebruikt JavaScript?

Ongebruikt JavaScript kan veel oorzaken hebben. De meest voorkomende zijn:

• Te veel plugins in je CMS.
• Dode code die niet meer wordt gebruikt door de huidige website.
• Slecht geschreven scripts met onnodige controles en vertakkingen.
• Onbeperkte toegang tot de tag manager, waarbij marketingteams tags toevoegen en vergeten ze te verwijderen.
• Onnodige imports: een hele bibliotheek importeren terwijl je maar één functie gebruikt.
• Code die op elke pagina draait maar alleen op specifieke routes nodig is.
• Scripts die direct geladen worden terwijl ze ook vlak voor gebruik geladen hadden kunnen worden.

Hoe beïnvloedt ongebruikt JavaScript de Core Web Vitals?

Ongebruikt JavaScript raakt je prestaties op twee manieren:

• Netwerkcongestie. Elk JavaScript-bestand moet worden gedownload. Deze verzoeken concurreren om bandbreedte met je LCP-afbeelding, je lettertypen en je CSS. Op een mobiele verbinding kan deze vertraging je Largest Contentful Paint ruim voorbij de drempel van 2,5 seconden duwen.
• Main thread blokkering. De browser moet al dat JavaScript parsen, compileren en uitvoeren. Terwijl hij dat doet, kan hij niet reageren op gebruikersinvoer of doorgaan met het renderen van de pagina. Dit heeft direct invloed op zowel LCP als INP.

Houd er rekening mee dat een Lighthouse-score geen Core Web Vitals-score is. De Core Web Vitals worden gemeten met velddata van echte gebruikers (CrUX). Lighthouse is een diagnostisch hulpmiddel dat je helpt problemen te vinden, maar je werkelijke prestaties zijn wat je bezoekers daadwerkelijk ervaren. Je kunt je veldprestaties verifiëren met Real User Monitoring.

Hoe vind je ongebruikt JavaScript

Er zijn drie manieren om ongebruikt JavaScript op je pagina te identificeren:

1. Lees de Lighthouse-audit

Lighthouse toont elk JavaScript-bestand met meer dan 20 KiB aan ongebruikte code. Het laat de totale bytes, de ongebruikte bytes en de mogelijke besparingen zien. Dit is je startpunt. Merk op dat Lighthouse 13 (oktober 2025) is overgestapt naar een op inzichten gebaseerd auditformaat, maar de controle op ongebruikt JavaScript is er nog steeds.

2. Gebruik de Chrome Coverage-tool

De Coverage-tool geeft je een regel-voor-regel overzicht van gebruikte versus ongebruikte code voor elk JavaScript- en CSS-bestand op de pagina.

Open Chrome DevTools met Ctrl+Shift+I (of Cmd+Option+I op Mac). Gebruik vervolgens Ctrl+Shift+P om het commandomenu te openen en typ coverage. Selecteer Show Coverage en klik op de herlaadknop om de instrumentatie te starten. Nadat de pagina is geladen, zie je elk bestand met het percentage ongebruikte bytes.

Schakel over naar de "Per block"-dekkingsmodus (dropdown bovenaan het paneel) voor meer gedetailleerde resultaten. Blokniveau-dekking detecteert ongebruikte vertakkingen binnen functies, niet alleen of een functie is aangeroepen.

Klik op een rij om het bestand te openen in het Sources-paneel. Blauwe regels zijn gebruikte code. Rode regels zijn ongebruikt. Dit vertelt je precies welke functies en vertakkingen nooit zijn uitgevoerd tijdens het laden van de pagina.

3. Analyseer je bundels

Als je een bundler gebruikt zoals webpack, Rollup of Vite, gebruik dan een bundle analyzer om te visualiseren wat er in je JavaScript-bestanden zit. Tools zoals webpack-bundle-analyzer en source-map-explorer tonen een treemap van elke module in je bundel, waardoor het duidelijk wordt wanneer een grote bibliotheek wordt binnengehaald voor een kleine functie.

Ongebruikt betekent niet altijd onnodig

Houd er rekening mee dat "ongebruikt" op één pagina niet "onnodig" betekent. Een script dat je afrekenformulier aanstuurt, wordt als 100% ongebruikt weergegeven op je homepage. Dat betekent niet dat je het moet verwijderen. Het betekent dat je het niet op de homepage moet laden.

Dit is wat code splitting oplost: elke route laadt alleen het JavaScript dat het daadwerkelijk nodig heeft. Als je grote hoeveelheden "ongebruikt" JavaScript ziet en je site is een single page application, dan is de oplossing bijna altijd betere code splitting op routeniveau, niet het verwijderen van code.

Hoe los je 'reduce unused JavaScript' op

Om de 'reduce unused JavaScript'-waarschuwing op te lossen, moet je eerst achterhalen waar de verspilling vandaan komt. Lighthouse vertelt je welke scripts een grote hoeveelheid ongebruikte bytes hebben. Hier zijn 7 manieren om het te verminderen:

1. Verwijder onnodige plugins. Als je een CMS zoals WordPress gebruikt, is de makkelijkste winst het verwijderen van plugins die je niet nodig hebt of het vervangen van triviale plugins door een paar regels code. Je analytics-plugin, social share-knoppen en chatwidget zijn veelvoorkomende boosdoeners.
2. Verwijder dode code. Dode code is code die de huidige website niet meer gebruikt. Plan minstens twee keer per jaar een dode code-audit. Tools zoals Knip kunnen de detectie van ongebruikte exports en dependencies in JavaScript-projecten automatiseren.
3. Tree-shake je bundels. Tree shaking verwijdert ongebruikte exports tijdens het bouwen. Hiervoor heb je ES module-syntax nodig (import/export), geen CommonJS (require). Voeg "sideEffects": false toe aan je package.json zodat je bundler agressief ongebruikte code kan verwijderen. Importeer alleen wat je nodig hebt:

   // Fout: importeert de hele bibliotheek (70+ KB)
   import _ from 'lodash';
   const result = _.debounce(fn, 300);
   
   // Goed: importeert alleen debounce (~1 KB met tree shaking)
   import { debounce } from 'lodash-es';
   const result = debounce(fn, 300);

4. Code-split je routes. Laad alleen het JavaScript dat elke pagina daadwerkelijk nodig heeft. Gebruik dynamische import() om je bundels te splitsen per route of per functionaliteit:

   // In plaats van alles vooraf te importeren:
   import { validateForm } from './formValidation.js';
   
   // Laad het alleen wanneer de gebruiker interactie heeft met het formulier:
   document.querySelector('form').addEventListener('focus', async () => {
     const { validateForm } = await import('./formValidation.js');
     validateForm();
   }, { once: true });

   In React gebruik je React.lazy() met <Suspense> voor splitting op componentniveau. In Next.js App Router versturen React Server Components standaard geen JavaScript naar de client. In Vue gebruik je defineAsyncComponent() of dynamische imports in Vue Router.

5. Ruim je tag manager op en beperk de toegang. De tag manager is een veelvoorkomende bron van ongebruikte code, vooral wanneer marketingteams tags toevoegen zonder oude te verwijderen. Audit je tag manager-container regelmatig. Elke tag die bij het laden van de pagina wordt geactiveerd, voegt JavaScript toe dat concurreert om bronnen.
6. Verwijder onnodige imports. Controleer in React-, Vue- en Next.js-projecten je importstatements. Importeer je een hele componentbibliotheek terwijl je maar twee componenten gebruikt? Haal je moment.js (330 KB) binnen terwijl de native Intl-API of een alternatief van 2 KB zoals dayjs volstaat?
7. Stel het laden van niet-kritische scripts uit. Soms heb je een script nodig (om bijvoorbeeld een formulier te verzenden) maar heb je het niet nodig tijdens het laden van de pagina. Laad het wanneer de gebruiker het daadwerkelijk nodig heeft. Een script dat bij interactie laadt in plaats van bij het laden van de pagina is niet langer "ongebruikt JavaScript" in de Lighthouse-audit. Zie ook async vs defer voor het begrijpen van het verschil tussen de twee laadstrategieën.

Wanneer je het niet volledig kunt oplossen

Soms kun je niet al het ongebruikte JavaScript verwijderen. Third-party scripts, A/B-testtools en advertentienetwerken leveren vaak grote bundels waar je geen controle over hebt. Minimaliseer in dat geval hun impact:

• Self-host third-party scripts op je eigen domein waar mogelijk. Dit vermijdt de kosten van een nieuwe DNS-lookup en TCP-verbinding voor elk extern domein.
• Prioriteer kritieke bronnen. Preload je LCP-afbeelding en kritieke lettertypen zodat ze niet vastzitten achter JavaScript-downloads in de netwerkwachtrij.
• Stel zoveel mogelijk JavaScript uit. Verplaats niet-kritische scripts uit het kritieke renderpad met defer, async of uitgesteld laden.
• Gebruik fetchpriority="low" voor niet-essentiële scriptbronnen om de browser te vertellen dat ze kunnen wachten.
• Monitor je velddata. Gebruik Real User Monitoring om te verifiëren dat je wijzigingen de ervaring voor echte gebruikers daadwerkelijk hebben verbeterd, niet alleen de Lighthouse-score.