Gids voor code-minificatie: CSS, JS en HTML uitgelegd

Code-minificatie verwijdert tekens die een machine niet nodig heeft (witruimte, commentaar, regelafbrekingen) uit je CSS-, JavaScript- en HTML-broncode, en herschrijft uitvoerige patronen naar kortere equivalenten. Het gedrag blijft hetzelfde; het bestand wordt alleen kleiner en laadt sneller.

Eén ding moet meteen helder zijn: minificatie is iets anders dan compressie. Minify werkt op je broncode en strip je syntactische redundantie. Gzip en Brotli werken op de bytes onderweg en coderen herhaalde patronen. Het gebeurt in verschillende fases, pakt verschillende soorten redundantie aan en stapelt op elkaar. Daarom moet je nog steeds minificeren, zelfs als je server al Brotli serveert. Deze gids legt precies uit waarom.

Wil je nu meteen iets comprimeren? Spring direct naar de CSS-minifier, de JavaScript-minifier of de HTML-minifier; elke tool draait volledig in je browser. Maar pas als je de werking begrijpt, kun je beslissen waar je comprimeert en of je het überhaupt met de hand hoeft te doen. Daarna komt aan bod wat minificatie eigenlijk doet, hoe CSS, JS en HTML elk geminificeerd worden, hoe minify stapelt met gzip en Brotli, wanneer je buildtool het al regelt, en hoe source maps geminificeerde code debugbaar houden.

Wat is minificatie (en wat is het niet)

Minificatie doet twee dingen. Het verwijdert tekens die geen betekenis hebben voor de parser, en het herschrijft je broncode naar een kortere vorm die precies hetzelfde betekent. De uitvoer is voor een machine volledig equivalent en voor een mens vrijwel onleesbaar. Aan hoe de code draait verandert niets, alleen de oppervlakte.

Dat laatste punt is de invariant om vast te houden voor de rest van deze gids: minify bewerkt alleen de oppervlakte van je broncode (witruimte, commentaar, namen van identifiers, overbodige syntaxis), nooit het gedrag of de uitvoer. Het is het spiegelbeeld van formatteren. Formatteren voegt witruimte toe om code leesbaar te maken; minificeren strip die juist om code klein te maken. Beide zitten op dezelfde as van “semantisch equivalent”, alleen wijzen ze de tegenovergestelde kant op.

Mensen verwarren voortdurend drie operaties die op elkaar lijken. Deze tabel zet ze op een rij:

Dimensie	Formatteren (beautify)	Minify	Comprimeren (gzip/Brotli)
Wat het verandert	Voegt witruimte, regelafbrekingen, inspringing toe	Verwijdert witruimte en commentaar, verkort syntaxis	Codering op byteniveau van herhaalde patronen
Welke laag	Broncode	Broncode	Transport / opslag
Nog steeds broncode?	Ja (leesbaar)	Ja (uitvoerbaar, moeilijk te lezen)	Nee (binair, moet gedecodeerd worden)
Wie doet het	Ontwikkelaar / editor	Buildtool / minifier	Server + browser
Omkeerbaar?	Semantisch	Semantisch (gedrag ongewijzigd)	Volledig (decomprimeren herstelt de bytes)

Formatteren en minify leven op één as, de as van semantische equivalentie. Compressie leeft op een compleet andere. Een geformatteerd bestand en een geminificeerd bestand zijn allebei geldige broncode; een gecomprimeerd bestand is een binaire blob die eerst gedecodeerd moet worden voordat er iets kan draaien.

Eén misverstand kost veel: “mijn server doet al gzip, dus minificeren heeft geen zin.” Dat klopt niet, en de cijfers verderop in deze gids laten zien waarom. Minificatie en compressie verwijderen verschillende redundantie, dus het een doen maakt het ander niet overbodig. Houd dat in je achterhoofd bij elke taal die langskomt.

Het helpt om na te denken over waarom de bytes die een minifier verwijdert er überhaupt zijn. Je schrijft witruimte, commentaar en beschrijvende namen voor jezelf en je teamgenoten; ze maken code reviewbaar en onderhoudbaar. De machine die je CSS parset, je JavaScript uitvoert of je DOM opbouwt, negeert ze stuk voor stuk. Minificatie is de stap die het puur menselijke materiaal weggooit zodra de mensen klaar zijn met de broncode. Daarom hoort minificatie ook bij productie en nooit bij ontwikkeling: je houdt de leesbare versie in je repository en levert de gestripte versie aan browsers. De leesbare kopie is de bron van waarheid; de geminificeerde kopie is een buildartefact dat je op elk moment opnieuw kunt genereren.

