Benchmarks · compare the work as well as the clock
Current JavaScript comparisons use same-run controls.
Speed and compression are separate dimensions. Minify++ now publishes three JavaScript policies—default, structured and aggressive—and its benchmark process treats post-validation and runner drift as first-class data.
The JavaScript result comes from the upstream privatenumber/minification-benchmarks suite over 12 real package artifacts. Every Minify++ refresh also reruns OXC, SWC, esbuild and Terser in the same job so a faster or slower runner is visible instead of being mistaken for a product regression.
Current JavaScript acceptance gate
The current performance-certified checkpoint passes 36 / 36 Minify++ real-bundle validations. That requirement is non-negotiable: a faster result that fails post-validation is rejected.
What the same-run comparison says
Minify++ default is the latency-oriented path and is competitive with the fastest native competitors on several large artifacts. Structured spends additional time on scope/reference analysis and binding renaming; on several large inputs it sits in roughly SWC-class territory. Aggressive spends much more CPU for compression, but remains materially faster than Terser on the large fixtures where both complete in the current suite.
The recent profile-driven campaign improved Minify++ relative to its preceding same-run-controlled checkpoint. Normalizing each fixture against the movement of OXC, SWC, esbuild and Terser, median throughput improved by about 11.6% default, 12.0% structured and 20.1% aggressive. The normalization matters because the GitHub runner itself moved substantially between historical executions.
Why old milliseconds are no longer compared directly
The exact same Minify++ production revision, 9ba9b4f, was benchmarked twice in different runner epochs and appeared roughly 15–24% slower in the later run despite identical production source. That demonstrated that absolute historical hosted-runner timings are not a reliable regression oracle by themselves.
A benchmark table can look same-host while containing cached competitor values from an earlier runner. Current performance decisions therefore require same-run controls or old/new Minify++ binaries in one job.
Representative performance work
Profiling large bundles found time concentrated in concrete syntax construction, binding/parameter renaming, scope graph construction, reference resolution and semantic-fact construction. The retained changes reduced allocation growth, indexed scope redeclarations, propagated function ownership once, skipped unused structured-mode semantic facts and stopped rebuilding a successful rename plan in later aggressive rounds.
Equally important, two plausible shortcuts were rejected: a broad lexical-resolution cache did not produce stable end-to-end gains, and a class-ancestry shortcut failed an existing self-referential-class semantic regression. Neither stayed in production.
Historical CSS comparison
The August 2026 CSS CLI comparison remains useful as a pinned historical snapshot rather than a current cross-tool leaderboard. On its stated i7-12700H host, fresh-process Minify++ CLI latency was lower than the measured esbuild and Lightning CSS invocations on Bootstrap 4, Animate.css and Tailwind CSS, while Lightning CSS produced smaller CSS output. That result illustrates the product trade-off: Minify++ performs a narrower conservative job.
| Fixture | Minify++ | esbuild | Lightning CSS |
|---|---|---|---|
| Bootstrap 4 | 2.797 ms | 19.406 ms | 9.964 ms |
| Animate.css | 1.953 ms | 9.853 ms | 4.396 ms |
| Tailwind CSS | 13.274 ms | 121.299 ms | 73.257 ms |
The raw historical CSS samples remain in the Minify++ repository under benchmarks/results/. They should not be merged numerically with the current JavaScript runner.
Reproducibility
# internal format regression gate
make benchmark
# stage/profile harness
make profile-js FILES="bundle.js" RUNS=7The external benchmark repository owns the 12-artifact competitor run. Keep the Minify++ commit, competitor revisions, runner identity, validation status and raw samples together when publishing a result.