Minify Before Deploy — Checklist That Stops 5KB Debates
Every few months someone argues that minifying “doesn’t matter anymore” because HTTP/2 multiplexes and Brotli is strong. Then a marketing page ships 800KB of commented CSS and a 2MB JS bundle with source maps dangling in production. Minify is not a religion — it is one line on a deploy checklist that stops preventable waste.
The order that actually works
- Build — transpile, tree-shake, code-split.
- Minify — CSS and JS (and SVG when relevant).
- Compress on the wire — Brotli or gzip at CDN/origin.
- Cache — long-cache hashed filenames; short-cache HTML.
- Measure — slow 3G or a throttled profile, not only office fiber.
Skipping step 2 because step 3 exists is like refusing to vacuum because you own a mop.
What minify changes vs what it does not
| Concern | Minify | Brotli/gzip | Tree-shaking |
|---|---|---|---|
| Whitespace/comments | Yes | Helps a bit | No |
| Dead exports | No | No | Yes |
| Image weight | No | No | No |
| Secret safety | No | No | No |
Debate “5KB” in isolation is silly; debate uncached first load on mobile is not. Minify + compression + caching compound.
CSS/JS checklist before you hit production
- Production build mode enabled (
NODE_ENV=productionor equivalent) - CSS purged/unused rules removed if you use a utility framework
- JS minified; no
console-spam left if policy requires stripping - Source maps not publicly discoverable unless you intentionally publish them
- HTML references hashed assets (
app.a1b2c3.js) - CDN returns
Content-Encoding: brorgzipfor text assets -
Cache-Controlsane for HTML vs immutable static files - Critical path: hero CSS not blocked behind a huge unused bundle
For a quick local pass on a snippet or legacy file outside the bundler, minify can shrink CSS/JS in the browser so you can see the before/after size while you fix the pipeline.
How to measure so the debate ends
- Chrome DevTools → Network → disable cache → slow 3G.
- Note transferred bytes for CSS/JS (encoded), not only resource size.
- Compare a release candidate against main on the same throttle.
- Track LCP/INP on a real mid-tier phone for the template you care about.
If transferred JS drops 30% and LCP barely moves, the bottleneck may be images or server TTFB — keep minify, fix the real bottleneck next.
Anti-patterns
- Minifying by hand and committing artifacts without a reproducible build
- Double-minifying already-minified vendor files in a broken pipeline (wastes CI, rare breakage)
- Shipping both
.min.jsand full.jsand linking the wrong one - Assuming HTTP/2 prioritization replaces smaller files
HTML and SVG are part of the same story
Minifying JS/CSS while shipping indented 200KB of HTML templates or inline SVG icons with editor metadata leaves easy wins on the table. Many static-site and framework pipelines can collapse HTML whitespace safely; SVGs often shrink dramatically after stripping comments and unused IDs. Treat “text assets on the critical path” as one budget, not three unrelated silos.
Also verify you are not serving application/javascript with Cache-Control: no-store for hashed bundles — minify then fail to cache is a self-own.
Keep the checklist boring
Minify belongs next to “tests passed” and “migrations ran.” It should be automatic in CI, visible in the bundle report, and uninteresting in standup. When someone reopens the 5KB debate, paste the throttled waterfall — not a Twitter thread — and move on.