Hoe CSS-minificatie werkt

CSS is van de drie de zachtaardigste om te minificeren, omdat de grammatica weinig ruimte voor dubbelzinnigheid laat. Een minifier strip commentaar, vouwt reeksen witruimte tot niets samen, laat de laatste puntkomma in elk blok vallen en verwijdert spaties rond {, }, : en ;. Dat ruimt op zich al de meeste bytes op.

CSS staat ook een reeks equivalentieherschrijvingen toe die geen enkele andere taal kent. Een goede minifier past ze veilig toe:

• Kleuren verkorten. #ffffff wordt #fff, en #ff0000 valt samen tot red (of andersom, wat korter te schrijven is).
• Eenheden bij nul weglaten. 0px wordt 0, en margin: 0 0 0 0 wordt margin: 0.
• Voorloopnullen strippen. 0.5em wordt .5em.
• Shorthands samenvoegen. Vier aparte declaraties margin-top, margin-right, margin-bottom en margin-left vouwen samen tot één margin.
• Regels combineren. Aangrenzende regels met identieke selectors of declaraties kunnen samengevoegd worden, en dubbele declaraties vallen weg.

Elk van deze houdt het gerenderde resultaat identiek, en dat is de grens die een correcte minifier nooit overschrijdt. Maar CSS is volgordegevoelig: een latere regel overschrijft een eerdere via de cascade. Een veilige minifier zal regels die zouden kunnen veranderen welke declaratie wint daarom niet blindelings herordenen. Bytes verkleinen mag; de cascade veranderen niet.

Die beperking is subtieler dan ze klinkt. Twee declaraties die er samenvoegbaar uitzien, zijn dat misschien niet, omdat iets ertussenin naar dezelfde property met dezelfde specificiteit verwijst. Bekijk dit:

