Most articles on minification stop at "you should do it." The part that actually matters — which tool, and when it's worth reaching for one at all — usually gets skipped. After building a free minification toolkit covering nine formats and fixing real edge-case bugs along the way, here's the practical answer.
Does minification still matter if you're already using a bundler?
Mostly no. If your build already goes through Vite, webpack, or esbuild, production output is minified automatically — running a separate tool on top adds a step without adding a benefit.
Where it still matters is everywhere that pipeline doesn't reach:
- Plain WordPress and PHP sites with no JS build step — most of the client work on this portfolio lives here.
- Inline
<style>/<script>blocks and CMS content editor snippets. - HTML emails — Gmail clips messages over roughly 102KB, and clipped content can hide the unsubscribe link most jurisdictions legally require.
- Embedded widgets, one-off SQL migrations, config files pasted somewhere they'll never see a build tool.
It's also worth being honest about why it helps today. Gzip and Brotli already compress away most of the whitespace savings, so minification's real remaining value isn't transfer bytes — it's parse and compile time on the client, the same budget covered in Core Web Vitals for WordPress.
Which JS and CSS minifier should you actually use?
For anything running inside a build pipeline: Terser is still the safe default — it's what most bundlers and WordPress minification plugins use under the hood. If build speed matters more than squeezing the last 1–2% out of the bundle, esbuild or SWC are dramatically faster. If output size is genuinely the priority and speed isn't, uglify-js still edges out the field, just far slower. For CSS, cssnano (or clean-css) covers the same ground. For HTML, html-minifier-terser.
The catch: these tools don't always agree on edge cases, and getting one wrong silently changes what your code does. A naive SQL minifier, for instance, will happily strip this as a comment:
SELECT * FROM orders WHERE note = 'Use code SAVE10 -- expires soon';
That -- is inside a string literal, not a comment — a minifier that doesn't track string boundaries truncates the rest of the query. I hit this exact bug (and a handful like it — an HTML minifier's internal placeholder colliding with literal user text, an XML minifier collapsing whitespace inside a text node) auditing my own toolkit before launch. The fix in every case was the same: protect string/text content before any comment-stripping or whitespace-collapsing runs. Worth remembering before trusting any minifier with production code you haven't tested it against.
What if you just need to minify one file, right now?
None of the above helps if you don't have Node.js open, or you just need to shrink a snippet before pasting it somewhere. That gap — not a lighter bundler, a zero-install one — is why I built MinifyAssets: CSS, JavaScript, HTML, JSON, XML, SQL, YAML, SVG, and Markdown, all minified entirely in the browser. Nothing gets uploaded to a server, so pasting in something you shouldn't paste into a random online tool isn't a concern — there's no server on the other end.
The compounding effect
Neither answer here is "always minify" or "never bother." It's picking the right tool for where the code actually lives: let the bundler handle what's already in the pipeline, and keep something reliable on hand for what isn't. That's the habit that actually shows up in PageSpeed scores — not a one-time pass, but not fussing over milliseconds a bundler already handles for you either.