I have slashed bundle sizes by 60% on client projects at Šikulovi s.r.o.. Here is everything I have learned about minifying JavaScript, CSS, and HTML for production.
When I first started optimizing web apps at Šikulovi s.r.o., I was amazed at how much bloat exists in production code. Code minification strips all the fluff - whitespace, newlines, comments, and those beautifully descriptive variable names - without changing how the code runs.
I have seen minification reduce file sizes by 40-60% on real projects. For one e-commerce client, that meant cutting 800KB off their main bundle. Faster loads, happier users, lower CDN costs. It is one of the easiest wins in web performance.
JavaScript minification is where I see the biggest gains. Modern minifiers like Terser do way more than remove whitespace - they actually understand your code.
I used to underestimate CSS minification until I saw a 200KB stylesheet on a client project. CSS minifiers are smarter than you might think - they understand the cascade and can optimize aggressively.
HTML minification is often overlooked, but for server-rendered apps at Šikulovi s.r.o., I find it makes a noticeable difference. Every response is smaller, every page loads faster.
I learned this lesson the hard way: never minify during development. I once spent two hours debugging a production issue because error line numbers made no sense. Now I have clear environment separation.
After trying nearly every minification tool out there, here are the ones I actually use at Šikulovi s.r.o.
I always check the numbers before and after minification. On one recent Sikulovi project, we went from 2.1MB to 780KB - a 63% reduction. The client was thrilled.
In my experience, well-commented code with descriptive variable names sees the largest reductions. Ironic that good coding practices lead to bigger savings.
No, and I get this question all the time. Minification does not change runtime performance at all - the code executes identically. What you gain is faster download times because files are smaller. I have never seen a case where minified code ran differently than the original.
It can if you are doing weird things with eval() or relying on function.name. I had this bite me once when a library used reflection. Properly written code works identically after minification. If something breaks, check for dynamic property access with strings.
Most libraries ship minified already - look for .min.js files. I never re-minify those. What I do instead is let my bundler handle everything together, which enables better tree shaking.
Source maps are your best friend here. I always generate them in CI and upload to Sentry. They map minified code back to original source, so you can debug in DevTools as if using the original files. Just keep them private - do not deploy publicly.
Founder of CodeUtil. Web developer building tools I actually use. When I'm not coding, I experiment with productivity techniques (with mixed success).
I used to debug regex by trial and error in my code. Compile, test, fail, repeat. Now I test patterns live before writing a single line. Here's how I actually use this thing, plus the patterns I copy-paste constantly.
After years of optimizing builds at Šikulovi s.r.o., I have developed a battle-tested approach to minification. Here is my complete guide to build tool integration, source maps, and avoiding common pitfalls.
Master color models for web development. Learn RGB, HSL, HEX, and CMYK differences, when to use each format, CSS color functions, accessibility contrast ratios, and how to build effective color palettes.