Minification typically takes JavaScript to something like half its source size, and Brotli then takes that to a quarter again. Those are real savings, but they are multiplicative on whatever you send — and the largest number in that equation is code you did not need. Code-splitting a 300 KB dependency out of the initial bundle beats every minifier setting combined. Minify last, after you have decided what actually needs to load.
Teams celebrate a bundle going from 480 KB to 310 KB and never check the compressed transfer size, which is what users download. Compare gzip and Brotli sizes before and after a minifier change: some transformations that shrink the raw file — aggressive identifier reuse, string inlining — make the output less compressible and end up neutral or worse over the wire.
Anything that resolves behaviour by identifier name breaks when PaymentService becomes e: older dependency-injection syntax, class names used as registry or serialisation keys, and any code reading Function.prototype.toString(). The fix is to remove the name dependency. If you cannot, set keep_fnames and keep_classnames and write down why, because the next person will try to remove them.
If you publish a package, minifying before publication is usually wrong. It prevents your consumers' bundlers from tree-shaking your exports, breaks their source maps, and hides your code from their debugger for no benefit — they will minify it themselves anyway. Publish readable ESM with source maps and let the application build do the compression.
Without maps, every production error is t is not a function at line 1, column 48120. Generate them, upload them to your error tracker at deploy time, and do not serve them publicly. This costs a build step and turns your error dashboard from noise into something actionable.
Removing "unused" exports depends on the bundler correctly believing a module has no side effects. A "sideEffects": false that is not actually true silently deletes polyfills, custom element registrations and CSS imports — and the failure shows up only in the production build. List the real exceptions instead: "sideEffects": ["*.css", "./src/register.js"].
Terser's unsafe family assumes built-in prototypes are unmodified, that typeof comparisons can be rewritten, and that Math functions are the real ones. Those assumptions are usually correct and occasionally catastrophic, and when they fail the code does not throw — it computes something slightly different. The byte saving is a rounding error next to that risk.
Run your end-to-end tests against the production bundle, not the development one, at least on every release branch. Nearly every mistake here produces code that works perfectly in npm run dev and fails only after minification, which is exactly the build most teams never test.