.btn { color: #ff0000; }
.alert .btn { color: blue; }
.btn { color: #f00; }

De eerste en derde regel delen een selector en zouden kunnen samenvoegen, maar alleen als dat de declaratie niet voorbij de middelste regel verplaatst op een manier die verandert welke wint voor een element dat aan beide voldoet. Een naïeve samenvoeging die deze herordent kan de cascade breken. Dit is precies het soort randgeval waar een productiewaardige engine als CSSO over moet kunnen redeneren, en daarom moet je niet zelf een “verwijder de witruimte”-minifier met een regex in elkaar knutselen. De transformaties zien er mechanisch uit, maar de veiligheidsanalyse erachter is dat niet.

Onze CSS-minifier gebruikt de CSSO-engine voor precies dit soort lossless minificatie, en draait volledig in je browser met een uitlezing van de bytebesparing, zodat je de impact op de payload van elke pass kunt zien. Diezelfde tool formatteert ook de andere kant op, zodat je een geminificeerde stylesheet die je van een live site hebt gekopieerd weer kunt uitvouwen tot leesbare, ingesprongen regels. Grijp ernaar als je een stukje CSS hebt gekopieerd en de gecomprimeerde grootte wilt checken, of als je een statische pagina levert zonder buildstap die het voor je doet.

Hoe JavaScript-minificatie werkt

JavaScript-minificatie gaat veel verder dan CSS, en daar zitten zowel de besparingen als de valkuilen. Om te zien waarom, bekijk je een kleine functie voor en na Terser:

// voor
function calculateTotal(items, taxRate) {
  let runningTotal = 0;
  for (const item of items) {
    runningTotal += item.price * item.quantity;
  }
  return runningTotal * (1 + taxRate);
}

// na
function calculateTotal(t,a){let n=0;for(const o of t)n+=o.price*o.quantity;return n*(1+a)}

De functienaam calculateTotal overleeft omdat hij geëxporteerd is (of van elders aangeroepen zou kunnen worden); de parameters en de lusvariabelen vallen samen tot losse letters. Dat is de kern, maar een JS-minifier doet meerdere afzonderlijke dingen:

• Identifiers manglen. Lokale variabelen en parameters worden hernoemd naar losse letters: getUserPreferences wordt a. Alleen lokale namen worden gemangled; globale en geëxporteerde namen blijven standaard intact, omdat het hernoemen ervan code zou breken die ze van buitenaf aanroept.
• Dead-code elimination. Onbereikbare branches en ongebruikte variabelen worden verwijderd, hand in hand met tree-shaking op bundlerniveau.
• Constant folding en syntaxiscompressie. Expressies worden ingekort: true wordt !0, false wordt !1, en return undefined; wordt return;.

De grootste valkuil bij JS-minificatie is automatic semicolon insertion (ASI). JavaScript laat je puntkomma’s weglaten, en de parser voegt ze volgens specifieke regels voor je in. Wanneer een minifier de regelafbrekingen verwijdert waar die regels van afhangen, kan code van betekenis veranderen. De klassieke fout is een statement dat begint met ( of [ en stilletjes aan de vorige regel geplakt wordt:

const x = getValue()
[1, 2, 3].forEach(handle)

Zonder puntkomma’s parset dit als getValue()[1, 2, 3], een indexeerexpressie, geen twee statements. Eenmaal geminificeerd op één regel zit de bug vast. Hetzelfde gevaar duikt op bij een regel die met ( begint, waar de vorige expressie als een functie wordt aangeroepen. Moderne Terser handelt de meeste praktijkgevallen netjes af, omdat het de code eerst tot een abstract syntax tree parset en de puntkomma’s daar opnieuw uitzet waar ze nodig zijn; het verwijdert geen tekst op de tast. Maar slechte broncode plus agressieve minificatie is een echte bron van productiebugs, en de fouten zijn juist zo vervelend omdat ze alleen in de geminificeerde build verschijnen, niet tijdens ontwikkeling. De oplossing ligt bij jou: schrijf code met expliciete puntkomma’s en ondubbelzinnige syntaxis, en de minifier blijft veilig. Een linterregel of een auto-formatter die op bronniveau puntkomma’s invoegt, haalt het risico volledig weg.

Een correcte minifier behoudt het gedrag, maar alleen als de invoer geldige, standaard JavaScript is. Terser parset ECMAScript; het begrijpt geen TypeScript of JSX. Die moeten eerst naar gewoon JS getranspileerd worden, anders mislukt minificatie bij de parse-stap. Als je een .ts-bestand in een JS-minifier plakt en een fout krijgt, is dat de reden.

Eén naamkwestie komt vaak voorbij: minify versus uglify. Ze betekenen praktisch hetzelfde. “Uglify” komt van UglifyJS, de vroege populaire JS-minifier; Terser is de moderne fork ervan die ES2015 en later ondersteunt. Tegenwoordig is “minify” de algemene term over alle drie de talen, en “uglify” leeft voort als een oudere, JS-specifieke naam voor hetzelfde proces.

Onze JavaScript-minifier draait Terser in de browser (lokale namen hernoemen, dode code weggooien en commentaar strippen) en rapporteert hoeveel bytes het bij elke pass heeft bespaard.

Hoe HTML-minificatie werkt

HTML-minificatie begint met de basis: commentaar verwijderen (waarbij de <!DOCTYPE>-declaratie en eventuele conditionele commentaren waar je nog op leunt behouden blijven), witruimte tussen tags samenvouwen, en overbodige spaties binnen attribuutlijsten wegsnoeien. Een klein fragment laat de vorm ervan zien:

<!-- nav -->
<ul>
  <li><a href="/">Home</a></li>
  <li><a href="/about">About</a></li>
</ul>

wordt:

<ul><li><a href=/>Home</a><li><a href=/about>About</a></ul>

Het commentaar is weg, de inspringing tussen tags is samengevouwen, de optionele sluittags </li> zijn weggelaten, en de attribuutwaarden zonder aanhalingstekens raken hun quotes kwijt. Vanaf daar kan een minifier nog een paar HTML-specifieke trucs toepassen:

• Optionele sluittags verwijderen. De HTML-specificatie staat toe om </li>, </p>, </td> en diverse andere weg te laten, dus een minifier kan ze laten vallen.
• Aanhalingstekens van attributen verwijderen. Wanneer een waarde geen spaties of speciale tekens bevat, wordt class="x" class=x.
• Booleaanse attributen samenvouwen. disabled="disabled" wordt enkel disabled, en checked="checked" wordt checked.
• Ingebedde CSS en JS minificeren. De inhoud van <style>- en <script>-blokken wordt ook geminificeerd, zodat één pass het hele document verkleint.

De grens die het meest telt: in HTML is witruimte soms betekenisvol. Binnen <pre> en <textarea> wordt elke spatie en elke nieuwe regel letterlijk gerenderd. Elementen met white-space: pre gedragen zich net zo. En de witruimte tussen inline-elementen beïnvloedt de layout: een spatie tussen twee <a>-tags verschijnt als een gat op de pagina. Agressieve minificatie die deze witruimte platslaat, kan veranderen hoe de pagina eruitziet. De vuistregel: verifieer na het minificeren de rendering rond pre, textarea en de grenzen van inline-elementen voordat je het levert.

Onze HTML-minifier formatteert met js-beautify en minificeert met CSSO en Terser voor de ingebedde stijlen en scripts, allemaal client-side. Hij is vooral handig voor e-mail-HTML en CMS-geëxporteerde markup, waar er zelden een buildstap is die de compressie voor je doet.

Minify versus gzip versus Brotli: hoe ze stapelen

De centrale vraag: als je server al gzip of Brotli serveert, moet je dan nog minificeren? Ja, en de reden is dat de twee technieken verschillende redundantie verwijderen.

Minificatie verwijdert syntactische redundantie op bronniveau: de witruimte, het commentaar, de lange namen en de uitvoerige constructies die bestaan voor menselijke leesbaarheid. Gzip en Brotli verwijderen statistische redundantie op byteniveau: strings en patronen die door het bestand heen herhaald worden, worden vervangen door kortere codes. De een begrijpt de syntaxis van je code; de ander ziet alleen een stroom bytes. Omdat ze verschillende dingen aanpakken, werkt het stapelen ervan, en werkt het goed.

Een concreet voorbeeld: gzip is uitstekend in opmerken dat de string function tweehonderd keer in een bundle voorkomt en elke voorkomst vervangen door een korte terugverwijzing. Het heeft geen idee dat getUserPreferences en getUserSettings variabelenamen zijn die het zou kunnen inkorten, of dat een heel if (false) { ... }-blok nooit zal draaien. Minificatie pakt precies dat aan: de structurele en semantische winst waar een compressor op byteniveau blind voor is. Draai ze samen en elke ruimt op wat de ander niet kan zien.

De rekensom, in de volgorde waarin het echt gebeurt:

1. Minify alleen verkleint CSS, JS en HTML doorgaans met 20–30%, door witruimte en commentaar te verwijderen en syntaxis in te korten.
2. Gzip op de geminificeerde uitvoer verwijdert nog eens 60–80%, door de herhaalde patronen te coderen die in de tekst overblijven.
3. Brotli in plaats van gzip levert uitvoer op die nog eens 15–25% kleiner is, dankzij een groter ingebouwd woordenboek en een beter algoritme.

De conclusie in één regel: minificeer eerst, comprimeer dan. Het gecombineerde resultaat is vaak 80–90% kleiner dan de oorspronkelijke broncode, en wie een van beide overslaat laat bytes liggen.

Waarom trekt minificatie nog steeds zijn gewicht bovenop Brotli? Drie redenen:

1. Kleinere invoer comprimeert kleiner. Een geminificeerd bestand geeft de compressor minder redundant materiaal om door te kauwen, en een kleinere, schonere invoer levert doorgaans een kleinere uitvoer op.
2. Minify doet dingen die compressie niet kan. Dead-code elimination en korte variabelenamen zijn semantische verwijderingen. Gzip begrijpt je code niet en ziet alleen bytes, dus het kan nooit een ongebruikte functie verwijderen of een variabele hernoemen.
3. De browser parset minder bytes. Na decompressie ontvangt de browser de geminificeerde code. Minder code betekent sneller parsen en uitvoeren, niet alleen een kleinere download.

De volgorde is geen keuze; ze volgt uit waar elke stap thuishoort. Minificatie hoort bij buildtijd (jij of je buildtool doet het één keer). Compressie hoort bij transporttijd (de server doet het per verzoek, de browser decomprimeert bij aankomst). De pijplijn is dus van nature minify → deployen → server comprimeert. Je kunt het niet andersom draaien: er is geen manier om “te comprimeren en daarna te minificeren”, want de gecomprimeerde uitvoer is geen broncode meer.

Er is een kleine maar belangrijke kanttekening bij “eerst minify, dan comprimeren”: zodra inhoud al gecomprimeerd is, is het nog eens comprimeren zinloos of zelfs contraproductief. Al-binaire assets met hoge entropie, zoals JPEG’s, PNG’s, WebP en fonts in WOFF2, winnen niets bij gzip of Brotli en horen helemaal niet in je tekstcompressieregels thuis. Minificatie is een transformatie die alleen op tekst werkt, dus die raakt die bestanden nooit aan; bij compressie moet je selectief zijn. Configureer je server om tekst-MIME-types (HTML, CSS, JS, JSON, SVG) te comprimeren en laat de al-gecomprimeerde binaire bestanden met rust.

Het configureren van de transportlaag (Brotli inschakelen, Content-Encoding instellen) is een ops-zaak die je server of CDN afhandelt. Deze gids blijft op de bronlaag, waar minificatie gebeurt. Optimaliseer je je payload breder, dan geldt dezelfde gedachte van “bytes besparen op de coderingslaag” ook voor afbeeldingen; onze gids voor beeldformaten behandelt de WebP/AVIF/JPEG-kant van dat verhaal.

Wanneer je niet met de hand hoeft te minificeren

Hier is een waarheid die veel marketing rond minifiers overslaat: als je een buildstap hebt, is je productie-uitvoer al geminificeerd. Moderne build-pijplijnen doen het automatisch.

Vite en esbuild minificeren JavaScript en CSS standaard. Rollup en webpack doen het via TerserPlugin en CssMinimizerPlugin. Lightning CSS verwerkt CSS op native snelheid. Next.js, Astro en vergelijkbare frameworks minificeren, tree-shaken en splitsen chunks in hun productiebuilds zonder dat jij een vinger uitsteekt. Het commando is meestal niets meer dan vite build of npm run build; minificatie is onderdeel van wat “bouwen voor productie” betekent, geen aparte stap die je erbovenop schroeft. Past dat bij je project, dan is een bestand achteraf door een aparte minifier halen op zijn best overbodig en op zijn slechtst schadelijk: al-geminificeerde code dubbel manglen kan verwarrende uitvoer opleveren en bespaart geen noemenswaardige extra bytes.

Buildtools doen ook iets wat een losse minifier niet kan: ze minificeren in de context van je hele dependency-graph. Tree-shaking werkt in het bijzonder alleen wanneer de bundler elke import en export kan zien en kan bewijzen dat een bepaalde functie nooit gebruikt wordt. Een minifier voor één bestand heeft geen graph om over te redeneren; hij kan dode code binnen het bestand dat je geeft weggooien, maar kan niet zien dat een hele geïmporteerde module onbereikbaar is. Dat is nog een reden waarom de build-pijplijn de juiste thuisbasis is voor productieminificatie.

Wanneer is een losse minifier dan wél de juiste tool? In de eerlijke verzameling gevallen waarin geen buildstap het voor je doet:

• Statische sites en met de hand geschreven pagina’s met één bestand zonder bundler in de keten.
• E-mail-HTML-templates, waar veel systemen per byte rekenen en er helemaal geen build-pijplijn is.
• Snippets van derden en widgetcode die je in de pagina van iemand anders inbedt.
• Snelle groottecontroles: plak een blok, zie hoe groot het wordt na minificeren en hoeveel je bespaarde. Daar is de uitlezing van de bytebesparing voor.
• Andermans geminificeerde code lezen, waarbij je de formatter in omgekeerde richting draait om het weer leesbaar te maken.

De beslissing is simpel. Heb je een build? Laat de build minificeren. Geen build, eenmalig, of even een grootte checken? Een online tool is de snelste weg, en omdat deze tools volledig in je browser draaien, verlaat je code nooit je apparaat. Dat doet ertoe voor propriëtaire of onuitgebrachte code, die je nooit in een server-side formatter zou moeten plakken die een kopie van alles ontvangt. Het is hetzelfde privacy-argument dat door onze SQL-stijlgids loopt, de andere formatteer-verdieping in dit cluster.

Source maps: geminificeerde code debuggen

Geminificeerde code is op zichzelf een debug-nachtmerrie. Zodra Terser elke lokale variabele heeft hernoemd naar a, b en c, vertelt een productie-stacktrace die naar bundle.min.js:1:48211 wijst je in wezen niets over wat er echt misging.

Source maps lossen dit op. Een source map is een .map-bestand dat de mapping vastlegt tussen elke positie in de geminificeerde uitvoer en de overeenkomstige positie in je oorspronkelijke broncode. Wanneer de DevTools van de browser hem laden, vertalen ze geminificeerde fouten terug naar echte bestandsnamen, regelnummers en variabelenamen. Je debugt tegen de code die je schreef, ook al draait de browser de code die je build produceerde.

In de praktijk genereert je buildtool de source map naast de geminificeerde bundle, en wijst een commentaar //# sourceMappingURL=bundle.min.js.map (of een HTTP-header) de browser naar de .map. Open DevTools, loop tegen een fout aan, en de stacktrace toont je echte bestandsnamen en regelnummers in plaats van de geminificeerde brij. De map wordt lui geladen, alleen wanneer DevTools openstaat, dus hij kost je bezoekers niets.

Er is een privacy-aspect dat het waard is te kennen. Een publieke source map levert in feite je oorspronkelijke broncode aan iedereen die DevTools opent. Voor open code is dat prima; voor propriëtaire code niet. Daar zijn verborgen source maps voor: de bundle draagt geen sourceMappingURL-commentaar, dus het publiek ziet de map nooit, maar je uploadt hem nog steeds naar een foutmonitoringdienst als Sentry. De dienst de-minificeert productie-stacktraces aan zijn kant en geeft je leesbare fouten zonder je broncode aan de wereld bloot te stellen.

Merk op hoe dit het eerdere punt versterkt: source maps zijn een capaciteit van de buildtool. Een gewone online minifier produceert er meestal geen, omdat eenmalige compressie het niet nodig heeft. Dat is nog een reden om je build de productieminificatie te laten afhandelen, want het geeft je de map gratis. En onthoud dat een source map de geminificeerde bundle zelf nooit verandert; het is een pure debug-hulp die ernaast ligt. Verwar de .map niet met een productieafhankelijkheid.

Veelgestelde vragen

Is minificatie hetzelfde als compressie?

Nee. Minificatie herschrijft je broncode (witruimte en commentaar strippen, namen inkorten) zodat het geldige code blijft, alleen kleiner. Compressie (gzip, Brotli) codeert de resulterende bytes voor transport, en de browser decodeert ze. Ze pakken verschillende redundantie aan, werken in verschillende fases, en stapelen: eerst minificeren, dan comprimeren.

Moet ik minificeren als ik gzip of Brotli gebruik?

Ja. Minificatie blijft van belang met gzip en Brotli. Geminificeerde code geeft de compressor minder redundante invoer, dus comprimeert ze kleiner, en minify doet semantische verwijderingen (dode code, korte variabelenamen) die compressie op byteniveau niet kan. De browser parset ook minder bytes. Gebruik beide, in die volgorde.

Breekt minificeren mijn code?

Een correcte minifier behoudt het gedrag: CSS rendert identiek, en Terser houdt JavaScript equivalent. De uitvoer draait hetzelfde als de broncode. Twee waarschuwingen: JavaScript dat leunt op automatic semicolon insertion heeft geldige syntaxis nodig, en witruimtegevoelige HTML zoals <pre> of <textarea> moet je na het minificeren verifiëren.

Wat is het verschil tussen minify en uglify?

Ze betekenen praktisch hetzelfde voor JavaScript. “Uglify” komt van UglifyJS, een vroege populaire JS-minifier; Terser is de moderne fork ervan die de huidige syntaxis ondersteunt. Tegenwoordig zeggen mensen “minify” in het algemeen over CSS, JS en HTML, terwijl “uglify” een oudere, JS-specifieke naam is voor hetzelfde proces.

Moet ik minificeren tijdens ontwikkeling?

Nee. Minificeer productiebuilds, niet ontwikkeling. Geminificeerde code is onleesbaar en moeilijk te debuggen, dus je wilt volledige, geformatteerde broncode tijdens het ontwikkelen. Je buildtool (Vite, esbuild, webpack) minificeert automatisch wanneer je voor productie bouwt, vaak met source maps zodat je de gedeployde bundle nog kunt debuggen.

Hoeveel verkleint minificatie de bestandsgrootte?

Minificatie alleen verkleint CSS, JS en HTML doorgaans met ongeveer 20–30%, vooral door witruimte en commentaar te verwijderen en namen in te korten. Gelaagd met gzip of Brotli erbovenop is het gecombineerde resultaat vaak 80–90% kleiner dan de oorspronkelijke broncode. Het exacte cijfer hangt af van hoeveel witruimte en redundantie het bestand had.