Tree Shaking

Tree shaking is een optimalisatietechniek die tijdens het buildproces van je website automatisch ongebruikte JavaScript-code detecteert en verwijdert. De naam verwijst naar het schudden aan een boom waarbij dode takken afvallen. In de praktijk analyseert een bundler zoals Webpack, Rollup of Vite welke functies, variabelen en modules je daadwerkelijk gebruikt en laat alles wat je niet aanroept achterwege in het uiteindelijke bestand. Voor een gemiddelde MKB-website betekent dit dat je JavaScript-bestanden 30 tot 60 procent kleiner kunnen worden, wat directe invloed heeft op de laadsnelheid en Core Web Vitals-score.

Hoe tree shaking werkt in moderne bundlers

Tree shaking vertrouwt op ES6-module-syntax (import en export) omdat die statisch te analyseren is. Tijdens het bouwen van je site scant de bundler alle import-statements en markeert welke exports daadwerkelijk worden aangeroepen. Code die nergens wordt geïmporteerd of aangeroepen krijgt het label 'dead code' en wordt niet meegenomen in het productiebestand. Dit proces werkt alleen betrouwbaar als je libraries gebruikt die ES-modules aanbieden en als je geen dynamische imports of eval-constructies toepast die de statische analyse verstoren. Moderne frameworks zoals React, Vue en Svelte ondersteunen tree shaking van nature, maar oudere CommonJS-modules blijven vaak volledig in je bundle zitten.

Waarom tree shaking nu standaard is in webontwikkeling

Rond 2015 introduceerde Rollup tree shaking als kernfunctie, gevolgd door Webpack 2 in 2017. Het antwoord op een groeiend probleem: JavaScript-bundles werden steeds groter door het gebruik van uitgebreide libraries zoals Lodash of Moment.js, terwijl websites vaak maar een handvol functies nodig hadden. Google maakte in 2018 duidelijk dat laadsnelheid een rankingfactor is en introduceerde Core Web Vitals in 2020. Sindsdien is tree shaking geen nice-to-have meer maar een basisvereiste voor elke professionele website. Een ongeoptimaliseerde bundle van 800 kB kan door tree shaking krimpen naar 250 kB, wat het verschil maakt tussen een acceptabele en een trage mobiele ervaring.

Wat tree shaking oplevert voor Nederlandse MKB-websites

In de praktijk zien we bij Monkey Vision dat tree shaking vooral impact heeft op websites met veel interactieve componenten of uitgebreide dashboards. Een webshop die een datepicker, validatie-library en analytics-script laadt, stuurt zonder tree shaking gemakkelijk 600 kB JavaScript naar de bezoeker, terwijl slechts 40 procent daarvan echt wordt uitgevoerd. Door tree shaking in te schakelen in combinatie met code splitting bereik je een First Contentful Paint die 1 tot 2 seconden sneller is, wat meetbaar effect heeft op bouncerates en conversie. Voor wie serieus wil investeren in snelheid en gebruikservaring is professionele front-end development met geoptimaliseerde buildprocessen de logische vervolgstap. Ook een link naar API-integraties is relevant, omdat tree shaking helpt om alleen de benodigde SDK-onderdelen te laden. Meer achtergrond over optimalisatie vind je in de JavaScript-optimalisatiegids van Google Developers.

Tree shaking komt pas echt tot zijn recht wanneer je werkt met externe libraries of een modulair opgezette codebase. Hieronder zie je waar de techniek het meeste verschil maakt en wanneer je er bewust voor kiest om tree shaking in te schakelen of juist over te slaan.

Utility-libraries zoals Lodash en date-fns optimaliseren

Lodash is een populaire JavaScript-library met meer dan 300 hulpfuncties, maar de meeste projecten gebruiken er slechts 5 tot 10. Zonder tree shaking importeer je de volledige library van circa 70 kB geminificeerd. Door ES-module-imports te gebruiken (import { debounce, throttle } from 'lodash-es') en tree shaking in te schakelen, neem je alleen de functies mee die je daadwerkelijk aanroept. Hetzelfde geldt voor date-fns: in plaats van de hele library van 200+ functies laad je alleen format, addDays en parseISO. Voor een B2B-platform met 15 medewerkers dat een planning-interface bouwt, scheelt dit gemakkelijk 150 kB aan onnodige code. Let op: gebruik altijd de ES-module-variant van een library, herkenbaar aan de -es suffix of het module-veld in package.json.

Component-libraries en design systems slank houden

Design systems zoals Material-UI, Ant Design of Chakra UI bieden tientallen componenten, maar een gemiddelde pagina gebruikt er maar 3 tot 7. Zonder tree shaking laad je de volledige library, inclusief componenten die je nooit gebruikt. Door named imports te hanteren (import { Button, TextField } from '@mui/material') en tree shaking te activeren, blijven alleen de benodigde componenten over. Een webshop met 500 producten die een custom checkout bouwt, kan zo van 400 kB Material-UI terugvallen naar 80 kB. Belangrijk: sommige libraries vereisen extra configuratie, zoals het babel-plugin-import-package voor Ant Design. Controleer altijd de documentatie en test de bundle-size met tools zoals Webpack Bundle Analyzer. Voor wie een volledig custom design wil zonder ballast is maatwerk webdesign vaak efficiënter dan het aanpassen van een bestaand design system.

Icon-sets en SVG-collecties filteren

Icon-libraries zoals FontAwesome, Heroicons of Material Icons bevatten duizenden iconen, terwijl een typische website er 20 tot 40 nodig heeft. Zonder tree shaking importeer je het volledige icon-font of SVG-sprite van 300 tot 500 kB. Met tree shaking importeer je alleen de iconen die je gebruikt (import { FaUser, FaShoppingCart } from 'react-icons/fa'), waardoor je uitkomt op 5 tot 15 kB. Voor een MKB-dienstverlener met een simpele corporate site maakt dit het verschil tussen een acceptabele en een trage mobiele ervaring. Vergeet niet dat tree shaking alleen werkt als je named imports gebruikt; een wildcard-import (import * as Icons) neemt alles mee. Als je twijfelt of je tree shaking goed hebt ingesteld, gebruik dan de coverage-tab in Chrome DevTools om te zien hoeveel procent van je JavaScript daadwerkelijk wordt uitgevoerd.

Wanneer tree shaking de juiste keuze is en wanneer niet

Tree shaking is zinvol zodra je externe libraries gebruikt, een modulaire codebase hebt of een SPA bouwt met een framework. Het is minder relevant voor kleine statische sites met minder dan 50 kB JavaScript of voor server-rendered pagina's waar de meeste logica in PHP of Python draait. Let op: tree shaking werkt niet goed met CommonJS-modules, dynamische imports of code die side effects heeft (zoals polyfills die automatisch de global scope aanpassen). Als je library geen ES-modules aanbiedt, blijft de volledige bundle staan. In dat geval is het slimmer om een alternatieve library te kiezen of de functies handmatig te cherry-picken. Voor complexere projecten met API-integraties en realtime data is een professionele development-setup met tree shaking, code splitting en lazy loading de enige duurzame route.